Startskript für LTSP-Nutzer / LML-Startskript (war: Firefoxproblematik)

[bau]

Lieber Herr Baumgärtner,

Aufgrund eines lockeren Netzkabels ist der Rechner 2 ausgegangen, als ich angemeldet war. Jetzt lässt sich der Rechner nicht mehr hochfahren und ich war noch angemeldet. Wenn ich mich jetzt an einem anderen Rechner anmelde, komme ich nicht mehr ins Internet, da ich auf dem alten noch im Internet war. Es kommt immer eine fehlermeldung, dass ich bereits im Internet bin. Was soll ich jetzt machen?

Viele Grüße
Giuliano Hess

[bau]

Wir sollten einige Scripte als Starter zur Verfügung stellen, mit denen man

• die ganzen Dateien

  .lock
  .parentlock
  parentlock
  

und wie sie alle heißen, mit einem Klick löschen kann (vielleicht nach einer Sicherheitsabfrage).

• das Profilverzeichnis des Firefox auf ~/einstellungen/firefox umbiegen, das Verzeichnis ~/einstellungen/firefox/ löschen und die Vorgabeeinstellungen eines gültigen Profils (muss übrigens mal wieder aktualisiert werden) aus /home/samba/progs/Vorlagen/firefox nach ~/einstellungen/firefox kopiert

• bislang wird das Profilverzeichnis nur bei einer Anmeldung am Samba-Server per netlogon-Script (/home/samba/netlogin/login.bat) nach ~/einstellungen/firefox kopiert, das sollte irgendwie in das Startup bei Linux integriert werden.

[Rüdiger Kupper]

Replying to bau:

Wir sollten einige Scripte als Starter zur Verfügung stellen, mit denen man

• die ganzen Dateien

  .lock
  .parentlock
  parentlock
  

und wie sie alle heißen, mit einem Klick löschen kann (vielleicht nach einer Sicherheitsabfrage).

Zustimmung.

• das Profilverzeichnis des Firefox auf ~/einstellungen/firefox umbiegen, das Verzeichnis ~/einstellungen/firefox/ löschen und die Vorgabeeinstellungen eines gültigen Profils (muss übrigens mal wieder aktualisiert werden) aus /home/samba/progs/Vorlagen/firefox nach ~/einstellungen/firefox kopiert

Verstehe ich nicht. Das Löschen der obigen Dateien müsste reichen: Alle relevanten Einstellungen, die erzwungen werden sollen, gehen nach ~/einstellungen/firefox/user.js und werden täglich durch ein Cronscript in die Homeverzeichnisse der Nutzer kopiert.

• bislang wird das Profilverzeichnis nur bei einer Anmeldung am Samba-Server per netlogon-Script (/home/samba/netlogin/login.bat) nach ~/einstellungen/firefox kopiert,

Was? Das ist ja die selbe blöde Idee, wie den Desktop bei jeder Anmeldung komplett zu löschen. So ein Quatsch!

das sollte irgendwie in das Startup bei Linux integriert werden.

Ich verstehe nicht, wieso die LML ihre Nutzer so bevormundet: Es reicht doch völlig, wenn wir die nötigen EInstellungen in der user.js vorgeben -- wieso sollten wir alle Einstellungen des Nutzers (persönliche Einstellungen, die ihm das Leben erleichtern, sämtliche Lesezeichen, etc.) bei jedem Login überschreiben?
Die Herangehensweise der LML kann ich bis heute nicht nachvollziehen.

[Rüdiger Kupper]

Querverweis: ticket:729

[bau]

Halt - Missverständnis.
Das Profil wird nur kopiert, wenn es noch nicht da ist!
Manchmal zerschießen sich die Benutzer das Profil aber, und dazu sollte ein Script mit starter da sein, welches das Profil löscht und wieder herstellt.

[Rüdiger Kupper]

Ah so, klar!
Es wäre vielleicht geschickt, auf für die LTSP-Clients ein Skript zu haben, das bei jeder Anmeldung des Nutzers kurz läuft und solche Aufgaben erledigt. Das könnte dann

• die default-Konfiguration einrichten, wenn sie noch nicht existiert
• nach laufenden Firefox-Prozessen auf anderen Servern suchen
• die Lockfiles löschen.

