Azure-devops-docs: Error "Must not run with sudo" while in step 3 - Configuring Azure Pipelines agent...

Created on 29 May 2019  Â·  17Comments  Â·  Source: MicrosoftDocs/azure-devops-docs

I've been following the steps (Windows) in this article, and while executing the docker run command, I'm getting this error message that stops the execution:

PS C:\dockeragent> docker run -e AZP_URL=<my url> -e AZP_TOKEN=<my token> -e AZP_AGENT_NAME=<my agent> -e AZP_POOL=<my pool> dockeragent:latest

  1. Determining matching Azure Pipelines agent...
  2. Downloading and installing Azure Pipelines agent...
  3. Configuring Azure Pipelines agent...
    Must not run with sudo
    PS C:\dockeragent>

Any clue on what does this mean and how to get past it?
Thanks


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

Pri1 devops-cictech devopprod doc-bug

Most helpful comment

Hi chispadelgado,

Does your start.sh file that you copied from this guide contain this line?

export AGENT_ALLOW_RUNASROOT="1"

you can also use export RUNNER_ALLOW_RUNASROOT="1"

All 17 comments

Hi chispadelgado,

Does your start.sh file that you copied from this guide contain this line?

export AGENT_ALLOW_RUNASROOT="1"

Yes. See:

#!/bin/bash
set -e

if [ -z "$AZP_URL" ]; then
  echo 1>&2 "error: missing AZP_URL environment variable"
  exit 1
fi

if [ -z "$AZP_TOKEN_FILE" ]; then
  if [ -z "$AZP_TOKEN" ]; then
    echo 1>&2 "error: missing AZP_TOKEN environment variable"
    exit 1
  fi

  AZP_TOKEN_FILE=/azp/.token
  echo -n $AZP_TOKEN > "$AZP_TOKEN_FILE"
fi

unset AZP_TOKEN

if [ -n "$AZP_WORK" ]; then
  mkdir -p "$AZP_WORK"
fi

rm -rf /azp/agent
mkdir /azp/agent
cd /azp/agent

export AGENT_ALLOW_RUNASROOT="1"

cleanup() {
  if [ -e config.sh ]; then
    print_header "Cleanup. Removing Azure Pipelines agent..."

    ./config.sh remove --unattended \
      --auth PAT \
      --token $(cat "$AZP_TOKEN_FILE")
  fi
}

print_header() {
  lightcyan='\033[1;36m'
  nocolor='\033[0m'
  echo -e "${lightcyan}$1${nocolor}"
}

# Let the agent ignore the token env variables
export VSO_AGENT_IGNORE=AZP_TOKEN,AZP_TOKEN_FILE

print_header "1. Determining matching Azure Pipelines agent..."

AZP_AGENT_RESPONSE=$(curl -LsS \
  -u user:$(cat "$AZP_TOKEN_FILE") \
  -H 'Accept:application/json;api-version=3.0-preview' \
  "$AZP_URL/_apis/distributedtask/packages/agent?platform=linux-x64")

if echo "$AZP_AGENT_RESPONSE" | jq . >/dev/null 2>&1; then
  AZP_AGENTPACKAGE_URL=$(echo "$AZP_AGENT_RESPONSE" \
    | jq -r '.value | map([.version.major,.version.minor,.version.patch,.downloadUrl]) | sort | .[length-1] | .[3]')
fi

if [ -z "$AZP_AGENTPACKAGE_URL" -o "$AZP_AGENTPACKAGE_URL" == "null" ]; then
  echo 1>&2 "error: could not determine a matching Azure Pipelines agent - check that account '$AZP_URL' is correct and the token is valid for that account"
  exit 1
fi

print_header "2. Downloading and installing Azure Pipelines agent..."

curl -LsS $AZP_AGENTPACKAGE_URL | tar -xz & wait $!

source ./env.sh

trap 'cleanup; exit 130' INT
trap 'cleanup; exit 143' TERM

print_header "3. Configuring Azure Pipelines agent..."

./config.sh --unattended \
  --agent "${AZP_AGENT_NAME:-$(hostname)}" \
  --url "$AZP_URL" \
  --auth PAT \
  --token $(cat "$AZP_TOKEN_FILE") \
  --pool "${AZP_POOL:-Default}" \
  --work "${AZP_WORK:-_work}" \
  --replace \
  --acceptTeeEula & wait $!

print_header "4. Running Azure Pipelines agent..."

