[gelöst] pam_exec.so - keine Reaktion

[TomL]

Moin

Ich habe die folgende Zeile als letzte unten angehängt:

Code: Alles auswählen

grep pam_exec /etc/pam.d/login
session optional  pam_exec.so seteuid /usr/local/bin/LogEntry.sh

Zum Testen obs funktioniert soll dieses Script gestartet werden, welches nur einen Journaleintrag erzeugt:

Code: Alles auswählen

cat /usr/local/bin/LogEntry.sh
#!/bin/bash

echo "(User:$USER) Programm gestartet mit Param.: $1 $2 $3" | systemd-cat -t "thlu:`basename $0`" -p info
exit 0

Aber es passiert gar nix.... keine Fehlermeldung, kein Eintrag, einfach nix. Ich habe mir zig HowTos im Web angesehen, aber im wesentlichen machen die auch nix anderes. Das betroffene Pam-Modul existiert, Pam arbeitet auch grundsätzlich, wie man bei Anmeldung "root" sieht:

Code: Alles auswählen

Jun 16 12:11:42 thomaspc su[17189]: pam_unix(su:session): session opened for user root by (uid=1000)

Ich habe mich ab- und wieder angemeldet, sogar den PC neu gestartet, damit PAM auch wirklich alle Änderungen mitkriegt... und es passiert weiter einfach nix. Das Script ist natürlich ausführbar und macht manuell im Terminal genau was es soll, nur leider nicht via Pam. Was könnte die Ursache sein? Wie geht man am Besten auf die Fehlersuche?

[uname]

Leider kenne ich mich mit Systemd und PAM relativ wenig aus. Aber du könntest mal das Beispiel aus dem unten aufgeführten Link versuchen. Dort gibt es ein anderes Script ohne Systemd und man soll deine PAM-Konfigurationszeile global eintragen. Vielleicht liegt es an Systemd oder daran, dass du pam_login nicht verwendest.

https://blog.stalkr.net/2010/11/login-n ... pting.html

[TomL]

Ich habs gelöst... danke für den Tip..... nun kriege ich login und logout eines Users perfekt mit und kann userabhängige Jobs veranlassen.

Code: Alles auswählen

# journalctl -b | grep thlu | grep sessionctl
Jun 16 14:42:08 thomaspc thlu:sessionctl[4413]: (User:thomas) Programm gestartet mit Param.: PAM_TYPE=open_session  PAM_USER=thomas  PAM_SERVICE=lightdm
Jun 16 14:42:47 thomaspc thlu:sessionctl[4583]: (User:thomas) Programm gestartet mit Param.: PAM_TYPE=close_session  PAM_USER=thomas  PAM_SERVICE=lightdm
Jun 16 14:42:53 thomaspc thlu:sessionctl[4677]: (User:thomas) Programm gestartet mit Param.: PAM_TYPE=open_session  PAM_USER=thomas  PAM_SERVICE=lightdm

Am Ende angefügt

Code: Alles auswählen

cat common-session | grep sessionctl
session required pam_exec.so seteuid /usr/local/bin/sessionctl

Code: Alles auswählen

cat /usr/local/bin/sessionctl
#!/bin/bash
echo "(User:$USER) Programm gestartet mit Param.: PAM_TYPE=$PAM_TYPE  PAM_USER=$PAM_USER  PAM_SERVICE=$PAM_SERVICE" | systemd-cat -t "thlu:`basename $0`" -p info
exit 0

[scientific]

Du kannst userabhängige Jobs auch mit systemd-user-Instanzen starten...

[TomL]

Du kannst userabhängige Jobs auch mit systemd-user-Instanzen starten...

Hast Du dafür mal ein Beispiel... das würde mich sehr interessieren. Es muss den angemeldeten Benutzer berücksichtigen, und das vor dem Hintergrund, dass bei Systemstart nicht bekannt ist, welcher Benutzer sich anmelden wird und ob sich im Laufe der PC-Betriebszeit vielleicht verschiedene Benutzer nacheinander anmelden. Ich habe dafür im Web keine Lösung mit Systemd gefunden, sondern nur Hinweise, dass systemd genau diesen Fall nicht unterstützt.

[scientific]

Dazu eine Frage:
Was genau willst du? Für verschiedene User unterschiedliche Jobs, die in z.B. einem Shell-Skript aufgelistet sind und abgearbeitet werden, oder willst du bestimmte Dienste für die sich einloggenden User unter deren UID starten?

