Singleton-Cookies verbleiben nach dem Abmelden in der Chrome-Konfig

[Rüdiger Kupper]

Auf dem nächsten Rechner öffnet sich dann Chrome nicht mehr. Grund ist ein behämmerter Mechanismus, den die Chrome-Leute verwenden um zu garantieren, dass das Chrome-Profil immer exklusiv genutzt wird und nicht von zwei Instanzen gleichzeitig. Sie wissen offenbar genau, dass ihr Produkt in einem Netzwerk nicht funktioniert. Statt Chrome netzwerkfähig zu machen sperren sie einfach das Profil, sobald man auf einem Rechner Chrome öffnet. Bei der Abmeldung bleibt das Profil aber grundlos gesperrt, außer man schließt immer brav alle Browserfenster, bevor man sich abmeldet. Das tun die Kollegen verständlicherweise nicht immer.

[Rüdiger Kupper]

Die Singleton-Cookies werden bereits jede Nacht aus den Profilen entfernt, offenbar reicht das nicht. Man kann sie aber auch nicht einfach bei jeder Anmeldung entfernen, denn sollte ein Kollege tatsächlich an zwei Rechnern gleichzeitig angemeldet sein (was recht oft passiert) und an beiden Chrome benutzen zerschießt er damit sein Profil.

[Rüdiger Kupper]

Für Thunderbird und Firefox hatte ich daher einen "Killer-Mechanismus" programmiert, der remote den Prozess auf dem alten Rechner beendet, falls er noch läuft, zur Sicherheit einen Moment wartet und dann erst den neuen Prozess lokal startet. Scheinbar brauchen wir so etwas wieder.
Sehr nervig, es wäre schöner die Entwickler würden einfach ihr Produkt vernünftig gestalten.

Querverweis: #4762

[Rüdiger Kupper]

Nachdem ich mich durch meinen alten Killer-Mechanismus gekämpft habe (ziemlich ausgefeilt aber grauenhaft anzupassen, wenn sich irgendwas ändert) bin ich zu dem Schluss gekommen, dass das zu kompliziert ist.

• Firefox und Thunderbird sind inzwischen Snaps und obwohl darin noch die bekannten Lockfiles angelegt werden, haben diese offenbar keine Bedeutung mehr. (Sie werden beim Schließen auch nicht mehr entfernt, liegen also generell immer im Profil). Wie die Snaps mitteilen, dass das Profil gesperrt ist, konnte ich heute Nachmittag nicht rausfinden. Irgendwie machen sie es :-/.
• Chrome benutzt ein anderes Format für seine Lockfiles, ich hätte den Mechanismus erst wieder darauf anpassen müssen und habe entnervt aufgegeben.

Ich habe mich jetzt für einen eher hässlichen Quick-and-dirty-Fix entschieden:

• Es gibt jetzt ein Skript in /usr/local/sbin/google-chrome. Das steht im Pfad ganz vorne, wird also als erstes ausgeführt. Es löscht schlicht und einfch alle Lockfiles und ruft dann das eigentliche /usr/bin/google-chrome auf.
• Im *.desktop-File habe ich den absoluten Pfad entfernt, so dass beim Klick auf das Symbol nun dieses Skript in /usr/local/sbin aufgerufen wird.

So startet Chrome auf jeden Fall. Falls auf einem anderen Rechner noch ein Chrome-Prozess des Users lief kommt dann allerdings die Meldung, dass es beim Öffnen des Profils einen Fehler gab. Inwieweit sich das auf die Funktionalität auswirkt konnte ich noch nicht herausfinden. Ich habe das Spiel ein paar Mal hin- und her gemacht und irgendwie lief Chrome immer.
Es besteht aber die konkrete Gefahr, dass der Nutzer sein Profil komplett unbrauchbar macht davor warnt auch ausdrücklich Chrome, wenn man es im Terminal aufruft.

Schauen wir also mal, wie lange das gut geht, bis die ersten Nutzer mit defektem Profil kommen.
Jedenfalls überfallen sie mich hoffentlich nicht mehr jede Pause damit, dass sich ihr Browserfenster nicht öffnet …

[Rüdiger Kupper]

Eine bessere Lösung wäre es, beim Anmelden zu prüfen, ob ein Nutzer noch woanders angemeldet ist und ihn dort abzumelden. Dass könnte über einen ähnlichen Mechanismus gehen wie ich ihn damals speziell für FF implementiert hatte. (Kommunikation über das Filesystem und ein Hintergrundprozess, der den Nutzer killt, sobald eine entdprechende Datei auftaucht.)
Das Problem ist nur, dass das so früh wie möglich im Anmeldeprozess passieren müsste, noch bevor die Sitzung des Nutzers richtig startet. Derzeit weiß ich nicht, wie ich das hinbekomme, zumal jetzt mit Wayland.

[bau]

Das passt doch zu dem Script, welches wir anpeilen:
Loggen der Events

• Login eines Users auf einer Maschine
• Logout eines Users von einer Maschine

[Rüdiger Kupper]

