☰

Debian 10 sobre SSH ignorando `DEBIAN_FRONTEND=noninteractive`

tag-icon • tag-icon bash ssh debian
Debian 10 sobre SSH ignorando `DEBIAN_FRONTEND=noninteractive`

Estou escrevendo alguns scripts para instalar algumas coisas em um servidor rodando Debian 10.

Este é o roteiro:

#!/usr/bin/env sh

address=$1

ssh -T $address <<EOF > /dev/null
  DEBIAN_FRONTEND=noninteractive
  sudo apt-get install --assume-yes docker.io
EOF

Quando executo o script passando como parâmetro o "[e-mail protegido]"Recebo a seguinte saída:

debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:

Meu entendimento é que isso DEBIAN_FRONTEND=noninteractivevisa evitar que esses avisos apareçam. Estou entendendo mal alguma coisa aqui?

Também tentei colocar os comandos em um script e executar o script em vez dos comandos. Então tentei não usar aqui os documentos, mas ainda sem sorte.

Responder1

Isto é o que acontece:

  1. No lado remoto, o servidor SSH gera um shell. O shell processa seu documento aqui transmitido do lado local.
  2. DEBIAN_FRONTEND=noninteractivedefine uma variável no shell. A variável não é exportada para o ambiente. Será uma variável de ambiente somente se já for uma variável de ambiente; muito provavelmente não é.
  3. O shell gera (ou executa) sudo. Apenas variáveis ​​de ambiente são herdadas, então sudonão conhece o seu arquivo DEBIAN_FRONTEND.
  4. sudogera apt-get. Mesmo que a ferramenta soubesse DEBIAN_FRONTEND, é normal sudohigienizar o ambiente de seu filho, então apt-getnão saberia DEBIAN_FRONTENDmesmo.

Para lidar com isso você precisa exportar a variável. Em vez de DEBIAN_FRONTEND=noninteractivevocê precisar enviar

export DEBIAN_FRONTEND=noninteractive

para o shell remoto. Então você precisa ter certeza de que sudonão irá ocultá-lo apt-get. Veja esta pergunta:Como manter variáveis ​​de ambiente ao usar sudo?De uma das respostas:

você precisa ler man sudocom atenção e prestar atenção na -Ebandeira. […]

Aqui está a citação da página de manual:

-E, --preserve-env
Indica à política de segurança que o usuário deseja preservar suas variáveis ​​de ambiente existentes. A política de segurança poderá retornar um erro se o usuário não tiver permissão para preservar o ambiente.

No seu caso, o documento aqui será assim:

export DEBIAN_FRONTEND=noninteractive
sudo -E apt-get install --assume-yes docker.io

Outra resposta menciona uma maneira de especificar variáveis ​​que devem sobreviver sem -E: env_keepno sudoersarquivo. Não vou entrar em detalhes sobre isso.

Ainda outro método: sudopermite definir variáveis ​​colocando-as entre sudoo comando real, embora estas também estejam sujeitas a restrições impostas pela política de segurança. O trecho a seguir deve funcionar (se a política permitir) mesmo sem exportar a variável:

DEBIAN_FRONTEND=noninteractive
sudo DEBIAN_FRONTEND="$DEBIAN_FRONTEND" apt-get install --assume-yes docker.io

Observe que aqui-document você precisa, <<'EOF'em vez de <<EOF, evitar a expansão da variável no lado local (ou precisa escapar $). Isso está ficando complicado e a boa notícia é que você não precisa da variável no shell remoto. No seu caso, isso deve ser suficiente para definir a variável correta para apt-get:

sudo DEBIAN_FRONTEND=noninteractive apt-get install --assume-yes docker.io

Finalmente, caso a política de segurança não permita que você especifique esta variável, você pode gerar sudooutro shell:

sudo sh -c 'DEBIAN_FRONTEND=noninteractive apt-get install --assume-yes docker.io'

Mas espero que tal política restritiva o impeça de correr sh, sudoem primeiro lugar, portanto o último comando pode não ter importância prática.

informação relacionada