Linuxclient:mehrfachanmeldung unterbinden

Clientpflege Linuxclient
1

Hallo miteinander, hallo Tobias,

gerade versuche ich, dies auf HULC / Kubuntu 14.04 / Ubuntu 16.04? / KDE Neon? zu übertragen
http://www.linuxmuster.net/wiki/anwenderwiki:linuxclient:mehrfachanmeldung

Inzwischen hat sich ja einiges geändert.

Als Position für mehrfachanmeldung.sh habe ich /usr/local/bin gewählt.
Der Aufruf erfolgt aus /etc/xdg/autostart/Mehrfachanmeldung.desktop.
(etc/linuxmuster-client/post-mount.d/020-mehrfachanmeldung ging nicht.)

Der richtige Pfad ist $HOME/Home_auf_Server/.userlock
Es muss lightdm neu gestartet werden, wenn .userlock vorhanden ist.

Es wird jetzt nach dem Anmelden eine .userlock angelegt.
Wenn diese vorhanden ist, wird nach der Anmeldung das Fenster mit dem Fehler 5 s lang angezeigt und danach fliegt man raus.

Leider klappt es beim Abmelden wie oben auch nicht, .userlock mit /etc/linuxmuster-client/pre-umount.d/000-mehrfachanmeldung zu löschen. Das Kommando rm $HOME/Home_auf_Server/.userlock von der Konsole aus tut es. Offenbar wird das Skript nicht ausgeführt.

Gesucht ist jetzt eine geeignete Stelle, wo der Löschbefehl ausgeführt wird.

Desweiteren sollte die Sperrdatei vom Lehrer gelöscht werden können, wenn sichergestellt ist, dass niemand mehr mit dem gesperrten Benutzerkonto angemeldet ist (z. B. nach einem harten Ausschalten).

Oder ist das ganze Bastelkram, der durch eine professionellere Lösung ersetzt ist?

[homes]
maxconnections=1

in /etc/samba/smb.conf.shares ist keine Lösung für Linux, sondern eher Teil des Problems, wenn es dafür sorgt, dass Home_auf_Server nicht eingehängt wird, und die Benutzer sich dann den mountpoint zumüllen …

Außerdem würde damit der hier beschriebene Lösungsansatz verhindert, denn um .userlock zu finden, muss Home_auf_Server kurz ein zweites Mal eingehängt werden.

Wer hilft mir weiter?

Gruß Jürgen

2

Hallo Jürgen,

gerade versuche ich, dies auf HULC / Kubuntu 14.04 / Ubuntu 16.04? / KDE
Neon? zu übertragen
anwenderwiki:linuxclient:mehrfachanmeldung [CommunityWiki]

Imho ist das outdated.

Der richtige Pfad ist $HOME/Home_auf_Server/.userlock
Es muss lightdm neu gestartet werden, wenn .userlock vorhanden ist.

Ja, hatte ich doch Recht. denn das mit der .userlock ist die alte Variante.

Oder ist das ganze Bastelkram, der durch eine professionellere Lösung
ersetzt ist?

Ob professioneller weiß ich nicht, aber es funktioniert jetzt anders.
Ich weiß nicht, ob das im Wiki dokumentiert ist, aber vielleicht bei
Jeskos Skripten im Github?!?

Ich kann dir aber auch meine Doku zu 12.04 mal raussuchen, da hab ich
das bereits anders umgesetzt.

Viele Grüße
Steffen

3

Hallo Steffen,

klar bin ich an Deiner Umsetzung in 12.04 interessiert :slight_smile:

Gruß Jürgen

4

Hallo was hat sich daraus ergeben die Umsetzung interessiert mich auch und wie komme ich
an

MfG
Wolfgang

5

Huhu :slight_smile:

mein Github ist: https://github.com/anschuetz/linuxmuster
Liebe Grüße Jesko

6

Bedankt
Wolfgang

7

Hallo Steffen,

die “outdated” Lösung (für 10.04) scheitert bei mir ja nur daran, dass ich in HULC (Kubuntu 14.04) .userlock in Home_auf_Server nicht gelöscht bekomme.
Offenbar wird mein Skript in /etc/linuxmuster/pre-umount.d nicht aufgeführt. Andere Skripte wahrscheinlich auch nicht?!
Verantwortlich hierfür soll /usr/sbin/linuxmuster-pam-umount sein, dass lt. der zweiten Stelle im Wiki zurzeit nicht benutzt wird!?
http://www.linuxmuster.net/wiki/dokumentation:handbuch51:clients:ubuntu:1204:linuxmuster-client-shares
https://www.linuxmuster.net/wiki/entwicklung:linuxclient:linuxmuster-client-shares

Wenn ich das Skript nach ~/.kde/shutdown kopiere, wird es beim Abmelden ausgeführt, nicht jedoch beim Herunterfahren (was die SchülerInnen üblicherweise am Ende einer Stunde ja eher tun).

Wie bekomme ich das Skript in /etc/linuxmuster/pre-umount.d zum Laufen?
Hat das womöglich was mit KDE zu tun und bislang hat keiner gemerkt, das es dort nicht funktioniert?

Gruß Jürgen

8

Hallo miteinander, hallo Jesko,

offenbar haben nur meine (neuen) eigenen Skripte in /etc/linuxmuster-client/pre-umount.d oder ~/.kde/shutdown nicht richtig funktioniert. Inzwischen versuche ich mit Jeskos “doppelanmeldung” zu verhindern, dass sich mehrere Benutzer ein Konto “teilen”.
Der cron-Job wird auch ausgeführt, eine Doppelanmeldung wird erkannt, eine email zu versenden versucht, aber im Postfach von administrator finde ich folgendes.