Ich habe hier z.B. mpd für jeden User in einer eigenen Instanz mit der UID des eingeloggten Users laufen.
Und damit mpd nur einmal beim ersten Einloggen gestartet und beim letzten Ausloggen (der User kann ja graphisch, am TTY und auch über ssh gleichzeitig eingeloggt sein) beendet wird, hab ich das über eine systemd-user-Instanz gelöst.

Dazu kommt in das Verzeichnis /etc/systemd/user/ das Service-file
mpd.service

Code: Alles auswählen

[Unit]
Description=Music Player Daemon
Documentation=man:mpd(1) man:mpd.conf(5)
Documentation=file:///usr/share/doc/mpd/user-manual.html
After=network.target sound.target
ConditionPathExists=%h/.config/mpd/mpd.conf

[Service]
ExecStart=/usr/bin/mpd --no-daemon

# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

# more paranoid security settings
NoNewPrivileges=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
# AF_NETLINK is required by libsmbclient, or it will exit() .. *sigh*
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
RestrictNamespaces=yes

# Note that "ProtectKernelModules=yes" is missing in the user unit
# because systemd 232 is unable to reduce its own capabilities
# ("Failed at step CAPABILITIES spawning /usr/bin/mpd: Operation not
# permitted")

[Install]
WantedBy=default.target

f

Und damit es für jeden User aktiviert ist, muss noch ein Symlink nach
/etc/systemd/user/default.target.wants/mpd.service -> ../mpd.service

Debian startet für jeden User der sich einloggt ein Service:
user@$UID.service
Dieses service startet für den User eine systemd --user Instanz. Diese hat ein default.target, und dieses ruft dann für jeden User mpd.service auf. Und das zum Zeitpunkt des ersten Einloggens auf der Maschine.
Wenn sich der User aus der letzten Session ausloggt, wird mpd auch mit dem beenden von user@$UID.service wieder beendet.

Ist das nicht das, was du suchst?

Ich hab über so eine Konstruktion sogar einen Guest-Account gebaut, der beim Login /etc/skelgast nach /home/gast kopiert, und dann die User-Session startet. Beim Ausloggen wird /home/gast wieder gelöscht. Beim erneuten Anmelden steht der User wieder vor einem blanken neuen Profil (das ich natürlich vordefiniert habe).

Das ist so in einem unserer Wohnhäuser seit Monaten erfolgreich für die Bewohner in Betrieb.
Du kannst es dir in meinem Github-Repo bei der guestsession ansehen https://github.com/xundeenergie/guestsession. Vielleicht findest du da eine Anregung für die userspezifischen Jobs.

Aber vielleicht meinst du ja etwas anderes.

[EDIT]
Ich hab grad nochmal nachgeschaut... bei der guestsession hab ich "bloß" zwei Services in Abhängigkeit von user@$UID.service gehängt.
Das heißt, der User meldet sich an, user@$UID.service wird gestartet, und dies wiederum startet zwei services, die als systemd --system laufen.
Verwendest du BindsTo=user@%i.service in der [Unit]-Section, dann wird der Service mit user@$UID.service wieder beendet.

Willst du aber einen Job mit der UID des Users starten, so gilt das, was ich oben für mpd geschrieben habe.
lg scientific

[TomL]

Dazu kommt in das Verzeichnis /etc/systemd/user/ das Service-file
mpd.service

Dein Vorschlag interessiert mich auf jeden Fall.... nur ist das leider soviel Input, dass ich das erst Mal nicht auf die Reihe kriege. Und mein erster Versuch war leider nicht erfolgreich. Die Unit wird zwar beim Systemstart gestartet, aber nicht erneut nach einem User-Login. Schau Dir bitte mein auf Einfachheit runtergebrochenes Beispiel an.... wie kriege ich das ans Laufen?

Hier in dem Beispiel soll NUR ein Logeintrag erstellt werden, wenn sich der User anmeldet. Nur passiert das leider nicht, sondern nur 1 Eintrag beim Boot.

cat /etc/systemd/system/log-entry.service

Code: Alles auswählen

[Unit]
Description=Startet, bei User-Login

[Service]
RemainAfterExit=yes
Type=simple
ExecStart=/usr/local/bin/LogEntry start systemd
ExecStop=/usr/local/bin/LogEntry stop systemd

