I'm attempting to automate the installation of a Debian server (debian 6.0 squeeze 64bit).
Part of the installation requires the Sun JRE package to be installed.
This package has a licence agreement, which has to be accepted. I have a script which uses the following lines to accept and install the JRE:
echo "sun-java6-bin shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections
apt-get install -y sun-java6-jre
This works fine when executing the script locally. However, I need to execute the script remotely using the ssh command, e.g.:
ssh -i keyFile root@hostname './myScript'
This doesn't work.
In particular, it fails on apt-get install -y sun-java6-jre
. It would seem that in spite of me setting the licence agreement to accepted, when run remotely in this manner it is ignored.
Despite setting the value to true
, I still get prompted to manually accept the agreement when I run this command:
ssh -i keyFile root@hostname 'apt-get install -y sun-java6-jre'
I suspect it is something to do with environment that is taken care of when running a proper terminal session, but have no idea what to try next to fix it.
Edit 0: I have compared the output of env
when executed remotely via ssh
and when executed via a local terminal session. The only difference between the outputs is that the local terminal session has the additional value TERM=xterm
.
Edit 1: Setting the TERM
environment variable when calling my script, like this ssh -i keyFile root@hostname 'export TERM=xterm; ./myScript'
, produces the correct behaviour, but that's really only half an answer, as I don't know why you need to set it. An accepted answer for the person who can best explain the why!
(I've revised the question title as well, from "Remote Scripted Installation of Sun/Oracle JRE" to "Why does TERM=xterm have to be set for my script to work correctly when remotely executed?" as it's a more accurate question)
Best Answer
The sun-java6-jre package contains
preinst
script that prompts for license agreement via/usr/share/debconf/confmodule
(also known as "shell script" interface to debconf frontend). The debconf implementation is very hard to follow but I'd guess that the implementation ofdb_input()
checks theTERM
environment variable and tries to implement different license agreement prompts for different terminals. See the debconf tutorial at http://www.fifi.org/doc/debconf-doc/tutorial.html. The idea is that debconf frontend may end up using braille display if the end user is vision impaired and the preinst script will just work.You're not supposed to pass scripted output to interactive debconf frontend as far as I can see it. It's meant for human consumption and may change at any time (according to environment variables, the moon phase and so on). You might want to google for
debconf frontend noninteractive
.