pam_mount.conf.xml Fehlermeldungen unterdrücken

Hinweis: In dem Thema pam_mount.conf.xml Fehlermeldungen unterdrücken gibt es 6 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Hallo Allerseits, folgendes Problem möchte ich der geschätzten Community antragen:


    Unsere Opensuse-Clients (42.2) sollen sich via PAM am AD anmelden und ein Netzwerkverzeichnis für den User einbinden - das funktioniert auch. Da sich die Verzeichnisse auf verschiedenen Serverpfaden befinden muss ich mehrere Pfade in der pam_mount.conf.xml angeben - einer davon stimmt, die anderen nicht. Das wiederum gibt mir eine Anzahl von Fehlermeldungen zurück und diese möchte ich weg haben, bzw. umgehen.


    Ich habe folgende Lösungsansätze in der pam_mount.conf.xml ausprobiert:
    <or></or> funktioniert im Bereich der Volumes nicht, option=„nofail“ ändert ebenfalls nichts, egal, wo ich es hinschreibe (mntoptions allow/require/deny, bzw, direkt in der Zeile f.d. Volume).
    Die Fehlermeldungen mittels 2&>/dev/null zu himmeln ist mir auch nicht gelungen, da die XML-Datei keine bash-Statements parst - gibt es hier eine andere Möglichkeit?
    Oder gibt es eventuell eine Möglichkeit ein Script „zwischenzuschalten“, um anhand des Nutzernamens den richtigen Pfad zu generieren und zurückzugeben? Eine ‚include‘-Funktion habe ich bei der pam_mount.conf.xml jedoch nicht gefunden.
    Hier hatte offenbar jemand ein ähnliches Problem, leider verdsandet das Thema ohne richtige Lösung, bzw. kommt mir die Lösung sehr Anwendungsspezifisch vor (oder habe ich das Konstrukt lediglich nicht verstanden?).
    Jetzt bin ich ratlos.


    Im Netz habe ich keinerlei Lösung zu dem Problem gefunden, mache ich hier etwas völlig neues? Oder bin ich auf den Holzweg?
    Würde mich über erhellende Antworten sehr freuen.
    Dank und Gruß - Contuxedo

    Für den Inhalt des Beitrages 110338 haftet ausdrücklich der jeweilige Autor: Contuxedo

  • Warum bindest du mehrere Pfade ein, wenn nur ein Pfad richtig ist?
    Wo ist die entsprechende pam.mount?


    Was willst du wirklich erreichen?
    Sind das Homes?
    Wenn ja, wer verwaltet die?


    Beschreibe die Topologie.

  • Die Userverzeichnisse liegen auf verschiedenen Netzwerkressourcen. Die User A-E befinden sich auf der ersten, F-J auf der zweiten LUN, usw. Da auch dort Änderungen stattfinden können (zB „E“ wandert auf die fünfte LUN, weil die erste voll ist) gibt es weitere links, die das ganze alphabetisch auflisten, diese können dann auf den Servern angepasst werden, anstatt auf 150 Clients. User „Bob“ befindet sich auf Pfad „B“, Alice auf „A“. Letzendlich habe ich 26 Pfade, da ich ja nun nicht vorhersagen kann wer sich am Rechner anmeldet. Ich habe also


    Code
    <volume path=„//Server/share/a/%(DOMAIN_USER) mountpoint=„/home/%(DOMAIN_USER) fstype=„cifs“>
    <volume path=„//Server/share/b/%(DOMAIN_USER) mountpoint=„/home/%(DOMAIN_USER) fstype=„cifs“>
    <volume path=„//Server/share/z/%(DOMAIN_USER) mountpoint=„/home/%(DOMAIN_USER) fstype=„cifs“>

    in der /etc/security/pam_mount.conf.xml
    Ja, das sind Heimatverzeichnisse, die von unserer Servergruppe verwaltet werden.
    Topologie? Eigentlich simpel: eine AD-Domäne, mehrere hundert Clients, meist Windows, aber eben auch Linux.


    Ich möchte, das das „richtige“ Verzeichnis gemountet wird (das funktioniert) und ich, bzw. der User keine 25 Fehlermeldungen erhält. Beim Anmelden an der grafischen Oberfläche sieht man diese auch nicht, doch unsere User benutzen gerne die Konsole; meldet man sich auf tty1-6 an, dann purzeln alle Fehlermeldungen ins stdout — also auf den Monitor.


    Ich möchte entweder einen passenden Pfad per Script erstellen (ergibt sich ja aus dem Usernamen: erster Buchstabe) und diesen solitär mit der pam_mount aufrufen, oder die Fehlermeldungen die quasi „falsch“ sind eliminieren, damit sie niemanden verwirren. Auf die pam_mount bin ich fixiert, weil das ganze Single-SignOn geschehen soll, also mit einer Passworteingabe beim Anmelden an den Client.

    Für den Inhalt des Beitrages 110352 haftet ausdrücklich der jeweilige Autor: Contuxedo

  • Die Bash parst keine XML Files und hat das nie getan.


    Dein Versuch klingt insgesamt schräg. Sehr schräg.


    Selbstverständlich gibt es includes für pam*.
    Probiere man 5 pam.d, weit unten wirst du fündig.


    Du verwendest das Akronym "LUN".
    Das ist entweder alte SCSI Terminologie, oder zeigt auf irgendwelche SANs.
    Was läuft da wirklich? Was meint bei dir "Netzwerkpfad zu den Homes"?


    Wenn du eine /etc/security/pam_mount.conf.xml nennst, schlussfolgere ich, dass eine Linuxkiste sich auf einem irgendwoanders AD Controller anmelden soll.
    Warum verwaltest du die HOME Pfade nicht im AD selbst?


    Irgendwie verstehe ich dein Problem nicht wirklich.
    Ich halte jedenfalls den Versuch quasi auf Vorrat irgendwelche potentiellen HOMEpfade reinzuballern, weil irgendwann mal einer treffen könnte, für nicht sonderlich sinnvoll.

  • Die Bash parst keine XML Files und hat das nie getan.

    Und umgekehrt genauso: XML parst kein bash, ja, hatte ich oben schon erwähnt.

    Dein Versuch klingt insgesamt schräg. Sehr schräg.

    Schlag mir etwas besseres vor. Bin für alles was funktioniert offen.

    Selbstverständlich gibt es includes für pam*.
    Probiere man 5 pam.d, weit unten wirst du fündig.

    Für pam.d mag das sein, aber nicht für pam_mount.conf.
    Probiere man pam_mount.conf

    Du verwendest das Akronym "LUN". Das ist entweder alte SCSI Terminologie, oder zeigt auf irgendwelche SANs.

    Ja, der Kram liegt im SAN, aber eigentlich ist es egal, ob die User auf verschiedene Festplatten oder SAN-Storages zugreifen müssen. Ich muss für verschiedene User auf verschiedene Netzwerkpfade zugreifen. Und jeder User kann sich an jedem Client anmelden. Ich kann also nicht vorher sagen, ob User Alice sich an Client foo oder an Client bar anmelden wird. Oder Bob. Oder Charly, oder, oder, oder...

    Was läuft da wirklich? Was meint bei dir "Netzwerkpfad zu den Homes"?

    Das was ich schrieb: der Netzwerkpfad zu den Verzeichnissen (s.o.: volume=„//server/…“). Die Userverzeichnisse liegen zentral im SAN, das jeder User von jedem Client darauf zugreifen kann.

    Wenn du eine /etc/security/pam_mount.conf.xml nennst, schlussfolgere ich, dass eine Linuxkiste sich auf einem irgendwoanders AD Controller anmelden soll.

    Das schrob ich bereits im ersten Post, erster Satz nach der Begrüßung, ja.

    Warum verwaltest du die HOME Pfade nicht im AD selbst?

    Tun wir, sie müssen aber vom Client angesprochen und gemountet werden. Das kann das AD schlechterdings nicht für den Client machen.

    Irgendwie verstehe ich dein Problem nicht wirklich.

    Den Eindruck habe ich auch, leider weiß ich nicht wie ich das Problem verständlicher machen soll.

    Ich halte jedenfalls den Versuch quasi auf Vorrat irgendwelche potentiellen HOMEpfade reinzuballern, weil irgendwann mal einer treffen könnte, für nicht sonderlich sinnvoll.

    „Irgenwann“ ist in jedem Fall. Bei gut 800 Mitarbeitern und 150 Linuxclients….
    Deswegen würde ich auch ein Script bevorzugen, was mir aus dem DOMAIN_USER den ersten Buchstaben extrahiert und einen korrekten Pfad zurückgibt, aber ich nehme was ich kriegen kann.

    Für den Inhalt des Beitrages 110356 haftet ausdrücklich der jeweilige Autor: Contuxedo

  • Die Fehlermeldungen mittels 2&>/dev/null zu himmeln ist mir auch nicht gelungen, da die XML-Datei keine bash-Statements parst

    Weil eine XML Datei halt kein Programm ist. Parsen können nur Programme, meist Interpreter. Eine HTML Datei parst auch keinen Webserver.



    - gibt es hier eine andere Möglichkeit? Oder gibt es eventuell eine Möglichkeit ein Script „zwischenzuschalten“, um anhand des Nutzernamens den richtigen Pfad zu generieren und zurückzugeben

    Selbstverständlich.


    Das ist sogar die zentrale Idee von PAM == PluggableAuthenticationModules. Kann man beliebig zusammenstecken.
    Und selbstverständlich kannst du dir jederzeit beliebig Module schreiben und die dann reinhängen.


    Eine ‚include‘-Funktion habe ich bei der pam_mount.conf.xml jedoch nicht gefunden.

    Weil die Datei nur Werte liefert, die von den entsprechenden Programmen verarbeitet werden. Und genau pam.d inkludiert solche Beschreibungen und ruft ggf. entsprechende Programme auf.
    Willst du dich blind und taub stellen, wirst du den entsprechenden Prozess zum Schweigen bringen müssen. Den Kopf in den Sand stecken ist aber immer der verkehrte Weg.

    Und umgekehrt genauso: XML parst kein bash, ja, hatte ich oben schon erwähnt.

    Ja. Weil kein Brathähnchen den Koch grillt, kein Haus den Maurer baut und selbst VW- Motoren nicht die Ingenieure konstruieren. Es gibt in dieser Welt soviele Dinge, die noch sehr viel mehr nicht parsen, dass wir gar nicht versuchen sollten, sie aufzuzählen.
    Das ist eine daemonische Aufgabe für die der Speicherplatz ganz sicher nicht reicht.

    Schlag mir etwas besseres vor. Bin für alles was funktioniert offen.

    Du könntest dir ein Modülchen schreiben, das das macht. Hilfreich dazu wäre bestimmt auch man 8 pam_env mit dem man das sogar relativ leicht erledigen könnte.
    Ich halte beides für den falschen Weg.
    Ein falscher Weg wird nicht richtig, weil man ihn clever geht.


    --snip--
    Ja, der Kram liegt im SAN, aber eigentlich ist es egal, ob die User auf verschiedene Festplatten oder SAN-Storages zugreifen müssen. Ich muss für verschiedene User auf verschiedene Netzwerkpfade zugreifen. Und jeder User kann sich an jedem Client anmelden. Ich kann also nicht vorher sagen, ob User Alice sich an Client foo oder an Client bar anmelden wird. Oder Bob. Oder Charly, oder, oder, oder...

    Das was ich schrieb: der Netzwerkpfad zu den Verzeichnissen (s.o.: volume=„//server/…“). Die Userverzeichnisse liegen zentral im SAN, das jeder User von jedem Client darauf zugreifen kann.

    Schön, dass du nicht einmal die Pfade ausschreibst. Nettes Geplauder, aber keine Information.


    Ich denke, dir sind zwei ganz wesentliche Prinzipien entgangen.
    Einmal ist eine AD (unter Linux heißt das LDAP) genau dazu da, solche Information zentral zu verwalten und zu verteilen.
    Dein pam_mount Versuch widerspricht dem vollständig. Ich denke, wenn du die Userdaten im AD schlicht korrekt setzen würdest, wäre das schon erledigt.
    Gehst du weiter deinen Weg, bist du sofort wieder beim Turnschuh- Update.
    Verwaltung von Userinformationen auf jedem Rechner.
    Widerspruch in sich selbst.


    Genau das wollen ja AD, LDAP und Konsorten ein- für allemal eliminieren.


    Das zweite ist, dass du mit den LUNs des SANs gar nie nicht in Berührung kommen solltest.
    Man kann zwar ein SAN ähnlich, wie einzelne Festplatten behandeln -und du tust das auch-, aber das ist ganz bestimmt nicht Sinn und Zweck eines SANs.


    Man macht einen Storagepool und ab da ist es völlig egal, auf welcher Platte was liegt. Da braucht man sich nie wieder drum zu kümmern. Das ist Sinn und Zweck eines SANs.
    Keine, auch nicht eine Applikation muss künftig mit irgendwelchen Platten, Kanälen oder sonstigem Low-Level-Kram rumfrimmeln.
    Und sie sollten das auch nicht. Das ist der Job der EDV Abteilung.


    ...Das schrob ich bereits im ersten Post, erster Satz nach der Begrüßung, ja....

    Tun wir, sie müssen aber vom Client angesprochen und gemountet werden. Das kann das AD schlechterdings nicht für den Client machen.

    Aber sie sollten NIEMALS von sich aus festlegen weder dürfen noch müssen, woher sie ihr Home mounten.


    Das widerspricht dem Gedanken von AD vollständig.


    Bei ca. 1000 Clients, sollte euer Unternehmen eine EDV Abteilung haben.
    Vielleicht solltest du mal mit dem einen aus dieser Abteilung reden, der ein SAN versteht.


    Wenn du diesen Unsinn weiter machen willst, solltest du dir pam_env sehr genau angucken.
    Das kann solchen Blödsinn ziemlich einfach möglich machen.
    Schreiben will ich solch Zeuchs nicht.