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)

3 Answers
3

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 of db_input() checks the TERM 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.

Thanks for your answer! I did test the echo "sun-java6-bin shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections both locally and remotely, and also used echo "sun-java6-bin shared/accepted-sun-dlj-v1-1 boolean false" | debconf-set-selections to unset it whilst I was experimenting. I verified the local behaviour (worked as expected, prompting the licence agreement when false, and skipping it when true), so I'm happy the command does work, although I'm guessing select is also acceptable. As such, I can say that I undid the effects of previous manual installs
–
chrisbunneyNov 13 '11 at 13:44

I've also updated the question, as I've found a solution, but would like to know why it works
–
chrisbunneyNov 13 '11 at 13:55

I can successfully reinstall sun-java6-jre over SSH and my TERM var is also missing when queried over SSH. See it here pastebin.com/hrK9D0Sx Can you post content of your ./myScript file?
–
AndreyNov 13 '11 at 15:28

TERM variable is checked as part of sun-java5-jre preinst script (see it here ) . Inside this script /usr/share/debconf/confmodule is used to interact with deconf database and to check whether the license has been set to accepted in the database or not. If not it will call debconf method to present the license to you. Debconf will present it in the way suitable for your environment. This is where TERM comes in. If you have no TERM it should fail over to other methods

So here is an example when license is set to false in debconf (not accepted)

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

And here is an example when the license has been approved (set to true in deconf)

Do you get the same "debconf" messages during install? You can see my experiments and successful installation of sun-java6-jre over SSH here NOTE : When running ssh root@localhost "env" I can't see TERM variable either.

If you want to see what the deb package is doing pre, during, post installation, donwload .deb file :

aptitude download sun-java6-jre

Extract .deb

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

Extract control.tar.gz and take a look at preinstal and other files. data.tar.gz is the content of the package.

Yes, I can see similar output from debconf, where it falls back to a different frontend, IIRC in my case it falls back to "teletype". However, when it does, I get prompted to accept the licence agreement. I'll have to look into the deb file
–
chrisbunneyNov 13 '11 at 16:36