Por que o TERM = xterm precisa ser configurado para que meu script funcione corretamente quando executado remotamente?

Question

Estou tentando automatizar a instalação de um servidor Debian (debian 6.0 squeeze 64bit).

Parte da instalação requer que o pacote Sun JRE seja instalado.

Este pacote tem um contrato de licença, que deve ser aceito. Eu tenho um script que usa as seguintes linhas para aceitar e instalar o JRE:

echo "sun-java6-bin shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections
apt-get install -y sun-java6-jre

Isso funciona bem ao executar o script localmente. No entanto, preciso executar o script remotamente usando o comando ssh, por exemplo:

ssh -i keyFile root@hostname './myScript'

Isso não funciona.

Em particular, falha em apt-get install -y sun-java6-jre . Parece que, apesar de eu definir o contrato de licença como aceito, quando executado remotamente dessa maneira, ele é ignorado.

Apesar de definir o valor como true , ainda sou solicitado a aceitar manualmente o contrato quando executo este comando:

ssh -i keyFile root@hostname 'apt-get install -y sun-java6-jre'

Eu suspeito que é algo relacionado ao ambiente que é cuidado ao executar uma sessão de terminal adequada, mas não tenho a menor idéia do que tentar em seguida para corrigi-lo.

Editar 0 : comparei a saída de env quando executada remotamente via ssh e quando executada via uma sessão de terminal local. A única diferença entre as saídas é que a sessão de terminal local tem o valor adicional TERM=xterm .

Editar 1 : Definir a variável de ambiente TERM ao chamar meu script, como este ssh -i keyFile root@hostname 'export TERM=xterm; ./myScript' , produz o comportamento correto, mas isso é apenas metade da resposta, como não sei por que você precisa configurá-lo. Uma resposta aceita para a pessoa que melhor explica o porquê!

