staging.inyokaproject.org

pam-mount restart - geht das? - Und wenn ja, wie???

Status: Ungelöst | Ubuntu-Version: Ubuntu 10.04 (Lucid Lynx)
Antworten |

eckisch

Anmeldungsdatum:
2. Juni 2009

Beiträge: Zähle...

Hallo,

kann mir bitte jemand einen Tipp geben, wie ich pam-mount aus dem laufenden System heraus erneut ausführen kann (also ohne mich nochmal neu anmelden zu müssen)?

Ich habe mich am Artikel Samba Winbind orientiert mit dem Ziel, dass jeder User seinen Eigenen Dateiordner automatich zur Verfügung gestellt bekommt. Das funktioniert alles prima!

Da der Rechner manchmal aber erst Kontakt zum NAS/Fileserver bekommt, kurz NACHDEM er hochgefahren und bereits beim PDC angemeldet ist, würde ich gerne 2 Minuten nach Rechnerstart die pam-mount Anbindung noch einmal durchlaufen lassen (dann hängt der Fileserver in der Regel im Netz). Ich habe dazu aber keinen Prozess unter /etc.init.d oder upstart finden können - und in der fstab ist diese Art der Einbindung ja auch nicht festgehalten.

Meine Frage: Wann wird die /etc/security/pam_mount.conf.xml abgearbeitet und von wem? Der Versuch über mount -a schlug ebenso fehl, wie der Ansatz, es mit einem erneuten Dienststart von nmbd, smbd oder winbind zu versuchen. Würde es überhaupt helfen, den Prozess, der die /etc/security/pam_mount.conf.xml ausliest, noch einmal neu zu starten?

Bitte! Hat irgendjemand einen Tipp für mich!

Mit Dank vorab und bestem Gruß

eckisch

raptor2101

Anmeldungsdatum:
8. Juni 2009

Beiträge: 1247

Erstmal eine knappe Anwort. Das PAM Module kann das nicht, soll es auch nicht können. Die Module klinken sich in den SessionProzess ein (pam.d) und sind alleine nicht lauffähig.

Die frage ist, warum ist der Server nicht da? WakeUp on LAN?

Vieleicht gibt es einen anderen Workaround...

eckisch

(Themenstarter)

Anmeldungsdatum:
2. Juni 2009

Beiträge: 32

Hallo,

herzlichen Dank für die Antwort!

Raptor 2101 schrieb:

Erstmal eine knappe Anwort. Das PAM Module kann das nicht, soll es auch nicht können. Die Module klinken sich in den SessionProzess ein (pam.d) und sind alleine nicht lauffähig.

Das hatte ich vermutet, darauf deutete auch dieser Internetfund hin. Die Frage, die mich umtreibt, ist, mit welchem Dienst ist pam-mount verknüpft? Und würde es eventuell klappen, diesen Dienst neu zu starten? Bei der Suche danach habe ich mich allerdings im upstart-Salat verlaufen.

Die frage ist, warum ist der Server nicht da? WakeUp on LAN?

Die kurze Antwort: Ja, PDC ist ein (stromsparender) smart-client und der separate Fileserver startet bei Client-Anmeldung an der Domäne über WOL.

Die Lange Antwort: Hier hatte ich den Fragekomplex vor gut einem Monat (leider bisher ohne Resonanz - vermutlich im falschen Forum) schon einmal langatmiger gestartet - und hab es hier nun noch einmal probiert.

Vieleicht gibt es einen anderen Workaround...

Ja, daran bastele ich inzwischen auch schon herum:

Eine mögliche Idee: Da der Fileserver vom PDC aufgeweckt wird während der Client sich anmeldet, bräuchte man NUR (?) den Client direkt NACH der Authentifizierung und VOR dem Start desjenigen Dienstes, der die /etc/security/pam_mount.conf.xml abarbeitet (welcher nur???), eine Warteschleife drehen zu lassen - die man zudem nach erfolgreichem PING zum Fileserver sofort abbrechen lassen kann.

Eigentlich ist es sogar noch einfacher: im Rahmen einiger Test-Starts habe ich den Client das WOL während des Bootens ausführen lassen und festgestellt, dass es ausreicht, dem Client nach Erscheinen des Anmeldebildschirms einfach eine Minute Pause zu gönnen (der Fileserver hat zu dem Zeitpunkt offensichtlich schon sein Magic-Package bekommen und fährt gerade hoch) bevor man sich anmeldet.