# `exec` the node runtime so it's aware of TERM and INT signals
# AgentService.js understands how to handle agent self-update and restart
exec ./externals/node10/bin/node ./bin/AgentService.js interactive

Interesting. For some reason, the export line that sets up the Ubuntu container to be able to run as root is not being functioning as it's supposed to.

This is the check that config.sh does to detect if the agent is running as root:
https://github.com/microsoft/azure-pipelines-agent/blob/3e0e6dd0111fa53e72e42e4cf14f94ac379cba5a/src/Misc/layoutroot/config.sh

I'm not able to repro this issue on my Windows machine with the same script (i.e. the agent can be configured successfully), so my advice to you is to update to the latest version of Docker for Windows. Mine is Docker Desktop Community, version 2.0.0.3 and came from the stable channel.

Same docker version as mine.

Could this have something to do with the fact that I'm behind a corporate network proxy?

I set the proxy in the Dockerfile, and I'm able to run the apt-get updates/install, no problem on that. No sure if this can have an impact on the agent, though.

FROM ubuntu:16.04

# To make it easier for build and release pipelines to run apt-get,
# configure apt to not require confirmation (assume the -y argument by default)
ENV DEBIAN_FRONTEND=noninteractive
RUN echo "APT::Get::Assume-Yes \"true\";" > /etc/apt/apt.conf.d/90assumeyes

ENV http_proxy 'http://<<<username>>>:<<<password>>>@<<<proxyUrl>>>:80'
ENV https_proxy 'http://<<<username>>>:<<<password>>>@<<<proxyUrl>>>:80'

RUN echo "Acquire::http::Proxy \"http://<<<username>>>:<<<password>>>@<<<proxyUrl>>>:80\"; Acquire::https::Proxy \"http://<<<username>>>:<<<password>>>@<<<proxyUrl>>>:80\";" > /etc/apt/apt.conf.d/proxy.conf

RUN apt-get update \
&& apt-get install -y --no-install-recommends \
        ca-certificates \
        curl \
        jq \
        git \
        iputils-ping \
        libcurl3 \
        libicu55

WORKDIR /azp

COPY ./start.sh .
RUN chmod +x start.sh

CMD ["./start.sh"]

Besides that, I attempted to set the proxy when calling the config.sh (inside start.sh file), but no luck:

./config.sh --unattended \
  --proxyurl http://<<<proxyUrl>>>:80 \
  --proxyusername "<<<username>>>" \
  --proxypassword "<<<password>>>"\
  --agent "${AZP_AGENT_NAME:-$(hostname)}" \
  --url "$AZP_URL" \
  --auth PAT \
  --token $(cat "$AZP_TOKEN_FILE") \
  --pool "${AZP_POOL:-Default}" \
  --work "${AZP_WORK:-_work}" \
  --replace \
  --acceptTeeEula & wait $!

Odd. I don't believe the extra network proxy configuration should interfere with the script setting the environment variable to direct the agent to run as root.

By the way, I updated the docs to set up an agent in a Windows container for Windows hosts. You might have more luck with those new instructions.

I have run into the same problem trying to configure a docker agent in Linux - turns out the URL returned by the TFS Api call (to download the appropriate tar.gz to unpack and configure the agent) contains a package that does not have the check for AGENT_ALLOW_RUNASROOT (config.sh once it is unpacked)
so where it should be:
if [ $user_id -eq 0 -a -z "$AGENT_ALLOW_RUNASROOT" ]; then
is in fact:
if [ $user_id -eq 0 ]; then

and hence the 'Must not run with sudo' message is seen.

This is for the following package:
https://vstsagentpackage.azureedge.net/agent/2.136.1/vsts-agent-linux-x64-2.136.1.tar.gz
which is returned when calling:
https://MY_TFS_v2018.3.2/_apis/distributedtask/packages/agent?platform=linux-x64

I'm seeing if I can get any further by downloading a later version of the package (hard coding the curl call into your script) to see if I can get this working

ok that seems to work - only other thing to note is the call at the end of start.sh

exec ./externals/node10/bin/node ./bin/AgentService.js interactive

should be

exec ./externals/node/bin/node ./bin/AgentService.js interactive

not sure that running a later agent (version wise) than TFS 2018.3.2 knows about is a sensible idea

Which line have you hard-coded the url?

On this one?

AZP_AGENT_RESPONSE=$(curl -LsS \
  -u user:$(cat "$AZP_TOKEN_FILE") \
  -H 'Accept:application/json;api-version=3.0-preview' \
  "$AZP_URL/_apis/distributedtask/packages/agent?platform=linux-x64")

