Firefox/Thunderbird lässt sich nicht auf zwei Rechnern gleichzeitig starten

[Rüdiger Kupper]

Hat der Nutzer bereits auf einem anderen Rechner einen Firefox-Prozess laufen, so weigert sich Firefox zu starten. Komischerweise ist dieses Problem erst wieder mit der NFS-Anbindung aufgetaucht (Grund?).

[Rüdiger Kupper]

Praktischerweise gibt das Lockfile, das Firefox anlegt, Auskunft über die IP des Rechners, auf dem es läuft und die Prozess-ID.

Ich habe ein Startskript geschrieben, das prüft, ob ein Lockfile existiert und dann anbietet, den Prozess auf dem entfernten Rechner zu beenden, bevor Firefox lokal gestartet wird.

Das Skript hat nur ein Problem: Um den Prozess auf dem entfernten Rechner zu beenden, muss eine SSH-Verbindung aufgebaut werden. Das geht von Schülernetz zu Schülernetz, von Lehrernetz zu Lehrernetz und von Lehrernetz zu Schülernetz. Es geht aber nicht von Schülernetz zu Lehrernetz.

Hat ein Kollege also einen Firefox im LZ laufen, so kann er ihn vom Klassenraum aus derzeit nicht beenden.

@bau: gibt's da eine Möglichkeit? Könnte man z.B. die Route über den ltsp6 nutzen?

[bau]

Können schon, dürfen nicht!
Es darf technisch nich möglich sein, vom Schülernetz ins Lehrernetz zu kommen!

[bau]

Wäre auch ein Script denkbar, das beim Login prüft, ob du schon wo anders eingelogged bist und dir anbietet, dich dort auszuloggen - das wäre ciher auch oft hilfreich. (So hat das der gute alte IBM Mainframe gemacht, der hat dir sogar die gesamte Sitzung hinterhergeschickt).

[bau]

Alternativvorschlag:
Ein Script läuft auf dem paedml, horcht auf einem Port und macht das Geschäft von dort aus.
Das Ganze muss natürlich irgendwie per Key abgesichert werden, aber dafür haben wir in der MikroMakroAG ja bereits einen Prototypen gebastelt.

[Rüdiger Kupper]

Ja, wäre alles denkbar. Die ssh-Verbindung wäre halt das einfachste gewesen.
Es gibt auch noch den "unsauberen" Weg, das Lockfile einfach zu löschen und den anderen Firefox einfach weiterlaufen zu lassen. Das wird in den meisten Fällen auch funktionieren...

[Rüdiger Kupper]

Die Sache ist doch gar nicht soooo einfach, wie sie auf den ersten Blick aussieht:

• Natürlich kann man Services auf den einzelnen Clients starten, die auf einem bestimmten Port horchen und dann z.B. Firefox-Prozesse oder die Gnome-Session beenden. Diese Services laufen dann aber als root, was bedeutet, dass der anfragende Nutzer sich erst einmal authentifizieren muss (denn sonst könnte jeder Nutzer die Prozesse jedes anderen Nutzers beenden!). Und der natürliche Weg, das zu erreichen, wäre wieder ssh...
• Beim Weg vom Schülernetz ins Lehrernetz müssten wir den paedml als Scharnier nutzen. Das wirft aber zwei Probleme auf:
  1. wie soll sich der Nutzer über diesen Umweg auf dem Client authentifizieren? Bis zum paedml mag das ja noch gehen, aber von dort aus muss die Anfrage dann ja an den Client weitergereicht werden, und wie soll da die Authentifizierung laufen?
  2. die Alternative wäre, dass root sich vom paedml passwortlos auf den Clients einloggen kann, und das finde ich inakzeptabel.

Ich habe daher jetzt ein anderes Verfahren implementiert. Das ist vielleicht nicht superelegant, aber funktioniert. Überlegung: Wenn Firefox das Filesystem nutzen kann, um mit sich über jegliche Netze hinweg zu kommunizieren, dann können wir das natürlich auch:

• das NFS-gemountete Filesystem ist gleichermaßen aus dem Schüler- wie aus dem Lehrernetz zu sehen.
• jeder Nutzer, egal in welchem Netz, greift auf sein Homeverzeichnis zu.

Also:

• Auf jedem Client wird beim Login des Nutzers ein Prozess gestartet, der alle drei Sekunden nach einer Datei ~/.killfirefox im Homeverzeichnis des Nutzers sucht.
  • gibt es die Datei, schaut er, ob lokal ein Firefox-Prozess läuft.
    • wenn ja, beendet er diesen und löscht die Datei
    • wenn nein, tut er nichts
• Auf jedem Client ist der normale Firefox-Start durch ein angepasstes Startskript ersetzt:
  • das Skript prüft, ob es derzeit eine Lockdatei gibt
    • falls nein startet er Firefox normal.
    • falls ja, und diese sich nicht auf den lokalen Rechner bezieht:
      • legt er die Datei ~/.killfirefox an
      • wartet, bis sie verschwindet
      • startet dann Firefox lokal

[Rüdiger Kupper]

Na super. Thunderbird macht natürlich genau das selbe... Aber das geht ja jetzt einfach.

[Rüdiger Kupper]

Weiteres kleines Problemchen: In der Seitenleiste erscheint beim Öffnen ein zweites FF-Symbol (weil der Launcher anders heißt...)

[Rüdiger Kupper]

Gelöst wie für FF.

[Rüdiger Kupper]

Killerprozess sollte Lockfiles entfernen, selbst wenn kein Prozess läuft. Die Lockdatei könnte fälschlicherweise übriggeblieben sein.

[Rüdiger Kupper]

Laut Bericht von jas ist das Problem dringend.

[Rüdiger Kupper]

Folgendes Problem:

• Ein Nutzer loggt sich auf einem Rechner ein, nutzt Firefox oder Thunderbird, und meldet sich ab, ohne das FF/TB-Fenster zu schließen. In diesem Fall bleibt öfter mal das Lockfile liegen -- das hat schon öfters Probleme gemacht.
• Der Nutzer loggt sich woanders ein und will FF/TB starten.
• Mein Firefox-Starter findet das Lockfile, sieht, dass es von einem fremden Rechner stammt, und erzeugt die Datei ~/.killfirefox. Dann wartet er darauf, dass der Killerprozess auf dem entfernten Rechner den Prozess killt und die Datei ~/.killfirefox entfernt.
• Da es aber auch dem entfernten Rechner gar keinen FF/TB-Prozess gibt, macht der Killerprozess gar nichts. Die ~/.killfirefox-Datei bleibt liegen und das Startskript wartet bis in alle Ewigkeit.

Der Fall muss abgefangen werden -- oder alternativ gehen wir einfach rabiater vor.

Möglichkeit 1

Der Firefoxstarter wartet maximal 10 Sekunden auf das Verschwinden der ~/.killfirefox-Datei. Ist sie dann noch immer da, geht er davon aus, dass der FF-Prozess auf dem fremden Rechner nicht mehr existiert. Er löscht das Lockfile und startet FF normal.

Möglichkeit 2

Wir löschen bei jedem Login einfach mögliche noch herumliegende Lockfiles. Dann lässt sich FF/TB immer starten. Wenn allerdings wirklich noch ein entfernter Prozess läuft, könnte das unerwünschte Nebeneffekte haben -- da z.B. dann zwei Prozesse auf Datenbanken im Profilverzeichnis zugreifen.
Allerdings muss ich sagen, dass ich noch niemals irgendwelche Probleme damit hatte...

[Rüdiger Kupper]

Okay, Variante 1 müsste laufen. Bisher nur auf den Lehrerzimmerrechnern. Die anderen Lehrerrechner bekommen die Änderung, sobald ich das Image erzeugt habe. Aber nicht mehr heute...

[Rüdiger Kupper]

Verbesserung der Logik: Erst Lockfile löschen und FF/TB starten, dann im Hintergrund Killdatei anlegen!

[Rüdiger Kupper]

Implementiert.