I would like to stop Topshelf service using cmd task in azure devops release pipeline.
What I do is create CommandLineTask which following script:
ServiceName.exe stop
As an output I see
v3.1.4 2020-06-05T10:14:20.1312163Z The ServiceName service can only
be stopped by an administrator
My question is if there is a way to run this CommandLineTask as an administrator?
PS. I use agent on my virtual machine where the service exist itself
Since you are using the self-hosted agent, you could try to use the administrator account (Local system admin) to create and run the agent.
For interactive mode self-hosted agent:
You could use the following command to create an agent with admin account.
.\config.cmd --unattended --url https://myaccount.visualstudio.com --auth pat --token myToken --pool default --agent myAgent --runAsAutoLogon --windowsLogonAccount myDomain\adminaccount --windowsLogonPassword Password
For service mode self-hosted agent:
On one hand, you could create an agent with the admin account(similar as interactive mode).
.\config.cmd --unattended --url https://myaccount.visualstudio.com --auth pat --token myToken --pool default --agent myAgent --runAsService --windowsLogonAccount myDomain\adminccount --windowsLogonPassword Password
On the other hand, you could navigate to local system -> Service and find the running agent service.
Then you could change the logon account as admin account.
Here is a doc about create agent.
Related
How to connect Linux vm using PowerShell script via pipeline. My SSH (.pem) file is stored in Library in secure file folder.
This PowerShell script I'm trying to pass the AZ CLI.
[1]: https://i.stack.imgur.com/obn2Y.png
[2]: https://i.stack.imgur.com/TrOQh.png
How to connect Azure Linux VM via Azure DevOps pipelines using
PowerShell
The answer is yes, but only support HTTP/HTTPS.
I notice you mentioned .pem file, I think you want to use powershell to connect to your linux VM via .pem file? If yes, then the answer to your question is NO.
If you are trying to use this command:
ssh -i <private key file> <user name of VM>#<VM IP address>
The pipeline will refuse to allocate Pseudo-terminal.
As you know, even you connect to linux VM via powershell, you still run bash after connect to target linux VM.
So there is another way to achieve:
Using SSH Deployment task to connect to target Azure liunx VM:
This is my YAML definition:
trigger:
- none
pool: VMAS
steps:
- task: SSH#0
inputs:
sshEndpoint: 'SSH_To_Remote_VM'
runOptions: 'inline'
inline: 'ls'
readyTimeout: '20000'
And my VM's NetWork setting:
I am trying to run a self- hosted agent in docker, I have created the dockerfile and start.ps1 files and installed the Azure DevOps Server Express Admin console. I am getting a "Basic authentication requires a secure connection to the server " when I try running the container in docker ( switched windows containers) URL: http://computername/DefaultCollection
I have also attached a screenshot of the error
can you please advise how to resolve this issue.
Docker Run error
thanks
Run a self-hosted agent in Docker
I could not reproduce this issue on my side with hosted agent windows-2019.
To test this issue, I created a folder dockeragent in my Azure repo, which including the files Dockerfile and start.ps1：
Then copy the content from the document Run a self-hosted agent in Docker to those two files.
Next, create a pipeline with an inline powershell task to create the docker image and run docker container:
cd $(System.DefaultWorkingDirectory)\dockeragent
docker build -t dockeragent:latest .
docker run -e AZP_URL=https://dev.azure.com/<YourOrganizationName> -e AZP_TOKEN=<YourPAT> -e AZP_AGENT_NAME=mydockeragent dockeragent:latest
The test result:
To make it work, please make sure the file Dockerfile and start.ps1 is correct without any change.
If above info not help you, please share the content of your Dockerfile and the steps you did.
Your are using azureDevOps without https.
Registering your PiplineAgent via PAT requires https (hence the error: "Basic authentication requires a secure connection to the server".
Try using other authentication Methoden (negotiation, which uses windows authentication)
I am trying to use the following to create a container in Azure:
New-NavContainer -accept_eula -containerName "test" -auth Windows -imageName
"mcr.microsoft.com/businesscentral/sandbox:base" -includeCSide -enableSymbolLoading -licenseFile
"licence.flf"
But it doesnt seem to allow setting the ResourceGroup in Azure:
So instead i tried using the following:
az container create --name test--image "mcr.microsoft.com/businesscentral/sandbox" --resource-
group testGroup --os-type Windows --cpu 2 --memory 3 --environment-variables ACCEPT_EULA=Y
ACCEPT_OUTDATED=Y USESSL=N --ip-address public --port 80 443 7048 7049 8080
I use the image name "mcr.microsoft.com/businesscentral/sandbox", but does that get the latest image ?
But where do i specify the LicenseFile ?
If you prefer to have your development sandbox in a container on your local machine, you must have Docker installed and working on your machine.
First, the username and password that you defined will be converted into PowerShell credential objects, and then the New-NavContainer command does all the heavy lifting to create your sandbox.
You can also immediately create a NAV Container on Azure Container Instances via the Azure CLI.
If you want to create the NAV container and uploading your Development License, you need to add this parameter in the environment variables:
-e ACCEPT_EULA=Y USESSL=N LICENSEFILE=c:\myfolder\license.flf
For more details, you could refer to this article.
I am new to devops, and I have been googling around, but I cannot find an answer to this simple question:
How do I make my Azure windows VM automatically pull all changes to local repo from master branch?
I could just schedule pull commands on the machine, but that does not seem very Devops to me. All windows guides I can find are more centered around pushing code to their other services.
So do I just manually add 'copy file' segments in the devops pipeline, for all the scripts I wish to deliver to the VM? It's the only way I see from the pipeline.
Sorry if this is too basic.
You can use SSH task and call command like cd /home/dev/<repo> && git pull
# SSH
# Run shell commands or a script on a remote machine using SSH
- task: SSH#0
inputs:
sshEndpoint:
runOptions: 'inline'
inline: cd /home/dev/<repo> && git pull
For endpoint:
The name of an SSH service connection containing connection details for the remote machine. The hostname or IP address of the remote machine, the port number, and the user name are required to create an SSH service connection.
The private key and the passphrase must be specified for authentication.
A password can be used to authenticate to remote Linux machines, but this is not supported for macOS or Windows systems.
Is it possible to run docker without elevated priv ex. (docker version).
Im trying to run a command on another machine (windows server with docker as service) with powershell invoke command but it seems as long as the docker insists on elevated priv i cannot.
So if i can get "docker verison" to work im all set.
The error i get is
docker.exe: error during connect: Post http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.39/containers/create: open //./pipe/docker_engine: Access is denied. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.
See 'C:\Program Files\Docker\docker.exe run --help
it works with an elevated powershell.
Any ideas?
This is normal - by default, a local named pipe is used for the Docker CLI to communicate with the service (aka daemon).
For development use you can configure the host machine's Docker service ("daemon") for TCP access but this is the least secure option. Just put this text in file daemon.json:
{
"hosts": ["tcp://0.0.0.0:2375"]
}
Once this is done you can connect with e.g.
docker --host tcp://1.2.3.4:2375 version
If this is for production use, you probably need to look at a container orchestration system.
A middle ground would be to useAttach-PSSession to attach to an admin PowerShell session on the remote machine. This still requires a privileged user but does work remotely.