And which version have you used?

Thanks!

Up to you and it depends what you're trying to do - you can leave that line alone or you could remove the api call if you wanted but it doesn't hurt (for me at the moment) and I'd like this to work when we upgrade to TFS 2019 (which does return a newer package). So I've left that alone and just changed this:

# BJ - hard code this to a version that actually looks for the env var set in this script - the version returned from TFS 2018 api does not do this!
#curl -LsS $AZP_AGENTPACKAGE_URL | tar -xz & wait $!
# BJ use hacked package - test out git versions 
#curl -LsS https://vstsagentpackage.azureedge.net/agent/2.141.1/vsts-agent-linux-x64-2.141.1.tar.gz | tar -xz & wait $!
curl -LsS http://10.1.1.2:81/vsts-agent-linux-x64-2.136.1_BenHack.tar.gz | tar -xz & wait $!

I basically tried to download a newer agent package (which has the correct check in config.sh):
https://vstsagentpackage.azureedge.net/agent/2.141.1/vsts-agent-linux-x64-2.141.1.tar.gz
...but this is for Prod TFS 2018 and I don't think this agent version is officially supported (I might be wrong) so I took this package:
https://vstsagentpackage.azureedge.net/agent/2.136.1/vsts-agent-linux-x64-2.136.1.tar.gz and added the missing check in config.sh then repackaged it and I just host it on the docker host machine and download it from there instead. I'm building a pipeline for agents and this is one option so this isn't quite for production yet - I guess you could just add that line in from the script after it has been downloaded and unpacked from MS.

I had to do a couple of other things to get this working - also my test build is complaining that git is out of date on the Linux agent in docker so I've got a few more things to do to get this working properly. I've just created a GitHub account to comment here from my work email so happy to share something if I can tidy this up some more.

@nextbenjy, @chispadelgado: aah, you're running TFS -- that was the piece I was missing. I should've asked that question first 😄. TFS releases are "anchored" to the latest agent version at that point in time, so that's why you're getting an older version package from the endpoint.

BTW, you can just use the latest version of the agent package for your TFS instance -- we support back-compat for TFS 2018 servers. It also has a couple of fixes that will make the agent run better in Docker.

https://github.com/microsoft/azure-pipelines-agent/releases

Yes using TFS 😄

Thanks for the tip - I will try out with a later version of the agent if it's backwards compatible

Sounds good, @nextbenjy.

I'll go ahead and close this issue, as this issue is now well understood.

Actually, I don't think I can personally close the issue (I don't see any option in the UI). @andyjlewis, do I need a special permission? Or do you want to close this issue for me?

Thanks @nextbenjy and @juliobbv.

Yes, it is TFS. I got past that error now by pointing to a newer version.

Not sure if I can use this thread to ask this, but, I was only able to connect to the agent by changing the AUTH mode to Negotiate and adding my username/password when calling config.sh. Any time I try to connect via PAT (and I've got a valid token), I get this error message:

  1. Determining matching Azure Pipelines agent...
  2. Downloading and installing Azure Pipelines agent...
  3. Configuring Azure Pipelines agent...

End User License Agreements:

Building sources from a TFVC repository requires accepting the Team Explorer Everywhere End User License Agreement. This step is not required for building sources from Git repositories.

A copy of the Team Explorer Everywhere license agreement can be found at:
/azp/agent/externals/tee/license.html

Connect:

Basic authentication requires a secure connection to the server.

Have you experienced something like this? What could be the issue (btw, TFS url is http)?

@chispadelgado I am sorry for this great delay in responding to the latest question in the thread, it sounds like a bug and if you haven't already I would file an issue in one (or both) of these two places:

https://github.com/microsoft/azure-pipelines-agent/issues/
https://developercommunity.visualstudio.com/spaces/21/index.html

Hi chispadelgado,

Does your start.sh file that you copied from this guide contain this line?

export AGENT_ALLOW_RUNASROOT="1"

you can also use export RUNNER_ALLOW_RUNASROOT="1"

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kieronlanning picture kieronlanning  Â·  3Comments

sevaa picture sevaa  Â·  3Comments

MJECloud picture MJECloud  Â·  3Comments

adnanebrahimi picture adnanebrahimi  Â·  3Comments

robinmanuelthiel picture robinmanuelthiel  Â·  3Comments