[Install]
WantedBy=default.target

cat /usr/local/bin/LogEntry

Code: Alles auswählen

#!/bin/bash

echo "Programm gestartet mit Param.: $1 $2 $3" | systemd-cat -t "thlu:`basename $0`" -p info
exit 0

ls /etc/systemd/user/default.target.wants

Code: Alles auswählen

insgesamt 8,0K
drwxr-xr-x 2 root root 4,0K 2017-06-17 10:12 .
drwxr-xr-x 3 root root 4,0K 2017-06-17 10:11 ..
lrwxrwxrwx 1 root root   37 2017-06-17 10:12 log-entry.service -> /etc/systemd/system/log-entry.service

[scientific]

Das glaube ich auch gerne... denn du hast das als in der systemd --system-Instanz gemacht.

cat /etc/systemd/system/log-entry.service

Code: Alles auswählen

    [Unit]
    Description=Startet, bei User-Login

    [Service]
    RemainAfterExit=yes
    Type=simple
    ExecStart=/usr/local/bin/LogEntry start systemd
    ExecStop=/usr/local/bin/LogEntry stop systemd

    [Install]
    WantedBy=default.target

Das gehört nach /etc/systemd/user/ nicht nach /etc/systemd/system

Und dann wechselst du nach

Code: Alles auswählen

cd /etc/systemd/user/default.target.wants

Falls dieses Verzeichnis noch nicht existiert, musst du es noch anlegen!

und dann legst du einen Symlink an

Code: Alles auswählen

ln -s ../log-entry.service

Logge dich danach ganz aus (auch von ssh und von den TTYs, falls du da eingeloggt bist), und logge dich erneut ein.

Aber Achtung!!! Der Befehl von ExecStart= wird unter der UID des eingeloggten Users ausgeführt. Das könnte ev. zu Rechteproblemen führen, wenn verschiedene User in die selbe Log-Datei schreiben wollen!
Du kannst ins Log auch mit systemd-cat schreiben.

Code: Alles auswählen

echo bla|systemd-cat -t testeintrag

ergibt

Code: Alles auswählen

Jun 17 13:04:47 aldebaran testeintrag[17184]: bla

lg scientific

[scientific]

Noch eine Ergänzung:

Diese Lösung legt beim ersten Login eines Users einen Eintrag an. Wenn du schon eingeloggt bist, und dich ein zweites Mal (z.B. auf TTY4) einloggst, wird kein Logeintrag angelegt.
Loggst du dich aus allen Sessions aus (loginctl ergibt für den User keinen Eintrag mehr), und loggst dich dann wieder ein, wird das Service wieder ausgeführt.

lg scientific

[scientific]

So ich habs gerade erfolgreich getestet:

Code: Alles auswählen

# cat /etc/systemd/user/log-entry.service 
[Unit]
[Service]
ExecStart=/bin/sh -c "echo BLA"

Code: Alles auswählen

cd /etc/systemd/user/default-target.wants

Code: Alles auswählen

ln -s ../log-entry.service

Hab mich auf TTY3 mit dem zweiten am Rechner vorhandenen User eingeloggt.
Das Journal spuckt das aus:

Code: Alles auswählen

Jun 17 13:10:43 aldebaran sh[18966]: BLA

Hab mich auf TTY4 ein weiteres Mal mit diesem User eingeloggt. Kein Journal-Eintrag.
Hab mit

Code: Alles auswählen

loginctl kill-user user2

alle Sessions von user2 gekillt
Erneut auf TTY3 eingeloggt, wieder der selbe Logeintrag nach dem Login.

lg scientific

[TomL]

Aber Achtung!!! Der Befehl von ExecStart= wird unter der UID des eingeloggten Users ausgeführt. Das könnte ev. zu Rechteproblemen führen, wenn verschiedene User in die selbe Log-Datei schreiben wollen!

Nein, kann nicht passieren... schau aufs aufgerufene Script, das schreibt ins Journal

So ich habs gerade erfolgreich getestet:

Bei mir funktioniert das einfach nicht

Und dann wechselst du nach

Code: Alles auswählen

cd /etc/systemd/user/default.target.wants

Falls dieses Verzeichnis noch nicht existiert, musst du es noch anlegen!

Code: Alles auswählen

cd /etc/systemd/user/default-target.wants

Das sind zwei Beispiele mit unterschiedlicher Schreibweise... ich vermute mal, mit "-" ist falsch. Aber mit "." funktioniert es bei mir auch nicht.