Bisher erledigen wir solche Aufgaben mit einem täglichen Cronskript, so dass die Nutzer im schlimmsten Fall einen Tag warten müssen. Mit dem Anmeldeskript würde Ab- und Wiederanmelden reichen.

(Das tieferliegende Problem ist natürlich, dass Firefox (a) seine Lockfiles nicht richtig aufräumt und (b) überhaupt nicht auf Nutzung in einem Netzwerk ausgelegt ist. Aber darauf haben wir wohl wenig Einfluss.)

[Rüdiger Kupper]

Siehe:

• ​http://kb.mozillazine.org/Profile_in_use

[Rüdiger Kupper]

Weiterer Vorschlag: LTSP bietet die Möglichkeit, einen Nutzer immer nur an einem Client den Login zu ermöglichen. Die Option in der lts.conf lautet

LDM_LIMIT_ONE_SESSION = True

Soweit ich verstehe (siehe ​launchpad:67366) sucht das bei jedem neuen Login nach übriggebliebenen Prozessen (ich denke aber, nur auf dem selben Server) und fragt, was getan werde soll.

Eine ähnliche Lösung bietet gnome-watchdog, mit dem Unterschied, dass das beim Ausloggen sicherstellt, dass alle Prozesse beendet wurden, siehe ​​https://help.ubuntu.com/community/UbuntuLTSP/GnomeWatchdog.

Bisher hielt ich es eigentlich für ganz praktisch, an mehreren Clients angemeldet sein zu können, doch für normale Nutzer macht das vermutlich mehr Probleme als es genutzt wird.

[bau]

Vielleicht sollten wir uns die LTSP-Cluster-Lösung doch mal genauer anschauen. Klaus Knopper meinte mal, da könne man auch seine X-Session einfach auf einen anderen Client umziehen (müsste doch eigentlich gehen - oder) Das fand ich früher in der Bausparkasse SHA prima, da hast du deine Großrechnersession einfach am nächsten Terminal angemeldet und der hat dich automatisch am letzten Client abgemeldet.

[Rüdiger Kupper]

Das wäre natürlich extrem kpomfortabel. Ich nehme aber an, auf die Clusterlösung umzustellen ist ein etwas größerer Aufwand. Würde ich auf die Wunschliste setzen.

[Rüdiger Kupper]

-> siehe #775.

[Rüdiger Kupper]

Replying to bau:

Halt - Missverständnis.
Das Profil wird nur kopiert, wenn es noch nicht da ist!

Da haben wir übrigens inzwischen zwei Mechanismen:

1. Die samba login.bat erstellt das Firefoxverzeichnis nach einer Vorlage (wo liegt die eigentlich?), sofern es noch nicht existiert.
2. Jede Nacht läuft ein Cronskript auf dem paedml, das den kompletten Baum unter /etc/skel-{students,teachers}/ in die Homeverzeichnisse der Nutzer schreibt. Dadurch wird ebenfalls das firefox-Verzeichnis angelegt und die user.js hinkopiert. Außerdem biegt es die profiles.ini so um, dass Firefox auch wirklich dort sucht. (Das macht die login.bat übrigens nicht.)

Ich wäre dafür, den "skeleton"-Mechanismus zu erweitern: Einen Dateibaum für Dateien, die jede Nacht überschrieben werden sollen, einen Dateibaum für Dateien, die angelegt werden sollen, wenn sie noch nicht existieren, und einen Dateibaum für Dateien, die gelöscht werden sollen.

Das würde dann einige der Skripte gleich mit erschlagen, die derzeit noch einzeln laufen (Löschskripte), und es würde den Mechnismus, der derzeit nur für die LML funktioniert, auch für die LTSPs übertragen.

Das könnte dann erstmal täglich per Cronskript laufen. Nach schöner wär's, wenn wir das Skript für den jeweiligen Nutzer anstoßen könnten, wenn er sich einloggt -- und zwar egal, ob per LTSP oder per LML. Da fällt uns sicher noch was ein.

[Rüdiger Kupper]

Der in comment:11 beschriebene Prozess ist nun teilweise implementiert:

• Es gibt auf dem paedml die vier Verzeichnisse
  1. `/etc/skel-teachers-default/`
  2. `/etc/skel-teachers-mandatory/`
  3. `/etc/skel-students-default/`
  4. `/etc/skel-students-mandatory/`

