Kein debconf-Frontend per ssh

[ratti]

Hallo,

ich habe diverse Debian- und Ubuntu-Server in Verschiedenen Versionen im Einsatz. Bei einigen (Die Logik habe ich noch nicht ermittelt) habe ich folgendes Problem:

Ich möchte gerne mit minimalem Aufwand (aber trotzdem händisch) die täglichen Updates durchführen. Also habe ich mir einen passwortlosen ssh-Login eingerichtet, mit dem ich z.B. folgendes machen kann:

Code: Alles auswählen

CMD="ls -la /"  &&  ssh root@example.com "$CMD"

Nur zum Verständnis. Das klappt auch prima.

Um das zu testen, auch mal etwas, das eine Eingabe erfordert:

Code: Alles auswählen

CMD="read"  &&  ssh root@example.com "$CMD"

Auch prima. Ich gebe xxx ein, und die Verbindung ist danach beendet.

Wenn ich das ganze aber jetzt nutzen will, um meine Systemupdates einzuspielen…

Code: Alles auswählen

CMD="aptitude update && aptitude dist-upgrade" && ssh root@example.com "$CMD"

…dann klappt das zwar (in dem Sinne, dass es „durchläuft“), ich bekomme aber ziemlich am Anfang folgende Meldung:

Code: Alles auswählen

debconf: kann Oberfläche nicht initialisieren: Dialog
debconf: (TERM ist nicht gesetzt, die Dialog-Oberfläche kann daher nicht verwendet werden.)
debconf: greife zurück auf die Oberfläche: Readline
debconf: kann Oberfläche nicht initialisieren: Readline
debconf: (Diese Oberfläche bedarf eines steuernden Terminals.)
debconf: greife zurück auf die Oberfläche: Teletype
dpkg-preconfigure: kann Stdin nicht wieder öffnen: 

Danach sind die Updates eingespielt.

Ich mache das aber erst seit einigen Tagen so und hatte noch kein Update, welches mir Rückfragen stellt. Ich habe aber die Befürchtung, dass das schiefgehen würde, weil anscheinend(?) keines der vorhandenen Eingabe-Interfaces geöffnet werden kann. Oder kann ich das trotz der letzten Zeile (Stdin blabla) so interpretieren, dass Teletype funktionieren wird?

Irgendwie scheine ich der einzige mit dem Problem zu sein, Google findet nur Quelltexte mit diesen Meldungen…

Ach so:

Code: Alles auswählen

CMD="echo $TERM" && ssh root@example.com "$CMD"
xterm-color

Ist also alles gelogen, TERM ist gesetzt.

Gruß,
Jörg

[rendegast]

Ach so:
CMD="echo $TERM" && ssh root@example.com "$CMD"
xterm-color

Scheinbar gut, aber MÖÖÖÖP!
Die bash löst die Variable wohl schon auf dem Client auf

Code: Alles auswählen

$ CMD="echo $TERM" && ssh mymash "$CMD"
xterm

$ CMD="set | grep TERM" && ssh mymash "$CMD"
BASH_EXECUTION_STRING='set | grep TERM'
TERM=dumb

Denkbar wäre, ein 'apt-get update && aptitude -d full-upgrade'.
Damit wären die Pakete schon da.
Obwohl /etc/cron.daily/apt schon dafür da wäre, nur eingestellt sein müsste.

Code: Alles auswählen

$ apt-config dump | grep -i peri
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "0";
APT::Periodic::RandomSleep "11";

('RandomSleep 11', weil sonst der cron-Job möglicherweise für etliche Minuten einfach nur abwartet, siehe Skript.)

Das Upgrade auf einer richtigen ssh-shell durchführen,
Benachrichtigung dafür durch ein Paket, zBsp. apticron.



Das "Spezial"-Paket apt-dater? <<<<
(Benutzt screen)




--------------------------------------
Nebenbei ein Vergleich unter meinen Gegebenheiten (Benutzung von apt-cacher-ng im lokalen Netz):
'apt-get update' 5 Sek
'dselect update' 13 Sek.
'aptitude update' 42 Sek.

Und für 1MB Upgrades braucht
'apt-get -d dist-upgrade' 3 Sek
'aptitude -d full-upgrade' 27 Sek.

(Beim Einspielen selbst bleibe ich aber bei aptitude)

[ratti]

Hallo,

Ach so:
CMD="echo $TERM" && ssh root@example.com "$CMD"
xterm-color
Scheinbar gut, aber MÖÖÖÖP!
Die bash löst die Variable wohl schon auf dem Client auf

Autsch. Ja, Du hast Recht. Ich habe das Dollarzeichen jetzt mal gebackslashed, TERM ist anscheinend "dumb".

Die anderen von dir aufgelisteten Ideen passen leider nicht so ganz zum Problem.
Entweder sind Sie sowieso schon im Einsatz (cron-apt statt apticron) oder gehen am Problem vorbei (automatisches Update im Hintergrund,…). Weil mein Problem ja nicht ist, einfach Updates ins System zu prügeln. Ich will das ja händisch machen, ich will ja die Fragen selbst beantworten, der Download ist auch lässig schnell genug und bedarf keines Caches— ich möchte einfach ein vernünftiges Frontend haben, wie ich es hätte, wenn ich das ganze „entzerren“ würde: ssh Login, dann aptitude blablabla, ggf. Fragen beantworten, dann wieder ausloggen.