Code: Alles auswählen

ln -s ../log-entry.service

Kein Logeintrag. Abmelden, Reboot... nix... kein Logeintrag.

Lediglich das funktioniert. Aber für jeden User einen Link auf allen Rechnern anzulegen schließe ich aus

Code: Alles auswählen

systemctl --user enable log-entry.service
Created symlink /home/thomas/.config/systemd/user/default.target.wants/log-entry.service → /etc/systemd/user/log-entry.service.

Ich habe mich ja schon öfter damit beschäftigt.... aber ein pauschaler für alle User geltender SymLink, wie Du ihn eingerichtet hast, geht hier nicht. So richtig verstehen kann ichs nicht.... Deine Befehle hier zu kopieren und an richtiger Stelle einzufügen.... das krieg ich schon hin... aber es klappt einfach nicht. Als wenn

Code: Alles auswählen

ls /etc/systemd/user/default.target.wants
lrwxrwxrwx 1 root root   35 2017-06-17 16:15 log-entry.service -> /etc/systemd/user/log-entry.service

keine Beachtung finden würde.

[scientific]

Ja stimmt. Die Schreibweise mit - ist die falsche.

Was sagt denn

Code: Alles auswählen

 
systemctl status user@1000.service

Ich nehme an, die UID deines Users ist 1000

[TomL]

Kommando zurück.... es läuft

Das klappt bestens... ich krieg Login und Logout mit........

Code: Alles auswählen

[Unit]
Description=Startet bei User-Login und Logout

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/bin/sh -c "echo START"
ExecStop=/bin/sh -c "echo STOP"

[Install]
WantedBy=default.target

Ob das mit vollständigem Pfad zusammenhängt...?... keine Ahnung... aber danach ging es:

Code: Alles auswählen

ln -s /etc/systemd/user/log-entry.service /etc/systemd/user/default.target.wants

Das sind jetzt weitere Möglichkeiten für mich... gleichwertig neben PAM.... da muss ich mal drüber nachdenken, was letzten Endes besser geeignet ist.

[scientific]

Na wunderbar!

Freut mich, dass es so einfach ging

Lg scientific

[TomL]

Na, einfach ist anders.... *lacht*... aber ich freu mich, dass es geht.... ... das war auf jeden Fall hilfreich

Nur weiss ich leider jetzt schon... seit ein paar Sekunden... dass es mein spezielles Problem nicht lösen wird. Nach meinem kurzen Gespräch mit smutbert und der neuen Erkenntnis, dass ich ACLs gleichzeitig mit tradtionellen Rechten nutzen kann, habe ich mich entschieden, mein Rechtesystem zu reformieren. Ich will eine weitere Reduzierung des Customizings bei den Clients erreichen und auf den Standard kommen, dass auf den Clients lediglich die lokale Einrichtung der User plus zwei, drei kopierter Standard-Files ausreichen müssen, damit für jeden User ad hoc bei der Anmeldung NUR seine erforderlichen Remote-Mounts erfolgen und der Sambaserver auch andere Verbindung ablehnen kann. Warum das alles....?

Fakt ist, das Handling bei dynamischen Remote-Mounts an Systemen mit mehreren Usern ist ein Desaster, unausgereift, von vorne bis hinten mit Problemen behaftet.

• Die fstab (resp. die Prozesse dahinter) kann nicht per default die Erreichbarkeit eines Ziels (der tatsächliche Server) feststellen
• Die fstab kann nicht ein Remote-Laufwerk flexibel mit den Rechten des jetzt aktiven Users mounten, wenn es Multiuser-Systeme sind
• Alle Mounts müssen bei Systemstart mit dem höchsten irgendwann gebrauchten Recht gemountet werden, auch wenn ein "späterer" User einzlene Mounts gar nicht benötigt, weswegen dann wieder mit neuem Aufwand (Gruppen u. Rechte) lokal eingeschränkt werden muss.
• Die fstab kann nicht vom User nicht-benötigte Remote-Laufwerk nicht mounten, sie mountet immer alles, auch die Laufwerke, auf die ein User samba-seitig gar keine Zugriffsrechte hätte. Es wurde ja mit dem höchsten Recht gemountet, eben wg. berechtigter User
• Es müssen bei Systemstart auch die Laufwerke gemountet werden, die von einzelnen Usern gar nicht benötigt werden.
• Das Handling zwischen Remote-Mounts und WLAN-Connects und NWM endet regelmäßig in ewigen Stop-Jobs
• Bei Multiuser-Systemen sieht der Server fast nie, wer tatsächlich ein beim Client-Systemstart gemountetes Laufwerk verwendet, er sieht nur den, der es gemountet hat - selbt dann, wenn sich zwischendurch mehrere andere User angemeldet haben.
• Automounts lösen nicht das Problem, dass ein spezielloer User samba-seits möglicherweise für eine Ressource gar nicht berechtigt ist, wenn der automount wieder mit einem anderen berechtigten User in der fstab durchgeführt wird.