Das Skript deploy-skeleton kopiert den Inhalt dieser Verzeichnisse per rsync in die Homeverzeichnisse der Nutzer (aller oder nur des angegebenen Nutzers, siehe deploy-skeleton --help). Dieses Skript läuft täglich per Cronjob.

• Verzeichnisse und Dateien in den *-default-Verzeichnissen werden nur dann kopiert, wenn Dateien dieses Namens im Homeverzeichnis des Nutzers noch nicht existieren. Der Nutzer erhält also spätestens einen Tag nach seinem Anlegen die Defaults für diese Dateien.
• Verzeichnisse und Dateien in den *-mandatory-Verzeichnissen werden jedes mal überschrieben. Der Nutzer erhält also täglich wieder die Ausgangsdateien.

In /etc/skel-*-mandatory liegen auch die Verzeichnisse einstellungen/thunderbird und einstellungen/firefox mit jeweiligen user.js-Dateien.

Das reicht, um Firefox mit den gewollten Einstellungen zu starten, alle weiteren Dateien legt Firefox beim ersten Start dann selbsttätig an.
Entsprechend habe ich in /home/samba/netlogon/login.bat das Kopieren der Firefox-Vorlage nun auskommentiert. Im ganzen login.bat sind nun alle Kepler-spezifischen Sachen auskommentiert, das Kript ist jetzt also praktisch wieder im Urzustand.

Das erstellen der (nutzerspezifischen) Thunderbird-prefs.js geschieht derzeit (noch) über das existierende Cronskript. Das sollten wir noch in den "skeleton"-Mechanismus integrieren.

Noch offen:

• der Mechanismus zum Löschen von Dateien über "deploy-skeleton" ist noch nicht implementiert
• es sollte eine Möglichkeit gefunden werden, das Skript beim Einloggen eines Nutzers auf einem LtspClient (und auch beim Einloggen auf einem LML-Client) anzustoßen.

[Rüdiger Kupper]

Das Löschen ist jetzt auch implementiert (changeset:425/keplertools). Die zugehörigen Files lauten

• /etc/skel-teachers-delete/
• /etc/skel-students-delete/

Damit werden nun jede Nacht auch die Lockfiles gelöscht.

[Rüdiger Kupper]

Habe die Option

LDM_LIMIT_ONE_SESSION = True

in die lts.conf aufgenommen. Mal sehen, wie sich das auswirkt.

[bau]

Sehr gute Arbeit :-)

Noch offen:

der Mechanismus zum Löschen von Dateien über "deploy-skeleton" ist noch nicht implementiert
es sollte eine Möglichkeit gefunden werden, das Skript beim Einloggen eines Nutzers auf einem
LtspClient? (und auch beim Einloggen auf einem LML-Client) anzustoßen.

für den Login am Samba-Server ist das ganz einfach, da gibt es in der /etc/samba/smb.conf die Option

   root preexec = samba-userlog --log=in --username=%U --hostname=%I --homedir=%H
   root postexec = samba-userlog --log=out --username=%U --hostname=%I --homedir=%H

Dieses Script müsste durch ein eigenes ersetzt werden, in dem das Script samba-userlog dann aufgerufen wird. Es wäre superpraktisch, wenn das Script beim Login am LTSP-Client auch aufgerufen würde, dann steht im Log wann sich welcher Schüler an welcher Workstation eingelogged hat.

[bau]

Da haben wir übrigens inzwischen zwei Mechanismen:

Die samba login.bat erstellt das Firefoxverzeichnis nach einer Vorlage (wo liegt die eigentlich?),
sofern es noch nicht existiert.

Die Vorlage lag bislang auf Laufwerk K: oder P: auf dem Server folglich in /home/samba/progs/Vorlagen.
Ich stimme absolut zu, dass die Scripte alle vom skel-Script ersetzt werden sollten, dann erhält jeder User auch die thunderbird-Vorlage und das zugehörige CronjobScript kann entfallen. Die Vorlage für thunderbird liegt unter /home/samba/progs/Vorlagen/thunderbird und wird aber vom script so angepasst, dass an der richtigen Stelle gleich der Username steht (siehe /etc/cron.daily/thunderbird)

[Rüdiger Kupper]

