Microsoft's own documentation provides the links to the images used for various operating systems, on top of which Microsoft-hosted agents get created.
For Windows Server 2019, the link shows bash as one of the tools included, and it also mentions WSL1 (Windows Subsystem for Linux v1) as installed. And it works just as expected, with Bash tasks running just fine inside Azure DevOps pipelines.
We're currently in the process of setting up our own self-hosted Windows agents, and we're looking for this capability as well. But to my knowledge, having Linux tools such as bash working on Windows requires 1) WSL installed and 2) a Linux distribution installed per a specific user. The procedure for deploying on Windows Server is here.
WSL doesn't currently have multiple-user support (GitHub issue here) and trying to run Linux tools as LOCAL SYSTEM presents challenges of their own. So in this context, how does the image used by the Microsoft-hosted Azure DevOps agents allow them to seamlessly run bash?
I heard about Cygwin, and know that it can provide similar functionality, but for now I'm trying to get bash configured similar to how it's done on Microsoft's own hosted agents.
As of this time, however, I think it is not supported running bash in Azure DevOps self-hosted Windows agent.
The Bash task runs on the agent as the user "NT Authority \ Network Service". However, we cannot install Linux distribution for this user. It will show that the user haven't logged in.
But for Microsoft, its virtual machines should have a specific user from whom bash starts rather than the default NT Authority \ Network Service.
Related
My team has a situation where we need to run Cosmos DB emulator in WSL on our Azure DevOps self hosted VMSS agents.
In order for our ubuntu distribution to install properly, we need the agent to run in interactive mode. (WSL commands require interactive mode)
In order for Cosmos DB emulator to run, the agent needs to run in elevated mode.
We can't manually adjust every VM since this is a Virtual Machine Scale Set which will scale up and down agents automatically, but we're very willing to make more adjustments to the base image. What are some ways we can allow our agents to run the emulator on WSL given those restrictions?
We've looked in to installing our distro for all users on the machine, but that has an open issue
https://github.com/microsoft/WSL/issues/2979
We've looked in to running WSL non interactive but that's also an open feature request
https://github.com/microsoft/WSL/issues/7022
Our attempts so far to run CosmosDB Emulator on start up also haven't been successful and also seems to be an open issue
https://github.com/MicrosoftDocs/azure-docs/issues/7990
Are there any other possibilities?
We are currently using multiple self-hosted build agents with Windows 10 as the operating system. In various pipelines in Azure Devops (whether Online or OnPremis), we have not had any bad experiences or questioned the OS we chose over the many years.
Now IT approached me and asked if there was anything wrong with using Windows Server 2019/2022 as the OS for a self-hosted build agent. I guess in the long run it would be a price advantage.
But are there any other advantages or disadvantages between Windows Server 2019/2022 and Windows 10/11?
There are no other advantages or disadvantages between Windows Server 2019/2022 and Windows 10/11. Only cost... and maybe system requirements of your build/external components.
I would like to know can we install and configure the windows self hosted agent on Azure Classic Machines? I have already created in ARM machines. I don't have classic machines from my end for testing but having at my client environment. We can't create Classic machines as well now (As it has been deprecated). Before requesting my client, I just want to get some clarity this is possible in the classic machines or not ?
Before requesting my client, I just want to get some clarity this is
possible in the classic machines or not ?
Classic mode is just one deployment model, just as Lex Li commented, the types of virtual machines doesn't matter in your scenario. Only the operating system makes sense for installation of self-hosted agents.
Check prerequisites of self-hosted agent:
Windows 7, 8.1, or 10 (if using a client OS)
Windows 2008 R2 SP1 or higher (if using a server OS)
PowerShell 3.0 or higher
.NET Framework 4.6.2 or higher
Only tips above have effect on the installation and usage of windows self agents. Hope it helps to resolve your puzzle.
Currently when I run the Publish symbols task on the Ubuntu hosted agent I get the following error "The current operating system is not capable of running this task. That typically means the task was written for Windows only. For example, written for Windows Desktop PowerShell."
I have run this task successfully on a Windows Agent but what I have seen it doesn't work on Linux. The only thing that I have seen that could work on Linux is SourceLink but that doesn't work with Azure DevOps Artifacts yet.
Looking around I'm not able to see any way to publish symbols to Azure DevOps artifacts on a Linux agent? Has anybody else encountered this issue and were you able to get around it?
I have a requirement to install tools like Nagios, BigFix and other tools inside an Azure virtual machine once it gets provisioned and joined to the domain. Currently, I have written PowerShell scripts for a remote installation of these tools via Jumpbox once the VM is domain joined.
Is there any other way this can be achieved?