Ich habe all diese Probleme jetzt gelöst... und zwar mit PAM. Ein PAM-Login unterscheidet das, zwar zwingend unterschieden werden muss, nämlich was es für ein Login ist, via "su", Terminal-Login oder Displaymanager. Das geht anscheinend mit der systemd-lösung leider nicht. Ich bin ja dabei, meinen neuen Banana PI als Ablöse für den bisherigen als Server eingesetzten RPi vorzubereiten. Und da will ich die Gelegenheit nutzen, alte Schwächen zu bereinigen.

Danke für die Lehrstunde...

[scientific]

Ja mit pam kann man auch sehr schöne Dinge anstellen.

Nur versteh ich dein Problem mit den mounts nicht...

Aber das macht nix. Da denken wir zu unterschiedlich

Lg scientific

[TomL]

Nur versteh ich dein Problem mit den mounts nicht...

Das ist ganz einfach. Wie mountest Du ein Laufwerk, wenn sich mehrere User an einem PC anmelden können und einige User haben als Recht auf den Share "RW" und einige User haben "R-"?
Und dann gibt es einen zweiten Share, wo sich die Anwender-Rechte möglicherweise vertauschen (nicht zwingend, aber kann). Als Beispiel:

Code: Alles auswählen

            Share1      Share2
User1       RW          R-
User2       R-          RW
User3       R-          R-

Dieses Modell geht doch nur, wenn nun noch ein vierter User eingerichtet wird, der eigentlich gar nicht notwendig ist, der aber beide Shares erst mal mit kompletten Rechten mounten kann/darf/muss, um dann die Rechte lokal am Client wieder zu filetieren und user- oder groupbezogen zu setzen. Samba-Rechte auf dem Server greifen für die User1, User2 und User3 gar nicht, weil Samba diese User gar nicht sieht, sondern nur den ominösen vierten User.

Ich kann nicht im fstab-Mount oder einer Mount-Unit unterscheiden kann, wer was darf und das entsprechend einschränken, also muss ich immer einen zusätzlichen User haben, der zwischen Enduser und Samba quasi ein Interface mit der Berechtigung zum Voll-Recht-Mount darstellt. Das ist doch totaler Mist und völlig unnötiger Aufwand.

Wenn jedoch jeder User mit seinen eigenen Credentials selber Samba-Client wird, habe ich auf dem Samba-Server für alle Rechner und alle User eine einzige zentrale Stelle des Rechte-Customizings und muss mir keine Gedanken mehr über noch ein zusätzliches Rechtemanagement auf jedem Client-PC für jeden User machen. Jeder User kann dann selber den Share ruhig RW mounten, Samba wird ihm schon mitteilen, was geht. Das geht aber nicht, weil fstab und Mount-Units statisch sind, User individuell nicht berücksichtigen und nur einmal bei Systemstart bearbeitet werden - ein Zeitpunkt also, wo gar nicht bekannt ist, welcher User sich anmeldet.

Erkläre mir einfach, wie man das anders oder besser regelt... oder wie man richtig mountet. Ich bin dankbar für jeden Tip der es verbessert.

[scientific]

Ach so.

Gut, ich muss gestehen, ich bin in die Materie Samba nie so tief mangels Bedarf und Testmöglichkeit eingestiegen...

Ich vermute aber, dass man in Samba pro User Berechtigungen pro Share geben können wird. Das würde ich sowieso am Samba-Server festlegen und nicht auf einzelnen Clients.

Ich würds jetzt einmal so probieren:

User1 hat in seinem Home einen Mountpoint ~/server1/share1
User2 hat in seinem Home einen Mountpoint ~/server1/share1

Das ist am Server ja das selbe share, aber jeder User mountet das für sich mit seinen Credentials.