Wie erwartet testet die LDM_LIMIT_ONE_SESSION-Option nur, ob der Nutzer auf dem selben Server schon angemeldet ist. Dann funktioniert das sehr gut.
Auf verschiedenen Servern kann man sich aber weiterhin problemlos parallel anmelden.

ltsp-cluster bietet hier eine Lösung, ich weiß aber nicht, wie umständlich es wäre, das mal auszuprobieren.

[Rüdiger Kupper]

• Übriggebliebene Firefox-Lockfiles werden inzwischen verlässlich gelöscht (per source:keplertools/etc/trunk/skel-teachers-delete und source:keplertools/etc/trunk/skel-students-delete).
• Die LDM_LIMIT_ONE_SESSION-Option sorgt zumindest in einem Teil der Fälle dafür, dass eine nicht korrekt beendete Sitzung beim erneuten Einloggen beendet wird.

Damit ist das ursprüngliche Problem dieses Tickets entschärft, spätestens am Folgetag funktioniert bei jedem Nutzer Firefox wieder.

• Den Mechanismus, der beim Einloggen an einem LtspClient automatisch ein Skript ausführt, gibt es inzwischen auch: source:keplertools/scripts/trunk/ltsp-startup (hatte ich im Rahmen der "Weihnachtsbegrüßung" implementiert). Das Skript läuft derzeit jeweils lokal auf dem LtspSver, wo man sich einloggt.

Todo

Weitere Ideen dieses Tickets können noch umgesetzt werden:

1. Das Einlogg-Skript könnte nicht nur lokal laufen, sondern einen Prozess auf den anderen LtspServern bzw. zentral auf dem paedml anwerfen. Auf diese Weise könnte man beim Einloggen übriggebliebene Sitzungen auf den anderen LtspServern abschießen. Das Skript bräuchte dann natürlich die Möglichkeit, sich ohne Nachfrage auf anderen Maschinen einzuloggen (ss-Schlüssel) und dort Prozesse zu töten. Klingt potenziell gefährlich.
2. Die Initskripte der LML durchsehen und in den Skeleton-Mechanismus übertragen. Jedenfalls sollte es keinen Unterschied machen, ob sich ein Nutzer zuerst an einem LML-Client oder einem LtspClient einloggt.

=> Ich setze den Rest dieses Tickets auf milestone:Wunschliste.

[Rüdiger Kupper]

Replying to bau:

Ich stimme absolut zu, dass die Scripte alle vom skel-Script ersetzt werden sollten, dann erhält jeder User auch die thunderbird-Vorlage und das zugehörige CronjobScript kann entfallen. Die Vorlage für thunderbird liegt unter /home/samba/progs/Vorlagen/thunderbird und wird aber vom script so angepasst, dass an der richtigen Stelle gleich der Username steht (siehe /etc/cron.daily/thunderbird)

Bisher wurden die Einstellungen für Firefox und Thunderbird, die für alle Nutzer gleich sein sollten, über den Skeleton-Mechanismus mit den Dateien ~/einstellungen/{firefox,thunderbird}/user.js verteilt.

Das hatte folgenden Nachteile:

• Die Thunderbird-Einstellungen für das "vereingerichtete" Mail-Account konnten auf diesem Weg nicht verteilt werden, weil hier der Nutzername eingesetzt werden musste. Das musste von einem eigenen Cronskript erledigt werden, das die "prefs.js" anlegt. Damit war die Nutzerkonfiguration an zwei Stellen verteilt.
• In der Mozilla-Dokumentation wird erwähnt, dass das "user.js"-File in zukünftigen Versionen vielleicht nicht mehr unterstützt wird (Zitat: "weil es zu oft missbraucht wurde").
• Stattdessen wird dort auf den "Mozilla-eigenen" Weg verwiesen, Nutzereinstellungen für Mozilla-Produkte systemweit vorzugeben. Die hat den Vorteil, dass dort auch der Nutzername referenziert werden kann.

Ich habe mich also mal durch die nicht sonderlich gute Doku gekämpft und diesen Mechanismus implementiert:

• Man benötigt auf den LtspServern die Datei /usr/lib/{firefox,thunderbird}/defaults/pref/kepler.js mit folgendem Inhalt:

  pref("general.config.obscure_value", 0);
  pref("general.config.filename", "kepler.cfg");
  

