Azure Powershell Linux - linux

Are there any more cmdlets for Linux Azure Powershell apart from these?
Is there an official repository for Azure Powershell for Linux?
Is there a way for terminal to launch powershell on startup, not bash?
My google-fu is weak today :(

Your question is old but I'll still answer it. In hopes that you will receive my response via email, others seeking help in the future will see this, and to establish reputation on this damn site so I can actually start using it effectively.
Are there any more cmdlets for Linux Azure Powershell apart from these?
I assume you're specifically looking for Azure because of your title. AzureRM.Netcore has been released as of ~1 month ago. This supports 90% of the functionality you need to deploy to Azure.
https://www.powershellgallery.com/packages/AzureRM.Netcore/0.9.1
Unfortunately, I am finding that some older cmdlets are not supported yet though, since they are in an older module called Azure, which does not yet have a .NET Core implementation. See my recent post for more information on that.
Is there an official repository for Azure Powershell for Linux?
You can find all of that discussion on the official Powershell repository. It is cross-platform. Additionally Microsoft intends to build Powershell 6 on top of .NET Core 2.0 which was released yesterday. So it's likely that future development will heavily support Linux. This will be your best resource: https://github.com/Azure/azure-powershell
Is there a way for terminal to launch powershell on startup, not bash?
There is. But I wouldn't recommend doing that. That just sounds wrong. But I'm a pretentious Linux user with a bias towards Microsoft so take my opinion with a grain of salt. There are two methods you can use to accomplish that.
1) Most Linux distros come with a command called chsh just for that. Try chsh -s /usr/bin/powershell provide that is the location of your installed Powershell binary. If you are not sure where it is, you can use which to determine the installation location. which powershell. Do not execute this command with sudo as that will attempt to change the shell for your root user rather than your current user.
2) Alternatively you can manually edit the file /etc/passwd on Linux. Locate the line that contains your user account, go to the very end of it, and replace /bin/bash or whatever shell you use with /usr/bin/powershell, or the proper location of your Powershell Binary.

Related

Difference between Azure CLI and PowerShell