Also kommt in die /etc/fstab

Code: Alles auswählen

//192.168.1.100/share1 /home/user1/server1/share1 cifs credentials=/home/user1/.smbcredentials  0 0
//192.168.1.100/share1 /home/user2/server1/share1 cifs credentials=/home/user2/.smbcredentials  0 0

Wobei ich momentan nicht sagen kann, ob zweimal das selbe Share in der ersten Spalte der fstab ein Problem ist. Müsst ich selber einmal testen.

Jedenfalls daraus abgeleitet ergibt das zwei systemd-mount-units:
home-user1-server1-share1.mount
home-user2-server1-share1.mount

Dazupassend würd ich mir zwei automount-Einträge (und auch die keep-alive@.service wie im Thread von jue erläutert und erklärt) dazubauen.
(Die Einträge in der fstab würd ich danach wieder auskommentieren, wenn du die Mountunits aus /run/systemd/generator/ nach /etc/systemd/system/ kopiert hast!!!)

In die Mount-Units muss noch ein

Code: Alles auswählen

After=network-online.target

, sofern es nicht eh schon drin ist, und

Code: Alles auswählen

systemctl enable NetworkManager-wait-online.service

Das Enablen von NetworkManager-wait-online.service hat aber auch einen mglw. unguten Nebeneffekt. Denn diese Unit stellt sicher, dass die Units, die zwingend eine funktionierende Netzwerkverbindung benötigen (z.b. wenn man gdm mit remote-Login ermöglichen will, oder die Home-Verzeichnisse von einem Remote-Server mountet) erst dann gestartet werden, wenn die Netzwerkverbindung steht. Das kann starke Verzögerungen beim Booten verursachen!!!
Aber das erlaubt eben auch, dass remote-Filesysteme die eine Abhängigkeit zu network-online.target haben, wirklich sicher gemountet werden können, ohne das ganze System zu blockieren.

Ich hoffe, du kannst meinen Ausführungen folgen.

Alternativ kannst du natürlich auch eine ganz "normale" systemd --user Serviceunit bauen, welche smbmount direkt aufruft und eine Abhängigkeit zu network-online.target hat.

lg scientific

[TomL]

Ich würds jetzt einmal so probieren:
User1 hat in seinem Home einen Mountpoint ~/server1/share1
User2 hat in seinem Home einen Mountpoint ~/server1/share1

Das ist am Server ja das selbe share, aber jeder User mountet das für sich mit seinen Credentials.

Also kommt in die /etc/fstab

Code: Alles auswählen

//192.168.1.100/share1 /home/user1/server1/share1 cifs credentials=/home/user1/.smbcredentials  0 0
//192.168.1.100/share1 /home/user2/server1/share1 cifs credentials=/home/user2/.smbcredentials  0 0

Das mag wohl funktionieren, aber Dir sollte klar sein, dass so etwas völlig unpraktikabel ist. Ich mounte doch nicht Publicshares wie ein gemeinsames Work-Dir oder ein MultiMedia-Dir alles ins Homeverzeichnis der User, die gehören imho nach /media. Stell Dir vor, Du hättest 25 User und 10 Mountpoints.... richtest Du dann bei jedem Systemstart 250 Mountpoints ein, weil sich jeder der 25 User anmelden könnte und einen der Mountpoints gebrauchen könnte? Darüber hinaus ist das auch theoretisch völlig ungeeignet, weil Du das ja bei jedem Client machen müsstest. Wie hoch soll denn da der Arbeitsaufwand sein, wenn es eine Benutzerfluktuation gäbe. Natürlich habe ich hier sowas nicht, insofern ist das nur theoretisch ungeeignet... aber mit so einer Lösung käme ich überhaupt nicht klar. Und die Client-PCs individuell zu customizen wäre ja fast ein Fulltime-Job.... das macht doch alles nur Sinn, wenn die PCs nach einem einfachen Standard aufgesetzt sind, der minimalen Aufwand benötigt.

Ich habe hier den Anspruch, wenn eine Lösung für Großes funktioniert, funktioniert sie auch für Kleines. Wobei man natürlich nicht das Verhältnis auf Aufwand und Ergebnis aus den Augen verlieren sollte.

[scientific]

Ich hab gerade eine spannende Erläuterung über systemd, network.target, usw. gefunden, wie es sicherstellt, dass eine Verbindung auch tatsächlich aufgebaut ist, wenn sich ein Service auf network.target bezieht...