Alternativ ist es (wenn man zu ungeduldig war und zu früh versucht hat sich anzumelden) auch möglich, sich einfach nochmal abzumelden und erneut anzumelden.

Letzte Variante, die mir bisher in den Sinn kam: Ich verzichte auf PAM-MOUNT und versuche es mit einem Netzwerk-Mount, den ich per Skript steuern kann.

Das sind aber alles unbefriedigende Krücken - die saubere Lösung würde mich einfach auch, sozusagen rein akademisch 😉 interessieren.

Nochmals vielen Dank für die bisherige Anteilnahme und Antwort

mit besten Grüßen

eckisch

raptor2101

Anmeldungsdatum:
8. Juni 2009

Beiträge: 1247

Du verstehst da was völlig falsch.

pam steht für Plugable Authentication Module. Das ist KEIN dienst und das triggert auch keinen dienst. Das PAM Module wird von deinem GDM (XDM,NODM,KDM,XDM) gerufen sobald sich dein User anmeldet. Du kannst den GDM neustarten, das zwingt aber den nutzer zur neuanmeldung. Bei der Anmeldung wird einfach ein mount.cifs ausgeführt.

Es gibt mehrere Möglichkeiten: * Bremms den Client: zb über die rc.local. Ping den server so lange, bis er da ist und lauf erst dann weiter. Denk drann der User bekommt davon nichts mit! * schreib ein cron script das alle 10 minuten versucht einen mount abzusetzten, wenn die laufwerke nicht gemountet sind. wo du die credentials her bekommst ist mir aber ein rätsel... * schau mal ob es einen Lazy mount bei CIFS gibt (also das der Mountpoint angelegt wird, aber keine verbindung zum server besteht)

eckisch

(Themenstarter)

Anmeldungsdatum:
2. Juni 2009

Beiträge: 32

Danke für die schnelle Rückmeldung!

Raptor 2101 schrieb:

Du verstehst da was völlig falsch.

pam steht für Plugable Authentication Module. Das ist KEIN dienst und das triggert auch keinen dienst. Das PAM Module wird von deinem GDM (XDM,NODM,KDM,XDM) gerufen sobald sich dein User anmeldet. Du kannst den GDM neustarten, das zwingt aber den nutzer zur neuanmeldung. Bei der Anmeldung wird einfach ein mount.cifs ausgeführt.

OK - das ist also ein Holzweg (?). Schade, ich hatte schon alle möglichen Prozesse und Dienste (ohne Erfolg) durchprobiert: Von erneutem mount -a über Neustart von Samba ond/oder Winbind bis hin (in meinem verzweifelten Bemühen) zu Modulen, von denen ich nicht einmal wusste, wozu sie da sind. GDM neu zu starten ist natürlich nicht wirklich ein praktikabler Weg - ein erneutes Einloggen kann man einfacher haben 😉

Es gibt mehrere Möglichkeiten: * Bremms den Client: zb über die rc.local. Ping den server so lange, bis er da ist und lauf erst dann weiter. Denk drann der User bekommt davon nichts mit!

Das ist gerade die Spur, die ich derzeit verfolge. Aber irgendwie klappte das noch nicht (ich bin mit meinen Versuchen aber auch erst am Anfang). Mich beschlich aber das Gefühl, dass die rc.local erst nach dem Einloggen abgearbeitet wird - bzw. dass das PAM-Modul aktiviert wird, BEVOR die rc.local dran ist oder UNABHÄNGIG davon. Hier hatte ich bereits mein Warten_Auf_Server_Bis_Ping_Klappt-Skript hineingebastelt - aber wie gesagt, das ist noch Baustelle und ich melde gerne Vollzug, wenn ich damit durch bin.

Meine derzeitige Idee ging in die Richtung, ein neues upstart-skript mit Warteschleife zu schreiben, das ich dann ins /etc/init-Verzeichnis einhänge und dann das Login von der Beendigung dieses eigenen Skriptes abhängig mache (da stehe ich aktuell vor der Frage: Welcher Prozess steuert im UPSTART den login-Aufruf? - diesen müsste ich dann in Abhängigkeit von meinen Skript setzen). Hier habe ich auch schon erste Versuche unternommen (bspw. indem ich versucht habe, GDM erst aufrufen zu lassen, wenn der Ping zum Fileserver klappt), was aber bisher nur dazu geführt hat, dass nicht etwa das Login verzögert wird, sondern statt des Startbildschirms ein Konsolen-Login erscheint.