Die Kernfrage wäre für mich, wieso TERM eigentlich „dumb“ ist. Wenn ich mich per ssh direkt einlogge, ist es ja auch "xterm-color". Was ist an

Code: Alles auswählen

ssh KOMMANDO

anders als an

Code: Alles auswählen

ssh
KOMMANDO

?

Gruß,
Jörg

P.S.: Nachtrag: Die Server sind Linuxe, mein Client ist aber ein Mac. Daher helfen mir Tips nicht weiter, die Linux-Tools auf dem CLient voraussetzen. Beziehungsweise: Ich möchte eigentlich auf den Macs nichts installieren.

[rendegast]

Ich habe noch ein wenig herumgespielt

Code: Alles auswählen

$ ssh mymash 'TERM=xterm set | grep TERM'
BASH_EXECUTION_STRING='TERM=xterm set | grep TERM'
TERM=dumb

$ ssh mymash 'bash -c "set | grep TERM"'
BASH_EXECUTION_STRING='set | grep TERM'
TERM=dumb


$ ssh mymash 'TERM=xterm bash -c "set | grep TERM"'
BASH_EXECUTION_STRING='set | grep TERM'
TERM=xterm

Ob das TERM im letzten Fall hier Abhilfe schafft?

Ich habe das mal mit /usr/sbin/pam-auth-update (benutzt debconf) ausprobiert (sicherheitshalber als einfacher User ):

Code: Alles auswählen

ssh mymash 'bash -c "/usr/sbin/pam-auth-update"'

schaltet in den readline-Modus, dagegen

Code: Alles auswählen

ssh mymash 'TERM=xterm bash -c "/usr/sbin/pam-auth-update"'

gibt dann das dialog-Interface ("xterm" wird also akzeptiert),
zerhackt jedoch die Konsole (braucht danach 'reset').
Ob ich das Risiko bei einem wichtigen Upgrade haben möchte,
vielleicht gibt es aber auch passendere Werte als "xterm"?

Was ist an
ssh KOMMANDO

anders als an
ssh
KOMMANDO

-> 'man ssh'
" If command is specified, it is executed on the remote host instead of a login shell."
-> 'man bash'
Das zweite ist eine sogenannte interaktive Shell.






--------------------------------------------------
Anmerkung

der Download ist auch lässig schnell genug und bedarf keines Caches—

Es ging hier nicht um den Download, daher die Erwähnung des apt-caches und des beispielhaften Downloads von unerheblichen ~ 1MB.
Es ging um die Verarbeitungsgeschwindigkeiten der tools.

Zugegeben, in dem Fall war es auf einem älteren Notebook,
auf dem großen Eisen erledigt apt-get seinen Job in ~ 2sec, dselect und aptitude brauchen ~ 3.5sec.

[ratti]

Es ist zum Mäusemelken - jetzt habe ich nix mehr zum Basteln, weil ich alle Updates eingespielt habe.

Trotzdem kurz meinen Zwischenstand: debconf war ein gutes (Such-)Stichwort.

Es könnte für die Praxis ausreichen, wenn man das debconf-Frontend temporär auf was simpleres setzt, statt an TERM rumzufummeln.

Da sieht folgendes erst mal verheissungsvoll aus:

Code: Alles auswählen

ssh root@example.com "aptitude -o DEBIAN_FRONTEND=readline dist-upgrade"
DEBIAN_FRONTEND=readline apt-get install slrn
dpkg-reconfigure --frontend=readline

Genaueres hier: http://debiananwenderhandbuch.de/debconf.html

Der Hintergedanke ist:
Dass aptitude dist-upgrade im Tagesgeschäft überhaupt eine Rückfrage stellt, ist ja extrem selten. Sollte das mal der Fall sein, reicht readline entweder, oder man bricht das ab. Wichtiger wäre mir nur, dass mir nicht „watching shit scroll“ nicht irgendwas ungefragt durchrutscht, und das Paket ist unkonfiguriert oder so.

Ich werde jetzt mal schauen, was passiert, wenn ich wieder Updates vorliegen habe. Ich mag meine produktiven Server jetzt nicht in einen komischen Zustand zwingen. Eilt ja nicht.

Vielen Dank erstmal! Ich muss erst mal was zu Mittag essen, sonst greife ich versehentlich zu fdisk.

Gruß,
Jörg

[rendegast]

Ich werde jetzt mal schauen, was passiert, wenn ich wieder Updates vorliegen habe.

Du könntest Dir von http://snapshot.debian.org die Vorversion eines passenden Paketes herunterladen und per 'dpkg' einspielen.

Alternativ wäre ein 'dpkg-reconfigure' eines passenden Paketes.
(Das 'pam-auth-update' entspricht dem)


Und dann gibt es natürlich die Möglichkeit einer VM,
mit der das im snapshot-Modus durchgespielt wird.

[ratti]

Hallo,

Du könntest Dir von http://snapshot.debian.org die Vorversion eines passenden Paketes herunterladen und per 'dpkg' einspielen.

Ja, das ist mir klar. Oder einfach irgendwas unnötiges einspielen und hinterher purgen, dann wäre nix betroffen, was aus gutem Grund installiert ist.

Da aber keinerlei Zeitdruck vorliegt, würde ich nicht so an einem Produktivserver rumspielen, sondern einfach warten. Eigentlich habe ich täglich updates auf irgendeiner Maschine.

Gruß,
Jörg