Weiß nicht, wie gut dein Englisch ist.
https://unix.stackexchange.com/question ... as-started

Kurz zusammengefasst, eine Unit die sich eine funktioniernede Netzwerkverbindung voraussetzt, benötigt diese Einträge

Code: Alles auswählen

[Unit]
Wants=network-online.target
After=network-online.target

Das sollte reichen.

lg scientific

[TomL]

Weiß nicht, wie gut dein Englisch ist.
https://unix.stackexchange.com/question ... as-started
Kurz zusammengefasst, eine Unit die sich eine funktioniernede Netzwerkverbindung voraussetzt, benötigt diese Einträge

Gut genug, um zu verstehen, dass das nicht aussreicht.... außerdem hatten wir exakt das gleiche an anderer Stelle schon einmal angesprochen.

Das Problem ist, es gibt KEINE abschließende Definition, was network-online.target überhaupt bedeutet, weil es im Ermessen von Diensten -z.B. des NWM- liegt, das Target nach Belieben als "erreicht" zu definieren.

Beschreibt das Target vielleicht,
- das Netzwerk wurde gestartet?
- der Networkmanager wurde gestartet?
- ein Netzwerk ist technisch verbunden, aber noch nicht via TCP/IP?
- eine IP-Adresse via DHCPD wurde angefordert?
- eine bestimmte Netzwerk-Ressource -z.B. die IP des Samba-Servers- ist erreichbar? (nee, das garantiert nicht!)

/etc/init.dnetworking, NWM, systemd-networkd oder ein einfaches 'ip link set dev eth0 up' + 'dhclient -v eth0' ... all diese Jobs öffnen das Netzwerk.... wer wann woduch das genannte target anzieht, bleibt ihm überlassen.... ich ziehe das beispielsweise gar nicht an.... eben, weils eh nix aussagt.....

Aber das hatte ich Dir in dem Thread vor Wochen auch schon erzählt... plus Link ... da stehts gleich oben an. Und selbst die dort beschriebene Lösung, die nur mit systemd-networkd funktioniert, sagt überhaupt nix darüber aus, ob das Ziel (der samba-server) tatsächlich erreichbar ist, sondern nur das irgendein Netz verbunden ist.... eben auch das bei McDonalds Cafe... wo die fstab dann garantiert failed....

[scientific]

Dann bau doch eine Service-Unit a la NetworkManager-wait-online.service, die aber prüft, ob ein bestimmter Server erreichbar ist und mache deine Mounts davon abhängig.

Ich hab mir das grad gebaut und erfolgreich getestet:

Code: Alles auswählen

# cat /etc/systemd/system/server-wait-online@.service 
[Unit]
Requires=network-online.target
After=network-online.target

[Service]
Type=oneshot
Environment=COUNT=10
ExecStart=/bin/sh -c 'for i in $(seq 1 $COUNT);do ping %I -c 1 2>/dev/null|grep "packets transmitted" -q && exit 0; sleep 1; done; exit 1'

In das servicefile von minidlna habe ich probehalber das eingebaut

Code: Alles auswählen

Requires=server-wait-online@localhost.service
After=server-wait-online@localhost.service

Daemon neu laden und minidlna restart, erfolgreich.

Ändere ich localhost in Requires= auf einen nicht existenten Host, dann verzögert sich der Start von minidlna um 10 Sekunden (eingestellt in COUNT) und failed dann.

Die Zeilen oben

Code: Alles auswählen

Requires=network-online.target
After=network-online.target

prüfen, ob eine Netzwerkverbindung erfolgreich aufgebaut wurde, bevor geprüft wird, ob der bestimmte Server erreichbar ist.