Also auch das noch ein weites Feld zum Basteln und Herumprobieren.

* schreib ein cron script das alle 10 minuten versucht einen mount abzusetzten, wenn die laufwerke nicht gemountet sind. wo du die credentials her bekommst ist mir aber ein rätsel...

Ja, gute Idee, aber die credentials... die hatte ich für Testzwecke in eigenen Dateien in den jeweiligen Home-Verzeichnissen des Clients abgelegt. Das führt aber den ganzen Ansatz ad absurdum, weil ich ja eben keine dezentral verteilten Passwörter administrieren will.

* schau mal ob es einen Lazy mount bei CIFS gibt (also das der Mountpoint angelegt wird, aber keine verbindung zum server besteht)

CIFS ist ein Bereich, den ich bisher ausgespart habe. Wenn ich mit meinen aktuellen Versuchen scheitern sollte, dann gehts in dieser Richtung weiter.

Jetzt ist aber erst einmal für heute Schluss - Ich muss morgen früh raus und kann mich voraussichtlci erst am Wochenende wieder intensiver darum kümmern.

Bis hierher aber schon mal vielen Dank für die Unterstützung!!!

eckisch

raptor2101

Anmeldungsdatum:
8. Juni 2009

Beiträge: 1247

die rc.local wurde ursprünglich am schluss des init.v angestoßen. wie das bei upstart genau ist, weiß ich nicht, aber sie stopt den bootvorgang noch immer. Mach dort mal ein sleep oder wait (jeh nachdem...) und der gdm sollte erst startet wenn die zeit abgelaufen ist...

eckisch

(Themenstarter)

Anmeldungsdatum:
2. Juni 2009

Beiträge: 32

Nee, nee,

das wird nix - das hatte ich schon. Es ist tatsächlich so, dass die rc.local (mehr oder weniger) unabhängig vom upstart-System ausgeführt wird. Wenn man in die rc.local bspw. ein SLEEP 60 einbaut, dann schäft die rc.local tatsächlich für 'ne Minute ein, aber das hindert den Rechner nicht im mindesten daran, vorher bzw. parallel dazu schon die Login-Prozedur mit allem drum und dran durchzuziehen. Ich hab dafür in die rc.local vor und nach dem SLEEP 60 (und auch in einige andere Dienst.conf-Aufrufe im /etc/init-Verzeichnis) eine ganze Reihe von BEEPs in unterschiedlicher Tonhöhe hineingeschrieben, so dass der Rechner während des Bootens lustig vor sich hin gepiept hat - und ich anhand der Tonfolge nachvollziehen konnte, wann welcher Prozess abgearbeitet wurde.

Ja, ok, vielleicht etwas unorthodox, aber ganz aufschlussreich.

Der langen Rede dumpfer Sinn: So wird das nix.

Aber da mir die Sache keine Ruhe ließ, habe ich nochmal in den upstart-Dateien herumgepfuscht - und siehe da: ES IST VOLLBRACHT!!!

Die Lösung (für die Workaround-Krücke!) ist folgende. Die gdm.conf sieht im Original so aus:

# gdm - GNOME Display Manager
#
# The display manager service manages the X servers running on the
# system, providing login and auto-login services

description	"GNOME Display Manager"
author		"William Jon McCann <mccann@jhu.edu>"

start on (filesystem
          and started dbus
          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
               or stopped udevtrigger))
stop on runlevel [016]

emits starting-dm

env XORGCONFIG=/etc/X11/xorg.conf

script

    if [ -n "$UPSTART_EVENTS" ]
    then
	[ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/gdm" ] || { stop; exit 0; }

	# Check kernel command-line for inhibitors
	for ARG in $(cat /proc/cmdline)
	do
	    case "${ARG}" in
		text|-s|s|S|single)
		    plymouth quit || :  # We have the ball here
		    exit 0
		    ;;
	    esac
	done
    fi

    if [ -r /etc/default/locale ]; then
	. /etc/default/locale
	export LANG LANGUAGE
    elif [ -r /etc/environment ]; then
	. /etc/environment
	export LANG LANGUAGE
    fi
    export XORGCONFIG

    exec gdm-binary $CONFIG_FILE
