Hallo zusammen,
ich habe augenscheinlich einen Fehler gemacht und nun Probleme mit meiner FHEM-Installation und dem dort laufenden System.
Ich habe mich erstmals mit dem Modul FHEMInstaller beschäftigt und jenes installiert. Dort erhielt ich via Popup eine Fehlermeldung bzgl. Zugriffsrechte (siehe Anhang1), begann zu googeln und fand hier Hoffnung: https://wiki.fhem.de/wiki/FHEM_mit_sudo
Auf meinem Raspberry Pi war ich im Terminal eingeloggt als User "Pi" und habe dies ausgeführt:
sudo visudo /etc/sudoers.d/011_fhem-nopasswdund wollte in die neue Datei die Zeile
fhem ALL=(ALL) NOPASSWD:SETENV: *einfügen und abspeichern.
Irgendwas lief schief, jedenfalls ist die Datei nun unter /etc/sudoers.d/ erzeugt, ich kann sie aber nicht mehr öffnen oder löschen, da der Besitzer "root" ist.
Wenn ich nun irgendwas im Termial probiere, erhalte ich nur noch:
Zitat
pi@raspberrypi:~ $ sudo rm /etc/sudoers.d/011_fhem-nopasswd
>>> /etc/sudoers.d/011_fhem-nopasswd: Syntax-Fehler near line 1 <<<
sudo: Syntax-Fehler in /etc/sudoers.d/011_fhem-nopasswd bei der Zeile 1
sudo: Keine gültige sudoers-Quelle gefunden, Programmende
sudo: Regelwerks-Plugin konnte nicht initialisiert werden
In diesem Zusammenhang fand ich schon einen älteren Hilfe-Thread in diesem Forum
https://forum.fhem.de/index.php/topic,94896.0.html
blicke aber ehrlicherweise nicht recht durch, was ich nun tun kann. Ich habe noch keinen Neustart des Systems gemacht, FHEM läuft aktuell und ich habe etwas
Panik, nun was falsch zu machen.
Beim Aufsetzen des Pis vor Jahren habe ich alle meine Vorgaben nach Tutorial aufgeschrieben, so auch das Kennwort für den User "Pi" usw. Für den User "root" habe ich nie ein Kennwort o.ä. vergeben (um mich jetzt z.B. als "root" einzuloggen, um diese Datei löschen zu können).
Mein derzeitig einziger Lösungsweg, wenn ich richtig verstanden habe, wäre ein Alternativsystem auf Linuxbasis, dort die SD-Karte mittels USB-SD-Cardreader zu mounten und dann die ensprechende Datei zu löschen. Ein zweiter Raspi und USB-Cardreader wäre vorhanden...
Hi,
kann mir zwar nicht erklären was da schief ging, aber die Datei wirkt und wirft Fehler. Damit hast Du Dich ev. ausgesperrt aus sudo ;)
Den Begriff SETENV: an der Stelle find ich eigenartig.
Ich denke das ist falsch.Edit: offenbar ein mir nicht bekannter Syntax, dazu würdest Du fhem für alle Befehle im Environment / System zum sudoer machen (wenn ich das richtig interpretiere), dass ist sowieso kein guter Gedanke!
Hier meine Notiz (https://heinz-otto.blogspot.com/2017/08/raspberry-ausschalten-mit-fhem.html).
ZitatMein derzeitig einziger Lösungsweg, wenn ich richtig verstanden habe, wäre ein Alternativsystem auf Linuxbasis, dort die SD-Karte mittels USB-SD-Cardreader zu mounten und dann die ensprechende Datei zu löschen. Ein zweiter Raspi und USB-Cardreader wäre vorhanden...
Das wäre der Weg :)
Gruß Otto
Zitat von: Otto123 am 10 Oktober 2022, 12:34:27
Den Begriff SETENV: an der Stelle find ich eigenartig. Ich denke das ist falsch.
Ich bin Laie mit Linux & Co. Deshalb schaue ich mir jeden Schritt einzeln an und kontrolliere i.d.R. mehfach nach bzw. lasse eigentlich von flexiblen Spielereien grundsätzlich aus Sicherheitsgründen die Finger. Damit fahre ich mit FHEM seit Jahren eigentlich sehr gut.
Obigen Befehl habe ich dem Popup aus FHEM entnommen, 1:1 kopiert und im Editor eingefügt. Schreibfehler sind ausgeschlossen (weil copy&paste)
Eigentlich bin ich auch recht sicher, danach die Datei im Editor gespeichert und den Editor geschlossen zu haben.
Leider kann ich zur Ursache weiter nichts beitragen.
Nach Feierabend heute nachmittag muss ich zuhause dann physisch mal ran. So ein Mist...
Aus Neugier:
Was passiert jetzt bei einem normalen Restart des Systems? Darf "Pi" sich noch einloggen?
Zitat von: Dracolein am 10 Oktober 2022, 12:48:56
(weil copy&paste)
Naja copy & paste sind aus einem Web Interface heraus auch nicht immer ein guter Gedanke, aber im Linux Editor hättest Du eigentümliche Zeichen eigentlich sehen müssen.
Ich würde auch so vergehen:
- Pi-Runterfahren
- SD-Card in 2. Rechner
- Mounten
- rm <mountpoint>/etc/sudoers.d/011_fhem-nopasswd
- unmounten
- im Pi reinstecken, hoch fahren und das "beten" nicht vergessen ;)
Generell: Vergieb einem Deamon so wenig Rechte wie möglich! (Wie Otto schon andeutete)
SETENV giebt es bei sudoers ...
https://serverfault.com/questions/480136/how-do-i-set-both-nopasswd-and-setenv-on-the-same-line-in-sudoers (https://serverfault.com/questions/480136/how-do-i-set-both-nopasswd-and-setenv-on-the-same-line-in-sudoers)
Edit:
Komische Zeichen (wie z.B. Zeilenumbrücke Windows), siehst Du im Editor nicht. Würde hier auch vorsichtig mit copy&paste sein ...
Wegen des Linux Dateisystems kann ich Windows- und macOS-basierte Systeme für das Vorhaben vergessen, oder?
Da ich davon ausgehe, das Dein Windows/MacOS kein ext3 lesen kann *) ... ja ....
Fallst Du eine 2. SD-Card hast, kannst Du auch dort ein reines "Life" System installieren, booten und mit einem CardReader ....
*) Es soll mitlerweile für Windows einen ext3 Treiber geben. Ob es stimmt und er funzt ?????
MacOS kenne ich zuwenig, aber so wie ich Apple einschätze ..... nein
ob mac geht weiß ich nicht, Du kannst aber irgendein linux live System nehmen (USB Stick), das funktioniert sogar an deinem Raspberry.
Ganz simpel für den Laien wäre:
SD Card raus und in den Reader. Reader an den raspberry stecken
andere SD Card mit Raspberry OS Lite bestücken und booten
SD Card Reader mounten ;)
Edit: war ich etwas langsam ;)
Zitat von: Wernieman am 10 Oktober 2022, 12:59:41
SETENV giebt es bei sudoers ...
https://serverfault.com/questions/480136/how-do-i-set-both-nopasswd-and-setenv-on-the-same-line-in-sudoers (https://serverfault.com/questions/480136/how-do-i-set-both-nopasswd-and-setenv-on-the-same-line-in-sudoers)
Danke für den Lesehinweis :)
Gibt aber besser .. war der erste Fund von Google
Feedback:
Das Löschen der besagten Datei mithilfe der gemounteten SD-Karte in einem Cardreader auf einem anderen Raspberry Pi System war unkompliziert und erfolgreich. Puh.... darauf gleich erstmal ein Bier und am Wochenende ein Backup, bevor ich wieder was rumprobiere.
Eigentlich hatte ich gehofft, mithilfe des FHEMInstaller Moduls auf einfachere Art & Weise Linux-Pakete installieren zu können usw.
Wenn ich nur wüsste, was schief gelaufen ist...
Ein get fheminstaller checkPrereqs ergibt - siehe Anhang -
Zu updaten wäre entsprechend genug, was ich auch gern befolgen würde.
Ich verwende das Installermodul nur um zu ermitteln was dem System so fehlt. Siehe mein Artikel (https://heinz-otto.blogspot.com/2022/08/howto-fhem-umzug-von-system-nach-system.html).
Ein latentes Problem: der Maintainer des Moduls ist derzeit nicht aktiv.
Update im System mach ich regelmäßig mit dem package manager apt ... Ich selbst installiere ungern mit CPAN (also Perlmodule)
Ich schau mal ob ich finde, was das Installermodul wirklich an sudo Rechten brauchen würde.
Und gerade, wenn man nicht Linux-afin ist, sollte man anstatt CPAN apt nehmen. Leider mögen vor allem Entwickler CPAN (u.Ä.) um den "neuen Scheiß" zu haben. Beim nächsten Komplettupdate macht aber gerade das dann Probleme.
(Sorry, kenne ich von meiner letzten Firma genügend ;o) )
Noch eine Frage:
Seit diesem Problem hier vor einigen Tagen, was nun augenscheinlich gelöst wurde, beobachte ich täglich 2-3 Zeiträume mit diversen Logeinträge über jeweils etwa 15-20 Minuten vieler Module, die timeouts und Verbindungsprobleme melden. Es wirkt, als sei der FHEM-Server auf dem Raspberry Pi vorübergehend vom Netzwerk abgeschnitten.
Das Dingen hängt per LAN Kabel im Unifi-Netz, was keinerlei Auffälligkeiten meldet und keine kürzlichen Updates oder änderungen erhielt. Lediglich der zeitliche Zusammenhang zu dieser Problematik fällt mir auf.
Möglicherweise habt Ihr eine Idee...
---------------------------------------
Davon ab sind bei mir einige Baustellen, wie es scheint, siehe Anhang.
Ich würde dann als unerfahrener Linuxianer per Terminal via
sudo apt-get updateneue Packetinfos einlesen und anschliessend per
sudo apt-get install ...neue Pakete installieren, nur scheitere ich aktuell daran die Paketbezeichnungen zu ermitteln für notwendige Pakete laut Screenshot.
Am Beispiel
Cache::Cache leite der Link aus FHEM hierher: https://metacpan.org/pod/Cache::Cache und dort unter "Install Instructions" erscheint
Zitat
To install Cache::Cache, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Cache::Cache
CPAN shell
perl -MCPAN -e shell
install Cache::Cache
Manches findet sich via Google, aber bin unsicher ob es exakt das Paket ist, was gefordert wird. z.B.
sudo apt install libsocket6-perlsudo apt-get install libdatetime-format-strptime-perl
Ein Großér Nachteil des Modules ist, das es eben auf CPAN und nicht auf die Packet-Quellen der Distri verweist. Irgendwo hatte Otto mal gepostet, wie man einfach ermitteln kann, welche Distri-Pakete welchen CPAN-Module entspricht.
Hast Du schon mal Module per CPAN nachinstalliert?
Nein noch nie
Zitat von: Wernieman am 12 Oktober 2022, 08:25:18
Irgendwo hatte Otto mal gepostet, wie man einfach ermitteln kann, welche Distri-Pakete welchen CPAN-Module entspricht.
https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html
Bzw. auch mit dem Installermodul ;)
https://heinz-otto.blogspot.com/2022/08/howto-fhem-umzug-von-system-nach-system.html
Zitat von: Dracolein am 12 Oktober 2022, 07:32:29
beobachte ich täglich 2-3 Zeiträume mit diversen Logeinträge über jeweils etwa 15-20 Minuten vieler Module, die timeouts und Verbindungsprobleme melden. Es wirkt, als sei der FHEM-Server auf dem Raspberry Pi vorübergehend vom Netzwerk abgeschnitten.
Oder hast Du dabei etwas eingebaut, was FHEM blockiert?
Der gesamte Sachverhalt steht hier im Thread. Ich war einmal zufällig vor Ort, FHEM war nicht blockiert. ZigBee Devices liessen sich steuern (USB Controller am Raspi), alles netzwerkbasierte Zeugs nicht.
Ich habe nun mein gesamtes raspian OS via update / upgrade aktualisiert, habe alle fehlenden Pakete händisch via Terminal (& Google-Suche) installiert, alles neugestartet und werde nun beobachten.
Der FHEMInstaller bemängelt nur noch ein Paket namens Perl::PrereqScanner::NotQuiteLite "used by Installer" sollte ergo egal sein hopefully.
ZitatSeit diesem Problem hier vor einigen Tagen, was nun augenscheinlich gelöst wurde, beobachte ich täglich 2-3 Zeiträume mit diversen Logeinträge über jeweils etwa 15-20 Minuten vieler Module, die timeouts und Verbindungsprobleme melden. Es wirkt, als sei der FHEM-Server auf dem Raspberry Pi vorübergehend vom Netzwerk abgeschnitten.
Das Dingen hängt per LAN Kabel im Unifi-Netz, was keinerlei Auffälligkeiten meldet und keine kürzlichen Updates oder änderungen erhielt. Lediglich der zeitliche Zusammenhang zu dieser Problematik fällt mir auf.
Möglicherweise habt Ihr eine Idee...
bedeutet unifi-netz wlan?
also von fhem zu den gestörten netzwerkteilnehmern ist eine wlan-strecke wirksam?
ja sowohl als auch. diverse Funksteckdosen sind im WLAN aber auch diverse Devices wie UWZ / DWD, also was eine Internetverbindung braucht, meldeten Fehler. Der Raspi hängt komplett per Kabels über div. Switches am Router.
Echte Netzwerkprobleme schließe ich eigentlich aus, das wäre seit > 1 Jahr das erste Mal sonst. Vielleicht war es tatsächlich eine abweichende Art von lokalem Freeze oder einer Blockierung. Werde beobachten .
Hier mal ein Beispiel, gerade ist es wieder passiert:
Server zuletzt neugestartet, die letzten Logeinträge nach dem Start wo alles i.O. war:
2022.10.12 10:48:51 1: usb create end
2022.10.12 10:48:51 0: Featurelevel: 6.1
2022.10.12 10:48:51 0: Server started with 196 defined entities (fhem.pl:26379/2022-09-03 perl:5.028001 os:linux user:fhem pid:1683)
und dann gings weiter mit sowas bis um 15:57 Uhr:
2022.10.12 15:10:43 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
(23) Failed writing body
2022.10.12 15:19:09 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:19:09 1: SMAInverter SMATripower6 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:19:10 1: SMAInverter SMATripower5 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:19:10 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
2022.10.12 15:19:15 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:19:21 1: SMAInverter SMATripower5 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:19:21 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
2022.10.12 15:26:33 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:26:35 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:26:40 1: [Shelly_status] device ShellyPlug5 has error read from http://192.168.178.106:80 timed out
2022.10.12 15:27:44 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:27:44 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:28:57 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:28:59 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:30:09 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:30:09 3: SMAEM HomeManager - WARNING - old process 6503 has been killed to start a new BlockingCall
2022.10.12 15:30:16 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
2022.10.12 15:30:19 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:30:28 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
2022.10.12 15:31:24 1: SMAInverter SMATripower5 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:31:24 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
2022.10.12 15:31:24 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:31:25 3: SMAEM HomeManager - WARNING - old process 6607 has been killed to start a new BlockingCall
2022.10.12 15:31:25 2: SVSaufDS - error while requesting http://192.168.178.10:5000/webapi/entry.cgi?api="SYNO.SurveillanceStation.HomeMode"&version="1"&method=GetInfo&_sid="KyoKa1CLNJPkk7N3gQJgt6bxlpBNhw2jBwrc6IeWcZg6321nxjuL7izkLifohA-IeGr5U6mWVmy_7uVk7OnIcU" - http://192.168.178.10:5000/webapi/entry.cgi?api="SYNO.SurveillanceStation.HomeMode"&version="1"&method=GetInfo&_sid="KyoKa1CLNJPkk7N3gQJgt6bxlpBNhw2jBwrc6IeWcZg6321nxjuL7izkLifohA-IeGr5U6mWVmy_7uVk7OnIcU": empty answer received
2022.10.12 15:31:28 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:32:37 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:32:37 1: SMAInverter SMATripower6 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:32:39 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:34:11 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:34:11 1: SMAInverter SMATripower6 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:35:01 3: SMAEM HomeManager - WARNING - old process 6928 has been killed to start a new BlockingCall
2022.10.12 15:35:01 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:35:04 1: SMAInverter SMATripower5 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:35:05 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
2022.10.12 15:35:05 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
2022.10.12 15:35:15 1: SMAInverter SMATripower6 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:35:15 1: SMAInverter SMATripower5 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2022.10.12 15:38:29 1: [Shelly_status] device ShellyPlug2 has error read from http://192.168.178.98:80 timed out
2022.10.12 15:38:30 1: [Shelly_status] device ShellyPlug5 has error read from http://192.168.178.106:80 timed out
2022.10.12 15:38:33 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
2022.10.12 15:39:36 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:39:41 1: 192.168.178.10:1883 reappeared (TeslaMate)
2022.10.12 15:39:59 1: SMAEVCgarger EVCharger22 -> BlockingCall SMAEVCharger_Run Timeout: process terminated
(23) Failed writing body
2022.10.12 15:40:49 3: SMAEM HomeManager - WARNING - old process 7570 has been killed to start a new BlockingCall
2022.10.12 15:40:53 1: 192.168.178.10:1883 disconnected, waiting to reappear (TeslaMate)
2022.10.12 15:40:59 1: [Shelly_status] device ShellyPlug6 has error read from http://192.168.178.107:80 timed out
2022.10.12 15:40:59 1: [Shelly_status] device ShellyPlug3 has error read from http://192.168.178.99:80 timed out
2022.10.12 15:40:59 1: [Shelly_status] device ShellyPlug1 has error read from http://192.168.178.97:80 timed out
2022.10.12 15:41:00 1: [Shelly_status] device ShellyPlug4 has error read from http://192.168.178.105:80 timed out
2022.10.12 15:41:00 1: [Shelly_status] device ShellyPlug2 has error read from http://192.168.178.98:80 timed out
2022.10.12 15:41:01 1: 192.168.178.10:1883 reappeared (TeslaMate)
Das sind alles Devices, die IP-basierte Geräte kontaktieren (Wechselrichter, Wallbox, Shelly Steckdosen....)
Hat zwar (verm.) nichts mit dem Problem zu tun aber das hier:
Zitat
2022.10.12 10:48:51 1: usb create end
klingt als wäre initialUsbCheck aktiv, kann (sollte) man deaktivieren...
Bist du sicher, dass im Netzwerk alles i.O. ist?
attr global dnsServer gesetzt?
Und: du hast ein Desktop-System, oder? Wie hast du das NW konfiguriert? Nicht dass sich der NW-Manager (der mit Desktop kommt) und irgendwelche Einstellungen aus "Wikis" oder "PI-Foren" gegenseitig "beißen"?
Gruß, Joachim
Zitat von: Dracolein am 12 Oktober 2022, 11:02:56
Ich habe nun mein gesamtes raspian OS via update / upgrade aktualisiert, habe alle fehlenden Pakete händisch via Terminal (& Google-Suche) installiert, alles neugestartet und werde nun beobachten.
Der FHEMInstaller bemängelt nur noch ein Paket namens Perl::PrereqScanner::NotQuiteLite "used by Installer" sollte ergo egal sein hopefully.
apt install libperl-prereqscanner-notquitelite-perlMein Artikel hat Dir bei der Suche nicht geholfen oder bist Du damit nicht klar gekommen?
Hast Du mal freezemon probiert?
docvh hat geholfen, mitunter konnte ich auch somit alle fehlenden Pakete finden und istallieren.
freezemon ist jetzt aktiv, mal sehen.
Abschliessendes Feedback unbd kurios zugleich:
Die 2-3x täglichen angedeuteten Verbindungsprobleme scheinen verschwunden zu sein. Seit dem 12.10 18:00 Uhr ist im Log nichts problematisches mehr aufgetreten.
Weiß der Geier was es war bzw. warum es nun gelöst ist. Meine einzige Änderung war der Install von FreezeMon gefolgt vom Disable des fhemInstallers sowie einige auskommentierte Codezeilen meiner FTUI3 Nutzeroberfläche.