Statt localhost kannst du natürlich jede beliebige IP-Adresse (ipv4) oder andere Serveradresse (z.B. den Router, den Dateiserver im LAN oder Googles Nameserver 8.8.8. einsetzen.

Hilft das?

lg scientific

[TomL]

Dann bau doch eine Service-Unit a la NetworkManager-wait-online.service, die aber prüft, ob ein bestimmter Server erreichbar ist und mache deine Mounts davon abhängig.

Ich hab mir das grad gebaut und erfolgreich getestet:

Ich habe das Gefühl, dass Du nur oberflächlich liest... und als ich das damals schon mal gesagt habe, warste fast beleidigt. Also wiederhole ich mich jetzt noch mal.... eine Mount-Unit wird beim Boot des systems gestartet... welche Laufwerke soll ich mit welchen Rechten mounten, wenn ich zu dem Zeitpunkt gar nicht weiss, welcher User sich anmeldet? Das steht doch bereits 2 mal weiter oben, mit Beispielen erklärt, warum das so nicht geht. Und einfach alles zu mounten mit allen Rechten mach ich doch jetzt schon .... ein absolut unbefriedigendes Dilemma, was ich unbedingt beheben will. Ich habe -als weiteres unbequemes Problem- einen virtuellen User Inet, der sich seinen eigenen Home-Daten-Share des Servers in sein lokales Homedir mountet. In diesem Home-Daten-Share betreibt dieser User den JDL2. Wenn dieser User sich anmeldet, versucht er auch alles zu mounten, aber Samba kloppt im ordentlich auf die Finger. Ich habe doch jetzt keinen Bock, für solche "kritische" Software dieses User, die in einer abgetrennten Umgebung läuft ein riesen Heckmeck zu veranstalten, nur damit dieser User eben nix darf, aber jeder andere, der sich anmeldet schon und das deshalb alles pemanent gemountet sein muss.

Und das Beispiel mit dem User-Mount funktioniert auch nicht, weil ein zweiter User (z.B. ich per SSH) nicht einfach seine Mounts in /media über die des angemeldeten Users klatschen darf. Was für eine komplizierte Logik soll man denn da aufbauen und pflegen, damit das mit systemd konfliktfrei läuft....?... das geht doch alles gar nicht.

Richte doch einfach mal einen Samba-Server für 10 User und 10 Mountpoints an beliebige Client-Rechner ein, wo jeder User sich jeden Laptop schnappen kann. Und dann eben so, dass z.B. ein User mit einem eigenen Windows-Zocker-PC zwar auf das Multimedia-Laufwerk zugreifen darf, aber nur readonly.... und dann noch, dass Laptops mal im Home-Netz sind, aber eben auch im Uni-Netz, oder bei McDonalds, aber via OpenVPN dann doch wieder im Netz (das heisst, der Connect zum Server kommt irgendwann).... und zum Schluss noch, dass Laptops mit Connect im Garten und deshalb schlechtem WLAN-Empfang fast 25 Sekunden bis zur IP benötigen.... machs einfach, dann reden mal weiter....

Was wäre wenn und hätte, würde, könnte bringt doch jetzt alles nix... ich habe den Thread auf "gelöst" gesetzt.... nen Pudding an die Wand zu nageln ist Zeitverschwendung.

[scientific]

Zum Thema des oberflächlichen Lesens geh ich mal nur soweit ein, als dass sich jeder selber an der Nase packen darf.

Du schriebst, dass network.target und network-online.target nicht prüfen, ob ein Server erreichbar ist, und daher als Abhängigkeit für Mounts nicht taugen

Ich hab jetzt eine auf jeden beliebigen Server anpassbare Unit gebaut, die du als Abhängigkeit statt network-online.target oder network.target verwenden kannst, die prüft, ob ein Server erreichbar ist, oder nicht und denentsprechend die Unit gestartet werden kann oder failed.

Alles weitere überlege dir bitte selber.

Ich klinke mich wieder aus. Dein Oberlehrerton behagt mir nicht. Ich hab heute frei, es ist Sonntag. Stretch wurde released und ich werde das mit einer kleinen Grillparty feiern.

lg scientific

[TomL]

Du schriebst, dass network.target und network-online.target nicht prüfen, ob ein Server erreichbar ist, und daher als Abhängigkeit für Mounts nicht taugen

Das Problem habe ich seit langem gelöst... und auch das hatte ich Dir schon mal gesagt... da war ich mittlerweile schon bei Version 5.0...
viewtopic.php?f=34&t=164467&p=1124762#p1124749

Ich bin kein Oberlehrer.... aber ich versuche ein reales Problem zu lösen, kein theoretisches..... und es ist schlichtweg blöd, wenn ich mich ständig wiederholen muss, weil Du immer nur ein Detail-Problem löst, was für sich alleine OK ist. Aber Du ignorierst dabei, dass es im Kontext des großen Ganzen eben so nicht funktioniert, weil andere Rahmenbedingungen das beeinflussen, oder verhindern, oder einfach nur sinnlos machen....