end script

Da wird also ein Skript abgearbeitet!

Jetzt habe ich (einfach) in die Lücke zwischen "script" und dem ersten "if" meinen kleinen Warte-Code hineingebastelt. Und sieh da - ES KLAPPT.

Meine modifizierte gdm.conf sieht jetzt so aus:

# gdm - GNOME Display Manager
#
# The display manager service manages the X servers running on the
# system, providing login and auto-login services

description	"GNOME Display Manager"
author		"William Jon McCann <mccann@jhu.edu>"

start on (filesystem
          and started dbus
          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
               or stopped udevtrigger))
stop on runlevel [016]

emits starting-dm

env XORGCONFIG=/etc/X11/xorg.conf

script

####### jetzt kommt meine Warteschleife ##########################

beep -f 261,6 -l 100

NOCHMAL=true
FILESERVER="192.168.0.10"
SCHLEIFE=0

while $NOCHMAL
  do
    SCHLEIFE=$(($SCHLEIFE+1))

    if ping -w 2 -c 2 $FILESERVER > /dev/null ; then
      NOCHMAL=false
      beep -f 523,2 -l 100
    fi

    if [ $SCHLEIFE -gt 40 ]; then
      NOCHMAL=false
      beep -f 392 -l 100
    fi

    beep -f 329,6 -l 100
    sleep 1
  done
beep -f 523,2 -l 100 -n -f 392 -l 100 -n -f 329,6 -l 100 -n -f 261,6 -l 100

########### Ab hier gehts normal weiter #####################################

    if [ -n "$UPSTART_EVENTS" ]
    then
	[ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/gdm" ] || { stop; exit 0; }

	# Check kernel command-line for inhibitors
	for ARG in $(cat /proc/cmdline)
	do
	    case "${ARG}" in
		text|-s|s|S|single)
		    plymouth quit || :  # We have the ball here
		    exit 0
		    ;;
	    esac
	done
    fi

    if [ -r /etc/default/locale ]; then
	. /etc/default/locale
	export LANG LANGUAGE
    elif [ -r /etc/environment ]; then
	. /etc/environment
	export LANG LANGUAGE
    fi
    export XORGCONFIG

    exec gdm-binary $CONFIG_FILE
end script

Da sind auch noch all die vielen Test-Piepser drin.

Seltsamerweise hat es mit dem WOL aus diesem Skript heraus nicht geklappt, so dass ich (im Wissen darum, dass die rc.local ja unabhängig verwurstet wird) den WOL-Aufruf dorhin verbannt habe.

Nochmals vielen Dank bis hierher!!!

Der Vollständigkeit halber (und um Menschen mit gleichgelagertem Problem vor diesen Irrwegen zu bewahren) füge ich hier meine zwei wesentlichsten Fehlschläge auf diesem Weg an:

1. Zuerst habe ich versucht, eine eigene warte-auf-server.conf zu schreiben und dann die gdm.conf davon abhängig zu machen. Nach dem Fehlversuch und einen Blick in die Dokumentation ahnte ich: mit dem Einfügen von "and started warte-auf-server" in die gdm.conf ist es nicht getan, denn die gdm.conf wartet dann nicht etwa, bis das warte-auf-server-Skript fertig abgearbeitet ist, sondern nur solange, bis es zwar gestartet ist - aber während seiner Abarbeitung vielleicht noch lustig vor sich hin wartet - da hat es ziemlich durcheinander gepiept 😉

Anmerkung dazu: der ganze Upstart-Prozess ist katastrophal schlecht dokumentiert. Vielleicht sollte mal jemand mit Durchblick versuchen, den Start-Vorgang von Ubuntu mit all seinen upstart-Abhängigkeiten visuell darzustellen???

2. Dann habe ich versucht der plymouth-splash.conf ein pre-start Script zu verpassen. Zwar hat der show-splash-Aufruf hübsch gewartet, bis das Skript fertig war, aber show-splash ist leider nicht relevant für den Login-Zeitpunkt (?).

So weit, so gut - und bis zum nächsten Problem

eckisch


NACHTRAG:

Die Erkenntnisse bezüglich UPSTART, die ich aus meinen Versuchen der letzten Tage ziehen konnte, habe ich versucht im Wiki-Artikel Upstart unterzubringen.

Antworten |