Previously I’ve written about Running PowerShell Core Commands in a Linux Target from Ansible . In this article, we’ll look at a similar topic, but instead the PowerShell commands will be executed directly on the local Ansible host, not on a Linux based remote target.
In my lab I’m running AWX in containers.
The cross-platform version of PowerShell is not installed by default in this deployment method of AWX, so we need to get it installed there first.
Ansible has modules shell, for executing commands against Linux targets, and win_shell for executing commands against Windows targets - typically using PowerShell. So I was curious to see if it was possible to execute commands in a Linux target using PowerShell Core and if so, how to do it.
For my test I have an Ubuntu 18.04 VM with PowerShell 7.3.5 installed:
The shell module has an executable parameter described as “Change the shell used to execute the command.
While looking to automate the installation of Jenkins I needed to get a list of installed plugins into a plugins.txt file to be used by the automated install process. It’s possible to view them in the GUI, but not get an easy export:
It’s possible to query the API to get this information:
Note: my test Jenkins server is not https, hence the need for the AllowUnencryptedAuthentication parameter
Back Story Back in January 2017 Craig and I made PowervRA available for macOS and Linux via PowerShell Core. It was always our intention to do the same thing for PowervRO and , although slightly later than we hoped, we’re finally able to do that. PowerShell Core has come a long way itself over the last year, currently in Release Candidate and soon to be GA, and I’m sure a lot of the hard work and community feedback which has gone into that has helped make the job of PowervRO supporting PowerShell Core very straightforward.
Carrying out the following in Windows PowerShell worked, but didn’t always make a lot of sense because Byte is not really an Encoding type:
If you try to run the same command in PowerShell Core you will receive the following error:
Set-Content : Cannot bind parameter ‘Encoding’. Cannot convert the “Byte” value of type “System.String” to type “System.Text.Encoding”.
This is because Byte is no longer a valid selection for the Encoding parameter:
A few months ago we had an issue logged in PowervRA where it was not possible to make a connection to the vRA appliance after it had been locked down following the VMware hardening guide. Specifically this was because SSLv3/TLSv1 (weak ciphers) had been disabled.
By default, Windows PowerShell 5.1 has the following Security Protocols available, Ssl3 and Tls - hence the above failure.
It’s possible to workaround this by adding in the security protocol required, in this case TLS 1.
When you make a change to a PowerShell Module Manifest and go to commit those changes in Git, I have observed for some time that it was not possible to see the actual changes in the file because Git was showing it as a binary file. I finally found out why this happens……
Take the following example. I’ve created a module manifest for a module Test with New-ModuleManifest:
Now I make a change to the manifest, say up the version to 1.
PowerShell v6 Alpha 17 has been released and contains an interesting change with the version parameter when applied to powershell.exe. Some discussion around it can be found here and here.
When using a Linux based shell, supplying the version parameter returns the version of the shell:
You can now do a similar thing in PowerShell Core:
Note that using $psversiontable still gives you fuller information:
This is slightly different from the pre-v6 PowerShell version on Windows where the version parameter requires an argument:
Back Story For a while Craig and I have had a number of requests regarding offering OS X and Linux support to PowervRA, particularly since in case you weren’t aware PowerShell is now available on those OSs and 3rd party modules such as PowerCLI are heading towards supporting that. We first looked at offering this support for PowervRA when the first Alpha release of PowerShell Core was shipped, however we were blocked by a couple of issues, particularly this one regarding certificate checking.