After several weeks of coding and testing, I have finally upgraded the AAC-base installers to support not just the official Microsoft PowerShell repos and VMware PowerCLI 10, but also Debian-based Linux releases. These are significant updates. But what are the AAC-base installers?
The AAC-base installers are tools used, not only to install my own GitHub repository tools, such as LinuxVSM, but also to initially set up or create the base for my Linux systems. I was asked to ensure LinuxVSM worked on Debian which was the start to this effort. These installers do not install an operating system, but add functionality to a minimal install of an operating system.
The installers could also be used to create Docker images of my tools. I do not use them this way, but I have created the images. The reason I do not distribute the Docker images is that they are not small, and they end up requiring things to be installed by the enduser due to license agreements. But Docker aside, the installers are designed to update, install, and auto-configure the tools as generically as possible.
The installers currently cover the following tools:
- DNScrypt 2.x using 1.1.1.1 with DNS over HTTPS (DoH)
- VMware OVF Tool w/my OVF Import tool
- VMware PowerCLI 10 w/Microsoft PowerShell
- VMware vSphere CLI
- A new version of VMware Management Assistant with PowerCLI, vSphere CLI, LinuxVSM, and OVF Tool
- Puppet agent and related tools
- Linux VMware Software Manager
- SecureESX (a for fee product)
In essence, these installers create ready to use tools while obeying the license requirements of the products. If things need to be downloaded by the end user, that is automated during install. Could these installers be part of something like Ansible Playbooks, Puppet, etc. Of course. They are simple shell scripts.
What makes these installers unique, I think, is that they work off Minimal installs of Linux, make no assumptions about what will be installed, and work within secure environments that make use of SELinux. Yes, these tools work while SELinux in Enforcing mode; the mode tools should run within.
The update of PowerShell and PowerCLI was a long time coming. Up until recently the installer would not support the official Microsoft repo or the latest PowerCLI. Originally, PowerNSX was part of the install as well, but since that fling has not been updated, it lacks support and was dropped from consideration. Once it does support the latest PowerShell core for Linux I will add it back in.
The installer setups the proper variables and changes the colors so that black on white is supported out of the box. While I use black on white, I know others do not, but I have always found yellow on white hard to read, so this change had to be made in an automated fashion.
The installers not only account for missing packages and SELinux but also allow the same tool to be used to update the installs. Yes, same code for updates. Which meant all the necessary protections have to be in the scripts. For PowerShell, as an example, if the same version has already been installed, do not do the install. Other protections are around configuration files which do not get removed but updated during updates.
Now in most cases the installers use packages whereever possible: RPM or Debian. However, some of these tools such as PowerCLI and DNScrypt 2.x do not have such packages, so we use the mechanisms at hand to install and update.
PowerShell on Linux now provides another location to run your PowerShell or PowerCLI scripts. The operating system should not matter for the scripting language of your choice. We have now removed one more limitation.
