[gelöst] WLan aktivieren ohne root-PWD-Abfrage
[gelöst] WLan aktivieren ohne root-PWD-Abfrage
Moin
Wie kriege ich das hin, dass das öffnen von WLAN-Verbindungen generell nicht mit root-PWD erlaubt werden muss? Bei mir wechseln die WLANs laufend, der alte Lenovo-Laptop wird von 3 Leuten genutzt und die Abfrage mit dem Hinweis "Die Systemrichtlinien verhindern das Bearbeiten von Netzwerkeinstellungen" geht ja gar nicht. Wer denkt sich denn so'n quatsch aus...? Die Benutzer müssen sich alle mit nem beliebigen WLAN verbinden dürfen.
Installiert ist (seit heute): Debian 8.1, Jessie, XFCE, I386. Es ist eine normale Standardinstallation auf die ich lediglich die benötigte Software installiert habe, rumgeschraubt am System habe ich nicht. Die Verbindung mache ich über den normalen Network-Manager bei den Tray-Icons.
Hat jemand eine Idee?
Wie kriege ich das hin, dass das öffnen von WLAN-Verbindungen generell nicht mit root-PWD erlaubt werden muss? Bei mir wechseln die WLANs laufend, der alte Lenovo-Laptop wird von 3 Leuten genutzt und die Abfrage mit dem Hinweis "Die Systemrichtlinien verhindern das Bearbeiten von Netzwerkeinstellungen" geht ja gar nicht. Wer denkt sich denn so'n quatsch aus...? Die Benutzer müssen sich alle mit nem beliebigen WLAN verbinden dürfen.
Installiert ist (seit heute): Debian 8.1, Jessie, XFCE, I386. Es ist eine normale Standardinstallation auf die ich lediglich die benötigte Software installiert habe, rumgeschraubt am System habe ich nicht. Die Verbindung mache ich über den normalen Network-Manager bei den Tray-Icons.
Hat jemand eine Idee?
Zuletzt geändert von TomL am 19.08.2015 17:36:53, insgesamt 1-mal geändert.
- habakug
- Moderator
- Beiträge: 4313
- Registriert: 23.10.2004 13:08:41
- Lizenz eigener Beiträge: MIT Lizenz
Re: WLan aktivieren ohne root-PWD-Abfrage
Hallo!
Schon mal probiert die User zu Mitgliedern der Gruppe "netdev" zu machen?
Gruss, habakug
edit:
Schon mal probiert die User zu Mitgliedern der Gruppe "netdev" zu machen?
Gruss, habakug
edit:
[1] https://wiki.debian.org/SystemGroups[1] hat geschrieben:netdev: Members of this group can manage network interfaces through the network manager and wicd.
Re: WLan aktivieren ohne root-PWD-Abfrage
Benutzer ist Mitglied der Gruppe 'netdev'?
Ups, zu spät.
Da das aber wohl nichts mit den Abbrüchen zu tun hat:
network-manager gegen wicd tauschen?
wlan-Hardware inspizieren? Vielleicht kündigt sich ein Router-Tod an.
Ups, zu spät.
Da das aber wohl nichts mit den Abbrüchen zu tun hat:
network-manager gegen wicd tauschen?
wlan-Hardware inspizieren? Vielleicht kündigt sich ein Router-Tod an.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: WLan aktivieren ohne root-PWD-Abfrage
Moin
Die Gruppe "netdev" hatte ich vorher schon bei meiner Fehlersuche auf ner Web-Seite gefunden und ich hatte die User eingetragen. Aber ich bin wohl in die Falle getappt, dass ich nicht komplett neu durchgebootet habe.... deswegen hat das nicht geklappt. Jetzt gerade habe ich mich nach dem Einschalten angemeldet und siehe da, es geht. Dann habe ich den Account meiner Frau angemeldet und es geht erstaunlicherweise nicht automatisch, obwohl sie jetzt mit netdev alle Rechte hat. Ich habe dann einfach mit Ihrem Account die Verbindung gelöscht und wieder neu angelegt und jetzt klappt es.
Interessanterweise hat das System beim letzten Start mit der WLAN-Verbindung auch alle meine über systemd gemounteten Server-Verzeichnisse tatsächlich auch gemountet, das funktionierte vorher auch nicht. Ich muss das jetzt einfach mal über 2, 3 oder auch 4 Systemstarts beobachten, ob jetzt jedesmal das WLAN korrekt gestartet wird und systemd mit dem mounten solange wartet, bis die Verbindung steht und dann auch wirklich mountet.
Danke für die Hilfe.
Die Gruppe "netdev" hatte ich vorher schon bei meiner Fehlersuche auf ner Web-Seite gefunden und ich hatte die User eingetragen. Aber ich bin wohl in die Falle getappt, dass ich nicht komplett neu durchgebootet habe.... deswegen hat das nicht geklappt. Jetzt gerade habe ich mich nach dem Einschalten angemeldet und siehe da, es geht. Dann habe ich den Account meiner Frau angemeldet und es geht erstaunlicherweise nicht automatisch, obwohl sie jetzt mit netdev alle Rechte hat. Ich habe dann einfach mit Ihrem Account die Verbindung gelöscht und wieder neu angelegt und jetzt klappt es.
Interessanterweise hat das System beim letzten Start mit der WLAN-Verbindung auch alle meine über systemd gemounteten Server-Verzeichnisse tatsächlich auch gemountet, das funktionierte vorher auch nicht. Ich muss das jetzt einfach mal über 2, 3 oder auch 4 Systemstarts beobachten, ob jetzt jedesmal das WLAN korrekt gestartet wird und systemd mit dem mounten solange wartet, bis die Verbindung steht und dann auch wirklich mountet.
Danke für die Hilfe.
Re: WLan aktivieren ohne root-PWD-Abfrage
Moin
Ich habe jetzt noch ein weiteres Problem in diesem Zusammenhang.... mit WLAN.... vermute ich mal... ... und zwar was der Herunterfahren betrifft. Beim Start des Systems und der User-Anmeldung wird die Netzverbindung über WLAN (oder Kabel) hergestellt und anschliessend via Systemd meine Netzwerklaufwerke gemountet. Das funktioniert sowohl via Kabel als auch via WLAN prima. Der Systemd-Job wartet gemäß seiner Einstellung ordentlich auf das fertige Netzwerk.
Das Problem besteht jetzt beim Herunterfahren des Rechners. "umount'e" ich vorher von Hand, fährt der Rechern binnen Sekunden sauber runter. Lass ich die mount's bestehen, hängt er minutenlang in verschiednen Stop-Jobs zur Trennung der Laufwerke. Der Effekt sieht m.E. so aus, dass das WLan vor dem umount geschlossen ist und das dann der umount versucht irgendwie ordnungsgemäß zu trennen, was er aber ohne Netz nicht mehr kann.... bis es dann vermutlich über nen Timeout für jeden mount passiert ist.
Gibts ne Möglichkeit es so einzustellen, dass der Rechner den umount durchführt, bevor er das WLAN trennt?
Das ist der Inhalt meines systemd-Service. Auf nem Laptop sollte irgendwie beides funktionieren, Kabel-Netz und auch Funk-Netz.
/etc/systemd/system/mountall.service
Ich habe jetzt noch ein weiteres Problem in diesem Zusammenhang.... mit WLAN.... vermute ich mal... ... und zwar was der Herunterfahren betrifft. Beim Start des Systems und der User-Anmeldung wird die Netzverbindung über WLAN (oder Kabel) hergestellt und anschliessend via Systemd meine Netzwerklaufwerke gemountet. Das funktioniert sowohl via Kabel als auch via WLAN prima. Der Systemd-Job wartet gemäß seiner Einstellung ordentlich auf das fertige Netzwerk.
Das Problem besteht jetzt beim Herunterfahren des Rechners. "umount'e" ich vorher von Hand, fährt der Rechern binnen Sekunden sauber runter. Lass ich die mount's bestehen, hängt er minutenlang in verschiednen Stop-Jobs zur Trennung der Laufwerke. Der Effekt sieht m.E. so aus, dass das WLan vor dem umount geschlossen ist und das dann der umount versucht irgendwie ordnungsgemäß zu trennen, was er aber ohne Netz nicht mehr kann.... bis es dann vermutlich über nen Timeout für jeden mount passiert ist.
Gibts ne Möglichkeit es so einzustellen, dass der Rechner den umount durchführt, bevor er das WLAN trennt?
Das ist der Inhalt meines systemd-Service. Auf nem Laptop sollte irgendwie beides funktionieren, Kabel-Netz und auch Funk-Netz.
/etc/systemd/system/mountall.service
Code: Alles auswählen
[Unit]
Description=mountall (avoid fstab-errors)
After= nmbd.service smbd.service
Requires= nmbd.service smbd.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/mountall
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99
[Install]
WantedBy=multi-user.target
- habakug
- Moderator
- Beiträge: 4313
- Registriert: 23.10.2004 13:08:41
- Lizenz eigener Beiträge: MIT Lizenz
Re: WLan aktivieren ohne root-PWD-Abfrage
Hallo!
Das ist ein Bug 769186 der erst in Version 219-1/220-2 gelöst ist. Entweder du gehst auf Stretch oder unmountest von Hand.
Gruss, habakug
Das ist ein Bug 769186 der erst in Version 219-1/220-2 gelöst ist. Entweder du gehst auf Stretch oder unmountest von Hand.
Gruss, habakug
Re: WLan aktivieren ohne root-PWD-Abfrage
Moin
Es ist wie verhext, es funktioniert einfach nicht..... egal, was ich unternehme ... .... alles vermutlich wegen diesem Bug 772914. Ich habe mir jetzt eine Systemd-Unit gebastelt, die beim Systemstart und beim Shutdown aktiv wird. Beim Systemstart ist sie erfolgreich, aber sie schafft es nicht, vor dem Wlan = OFF zu umounten, obwohl sie aktiv ist.
So sieht meine Unit aus:
/etc/systemd/system/mountctrl.service
Dieses Script wird erfolgreich gestartet:
/usr/local/bin/mountctrl
In meinem Log sehe ich, dass alles korrekt gestartet wurde:
/var/log/MyDebugLog.txt
Und trotzdem funktioniert der umount nicht, bevor das WLan weg ist. Jetzt habe ich aufgrund eines Hinweises im Bugreport versucht, das Problem über den Networkmanager-Dispatcher zu lösen, aber dieses Script wird überhaupt nicht gestartet, zu keiner Zeit. Ich habe keine Ahnung, warum nicht... nach den Dokus ist das doch eigentlich recht easy.... aber er tuts trotzdem nicht.
/etc/NetworkManager/dispatcher.d/pre-down.d/mountctrl.helper
An den Rechten der Scripte liegts nicht. Ich habe sie alle root "gegeben" und alle dürfen lesen und starten. Jetzt habe ich nur noch die Hoffnung, dass die Fachleute sehen, woran es hapert, den Bug erfolgreich zu umgehen.
Es ist wie verhext, es funktioniert einfach nicht..... egal, was ich unternehme ... .... alles vermutlich wegen diesem Bug 772914. Ich habe mir jetzt eine Systemd-Unit gebastelt, die beim Systemstart und beim Shutdown aktiv wird. Beim Systemstart ist sie erfolgreich, aber sie schafft es nicht, vor dem Wlan = OFF zu umounten, obwohl sie aktiv ist.
So sieht meine Unit aus:
/etc/systemd/system/mountctrl.service
Code: Alles auswählen
[Unit]
Description=MountControl (avoid mount + umount + stop-job-errors)
After=network.target nmbd.service smbd.service
Before=shutdown.target
Requires=network.target
[Service]
RemainAfterExit=yes
Type=oneshot
ExecStart=/usr/local/bin/mountctrl start
ExecStop=/usr/local/bin/mountctrl stop
[Install]
WantedBy=multi-user.target
/usr/local/bin/mountctrl
Code: Alles auswählen
#!/bin/sh
#
# mountctrl
# defaults = rw,suid,dev,exec,auto,nouser,async
# rw,dev,exec,noauto,nouser,async,noatime
#---------------------------------------------------------------------------------------------------
[ -z "$1" ] || JobToDo=$1 # empty? no = assign
#Debug
d=`date +%d-%m-%Y-%H-%M`
log=/var/log/MyDebugLog.txt
echo $d "mountctrl: "$JobToDo >>$log
#---------------------------------------------------------------------------------------------------
case $JobToDo in
start)
# Admin-Share's
mount //10.10.1.2/HD_1 /media/HD_1 -t cifs -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,rw,suid,dev,exec,user,async
mount //10.10.1.2/HD_2 /media/HD_2 -t cifs -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,rw,suid,dev,exec,user,async
# Non-Public-Share's
mount //10.10.1.2/Programme /media/Programme -t cifs -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,rw,suid,dev,exec,user,async
# Public Share's
mount //10.10.1.2/DatenAlle /media/DatenAlle -t cifs -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,rw,suid,dev,exec,user,async
mount //10.10.1.2/MultiMedia /media/MultiMedia -t cifs -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,rw,suid,dev,exec,user,async
;;
#-----------------------------------------------------------------------------------------
stop)
# Admin-Share's
umount /media/HD_1 -f
umount /media/HD_2 -f
# Non-Public Share's
# umount /media/Programme -f
# Public Share's
umount /media/DatenAlle -f
umount /media/MultiMedia -f
# /etc/init.d/umountnfs.sh
df -h >>$log
;;
#-----------------------------------------------------------------------------------------
*)
echo "Usage: $0 {start | stop}"
echo $d "Job canceled! Wrong or missing parameter"
exit 1
;;
esac
exit 0
/var/log/MyDebugLog.txt
Code: Alles auswählen
23-07-2015-20-55 mountctrl: stop
23-07-2015-20-58 mountctrl: start
23-07-2015-21-00 mountctrl: stop
23-07-2015-21-01 mountctrl: start
23-07-2015-21-12 mountctrl: stop
23-07-2015-21-12 mountctrl: start
23-07-2015-21-47 mountctrl: stop
23-07-2015-21-49 mountctrl: start
/etc/NetworkManager/dispatcher.d/pre-down.d/mountctrl.helper
Code: Alles auswählen
#!/bin/sh
IF=$1
STATUS=$2
#Debug
d=`date +%d-%m-%Y-%H-%M`
log=/var/log/MyDebugLog.txt
echo $d "mountctrl_helper: "$IF - $STATUS >>$log
if [ "${IF}" = "wlan0" ] && [ "${STATUS}" = "down" ]; then
/usr/local/bin/mountctrl stop
fi
exit 0
Zuletzt geändert von TomL am 24.07.2015 21:50:22, insgesamt 3-mal geändert.
Re: WLan aktivieren ohne root-PWD-Abfrage
http://www.freedesktop.org/software/sys ... rvice.html
Vielleicht Type=notify ?
Mögliches Problem:
Wenn das Mounten nicht funktioniert, bleibt der Systemstart stehen?
-> 2 Units
Idee,
damit die Mounts überwacht werden können
Kopien der mitgebrachten mount-Units erstellen,
wobei jedoch statt 'mount -a'
'mount --fstab meine-wlan-fstab -a' benutzt wird.je nachdem.
Vielleicht Type=notify ?
Obwohl da nicht vom Stoppen steht, gilt es vielleicht auch dabei?Behavior of notify is similar to simple; however, it is expected that the daemon sends a notification message via sd_notify(3) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is not set, it will be implicitly set to main. Note that currently Type=notify will not work if used in combination with PrivateNetwork=yes.
Mögliches Problem:
Wenn das Mounten nicht funktioniert, bleibt der Systemstart stehen?
-> 2 Units
Code: Alles auswählen
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/mountctrl start
ExecStop=/usr/bin/true
Code: Alles auswählen
Type=notify
ExecStart=/usr/bin/true
ExecStop=/usr/local/bin/mountctrl stop
Idee,
damit die Mounts überwacht werden können
Kopien der mitgebrachten mount-Units erstellen,
wobei jedoch statt 'mount -a'
'mount --fstab meine-wlan-fstab -a' benutzt wird.
Code: Alles auswählen
# dpkg-query -L systemd | sort | grep -i mount
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: AW: WLan aktivieren ohne root-PWD-Abfrage
Moin
Nur bei der Kombination mounts + Wlan + Shutdown haut das nicht vollständig hin... siehe Bug. Die mounts beim Systemstart klappen perfekt, systemd wartet, bis das Funknetz verfügbar ist, bevor es mein Script startet und darüber die Netzlaufwerke mounted. Im Unterschied zur Kabelverbindung wird beim Shutdown aber bei Wlan zuerst Wlan geschlossen und danach erst das Script gestartet. Und das hängt natürlich dann fest, weil es das Netz nicht mehr gibt. Das bedeutet, der "ordentliche" umount schlägt fehl.
MIT Script habe ich derzeit nur den Effekt, dass ich keine Fehlermeldung in der Shutdown-Konsolen-Ausgabe sehe. Ohne Script hängt der Laptop genauso, aber mit Fehlermeldungen "Fehlendes Netz". Der Fehler liegt imho in der Abarbeitung der Abhängigkeiten bei Systemd...hier: Wlan geschlossen VOR netzabhängigen Routinen. Bei Kabelanschluss besteht das Problem nicht.
Das es Bugs gibt, ist nicht das Problem. Mich ärgert nur, dass ich das nicht mit manuellen Vorgaben oder Steuerung umschiffen kann.
Das ist ja das verhexte....die mounts klappen beim Systemstart perfekt, so gut, dass ich die fstab gar nicht mehr verwenden will. Ebenso beim runterfahren, wenn der PC via Cat5-Kabel verbunden ist. Bevor das Netz weg ist, hat das Script erfolgreich umounted. Das funktioniert also mit Cat5e-Verbindung richtig klasse.rendegast hat geschrieben:Mögliches Problem:
Wenn das Mounten nicht funktioniert, bleibt der Systemstart stehen?
Nur bei der Kombination mounts + Wlan + Shutdown haut das nicht vollständig hin... siehe Bug. Die mounts beim Systemstart klappen perfekt, systemd wartet, bis das Funknetz verfügbar ist, bevor es mein Script startet und darüber die Netzlaufwerke mounted. Im Unterschied zur Kabelverbindung wird beim Shutdown aber bei Wlan zuerst Wlan geschlossen und danach erst das Script gestartet. Und das hängt natürlich dann fest, weil es das Netz nicht mehr gibt. Das bedeutet, der "ordentliche" umount schlägt fehl.
MIT Script habe ich derzeit nur den Effekt, dass ich keine Fehlermeldung in der Shutdown-Konsolen-Ausgabe sehe. Ohne Script hängt der Laptop genauso, aber mit Fehlermeldungen "Fehlendes Netz". Der Fehler liegt imho in der Abarbeitung der Abhängigkeiten bei Systemd...hier: Wlan geschlossen VOR netzabhängigen Routinen. Bei Kabelanschluss besteht das Problem nicht.
Das es Bugs gibt, ist nicht das Problem. Mich ärgert nur, dass ich das nicht mit manuellen Vorgaben oder Steuerung umschiffen kann.
Re: WLan aktivieren ohne root-PWD-Abfrage
Moin
Ich habe ein paar neue Erkenntnisse ... .... wo ich jetzt nicht weiss, ob ich lachen oder heulen soll
Also, mein obiges Script mountctrl in Verbindung mit der systemd-unit funktioniert tadellos, sowohl beim Start, als auch beim Shutdown. Beim Starten werden die Netzlaufwerke einwandfrei gemounted, beim Shutdown sauber umounted. Nach dem Start sehe ich es ja, alle Laufwerke sind da. Aber für den Shutdown habe ich nach dem Stop-Block im Script ein df -h >>$log (s.o.) angefügt, mit diesem Ergebnis beim Shutdown:
Und trotzdem hängt der Shutdown danach für 120 Sekunden mit der folgenden Meldung, um mir hinterher noch zu sagen, das er alle mountpoints (die nennt er dann einzeln und namentlich) umounted hat.... so'n quatsch, die sind alle lange vorher weg.
Ich habe ein paar neue Erkenntnisse ... .... wo ich jetzt nicht weiss, ob ich lachen oder heulen soll
Also, mein obiges Script mountctrl in Verbindung mit der systemd-unit funktioniert tadellos, sowohl beim Start, als auch beim Shutdown. Beim Starten werden die Netzlaufwerke einwandfrei gemounted, beim Shutdown sauber umounted. Nach dem Start sehe ich es ja, alle Laufwerke sind da. Aber für den Shutdown habe ich nach dem Stop-Block im Script ein df -h >>$log (s.o.) angefügt, mit diesem Ergebnis beim Shutdown:
Code: Alles auswählen
24-07-2015-15-47 mountctrl: stop
24-07-2015-15-50 mountctrl: start
24-07-2015-15-58 mountctrl: stop
24-07-2015-15-59 mountctrl: start
24-07-2015-16-02 mountctrl: stop
24-07-2015-21-20 mountctrl: start
24-07-2015-21-26 mountctrl: stop
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1 451G 4,2G 424G 1% /
udev 10M 0 10M 0% /dev
tmpfs 790M 9,5M 781M 2% /run
tmpfs 2,0G 0 2,0G 0% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 2,0G 0 2,0G 0% /sys/fs/cgroup
tmpfs 395M 4,0K 395M 1% /run/user/117
tmpfs 395M 4,0K 395M 1% /run/user/1001
24-07-2015-21-30 mountctrl: start
Code: Alles auswählen
CIFS VFS: Server xxx has not responded in 120 seconds
Re: WLan aktivieren ohne root-PWD-Abfrage
systemd fängt die Aufrufe doch ab.
Beim Mounten: Obwohl die wlan-Verbindung noch nicht da sein sollte
(dieser Vorgang dauert bei mir norrmalerweise einige Sekunden)
wird der mount schon als getätigt angezeigt, und nach dem vollen Boot ist dem dann wohl auch so.
Ein echter Test wäre hier dann nicht die Ausgabe des 'mount', das die Netzlaufwerke als verbunden zeigt,
sondern zBsp. die Ermittlung der Checksumme einer Datei auf dem Share, also ein echter Zugriff.
Wenn das beim Beenden auch in der Art läuft,
ist die Ausgabe Deines 'mount' vielleicht eine Vorspiegelung falscher Tatsachen.
Eine Ausweichmöglichkeit könnte autofs sein,
welches unbenutzte Mounts nach einer (einstellbaren) Zeit aushängt.
Die Shares wären dann vielleicht meistens gar nicht gemountet beim Herunterfahren.
Ein Stolperstein für diesen Weg könnte derart sein,
daß (dem Namen nach) von /media/Programme ein im Hintergrund laufendes Programm läuft oder /media/Multimedia von einem Streaming-Server offengehalten wird.
Beim Mounten: Obwohl die wlan-Verbindung noch nicht da sein sollte
(dieser Vorgang dauert bei mir norrmalerweise einige Sekunden)
wird der mount schon als getätigt angezeigt, und nach dem vollen Boot ist dem dann wohl auch so.
Ein echter Test wäre hier dann nicht die Ausgabe des 'mount', das die Netzlaufwerke als verbunden zeigt,
sondern zBsp. die Ermittlung der Checksumme einer Datei auf dem Share, also ein echter Zugriff.
Wenn das beim Beenden auch in der Art läuft,
ist die Ausgabe Deines 'mount' vielleicht eine Vorspiegelung falscher Tatsachen.
Eine Ausweichmöglichkeit könnte autofs sein,
welches unbenutzte Mounts nach einer (einstellbaren) Zeit aushängt.
Die Shares wären dann vielleicht meistens gar nicht gemountet beim Herunterfahren.
Ein Stolperstein für diesen Weg könnte derart sein,
daß (dem Namen nach) von /media/Programme ein im Hintergrund laufendes Programm läuft oder /media/Multimedia von einem Streaming-Server offengehalten wird.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: WLan aktivieren ohne root-PWD-Abfrage
Das könnte ich jetzt noch nicht mal mehr ausschließen. Ich habe jetzt 2 reproduzierbare Effekte. Wenn es systemisch beim Shutdown und über Systemd mit meinem Script "mountctrl stop" läuft, habe ich 2 Minuten Wartezeit und bekomme die Meldung:rendegast hat geschrieben:ist die Ausgabe Deines 'mount' vielleicht eine Vorspiegelung falscher Tatsachen.
Code: Alles auswählen
CIFS VFS: Server xxx.xxx.xxx.xx has not responded in 120 seconds. Reconnecting...
Code: Alles auswählen
a stop-job is running for 120 seconds
Und zwar mit "apt-get install sudo" und dem folgenden Script mit einem Desktop-Starter:
Code: Alles auswählen
#! /bin/sh
echo Bitte warten..... Laptop wird ausgeschaltet!
sudo umount -a -f >/dev/null 2>&1
sleep 4
sudo shutdown -h now
Ja, Du hast Recht, das hört sich missverständlich an. Aber dieser Share enthält keine ausführbaren Programme, sondern nur die Setup-Versionen (z.B. deb-Packages, etc), um Programme zu installieren.... und dieser Share zählt bei mir zu den Admin-Shares, an den Anwender gar nicht dran kommen.rendegast hat geschrieben:Ein Stolperstein für diesen Weg könnte derart sein, daß (dem Namen nach) von /media/Programme ein im Hintergrund laufendes Programm läuft oder /media/Multimedia von einem Streaming-Server offengehalten wird.
Eigentlich passt es mir gar nicht, jetzt mit AutoFS ein drittes Verfahren in Erwägung zu ziehen. Eigentlich möchte ich auf allen meinen Rechner ein relativ gleiches Customizing vorfinden, damit andere Dinge, wie Backups, Wartung, etc. gedanklich immer auf gleicher Erinnerung basieren und Jobs übertragbar sind. Weil auf 2 meiner Server die fstab nicht vernünftig läuft, habe ich auf die Alternative "Mount-Script" gewechselt. Und weil die rc.local wiederum unter systemd auf einer Maschine nicht richtig abgearbeitet wird, bin ich konsequent komplett auf die Schiene Systemd umgeschwenkt. Und genau die funktioniert jetzt wieder nicht in Verbindung mit mounts über eine WLAN-Verbindung..... das ist alles echt nervig.
- habakug
- Moderator
- Beiträge: 4313
- Registriert: 23.10.2004 13:08:41
- Lizenz eigener Beiträge: MIT Lizenz
Re: WLan aktivieren ohne root-PWD-Abfrage
Hallo!
Die Datei sollte also root und der Gruppe root gehören, ausführbar sein und die Erlaubnis zum Schreiben allein für den Besitzer erteilen. Das geht leider aus man 8 NetworkManager nicht hervor.
Dieses Skript wird ausgeführt, wenn das Netzwerk-Device vom NetworkManager getrennt wird:
Das nm-applet scheint diese Aktion beim Klicken auf "Ausschalten" leider nicht auszuführen. Da lässt sich aber sicher ein Knopf draus basteln.
Gruss, habakug
Die Voraussetzungen für das Starten der Skripte aus z.B. /etc/NetworkManager/dispatcher.d/pre-down.d/ sind beispielhaft folgende:TomL hat geschrieben:Jetzt habe ich aufgrund eines Hinweises im Bugreport versucht, das Problem über den Networkmanager-Dispatcher zu lösen, aber dieses Script wird überhaupt nicht gestartet, zu keiner Zeit.
Code: Alles auswählen
root@debian:~# vi /etc/NetworkManager/dispatcher.d/pre-down.d/umount_cifs
#!/bin/bash
umount -a -l -t cifs
root@debian:~# chown root:root /etc/NetworkManager/dispatcher.d/pre-down.d/umount_cifs
root@debian:~# chmod +x /etc/NetworkManager/dispatcher.d/pre-down.d/umount_cifs
root@debian:~# chmod 755 /etc/NetworkManager/dispatcher.d/pre-down.d/umount_cifs
Dieses Skript wird ausgeführt, wenn das Netzwerk-Device vom NetworkManager getrennt wird:
Code: Alles auswählen
user@debian:~# nmcli device disconnect wlan0
Gruss, habakug
Re: WLan aktivieren ohne root-PWD-Abfrage
Genau das ist das Problem.... beim Ausschalten passiert nix..... genau das hatte ich zwischenzeitlich auch festgestellt. Mein Script und die Einstellungen waren ok, es wird nur leider beim Ausschalten nicht ausgeführt.habakug hat geschrieben:Das nm-applet scheint diese Aktion beim Klicken auf "Ausschalten" leider nicht auszuführen. Da lässt sich aber sicher ein Knopf draus basteln.
Und Im Moment bin ich ziemlich frustriert, weil mal wieder alle Anstrengungen erfolglos sind. Von meinem Blickpunkt her habe ich momentan haufenweise Dinge, die nicht funktionieren. Das eigentliche Ziel war ja, vor dem Close der WLAN-Verbindung alle Mounts zu trennen, damit das System nicht ewig beim Shutdown hängt. Fakt ist, WLan wird "stillschweigend" gekappt, anscheinend ohne das restliche System via Message zu informieren. Das ist das ganze Problem.
Aus diesem Problem resultiert dann ein neues, und zwar, das der Anwender vor dem Shutdown etwas tun müsste, was ihm aber verboten ist....und zwar die Mountpoints trennen.Mit Bordmitteln und ohne Sudo nachzuinstallieren, ist das anscheinend nicht möglich. Weil sudo eigentlich für mich heute kein Mittel der Wahl mehr sein sollte, habe ich versucht, das über die Policies zu lösen, in dem ich die Datei
Code: Alles auswählen
/usr/share/polkit-1/actions/org.freedesktop.udisks2.policy
Dann habe ich nach irgendeiner Doku eigene neue Rules erstellt, in der Datei:
Code: Alles auswählen
/usr/share/polkit-1/rules.d/udisks2.rules
Code: Alles auswählen
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.filesystem-unmount-others") {
return polkit.Result.YES;
}
});
- habakug
- Moderator
- Beiträge: 4313
- Registriert: 23.10.2004 13:08:41
- Lizenz eigener Beiträge: MIT Lizenz
Re: WLan aktivieren ohne root-PWD-Abfrage
Hallo!
Du wolltest doch eigentlich, dass der User Netzwerkgeräte ein- und ausschalten darf. Das geht jetzt und du brauchst dich um die Rechte beim unmounten nicht zu sorgen. Ich hatte oben aufgezeigt das nmcli die Skripte triggert. Mit "Knopf bauen" meinte ich in einem Standard-Debian Jessie mit Gnome in die obere linke Ecke zu klicken und alacarte zu tippen und zu klicken. Im Hauptmenü den Button "Neuer Eintrag" wählen und einen Namen für den Button vergeben, das Kommando "nmcli device disconnect wlan0" sowie einen Kommentar einfügen. Das "Launch in Terminal" kann ebenfalls gefahrlos angehakt werden.
Jetzt gibt es einen Button im Aktivitäten-Menü der das Wlan abschaltet und vorher dein oder das oben genannte Skript ausführt.
Icons für die Buttons findet man in /usr/share/icons.
Man könnte weiter überlegen auch den shutdown noch in den Button zu integrieren
Gruss, habakug
Du wolltest doch eigentlich, dass der User Netzwerkgeräte ein- und ausschalten darf. Das geht jetzt und du brauchst dich um die Rechte beim unmounten nicht zu sorgen. Ich hatte oben aufgezeigt das nmcli die Skripte triggert. Mit "Knopf bauen" meinte ich in einem Standard-Debian Jessie mit Gnome in die obere linke Ecke zu klicken und alacarte zu tippen und zu klicken. Im Hauptmenü den Button "Neuer Eintrag" wählen und einen Namen für den Button vergeben, das Kommando "nmcli device disconnect wlan0" sowie einen Kommentar einfügen. Das "Launch in Terminal" kann ebenfalls gefahrlos angehakt werden.
Jetzt gibt es einen Button im Aktivitäten-Menü der das Wlan abschaltet und vorher dein oder das oben genannte Skript ausführt.
Icons für die Buttons findet man in /usr/share/icons.
Man könnte weiter überlegen auch den shutdown noch in den Button zu integrieren
Gruss, habakug
Re: WLan aktivieren ohne root-PWD-Abfrage
Moin
1. umount -a -f
2. nmcli device disconnect wlan0
3. shutdown -h now
Aber ich denke, auf Punkt 2 könnte man eigentlich auch verzichten.... 'umount' zuerst, dann direkt 'shutdown'. Den "Disconnect wlan0" übernimmt dann ganz sicher systemd beim poweroff. Das Problem liegt jetzt bei Punkt 1. Jeder Job, egal von wem aufgerufen (systemd, network-dispatcher oder Knopf), scheitert an diesem Punkt ... denn der Anwender ist schlichtweg nicht dazu berechtigt. Und damit läuft der shutdown nicht mehr sauber ab. Entweder gibt der Anwender das root-PWD ein, dann klappt es mit dem umount und der shutdown läuft. Oder er machts nicht (weil er es nicht kennt) und der shutdown hängt mit den Messages "stop-job *irgendwas* 120 seconds" und "Cifs VFS *irgendwas* reconnect 120 seconds" .
Ich suche jetzt ne Lösung, wie ich den Anwender mit vorhandenen (!) Bordmitteln zum umount berechtigen kann (ohne sudo zu installieren), damit der wlan0-Disconnect beim shutdown kein Chaos wegen der vorhandenen mounts auslöst.
Ja, das war ja schon mit Deiner Antwort im zweiten Posting gelöst.... und das funktionier alles prima. Es ist ja auch gar nicht das Problem einen zusätzlichen Knopf zu installieren, der irgendwas macht, z.B. WLAN deaktivieren oder so..... aber imho ist das gar nicht notwendig, das WLAN vor dem shutdown zu deaktivieren. Und wenn man es trotzdem wollte, sieht die vollständige Job-Kette eines solchen Knopfes m.E. so aus:habakug hat geschrieben: Du wolltest doch eigentlich, dass der User Netzwerkgeräte ein- und ausschalten darf.
1. umount -a -f
2. nmcli device disconnect wlan0
3. shutdown -h now
Aber ich denke, auf Punkt 2 könnte man eigentlich auch verzichten.... 'umount' zuerst, dann direkt 'shutdown'. Den "Disconnect wlan0" übernimmt dann ganz sicher systemd beim poweroff. Das Problem liegt jetzt bei Punkt 1. Jeder Job, egal von wem aufgerufen (systemd, network-dispatcher oder Knopf), scheitert an diesem Punkt ... denn der Anwender ist schlichtweg nicht dazu berechtigt. Und damit läuft der shutdown nicht mehr sauber ab. Entweder gibt der Anwender das root-PWD ein, dann klappt es mit dem umount und der shutdown läuft. Oder er machts nicht (weil er es nicht kennt) und der shutdown hängt mit den Messages "stop-job *irgendwas* 120 seconds" und "Cifs VFS *irgendwas* reconnect 120 seconds" .
Ich suche jetzt ne Lösung, wie ich den Anwender mit vorhandenen (!) Bordmitteln zum umount berechtigen kann (ohne sudo zu installieren), damit der wlan0-Disconnect beim shutdown kein Chaos wegen der vorhandenen mounts auslöst.
Genau das ist das einzige Problem.... denn der Anwender ist nicht zum umount berechtigt. .... .... moment mal.... jetzt gerade beim Schreiben macht da was "click"..... nmcli device disconnect wlan0 wird vom User aufgerufen. Und der dadurch ausgelöste Dispatcher-Job dann mit root-rechten? ... ... dann wäre das ja wirklich die Lösung.... sofern der disconnect dann nicht sofort wieder persistent wäre. Das probiere ich morgen.Das geht jetzt und du brauchst dich um die Rechte beim unmounten nicht zu sorgen.
- habakug
- Moderator
- Beiträge: 4313
- Registriert: 23.10.2004 13:08:41
- Lizenz eigener Beiträge: MIT Lizenz
Re: WLan aktivieren ohne root-PWD-Abfrage
Hallo!
Das pre-down-Skript wird, wie man sieht, vor dem Disconnect ausgeführt.
Ein Standard Debian kann vom User übrigens mit einem systemctl poweroff heruntergefahren werden. Hängt man ein "-i" dran, kann man sogar den über SSH angemeldeten root rauswerfen
Gruss, habakug
Ich hatte oben ausdrücklich erklärt, dass die Skripte root gehören müssen. Alles was drin steht wird also mir root-Rechten ausgeführt.Und der dadurch ausgelöste Dispatcher-Job dann mit root-rechten?
Code: Alles auswählen
Jul 27 22:50:43 debian NetworkManager[483]: <info> (wlan0): device state change: activated -> deactivating (reason 'user-requested') [100 110 39]
Jul 27 22:50:43 debian nm-dispatcher[2244]: Dispatching action 'pre-down' for wlan0
Jul 27 22:50:43 debian nm-dispatcher[2244]: This is your Captain speaking.
Jul 27 22:50:43 debian NetworkManager[483]: <info> (wlan0): device state change: deactivating -> disconnected (reason 'user-requested') [110 30 39]
Jul 27 22:50:43 debian NetworkManager[483]: <info> (wlan0): deactivating device (reason 'user-requested') [39]
Jul 27 22:50:43 debian NetworkManager[483]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 2232
Ein Standard Debian kann vom User übrigens mit einem systemctl poweroff heruntergefahren werden. Hängt man ein "-i" dran, kann man sogar den über SSH angemeldeten root rauswerfen
Gruss, habakug
Re: WLan aktivieren ohne root-PWD-Abfrage
Moin
Aber die Lösung ist gefunden. Es funktioniert ... ... richtig gut... zwar jetzt etwas anders, als von Dir vorgeschlagen, aber Du hast definitiv den Karren in die richtige Richtung auf die Strasse gestellt Danke! Ich werde etwas später hier noch mal die ganze Lösung anhängen.... vielleicht ist das ja für den einen oder anderen auch noch interessant. Für mich war dabei jetzt wichtig, dass ich ein Customizing bekomme, welches bei uns auf mehreren Laptops, Notebooks, Desktops und mehreren Raspberry Pi's ohne Anpassungen läuft und dabei unterschiedliche systemspezifische Fehler umgeht oder löst. Ich denke mal, das ist gelungen.
Wenn ich das Rechte-System nicht völlig falsch verstanden habe, müsste es doch eigentlich völlig irrelevant sein, wem ein Script gehört. Wichtig ist nur, wem der Besitzer erlaubt, es ausführen zu dürfen: nur er selber, seiner Gruppe, oder allen. Das es alle ausführen dürfen sagen ja hier in dem Beispiel die Rechte "0755" und "ausführbar". Und derjenige, der es dann ausführt, tut das mit seinen Rechten, ganz egal, ob ihm das Script gehört oder nicht. Also, ob das Script root gehört oder nicht, ist m.E. egal, wichtig ist nur der Effekt, wenn root es ausführt, dann tut er es mit root-rechten und nicht mit den Rechten des Besitzers. Ebenso kann ja ein User ein Script ausführen, dessen Eigentümer root ist, wenn root die Ausführung mit dem Recht "0755" "allen" erlaubt. Führt der User es dann aus, tut er das allerdings nur mit seinen eingeschränkten Rechten. Ist das jetzt falsch?habakug hat geschrieben: Ich hatte oben ausdrücklich erklärt, dass die Skripte root gehören müssen. Alles was drin steht wird also mir root-Rechten ausgeführt.
Aber die Lösung ist gefunden. Es funktioniert ... ... richtig gut... zwar jetzt etwas anders, als von Dir vorgeschlagen, aber Du hast definitiv den Karren in die richtige Richtung auf die Strasse gestellt Danke! Ich werde etwas später hier noch mal die ganze Lösung anhängen.... vielleicht ist das ja für den einen oder anderen auch noch interessant. Für mich war dabei jetzt wichtig, dass ich ein Customizing bekomme, welches bei uns auf mehreren Laptops, Notebooks, Desktops und mehreren Raspberry Pi's ohne Anpassungen läuft und dabei unterschiedliche systemspezifische Fehler umgeht oder löst. Ich denke mal, das ist gelungen.
Re: WLan aktivieren ohne root-PWD-Abfrage
Für das Ausführen an sich ist es egal, wem das Skript gehört. Es stellt aber durchaus ein Sicherheitsrisiko dar, wenn ein Skript, das später mit root-Rechten ausgeführt wird, einem beliebigen Benutzer gehört – und von diesem verändert werden kann.TomL hat geschrieben:Wenn ich das Rechte-System nicht völlig falsch verstanden habe, müsste es doch eigentlich völlig irrelevant sein, wem ein Script gehört.
Manchmal bekannt als Just (another) Terminal Hacker.
Re: WLan aktivieren ohne root-PWD-Abfrage
Ja, ich weiss, du hast natürlich Recht. Aber in diesem Fall sind es sowieso immer meine Scripte, die ich selber erstellt habe und die ich selber pflege. Manchmal ändere ich sie mit nano an Ort und Stelle, danach gehören sie im Regelfall root. Manchmal schreibe ich sie aber auch mit Kate in meinem Script-Dir und kopiere sie danach an Ort und Stelle, dann gehören sie halt mir. Und ich sehe da gerade keinen großen Unterschied beim Recht 0755, da sowieso nur der Besitzer ein Änderungsrecht hat und "others" bei beiden Besitzern das Lese- und Ausführenrecht haben.JTH hat geschrieben:Für das Ausführen an sich ist es egal, wem das Skript gehört. Es stellt aber durchaus ein Sicherheitsrisiko dar, wenn ein Skript, das später mit root-Rechten ausgeführt wird, einem beliebigen Benutzer gehört – und von diesem verändert werden kann.TomL hat geschrieben:Wenn ich das Rechte-System nicht völlig falsch verstanden habe, müsste es doch eigentlich völlig irrelevant sein, wem ein Script gehört.
- habakug
- Moderator
- Beiträge: 4313
- Registriert: 23.10.2004 13:08:41
- Lizenz eigener Beiträge: MIT Lizenz
Re: WLan aktivieren ohne root-PWD-Abfrage
Hallo!
Der Vollständigkeit halber hier [1] der Bug-Report (Gnome) und die Begründung (?) warum die Skripte nicht ausgeführt werden:
Gruss, habakug
[1] https://bugzilla.gnome.org/show_bug.cgi?id=701242
Der Vollständigkeit halber hier [1] der Bug-Report (Gnome) und die Begründung (?) warum die Skripte nicht ausgeführt werden:
Da mag es auch andere Meinungen geben, das muss man aber erst mal so hinnehmen.Thomas Haller hat geschrieben:When NetworkManager is stopped, it leaves the connections up. It does that on purpose, for example not do break connectivity during restart or NetworkManager.
Since it doesn't down the connection, the dispatcher scripts don't run either. That seams correct to me.
[...]
Leaving the connection up, allows non-destructive restart of NetworkManager.
Gruss, habakug
[1] https://bugzilla.gnome.org/show_bug.cgi?id=701242
Re: WLan aktivieren ohne root-PWD-Abfrage
@habakug
Ich muss da wohl mal jetzt gaaaanz kleine Brötchen backen....... ... dieser verdammte Networkmanager bootet das Dispatcher-Script doch tatsächlich nur, wenn root der Besitzer ist. Ich war völlig baff, als ich gerade am Laptop meiner Frau bemerkt habe, dass der Job nicht gestartet wird. Ich habe natürlich alles mögliche an Fehlern gesucht und untersucht und nach ner halben Stunde auch mal den Besitz kontrolliert.... verdorri nochma.... das gibts doch gar nicht... gibts aber leider doch.... so kann man sich täuschen.
Ich muss da wohl mal jetzt gaaaanz kleine Brötchen backen....... ... dieser verdammte Networkmanager bootet das Dispatcher-Script doch tatsächlich nur, wenn root der Besitzer ist. Ich war völlig baff, als ich gerade am Laptop meiner Frau bemerkt habe, dass der Job nicht gestartet wird. Ich habe natürlich alles mögliche an Fehlern gesucht und untersucht und nach ner halben Stunde auch mal den Besitz kontrolliert.... verdorri nochma.... das gibts doch gar nicht... gibts aber leider doch.... so kann man sich täuschen.