I am asking this question as Windows user but I request you not to limit the answer for windows only.
I tried executing Azure CLI commands in Power-Shell and they are executing successfully but not the other way around. In that case why do we have 2 separate command sets? Why not just work on Power-Shell? I have only tried some basic commands and they are all working except filter commands | find only works on CLI and | Select only works in Power-Shell.
I know that Azure CLI is for cross platform support. But is there any difference for Windows user? Are there any consequences to run CLI command on Power-Shell?
Thanks in advance.
Here are my opinions from using both. In no way am I saying one is better than the other. They both have their pros and cons.
Azure CLI is cross-platform command-line tool for managing Azure resources, and it can run in Windows, Mac and Linux. This also means it can run on Windows PowerShell. Its more flexible than Azure PowerShell since its a binary and can run inside any OS default shell.
Are there any consequences to run CLI command on Power-Shell?
Updating can be a bit of a pain. If you want to update it on Windows you have to re-install the MSI with the instructions from Install Azure CLI on Windows. Updating is easier on other platforms, and makes me only want to only use Azure PowerShell on Windows PowerShell. A work around is to use WSL on Windows, then you can run Azure CLI on Linux inside a Windows machine. You can install WSL at Windows Subsystem for Linux Installation Guide for Windows 10. I find updating the azure-cli package much easier on Linux using apt-get than the Windows equivalent. You can have a look at Install Azure CLI with apt on how to install the Azure CLI package on Linux.
Another difference is that you have to chain multiple commands with Azure CLI, such as az group list vs Get-AzResourceGroup from Azure PowerShell. You also can't run Get-Help with Azure CLI commands like you do with Azure PowerShell, which is a huge game changer for me, since I find the PowerShell help system to be very helpful displaying in-depth information about PowerShell Cmdlets. The Azure CLI help info is found with az --help, but is not as comprehensive as Get-Help.
Tab completion also doesn't work in Azure CLI when using Windows PowerShell. This makes typing a bit of a pain as well, another reason I use WSL inside of Windows. You can have a look at the other alternatives at this Autocompletion support in Windows command line GitHub issue.
Azure PowerShell on the other hand is a set of PowerShell Cmdlets for managing Azure resources from the command-line, and only works in Windows PowerShell and PowerShell Core. This also means that if another OS such as Mac or Linux is running PowerShell Core, then it can run Azure PowerShell as well.
I have only tried some basic commands and they are all working except filter commands | find only works on CLI and | Select only works in Power-Shell.
Select-Object or the shorthand Select is a PowerShell Cmdlet, so it only works on PowerShell objects. find can search a string or text file. Furthermore, if you are searching for data from Azure CLI, you should use the --query parameter instead of find, since find is limited to searching strings inside text. Azure CLI uses the JMESPath query language to search for data inside the JSON output you receive. If your comfortable with this query language then searching for data using Azure CLI shouldn't be too much of an issue. Additionally, you can also use Azure CLI commands inside PowerShell scripts, but not vice-versa.
Summary
If you deal with multiple platforms or want to write scripts with others that use different platforms, using Azure CLI is a good choice. However, if you mainly deal with Windows systems and work with others who do so as well, then using Azure PowerShell is a good idea. If your like me and have to use different platforms, then installing both is a good idea. If you still just want to use Azure PowerShell on different OS platforms, then you need PowerShell Core.
For simple tasks, like quickly looking up resources in cloud shell or writing quick scripts, Azure CLI is good to use and less verbose than Azure PowerShell. If you already use bash a lot, this will feel more natural, and adding Azure CLI commands to existing scripts will be a simple task. As others have also said, there is nothing stopping you from adding Azure CLI commands to powershell scripts, which allows you to deserialize the JSON output using ConvertFrom-Json into a PSCustomObject.
For more complex tasks, Azure PowerShell is preferable, since working with .NET objects/OOP principals is much easier than parsing the JSON text given from Azure CLI. This is one reason I try to use Azure PowerShell when I can.
Azure CLI does benefit from being idempotent, so running the same command against the resources won't require any null checking like in Azure PowerShell. If this becomes an issue, then you can run ARM templates in Azure PowerShell, which are idempotent.
Update
As #AimusSage helpfully pointed out in the comments, PowerShell 7.0 has recently been released, replacing the name PowerShell Core or PowerShell 6.x. You can read more at Announcing PowerShell 7.0.
Another Idea
If you want to maintain OOP principals from Azure PowerShell, but use something that is easier for Linux Sys Admins to use, then you can consider using the Azure SDK for Python. I have used this in the past when I wanted to run scripts in a Linux host, but didn't want to use Azure CLI or install PowerShell.
I like the previous answers, I just want to add a different point of view for people in the enterprise world that is forced to pick one:
In that case why do we have 2 separate command sets? Why not just work on Power-Shell?
Rephrasing: Both Az CLI and Az PowerShell just call the same set of APIs, the Azure APIs.
This is important because theoretically and eventually you will be able to do everything in both ways
So why did Microsoft creates and maintains two ways of doing the same thing?
Martin Fowler ones said: but remember, the skill of the team will outweigh any monolith/microservice choice
If you change the monolith/microservice by PowerShell/Bash then this answers the question.
I believe that there are people with decades of development of systems using Bash, and there are other teams that are heavy users of PowerShell. Microsoft does not want them to have to learn a whole new programming language to be able to use Azure.
Summary:
If your team is familiar with PowerShell, go with PowerShell and do as much native PowerShell stuff as possible. This way you benefit from things like error handling, OOP concepts,environment settings, parallelization, etc
If yout team are linux admins, heavy users of jenkins, with million lines of Bash to automate other things already there, and working with Bash for their entire life, go with CLI and keep consistency across all the already built tools
I've noticed when doing the MS Azure training (AZ-900 fundamentals and AZ-303 Azure Architect) is that the exercises are done in Azure CLI.
That's not to say it's better, but if you're wanting to do the exams it might be worth being familiar with it. For the record, I'm a PowerShell guy.
the existing answer is silly way of looking at this question. and misleading.
The biggest difference is that azure cli is a binary (that can run on different platforms) and Powershell is a shell that works across platforms. Azure Powershell is a bunch of Powershell modules, everything else derives from that.
find cannot work in the cli, because there is no in the cli, because its not a shell. find works perfectly fine in Powershell on Windows, because its a binary in the Windows OS, whereas select is a cmdlet in Powershell and hence it will not work in command line on Windows (or bash on Linux).
Furthermore, if you are searching for data from Azure CLI, you should
use the --query parameter instead of find
this is also debatable, JMESPath query language is overcomplicated for no particular reason and I dont know how Azure Cli is actually compatible with the official JMESPath documentation. I prefer to use Powershell to run Azure Cli commands and just parse output JSON with Powershell. Obviously, you might not be as comfortable with Powershell as I am and you might not find this convenient.
Another issue with Azure Powershell that does not seem to be the case with azure cli is the different versions. I have spent days figuring out which version of which command for which script in my pipeline needs to be what. Seriously the most ridiculous assinined