Genau, so habe ich es ja mit FF und TB zuvor auch gemacht: man braucht eine Datenquelle, auf die von allen Rechnern zugegriffen werden kann, egal ob sie sich im Schüler- oder Lehrernetz befinden. Da die Sache hier nutzerspezifisch ist ist das Homeverzeichnis ein logischer Ort. Beim Einloggen wird dort eine kleine Datei angelegt mit der IP des Rechners. In allen anderen Instanzen läuft ein Hintergrundjob, der diese Datei sucht und wenn die IP nicht passt weiß er, dass der Nutzer sich zusätzlich auf einem anderen Rechner eingeloggt hat. Und beendet die lokale Sitzung.

Das ist die Theorie, die Praxis ist sehr viel hässlicher:

• Wie beendet man eine Nutzersitzung sauber so schnell wie möglich? Die naheliegende Lösung ist, STRG-ALT-ENTF an die aktuelle Sitzung zu schicken (oder ein programmatisches Äquivalent davon). Dann erscheint aber erst mal der Logoutdiaglog, der 60 Sekunden Zeit lässt. Der Nutzer will am anderen Rechner aber kaum 60 Sekunden lang warten, bis seine alte Sitzung beendet wurde. Und die neue Sitzung davor zu starten ist unsicher.
• Also könnte man auf dem alten Rechner die Sitzung einfach hart killen. Dann ist der Nutzer sofort ausgeloggt, man handelt sich damit aber eine ganze Latte von Problemen ein, von verbleibenden Lockfiles bis zu nicht gespeicherten Änderungen in offenen Dokumenten.
• Das alles muss am neuen Rechner auch noch passieren, bevor überhaupt die graphische Sitzung startet, denn sonst werden alle Dienste beschädigt, die zusammen mit der Sitzung starten. Ein prominentes Beispiel ist der GNOME-Keyring. Der Versuch, den gleichzeitig in zwei verschiedenen Sitzungen zu öffnen führt zur dauerhaften Sperrung aller Passwörter. Den Dialog hat vermutlich jeder schon mal gesehen. Einmal in diesem Zustand kann man den Keyring nur noch löschen und neu anlegen.

Alle üblichen Mechanismen wie Autostart-Files oder *.rc-Dateien greifen erst viel später im Loginprozess und sind damit ungeeignet. Wir müssten uns ganz früh in den Aufbau der Wayland-Session einklinken und ich weiß einfach nicht wie das geht.

[Rüdiger Kupper]

An dieser Stelle finde ich es einfacher, den Kollegen zu verklickern, dass sie sich nach getaner Arbeit ausloggen müssen.

[Rüdiger Kupper]

… und dass das keine Schikane ist, sondern schlicht erforderliches Verhalten.

[Rüdiger Kupper]

An andere Regeln können sich die Kollegen auch halten, z.B. den Klassenraum hinter sich abzuschließen. Sich am Rechner auszuloggen ist nichts anderes.

[bau]

Äh .... NEIN, nicht wirklich - immer wieder kann man beobachten, dass: Fenster offen, Beamer an, Licht an, Tür nicht abgeschlossen, ...

Technische Lösungen sind zuverlässiger!

[bau]

Ich meinte als Quelle: Das Log auf dem Server, wo alle User reingeschrieben werden.

Hattest du das schon probiert:
​https://askubuntu.com/questions/526972/remotely-log-out-of-graphical-gnome-session

  ssh to client
  env DISPLAY=:0.0 gnome-session-quit --logout

[Rüdiger Kupper]

Replying to bau:

Äh .... NEIN, nicht wirklich - immer wieder kann man beobachten, dass: Fenster offen, Beamer an, Licht an, Tür nicht abgeschlossen, ...

Technische Lösungen sind zuverlässiger!

Die allermeisten Klassenraumtüren, auf die ich treffe sind abgeschlossen, im Gegensatz zu sehr vielen Nutzeraccounts.
Würden die Kollegen plötzlich dazu übergehen, massenhaft die Türen offenzulassen wäre unsere Maßnahme auch nicht, Maschinen zu bauen, die die offenen Türen abschließen. Sondern eine klare Aufforderung an die Kollegen.
Wir haben für solche Maschinen auch gar keine Ressourcen und genauso habe ich allmählich keine Ressourcen mehr, den Kollegen hinterherzuarbeiten, die aus reiner Nachlässigkeit ihre Profile beschädigen.

[Rüdiger Kupper]

Replying to bau:

Ich meinte als Quelle: Das Log auf dem Server, wo alle User reingeschrieben werden.

Wir brauchen dafür kein zentrales Log und ich halte das auch aus Datenschutzgründen für problematisch. Das Homeverzeichnis ist sowieso bereits gemountet und es ist nutzerspezifisch also der beste Ort für diese Aufgabe.

Hattest du das schon probiert:
​https://askubuntu.com/questions/526972/remotely-log-out-of-graphical-gnome-session

  ssh to client
  env DISPLAY=:0.0 gnome-session-quit --logout

Unterbindet das die 60 Sekunden Wartezeit? Dann wäre das eine Möglichkeit. -> testen