[gelöst] pam_exec.so - keine Reaktion

[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....

[scientific]

Mir reichts schon wieder.

Leb wohl.