Open Excel File on Azure VM with Powershell Script Sent from Local Computer

Can someone show how I can open an Excel document and show it visually on an Azure virtual machine using a Powershell script sent from my local machine? I have already figured out how to run Powershell script on the VM through the AzureVM module but am running into the issue of Windows not allowing remote Powershell users to interact with a user interface. Notes:
I have tried PSEXEC with no luck. This may be the way to go, but I have had no luck getting it to actually work.
I am not smart, so please use the most dumbed-down terminology as possible.
My end goal is exactly that stated above - nothing more nothing less.
Riches and honor to the one who can solve this.

How do I work locally with files in my Cloud Shell profile

Either this isn't possible, or it's so simple, I am missing the trick or I am going about it the wrong way. Similar to this question.
I prefer working with VS Code and basically, I want to treat the home path in cloud CLI as a local folder, exposed to VS Code.
I have installed the following VS Code extensions:
Azure Account
Azure Storage
Azure CLI Tools
If I connect to cloud shell via VS Code (F1 > Azure:Open Bash in Cloud Shell) (as explained here) or through the Portal, I have a home directory /home/john, where I can put files. It is this area I want to connect to from my PC (via VS Code).
My first thought was that this area would be exposed in Azure Storage Explorer, however, the only thing in my cloud shell storage account is: File Shares: azclishare > .cloudconsole > acc_john.img. There is no sign of any of the files in /home/john. I'm guessing they're wrapped up in acc_john.img.
I also though about using SCP, but I can't find any reference to this either and I can't find any "connection strings" in the portal.
If anyone has any ideas, I'd be grateful if you could share...
P.S. I am using Windows 10.
It's always the same, post a question on SO then find the answer!
The full answer is here: https://learn.microsoft.com/en-us/azure/cloud-shell/persisting-shell-storage
The short answer is that Cloud Shell does map to the storage account (files), but to /usr/john/clouddrive.
In fact, there is a symlink to clouddrive in /home/john.

How to turn off Internet Explorer enhanced security settings in Azure

My site is hosted on Azure. I need to programmatically turn off Internet Explorer's default enhanced security configuration settings whenever I repave or redeploy a new box on Azure.
How do I do this?
I found this article on another site http://jetlounge.net/blogs/teched/archive/2009/10/25/fix-ie-esc-won-t-turn-off-internet-explorer-enhanced-security.aspx. It included the following command line syntax, but on my local box I couldn't find the IEHARDEN.INF file it referred to. I also don't think this solution is Azure-specific.
rundll32.exe setupapi.dll,InstallHinfSection IESoftenAdmin 128 %windir%\inf\IEHARDEN.INF
I need to turn off these default hardening settings under Azure because I have a 3rd party IE screen capture DLL that needs to execute Javascript on webpages.
I think that this approach, shaped in a Windows Azure StartupTask running in Elevated execution context will help you.
Just remember that the .bat or .cmd file you create needs to be UTF8 encoded. There used to be some issues with the batch files if they are not UTF8.
UPDATE
I decided to update the answer, because it would have been too long for a second comment. I want to first make clear that I do not intend to offend anyone and the next is just mine personal view and thoughts.
Well, I mine vision might be (is) distorted through mine prism. But, I think that these specifics has nothing to do with Windows Azure itself.
These are OS related configuration specifics and the approach would be one and the same (with some variations) regardless of a (hosting/cloud) provider. If you had to deploy your solution to a dedicated (or virtual) server, you would had to create some kind of scheduled task, or startup task to make these configuration changes. Or even interactively login to make these changes.
Since Windows Azure offers the StartUp Task, it is up to us (developers) to decide what to do and how to shape the OS according to our needs.
The OS configuration changes that one can possibly need are only limited by the total ammount of all available Windows Server 2008/R2 configuration options. I personally do not believe that these needs to be reflected in Windows Azure documentation by any means. They have their place in Windows Server documentation. It is arguable which are "commonly used", because what might be common for one, might also be "never needed" for others ...

Give webservice access to windows service

I am running a webservice on server 2008 that needs access to a windows service and I need to give access to [the user that the web service is running as] via the command line.
(sorry if my wording is terrible, hopefully the brackets helped?).
I know there is a utility available with the windows 2000 resource kit (SUBINACL.exe), but is there one available in server 08 that doesn't require downloading a resource kit?
Thanks.
For everyone else wondering how to do this...
Microsoft offers a utility available for download called Subinacl.exe that allows you to do just this.
subinacl.exe /service <serviceName> /grant=Domain\AccountName=<AccessType>
For info on the different access types and on the utility in general...
subinacl.exe /help /full

Resources