Debian 10 sobre SSH ignorando `DEBIAN_FRONTEND=noninteractive`

Question

Estoy escribiendo algunos scripts para instalar algunas cosas en un servidor que ejecuta Debian 10.

Este es el guión:

#!/usr/bin/env sh

address=$1

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

Cuando ejecuto el script pasando como parámetro "[correo electrónico protegido]"Recibo el siguiente resultado:

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: 

Tengo entendido que DEBIAN_FRONTEND=noninteractiveestá destinado a evitar que aparezcan esas advertencias. ¿Estoy entendiendo mal algo aquí?

También intenté poner los comandos en un script y ejecutar el script en lugar de los comandos. Luego intenté no usar estos documentos pero aún así no tuve suerte.

Answer 1

Esto es lo que pasa:

1. En el lado remoto, el servidor SSH genera un shell. El shell procesa su documento aquí transmitido desde el lado local.
2. DEBIAN_FRONTEND=noninteractivedefine una variable en el shell. La variable no se exporta al entorno. Será una variable de entorno sólo si ya lo es; lo más probable es que no lo sea.
3. El shell genera (o ejecuta) sudo. Solo se heredan las variables de entorno, por lo que sudono conoce su archivo DEBIAN_FRONTEND.
4. sudoengendra apt-get. Incluso si la herramienta lo supiera DEBIAN_FRONTEND, es normal que sudodesinfecte el entorno de su hijo, por lo que apt-getno lo sabría DEBIAN_FRONTENDde todos modos.

Para solucionar esto es necesario exportar la variable. En lugar de DEBIAN_FRONTEND=noninteractiveusted necesita enviar

export DEBIAN_FRONTEND=noninteractive

al shell remoto. Luego debes asegurarte sudode no ocultarlo apt-get. Vea esta pregunta:¿Cómo mantener las variables de entorno cuando se usa sudo?De una de las respuestas:

debes leer man sudoatentamente y prestar atención a la -Ebandera. […]

Aquí está la cita de la página de manual:

-E, --preserve-env
Indica a la política de seguridad que el usuario desea preservar sus variables de entorno existentes. La política de seguridad puede devolver un error si el usuario no tiene permiso para preservar el medio ambiente.

En su caso, el documento aquí será así:

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

Otra respuesta menciona una forma de especificar variables que deberían sobrevivir sin -E: env_keepen sudoersel archivo. No daré más detalles sobre esto.

Otro método más: sudopermite definir variables colocándolas entre sudoel comando real y el mismo, aunque también están sujetas a restricciones impuestas por la política de seguridad. El siguiente fragmento debería funcionar (si la política lo permite) incluso sin exportar la variable:

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

Tenga en cuenta que con el documento aquí necesita <<'EOF'evitar <<EOFla expansión de la variable en el lado local (o necesita escapar $). Esto se está volviendo complicado y la buena noticia es que no necesita la variable en el shell remoto en absoluto. En su caso, esto debería ser suficiente para definir la variable correcta para apt-get:

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

Finalmente, en caso de que la política de seguridad no le permita especificar esta variable, puede generar sudootro shell:

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

Pero espero que una política tan restrictiva le impida postularse shen sudoprimer lugar, por lo que la última orden puede no tener importancia práctica.