(Eu também revisei o título da questão, de " Instalação remota com script do Sun / Oracle JRE " para "" Por que TERM = xterm precisa ser definido para o meu script funciona corretamente quando executado remotamente? "como é uma questão mais precisa)

    

Answer 1

O pacote sun-java6-jre contém o script preinst que solicita o contrato de licença via interface /usr/share/debconf/confmodule (também conhecida como interface shell script para o frontend debconf). A implementação do debconf é muito difícil de seguir, mas eu acho que a implementação de db_input() verifica a variável de ambiente TERM e tenta implementar diferentes prompts de acordo de licença para diferentes terminais. Veja o tutorial debconf no link . A ideia é que o frontend do debconf pode acabar usando o braille se o usuário final estiver com problemas de visão e o script preinst funcionar.

Você não deve passar a saída do script para o frontend debconf interativo até onde eu possa vê-lo. É destinado ao consumo humano e pode mudar a qualquer momento (de acordo com as variáveis do ambiente, a fase da lua e assim por diante). Você pode querer google por debconf frontend noninteractive .

    

Answer 2

Não é booleano , mas selecione .

Você pode verificar o conteúdo do banco de dados debconf:

root@workstation:~# debconf-show sun-java6-jre
* shared/accepted-sun-dlj-v1-1: true
  sun-java6-jre/stopthread: true
  sun-java6-jre/jcepolicy:
  shared/error-sun-dlj-v1-1:
* shared/present-sun-dlj-v1-1:
root@workstation:~# 

Como você pode ver na minha máquina, ela já está configurada como true porque eu a aceitei manualmente durante a instalação. Se eu fosse instalar o sun-java6-jre novamente, ele não me pediria para aceitar a licença.

Vamos defini-lo como falso:

root@workstation:~# echo sun-java6-jre shared/accepted-sun-dlj-v1-1 select false | /usr/bin/debconf-set-selections

Agora vamos verificar:

root@workstation:~# debconf-show sun-java6-jre
* shared/accepted-sun-dlj-v1-1: false
  sun-java6-jre/stopthread: true
  sun-java6-jre/jcepolicy:
  shared/error-sun-dlj-v1-1:
* shared/present-sun-dlj-v1-1:
root@workstation:~# 

Então tente:

ssh -i keyFile root@hostname "echo sun-java6-jre shared/accepted-sun-dlj-v1-1 select true | /usr/bin/debconf-set-selections && apt-get install -y sun-java6-jre"

Use o comando debconf-show para solucionar problemas.

Eu suspeito quando você diz

This works fine when executing the script locally.

É porque você instalou o sun-java6-jre manualmente em algum momento.

    

Answer 3

Como a questão mudou, aqui está outra resposta.

A variável TERM é verificada como parte do sun-java5-jre script preinst (veja aqui ). Dentro deste script / usr / share / debconf / confmodule é usado para interagir com o banco de dados deconf e para verificar se a licença foi definida como aceita no banco de dados ou não. Se não, ele irá chamar o método debconf para apresentar a licença para você. O Debconf irá apresentá-lo da maneira adequada ao seu ambiente. É aqui que o TERM entra. Se você não tiver um TERMO, ele deve passar para outros métodos

Então aqui está um exemplo de quando a licença está definida como falsa no debconf (não aceita)

Preparing to replace sun-java6-jre 6.26-1~lffl~oneiric~ppa (using .../sun-java6-jre_6.26-1~lffl~oneiric~ppa_all.deb) ...
debconf: Unable to initialise frontend: Dialog
debconf: (TERM is not set so the dialogue frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: Unable to initialise frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
Configuring sun-java6-jre
-------------------------

Operating System Distributor License for Java v1.1 (DLJ)

Operating System Distributor License for Java version 1.1 (DLJ)

SUN MICROSYSTEMS, INC. ("SUN") IS WILLING TO LICENSE THE JAVA PLATFORM STANDARD
EDITION DEVELOPER KIT ("JDK" - THE "SOFTWARE") TO YOU ONLY UPON THE CONDITION
THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS LICENSE AGREEMENT (THE
"AGREEMENT").  PLEASE READ THE AGREEMENT CAREFULLY.  BY INSTALLING, USING, OR
DISTRIBUTING THIS SOFTWARE, YOU ACCEPT ALL OF THE TERMS OF THE AGREEMENT. 



...................................... CUT .................................
    DLJ v1.1                                                  27APR2006ANS

In order to install this package, you must accept the license terms, the
"Operating System Distributor License for Java" (DLJ), v1.1. Not accepting will
cancel the installation.

Do you accept the DLJ license terms? yes

E aqui está um exemplo de quando a licença foi aprovada (definida como verdadeira em deconf)

 root@workstation:/home/andrey/buildarea# ssh root@localhost "echo 'sun-java6-bin shared/accepted-sun-dlj-v1-1 boolean true' | debconf-set-selections && aptitude -y reinstall sun-java6-jre"
root@localhost's password:
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initialising package states...
Writing extended state information...
The following packages will be REINSTALLED:
  sun-java6-jre
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 168 not upgraded.
Need to get 0 B/6,381 kB of archives. After unpacking 0 B will be used.
Writing extended state information...
debconf: Unable to initialise frontend: Dialog
debconf: (TERM is not set so the dialogue frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: Unable to initialise frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: Unable to re-open stdin:
(Reading database ... 161723 files and directories currently installed.)
Preparing to replace sun-java6-jre 6.26-1~lffl~oneiric~ppa (using .../sun-java6-jre_6.26-1~lffl~oneiric~ppa_all.deb) ...
debconf: Unable to initialise frontend: Dialog
debconf: (TERM is not set so the dialogue frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: Unable to initialise frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
sun-dlj-v1-1 license has already been accepted
Unpacking replacement sun-java6-jre ...
Processing triggers for shared-mime-info ...
Setting up sun-java6-jre (6.26-1~lffl~oneiric~ppa) ...
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initialising package states...
Writing extended state information...
root@workstation:/home/andrey/buildarea# 

Você recebe as mesmas mensagens "debconf" durante a instalação? Você pode ver minhas experiências e instalação bem sucedida de sun-java6-jre sobre SSH aqui NOTA: Ao executar ssh root @ localhost "env" eu posso veja a variável TERM também.

Se você quiser ver o que o pacote deb está fazendo antes, durante a pós-instalação, baixe o arquivo .deb:

aptitude download sun-java6-jre

Extraia o .deb

ar x sun-java6-jre......deb

Extraia o control.tar.gz e dê uma olhada nos arquivos preinstal e outros. data.tar.gz é o conteúdo do pacote.

Isso pode não responder à sua pergunta diretamente, mas esperamos que ajude.