Moin liebe Community,
ich habe ab und zu das Problem, dass sich mein Bluetooth Dongle "aufhängt" und ich diesen mit folgenden Befehlen wieder zum laufen bekomme:
hciconfig hci0 down
hciconfig hci0 up
Diese Befehle führe ich als root via ssh aus.
Danach läuft der Bluetooth Dongle wieder einwandfrei.
Ich wollte nun gerne diese Befehle via FHEM senden, dazu habe ich folgenden Code in die FHEM Commandozeile ausgeführt:
{system('hciconfig hci0 down')}
Als Rückgabe habe ich direkt "-1" bekommen und im Log steht:
Can't down device hci0: Operation not permitted (1)
Dieser Code wird ja als User "fhem" ausgeführt, der augenscheinlich nicht die notwendigen Rechte besitzt.
Daraufhin habe ich mir gedacht, ich versuche "fhem" die notwendigen Rechte zu geben in der /etc/sudoers habe ich deswegen folgendes stehen:
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
fhem ALL=(ALL:ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
fhem ALL=(ALL) NOPASSWD: ALL
Habe danach einen Reboot ausgeführt und erneut probiert, leider bleibt die Fehlermeldung identisch.
Bevor ich nun also weiter herumprobiere, wollte ich Euch lieber fragen, ob ihr konkrete Tipps für mich habt.
Recht herzlichen Dank
gruß Mathze
Hi,
mach diesen Leichtsinn in der sudoers bitte wieder rückgängig und führe folgendes aus
#!/bin/bash
# ergänze eine Datei zum sudoers Script Verzeichnis /etc/sudoers.d/
sudo su
File="011_fhem-nopasswd"
echo "fhem ALL=(ALL) NOPASSWD: /usr/sbin/hciconfig *" >/etc/sudoers.d/$File
chmod 0440 /etc/sudoers.d/$File
Danach kannst Du in der FHEM Kommandozeile folgendes direkt testen (ohne {system()})!
"sudo hciconfig hci0 down"
Gruß Otto
Moin Otto,
habe die Veränderung in der sudoers-Datei wieder rückgängig gemacht.
Ich wollte nun nach deine Anleitung das Script erstellen, wobei ich auf folgendes Problem stoße:
cd /etc/sudoers.d/
-bash: cd: /etc/sudoers.d/: Datei oder Verzeichnis nicht gefunden
Bei mir existiert dieser Pfad nicht, soll ich diesen zuerst anlegen?
Gruß
Mathze
Den Pfad anlegen, und in der sudoers Datei die entsprechende include-Zeile aktivieren ("#" entfernen).
Den zweiten fhem-Eintrag hast Du auch entfernt?
Oh ja hab ich übersehen :-[
Was für ein System hast Du? Normalerweise kenne ich das als aktiv und vorhanden...
Zitat von: digiart am 04 Januar 2019, 10:56:48
Den zweiten fhem-Eintrag hast Du auch entfernt?
Guter Hinweis!
Zitat von: digiart am 04 Januar 2019, 10:56:48
Den Pfad anlegen, und in der sudoers Datei die entsprechende include-Zeile aktivieren ("#" entfernen).
Weder Pfad anlegen noch den Kommentar wegnehmen sollte er machen...
Den Kommentar wegnehmen ist unnötig!
@t1me2die:
welches System hast Du!?
(wobei es eigenartig ist wäre, da ja der Hinweis in der sudoers steht)
EDIT: @Otto: bin schon wieder raus ;)
EDIT2: bzw. wenn der Pfad nicht existiert, dann einfach Ottos "Eintrag" aus dem Script per "sudo visudo" in die eigentliche sudoers eintragen (so wie vorher auch deine fhem-Einträge)... Also: ganz am Ende einfach das hier ergänzen: fhem ALL=(ALL) NOPASSWD: /usr/sbin/hciconfig *
Gruß, Joachim
Moin ihr zwei, nun bin ich etwas überfordert.
Ich habe Ubuntu in einer VM laufen.
Als ich vorhin:
nano /etc/sudoers
gemacht habe, wurde diese Datei neu angelegt, diese war also standardmäßig nicht vorhanden.
Von Debian bin ich es gewohnt, dass diese Dateien vorhanden sind. (hab auf einem RaspberryPi Zero mit Debian nachgeschaut, hier ist der Pfad / Datei vorhanden).
Ich soll nun also in der sudoers-Datei den folgenden Punkt aktivieren:
#includedir /etc/sudoers.d
Danach soll ich den Ordner anlegen:
mkdir /etc/sudoers.d/
Und soll in
cd /etc/sudoers.d/
eine Datei mit dem Script von Otto anlegen, ist das richtig?
Gruß
Mathze
Hi,
ohje das endet jetzt offenbar im Chaos! :-[
Die sudoers Datei bearbeitet man bitte
ausschließlich mit visudo !
Die Zeile
#includedir /etc/sudoers.d
ist richtig so und es ist kein Kommentar!
Eigentlich sollst Du kein Script anlegen! Du sollst einfach die Befehle ausführen! Oder mit
sudo visudo -f /etc/sudoers.d/011_fhem-nopasswd
Eine Datei mit dem Inhalt
fhem ALL=(ALL) NOPASSWD: /usr/sbin/hciconfig *
anlegen.
Aber klar den Pfad braucht man dazu.
Erklärung:
Es gibt gute Gründe die Datei sudoers so zu lassen wie sie ist und ausschließlich den Mechansimus /etc/sudoers.d/... zu verwenden.
Ich finde gerade den Erklärbeitrag nicht von dieser Tage :-\ war so in der Art (ob das alles stimmt hab ich nicht geprüft)
ZitatChanges made to files in /etc/sudoers.d remain in place if you upgrade the system. This can prevent user lockouts when the system is upgraded. Ubuntu tends to like this behavior. Other distributions are using this layout as well.
It has been my experience that the rules on files in this directory are looser than for /etc/sudoers. This has included:
Mistakes in the file did not cause sudo to fail. However, the file was ignored.
Permission rules appear less strict. It allows the applicable group or other to read the file. I don't believe that was possible with /etc/sudoers. Write permissions must be restricted to root to maintain security. The current Ubuntu version of sudo allows read permissions for group or other. (This capability allows sudo access to be audited using without requiring root access.)
The visudo command only defaults to /etc/sudoers. It will edit and verify any file you specify with the -f option. I use this capability to edit files which will be automatically installed as /etc/sudoers or into /etc/sudoders.d. However, definitions from other files may not be found. It is best to make the file independent.
Quelle (https://superuser.com/questions/869144/why-does-the-system-have-etc-sudoers-d-how-should-i-edit-it/1027257)
Gruß Otto
NEIN!
Schon das erste Anlegen der sudoers war "irgendwie eigenartig"!
Und noch mehr, dass es OHNE sudo etc. "geklappt" hat...
Zum Bearbeiten der sudoers:
entweder ein "verlässliches" Script (siehe Otto)
oder "visudo" verwenden, da dies auch Syntay-Checks durchführt (siehe meine letzte Antwort)
Wie hast du das System erstellt?
Was hast du denn schon alles "getan"?
EDIT: ist sudo bei dir überhaupt "installiert"? Also wenn du 'sudo' in der Linux-Shell ausführst was kommt?
Gruß, Joachim
Das System habe ich vor ca. 1 Jahr aufgesetzt, irgendwann wurde es dazu verwendet iBeacons (BTLE Tags) zu überwachen.
Ich habe dort lediglich FHEM (als root) installiert, wie es auf https://debian.fhem.de/ beschrieben war.
Dann habe ich nur noch lepresenced installiert und das war es.
sudo war nicht installiert, habe dies nun mit "apt-get install sudo" nachinstalliert.
Jetzt sind auch alle Dateien und Pfade vorhanden.
Nun habe ich folgendes gemacht:
sudo visudo -f /etc/sudoers.d/011_fhem-nopasswd
hier habe ich folgendes eingefügt:
fhem ALL=(ALL) NOPASSWD: /usr/sbin/hciconfig *
Nun noch ein "shutdown -r now" ausgeführt.
Nun sollte ich laut Otto direkt in FHEM in der Commandozeile folgendes eingeben:
sudo hciconfig hci0 down
Als Meldung erhalte ich:
Unknown command sudo, try help.
Gruß
Mathze
Welcher User bist du, wenn du in der Kommandozeile das "sudo hciconfig hci0 down" eingibst?
EDIT: ups die Frage war Quatsch ;) Du meinst ja schon die FhemWeb-Cmd... ;)
Außerdem meinte Otto (so lese ich das), dass du das (inclusive der Anführungszeichen) in die FHEM-Web-cmd eingeben sollst:
"sudo hciconfig hci0 down"
Gruß, Joachim
genau :D ::)
Erklärung -> https://commandref.fhem.de/commandref_DE.html#command "Shell Befehle"
Der Neustart war übrigens unnötig - aber schadet nie!
Mit etwas mehr Prosa steht das auch hier (https://heinz-otto.blogspot.com/2017/08/raspberry-ausschalten-mit-fhem.html), aber ich sollte einen Wiki Artikel machen.
Gruß Otto
Moin Joachim,
du hast Recht, dass habe ich tatsächlich falsch gelesen / verstanden gehabt.
Nachdem ich nun
"sudo hciconfig hci0 down"
bzw.
"sudo hciconfig hci0 up"
eingegeben habe, erhalte ich keine "-1" mehr, dafür steht nun im Log folgendes:
Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die
Regeln erklärt hat. Normalerweise läuft es auf drei Regeln hinaus:
#1) Respektieren Sie die Privatsphäre anderer.
#2) Denken Sie nach, bevor Sie tippen.
#3) Mit großer Macht kommt große Verantwortung.
sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben
Die Meldung, mit Opertion not permitted ist auch weg. Die Frage ist nun, wurden die Befehle tatsächlich ausgeführt?
Gruß
Mathze
Na gut, das ist den System Spezialität. Ich glaube in dem Fall muss man sich einmal als user fhem interaktiv anmelden um das weg zu bekommen :-[
Wenn ja, dann:
Die Befehle ausführen bzw. das tun was im Kommentar steht:
sudo cp /etc/passwd /etc/passwd.sav
sudo nano /etc/passwd
# in der Zeile: fhem:x:999:20::/opt/fhem:/bin/false
# von /bin/false auf /bin/bash ändern und speichern
sudo passwd fhem # Passwort vergeben und bestätigen
su fhem # Als fhem einloggen, es startet eine neue session!
Jetzt einmal was mit sudo machen. Frage bestätigen. Dann testen ob die Frage ausbleibt. Dann die Sitzung verlassen und die Sache mit der Anmeldung von fhem zurücksetzen.
exit
sudo cp /etc/passwd.sav /etc/passwd #und Anmeldung wieder zurückstellen
Gruß Otto
Moin Otto, habe ich so gemacht, wie du geschrieben hast:
root@FHEM-Beacons:~# sudo passwd fhem
Geben Sie ein neues UNIX-Passwort ein:
Geben Sie das neue UNIX-Passwort erneut ein:
passwd: Passwort erfolgreich geändert
root@FHEM-Beacons:~# su fhem
fhem@FHEM-Beacons:/root$ sudo -l
Passende Defaults-Einträge für fhem auf
FHEM-Beacons:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
Der Benutzer fhem darf die folgenden Befehle auf
FHEM-Beacons ausführen:
(ALL) NOPASSWD: /usr/sbin/hciconfig *
fhem@FHEM-Beacons:/root$ sudo hciconfig hci0 down
Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die
Regeln erklärt hat. Normalerweise läuft es auf drei Regeln hinaus:
#1) Respektieren Sie die Privatsphäre anderer.
#2) Denken Sie nach, bevor Sie tippen.
#3) Mit großer Macht kommt große Verantwortung.
[sudo] Passwort für fhem:
Leider darf der Benutzer fhem »/bin/hciconfig hci0 down« als root auf FHEM-Beacons.fritz.box nicht ausführen.
fhem@FHEM-Beacons:/root$
Und nun?
Gruß
Mathze
Hmm sorry, ich hatte auf meinem System geschaut wo hciconfig ist. Das ist bei Dir anders:
/bin/hciconfig
Musst Du nochmal in der /etc/sudoers.d/011 ... ändern. Also "usr/s" löschen :)
Gruß Otto
Danke Otto :)
Funktioniert!
Auch ohne Meldungen im Log, super!
Jetzt möchte ich gerne einen at anlegen, der jeden Tag um 03:00:00 ausgeführt ist, eigentlich kein großer Akt, jedoch bin ich mir bei den Anführungszeichen und dem escapen unsicher, außerdem möchte ich zwischen "down" und "up" eine kurze Verzögerung einbauen:
Was ich probiert habe:
define t_test at *12:56:00 ""sudo hciconfig hci0 down"" ;; sleep 30 ;; ""sudo hciconfig hci0 up""
define t_test at *12:56:00 \"sudo hciconfig hci0 down\" ;; sleep 30 ;; \"sudo hciconfig hci0 up\"
Beides hat nicht funktioniert, weil ich falsch escape.
Dies funktioniert, jedoch wollte ich eigentlich nicht auf die Perlebene gehen, wenn es nicht sein muss.
define t_test at *12:56:00 { fhem"\"sudo hciconfig hci0 down\" ;; sleep 30 ;; \"sudo hciconfig hci0 up\" "}
Gruß
Mathze
Einfacher ;)define t_test at *12:56:00 "sudo hciconfig hci0 down" ;; sleep 30 ;; "sudo hciconfig hci0 up"
Zitat von: Otto123 am 04 Januar 2019, 13:23:15
Einfacher ;)define t_test at *12:56:00 "sudo hciconfig hci0 down" ;; sleep 30 ;; "sudo hciconfig hci0 up"
Das hatte ich auch schon probiert gehabt, bekomme dann folgende Meldung im Log:
Warning: unknown command - "hciconfig"
Warning: unknown command - "hci0"
Gruß
Mathze
Ja fhem hat offenbar keinen Pfad dahin. Ändere das mal in absolute Pfade. Ist sowieso immer besser
/bin/hciconfig
Zitat von: Otto123 am 04 Januar 2019, 13:56:05
Ja fhem hat offenbar keinen Pfad dahin. Ändere das mal in absolute Pfade. Ist sowieso immer besser
/bin/hciconfig
Dann bekomme ich die Fehlermeldung:
Warning: unknown command - "/bin/hciconfig"
Warning: unknown command - "hci0"
Gruß
Mathze
Wo genau kommt der Fehler? Beim anlegen? Im Log?
Also mein Test mit defmod a_test1 at *13:53 "echo test"
funktioniert einwandfrei
Aber ein Test mit defmod a_test1 at *13:53 "echo test" ;; "echo willi "
Funktioniert nicht wie erwartet. Dann steht im Log test ; echo willi
Offenbar gibt es da ein "Interpretationsproblem" - auch das Beispiel aus der Doku
define a3 at 17:00:00 "/bin/echo "Teatime" > /dev/console" # shell Befehl
funktioniert nicht wie erwartet, kann aber ein anderes Problem sein.
Ich bin damit am Ende meiner Ideen. Nimm doch die Perl Variante.
Gruß Otto
Anlegen kann ich den at, da gibt es keine Meldung.
Erst zum Ausführungszeitpunkt wird die Meldung ins Log geschrieben.
Ein
define t_BluetoothDongle_Restart at 14:25:30 "sudo /bin/hciconfig hci0 down"
funktioniert.
Ein Befehl zur Zeit funktioniert.
Bei
define t_BluetoothDongle_Restart at 14:24:30 "sudo /bin/hciconfig hci0 down" ;; sleep 30 ;; "sudo /bin/hciconfig hci0 up"
oder
define t_BluetoothDongle_Restart at 14:28:30 "sudo /bin/hciconfig hci0 down" ;; "sudo /bin/hciconfig hci0 up"
kommt der o.g. Fehler.
Muss ich also doch auf Perl-Ebene gehen? (wäre jetzt auch nicht weiter schlimm, ich dachte nur, es würde auch ohne gehen bzw. ich stelle mich evtl. zu dumm an?!)
Gruß
Mathze
Ja offenbar. Ein Befehl geht, zwei gehen nicht...
Okay, trotzdem danke Otto :)
Ich begnüge mich dann mit
define t_BluetoothDongle_Restart at *03:00:00 { fhem"\"sudo hciconfig hci0 down\" ;; sleep 5 ;; \"sudo hciconfig hci0 up\" "}
Denn das funktioniert :)
Gruß
Mathze