— schnipp —
Reporting-MTA: dns; server.linuxmuster-net.lokal
X-Postfix-Queue-ID: 1CF122002A8
X-Postfix-Sender: rfc822; root@linuxmuster-net.lokal
Arrival-Date: Wed, 31 May 2017 18:40:03 +0200 (CEST)

Final-Recipient: rfc822; administrator@server
Original-Recipient: rfc822;administrator@server
Action: failed
Status: 5.4.6
Diagnostic-Code: X-Postfix; mail for server loops back to myself
— schnapp —

und
— schnipp —
Host key verification failed.
Host key verification failed.
— schnapp —

Der Inhalt der ersten email ist richtig. Die herunter zu fahrenden Rechner stimmen. Vielleicht würde es reichen, eine andere Adresse (nach “draußen” geht vermutlich nicht, da dies nicht eingerichtet ist) oder administrator@linuxmuster-lokal.net in doppelanmeldung einzutragen?

Aus der zweiten email ist zu schließen, dass ich irgendeinen Schlüssel auf die Clients kopieren müsste, damit die passwortlose Anmeldung als root funktioniert?
https://www.linuxmuster.net/wiki/anwenderwiki:linuxclient:defaultcloop_14.04#ssh_-_zugriff_vom_server_passwortlos_per_zertifikat

Gruß Jürgen

9

Hallo Jürgen,

Aus der zweiten email ist zu schließen, dass ich irgendeinen Schlüssel
auf die Clients kopieren müsste, damit die passwortlose Anmeldung als
root funktioniert?
anwenderwiki:linuxclient:defaultcloop_14.04 [CommunityWiki]

ja, genau.

LG

Holger

10

Hallo Holger,

in der Tat fehlte der oben beschriebene public key. Jetzt funktioniert ssh als root vom server auf den client und ich kann den client mit shutdown -h now herunterfahren.
doppelanmeldung stößt jedoch immer noch nur Drohungen aus, denen keine Taten folgen :frowning:
neustart=1 ist gesetzt.
administrator bekommt weiterhin eine email

— schnipp —
Host key verification failed.
Host key verification failed.
— schnapp —

Wo soll ich den Fehler als nächstes suchen?

Gruß Jürgen

11

Hallo Holger, hallo Jesko,

nachdem ich in doppelanmeldung die Zieladresse “administrator@server” in “administrator” geändert und debug=1 gesetzt habe, kommt diese email korrekt an.
— schnipp —
ssh root@vlz-s163.linuxmuster-net.lokal reboot
ssh root@vlz-s164.linuxmuster-net.lokal reboot
— schnapp —

Sie zeigt auch, woran es noch scheitert:
Die Rechner sind dem server ohne ohne Domänennamen als known_hosts bekannt.
Wenn ich
ssh root@vlz-s163.linuxmuster-net.lokal reboot
als root auf dem server eingebe, muss ich erst zustimmen, damit dieser Rechnername in known_hosts aufgenommen wird.

Wie sorge ich dafür, dass doppelanmeldung den Kurznamen nimmt?

Gruß Jürgen

12

Hallo Jürgen,

Sie zeigt auch, woran es noch scheitert:
Die Rechner sind dem server ohne ohne Domänennamen als known_hosts bekannt.
Wenn ich
ssh root@vlz-s163.linuxmuster-net.lokal reboot
als root auf dem server eingebe, muss ich erst zustimmen, damit dieser
Rechnername in known_hosts aufgenommen wird.

die Frage kommt doch pro Rechner nur einmal, oder?
Versuch es also gerade nochmal

LG

Holger

13

Hallo Holger,

schon richtig: Wenn ich es einmal von Hand mache und “yes” eintippe, geht es.

Aber dann müsste ich jeden der 140 Clients einmal antreffen! Geht das auch anders?

(Außerdem denke ich, dass Jeskos Skript auch anderswo deshalb versagen könnte).

Gruß Jürgen

14

Hallo Jesko,

nachdem das Authentifizierungsproblem weitgehend gelöst ist, indem ich von server aus auf jeden laufenden Client in den Unterrichtsräumen einmal eine ssh-Sitzung aufgrufen und dabei den Schlüssel akzeptiert habe, zeigt sich folgendes Verhalten. Dabei ist die Zahl jeweils das letzte Oktett der IP in Dezimalschreibweise.

164 zuerst angemeldet, dann 163

164 bekommt die erste Meldung, 163 nicht.
163 fährt sofort runter.
164 bekommt die zweite Meldung, fährt jedoch nicht runter.
Bei erneutem Anmelden an 163 fliegt man sofort wieder raus.

163 zuerst angemeldet, dann 164

163 bekommt die erste Meldung, 164 nicht.
(mit debug=1 viel später als /tmp/doppelanmeldung/engelaju existiert)
Erste Meldung kommt nach Neustart, obwohl in /tmp/doppelanmeldung geöscht, bei nur einer Anmeldung
Nach 2 min fährt 163 runter.
Erneutes Anmelden nicht möglich (bootet 2*)

164 abgemeldet

Weiterhin keine Anmeldung möglich.

Automatisches Löschen von /tmp/doppelanmeldung/engelaju klappt nicht.

Wie soll ich weiter debuggen?

Gruß Jürgen