• Dann wird bei jedem Firefox/Thunderbird-Start die Datei /usr/lib/{firefox,thunderbird}/kepler.cfg eingelesen. Diese kann voreingestellte bzw. festgelegte Preferences enthalten, und dort ist auch der Nutzername abfragbar.

Ergebnis

Die Voreinstellungen für unsere Nutzer werden nun in den Dateien /usr/lib/{firefox,thunderbird}/kepler.cfg auf den LtspServern festgelegt.

• das thunderbird-Cronskript wurde deaktiviert
• das user.js für Thunderbird wurde aus dem Skeleton-Mechanismus entfernt
• das user.js für Firefox enthält nur noch eine einzige Option, nämlich die Startseite (weil die für Lehrer und Schüler unterschiedlich voreingestellt ist, hier habe ich keine andere Lösung gefunden)

[bau]

Hallo Rüdiger,
funktioniert das auch von den Windows-Maschinen aus?

[Rüdiger Kupper]

Konnte ich noch nicht testen, hoffe es aber.
Ausprobieren!
-> einen unserer Testnutzer neu initialisieren, z.B. den Test-Schüler:

delet-userfiles --home schuelte

Dann als schuelte einloggen und Thunderbird starten. Wenn alles klappt, muss das Mailaccount von schuelte vorinitialisiert sein.

[Rüdiger Kupper]

Replying to bau:

Hallo Rüdiger,
funktioniert das auch von den Windows-Maschinen aus?

Du hast natürlich recht, ein ganz neuer Nutzer erhält seine Konfiguration beim Login auf Windows nur, wenn das .cfg-File auch im Windows-Image vorhanden ist. Hat er sich vorher mal unter Linux eingeloggt, hat er die Sachen bereits in seinem prefs.js drinstehen und es müsste auch unter Windows funktionieren.

Da man im Windows-Image nicht ganz so einfach eine Datei ändert wie auf den LtspServern ist das schon wieder eher unpraktisch (jedenfalls nicht viel praktischer als die Lösung zuvor ;-).

Folgende Möglichkeiten:

• Windows abschaffen ;-) (Wäre mir das liebste -- irgendwann können wir das hoffentlich mal)
• Die Datei ins Image packen, sollte ja nicht oft geändert werden
• Zurückkehren zum alten Verfahren. Vorteil: läuft völlig auf dem paedml ab. Noch wird das user.js ja unterstützt.
• Dem Skeleton-Mechanismus beibringen, Variablen in den Dateien zu ersetzen. Habe schon darüber nachgedacht, wie sich das machen lässt. Dann wäre wieder alles an einem Ort. Funktioniert aber auch nur solange das user.js noch unterstützt wird.

Der Hinweis, dass die Unterstützung von user.js möglicherweise entfernt wird, findet sich unten auf dieser Seite: ​https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences
Wie aktuell das ist, ist unklar

Was schlägst Du vor?

[Rüdiger Kupper]

Okay, ich habe vorsorglich Das String-Ersetzen im Skeleton-Mechanismus umgesetzt:

In den Dateien unterhalb von /etc/skel-{teachers,students}-{mandatory,default,delete} werden nun die folgenden Strings beim Verteilen ersetzt:

String	wird ersetzt durch
%%%%USER%%%%	<Nutzername>
%%%%HOME%%%	<Homeverzeichnis des Nutzers (Linux)>
%%%%NAME%%%	<Vollständiger Name des Nutzers>

Damit ließe sich die nutzerspezifische Konfiguration für Thunderbird auch mit dem Skeleton-Mechanismus verteilen.

[Rüdiger Kupper]

So, da mir das Verwalten der *.cfg-Dateien unter Linux und Windows zu umständlich ist, werden die Einstellungen nun wieder über user.js-Dateien verteilt, nun aber mit der String-Ersetzung.
Netter Zusatz: Wir können auch den vollständigen Namen des Nutzers ersetzen und in der thunderbird-Config eintragen.

Sollte die Unterstützung von user.js tatsächlich eingestellt werden, wissen wir nun immerhin, wie man den *.cfg-Mechanismus verwendet.

Damit wäre das erstmal abgeschlossen.

Verbleibt auf Wunschliste

Todo in comment:18.