NEWS
[HowTo] USV: NUT Server auf SBC installieren
-
In der Konsole mache ich es mit sudo.
In der Datei habe ich es ohne angegeben, da in jeder Anleitung (Auch auf der seine von Rasparry) steht, dass Befehle aus dieser Datei immer als root mit sudo ausgeführt werden.Werde es aber mal testen.
@David-G sagte in [HowTo] USV: NUT Server auf SBC installieren:
als root mit sudo
Das möchte ich sehen. Das ist nämlich Oberquark.
-
@David-G Bei meinem OPi steht es auch ohne sudo. Und das hat auch funktioniert. Ohne nicht, damit schon. So steht es zumindest in meinen Notizen. Das Ding hat aber eine uptime von 492 Tagen und macht nur den NUT-Server.
Aber es muß ja einen Grund haben, daß es in der Console geht und im rc.local nicht. Und die Linuxrechteverwaltung ist immer einen Versuch wert.Wie muss ich vorgenenhen bei der Rechteverwaltung? Bin wie gesagt was Linux angeht ein ziemlicher Dau.
@Thomas-Braun
Unter raspberrypi.org/documentation findet man folgende Passage:One more point to note is that all commands will be executed by the root user. This can lead to unexpected behaviour: for example, if a folder is created by a mkdir command in the script, the folder would have root ownership and would not be accessible by anyone other than the root user.Was ich auch interessant fand ist folgendes, jedoch ist es bisher ja bei niemandem nötig gewesen (und bezieht sich auf Dateien):
Also, be sure to reference absolute filenames rather than relative to your home folder; for example, /home/pi/myscript.py rather than myscript.py.EDIT:
Der sudo hat nichts gebracht.Evtl. muss die ganze Geschichte was verzögert ausgeführt werden. Kann das sein? Wobei ich auch da kp hab wie ich das mache oder wonach ich suchen muss.
EDIT 2:
Ich habe eben übersudo sh /etc/rc.localdie rc.local nochmal verzögert manuell gestartet (als mir der Telegram Adapter eine Nachricht gesendet hat, dass er geladen ist).
Alles wurde korrekt gestartet.
Muss also irgendwie einen verzögerten Start hinbekommen. -
Wie muss ich vorgenenhen bei der Rechteverwaltung? Bin wie gesagt was Linux angeht ein ziemlicher Dau.
@Thomas-Braun
Unter raspberrypi.org/documentation findet man folgende Passage:One more point to note is that all commands will be executed by the root user. This can lead to unexpected behaviour: for example, if a folder is created by a mkdir command in the script, the folder would have root ownership and would not be accessible by anyone other than the root user.Was ich auch interessant fand ist folgendes, jedoch ist es bisher ja bei niemandem nötig gewesen (und bezieht sich auf Dateien):
Also, be sure to reference absolute filenames rather than relative to your home folder; for example, /home/pi/myscript.py rather than myscript.py.EDIT:
Der sudo hat nichts gebracht.Evtl. muss die ganze Geschichte was verzögert ausgeführt werden. Kann das sein? Wobei ich auch da kp hab wie ich das mache oder wonach ich suchen muss.
EDIT 2:
Ich habe eben übersudo sh /etc/rc.localdie rc.local nochmal verzögert manuell gestartet (als mir der Telegram Adapter eine Nachricht gesendet hat, dass er geladen ist).
Alles wurde korrekt gestartet.
Muss also irgendwie einen verzögerten Start hinbekommen.@David-G
Auf 'modernen' Linux-Systemen nutzt man systemd um daemons zu starten.
Das ist halt in der Konfig etwas biestig, dafür kann man es viel feiner einstellen.Nicht umsonst steht in der oben verlinkten Dokumentation nämlich:
NOTE: on Jessie, Stretch and Buster (which use systemd), rc.local has drawbacks: not all programs will run reliably, because not all services may be available when rc.local runs.
Richtig ist: Über rc.local angestoßene Dinge laufen im root-Kontext ab.
Das ist aber was anderes als 'als root mit sudo'Über systemd kann man den upsd wohl danach starten:
-
@David-G
Auf 'modernen' Linux-Systemen nutzt man systemd um daemons zu starten.
Das ist halt in der Konfig etwas biestig, dafür kann man es viel feiner einstellen.Nicht umsonst steht in der oben verlinkten Dokumentation nämlich:
NOTE: on Jessie, Stretch and Buster (which use systemd), rc.local has drawbacks: not all programs will run reliably, because not all services may be available when rc.local runs.
Richtig ist: Über rc.local angestoßene Dinge laufen im root-Kontext ab.
Das ist aber was anderes als 'als root mit sudo'Über systemd kann man den upsd wohl danach starten:
Was ist das kompliziert.
Wenn man keine Ahnung hat und dann sowas kommt.Aber vielen Dank für eure Hilfe.
Überschreibt die systemd Variante meine aktuelle Konfiguration? In den Files auf git sind ja auch sämtliche Dateien enthalten welche ich bei der Installation manuell angepasst habe.
Evtl wird ja irgendwann die Anleitung oben in Post 1 angepasst.
-
Was ist das kompliziert.
Wenn man keine Ahnung hat und dann sowas kommt.Aber vielen Dank für eure Hilfe.
Überschreibt die systemd Variante meine aktuelle Konfiguration? In den Files auf git sind ja auch sämtliche Dateien enthalten welche ich bei der Installation manuell angepasst habe.
Evtl wird ja irgendwann die Anleitung oben in Post 1 angepasst.
@David-G sagte in [HowTo] USV: NUT Server auf SBC installieren:
Evtl wird ja irgendwann die Anleitung oben in Post 1 angepasst.
Vermutlich nicht. @klassisch hat es ja nicht so mit Linux.
-
@David-G sagte in [HowTo] USV: NUT Server auf SBC installieren:
Evtl wird ja irgendwann die Anleitung oben in Post 1 angepasst.
Vermutlich nicht. @klassisch hat es ja nicht so mit Linux.
@Thomas-Braun sagte in [HowTo] USV: NUT Server auf SBC installieren:
@klassisch hat es ja nicht so mit Linux.
Da hast Du leider recht. Und z.B. dieser Thread bestätigt mich leider wieder. Die Restart-Persistenz habe ich bei meinem OPi unter stretch getestet und entsprechend dokumentiert. Kaum 500 Tage später geht das bei einem (anderen?) Linux-System nicht (mehr). Schade für alle und für mich nicht so einfach nachzuvollziehen.
Es ist ja nicht so, daß ich Linux verdamme oder ein Linux-Hasser wäre, aber ich gehe halt den Weg des (für mich) geringsten Widerstands bei ausreichender Systemstabilität. Und ich würdige stets die Verdienste von Linux durch den Wettbewerbsdruck zur Verbesserung von Windows beigetragen zu haben und auch weiter beizutragen. Dazu muß Linux halt auch die entsprechenden Qualitäten erreichen und halten. Und da müssen bei den SBC-Varianten sicherlich nlotgedrungen Abstriche gemacht werden.
Ich möchte meine Tendenz vielleicht noch weiter abstrahieren: Ich war und bin von headless Systemen prinzipiell fasziniert. Aber ich will aus Wartungsgründen nur noch ausgewachsene System mit einem vollen Köcher an graphisch zugänglichen Analysetools nutzen. Und da ich auch anderweitig mit Windows arbeite, bietet sich das für mich an.Vermutlich nicht.
Das ist aber ein anderes Thema. Selbstverständlich bin ich daran interessiert, funktionierende Anleitungen zu veröffentlichen und aktuell zu halten.
Aber zur Korrektur bzw. Erweiterung brauche ich in diesem Fall Eure Hilfe weil bei mir alles so wie beschrieben funktioniert. Deshalb wäre es super, wenn Ihr beschreiben könntet- Ab welchem Linux meine Persistenz-Anleitung nicht mehr geht ndwie man das erkennen kann
- Was man tun muß, damit die Persistenz wieder sichergestellt ist
- Und als bonus vielleicht noch warum das jetzt anders gehen muß
Dann kann ich
- im ersten Post auf Eure Erklärung verlinken
- oder Eure Erklärung gleich in den ersten Post mit aufnehmen. Mit Credits selbstverständlich
Da richte ich mich selbstverständlich nach Euren Vorschlägen.
-
@Thomas-Braun sagte in [HowTo] USV: NUT Server auf SBC installieren:
@klassisch hat es ja nicht so mit Linux.
Da hast Du leider recht. Und z.B. dieser Thread bestätigt mich leider wieder. Die Restart-Persistenz habe ich bei meinem OPi unter stretch getestet und entsprechend dokumentiert. Kaum 500 Tage später geht das bei einem (anderen?) Linux-System nicht (mehr). Schade für alle und für mich nicht so einfach nachzuvollziehen.
Es ist ja nicht so, daß ich Linux verdamme oder ein Linux-Hasser wäre, aber ich gehe halt den Weg des (für mich) geringsten Widerstands bei ausreichender Systemstabilität. Und ich würdige stets die Verdienste von Linux durch den Wettbewerbsdruck zur Verbesserung von Windows beigetragen zu haben und auch weiter beizutragen. Dazu muß Linux halt auch die entsprechenden Qualitäten erreichen und halten. Und da müssen bei den SBC-Varianten sicherlich nlotgedrungen Abstriche gemacht werden.
Ich möchte meine Tendenz vielleicht noch weiter abstrahieren: Ich war und bin von headless Systemen prinzipiell fasziniert. Aber ich will aus Wartungsgründen nur noch ausgewachsene System mit einem vollen Köcher an graphisch zugänglichen Analysetools nutzen. Und da ich auch anderweitig mit Windows arbeite, bietet sich das für mich an.Vermutlich nicht.
Das ist aber ein anderes Thema. Selbstverständlich bin ich daran interessiert, funktionierende Anleitungen zu veröffentlichen und aktuell zu halten.
Aber zur Korrektur bzw. Erweiterung brauche ich in diesem Fall Eure Hilfe weil bei mir alles so wie beschrieben funktioniert. Deshalb wäre es super, wenn Ihr beschreiben könntet- Ab welchem Linux meine Persistenz-Anleitung nicht mehr geht ndwie man das erkennen kann
- Was man tun muß, damit die Persistenz wieder sichergestellt ist
- Und als bonus vielleicht noch warum das jetzt anders gehen muß
Dann kann ich
- im ersten Post auf Eure Erklärung verlinken
- oder Eure Erklärung gleich in den ersten Post mit aufnehmen. Mit Credits selbstverständlich
Da richte ich mich selbstverständlich nach Euren Vorschlägen.
Gerne würde ich es mit Hilfe probieren.
Ich nutze Raspbian buster auf einen Rasparry 4B.Werde im Testzeitraum wohl keinen Stromausfall haben. Wobei, man weiß nie......
Ich hätte schon ein Problem die Sachen von git zu installieren ^^.
Zu Linux:
Ich mag es mehr und mehr.
Für die meisten Dinge findet man ja Anleitungen und Hilfe online.
Auch wenn ich grafische Oberflächen bevorzuge.
Viel ist aber eben headless.
Ist eben alles Geschmackssache. Ich zB hasse MacOS 😅. -
@Thomas-Braun sagte in [HowTo] USV: NUT Server auf SBC installieren:
@klassisch hat es ja nicht so mit Linux.
Da hast Du leider recht. Und z.B. dieser Thread bestätigt mich leider wieder. Die Restart-Persistenz habe ich bei meinem OPi unter stretch getestet und entsprechend dokumentiert. Kaum 500 Tage später geht das bei einem (anderen?) Linux-System nicht (mehr). Schade für alle und für mich nicht so einfach nachzuvollziehen.
Es ist ja nicht so, daß ich Linux verdamme oder ein Linux-Hasser wäre, aber ich gehe halt den Weg des (für mich) geringsten Widerstands bei ausreichender Systemstabilität. Und ich würdige stets die Verdienste von Linux durch den Wettbewerbsdruck zur Verbesserung von Windows beigetragen zu haben und auch weiter beizutragen. Dazu muß Linux halt auch die entsprechenden Qualitäten erreichen und halten. Und da müssen bei den SBC-Varianten sicherlich nlotgedrungen Abstriche gemacht werden.
Ich möchte meine Tendenz vielleicht noch weiter abstrahieren: Ich war und bin von headless Systemen prinzipiell fasziniert. Aber ich will aus Wartungsgründen nur noch ausgewachsene System mit einem vollen Köcher an graphisch zugänglichen Analysetools nutzen. Und da ich auch anderweitig mit Windows arbeite, bietet sich das für mich an.Vermutlich nicht.
Das ist aber ein anderes Thema. Selbstverständlich bin ich daran interessiert, funktionierende Anleitungen zu veröffentlichen und aktuell zu halten.
Aber zur Korrektur bzw. Erweiterung brauche ich in diesem Fall Eure Hilfe weil bei mir alles so wie beschrieben funktioniert. Deshalb wäre es super, wenn Ihr beschreiben könntet- Ab welchem Linux meine Persistenz-Anleitung nicht mehr geht ndwie man das erkennen kann
- Was man tun muß, damit die Persistenz wieder sichergestellt ist
- Und als bonus vielleicht noch warum das jetzt anders gehen muß
Dann kann ich
- im ersten Post auf Eure Erklärung verlinken
- oder Eure Erklärung gleich in den ersten Post mit aufnehmen. Mit Credits selbstverständlich
Da richte ich mich selbstverständlich nach Euren Vorschlägen.
@klassisch sagte in [HowTo] USV: NUT Server auf SBC installieren:
Dazu muß Linux halt auch die entsprechenden Qualitäten erreichen und halten.
Die Wahrnehmung ist aber eine verzerrte. Linux hat mit ganz großer Sicherheit im Bereich 'Server' und dem ganzen Drumherum eine hervorragende Qualität erreicht. Nicht ohne Grund läuft die überwiegende Zahl von Serversystemen auf Linux. Also die Qualitätsanforderungen von 'Profis' erfüllt ein Linux-Server ganz bestimmt.
Für Hobby-Admins sind die Ansprüche aber ganz andere. Und das beißt sich an der Stelle. Ein Linux-Server hat und braucht keine 'Klick-hier-und-klick-da'-Oberfläche, der Hobby-Heim-Admin meint aber oft, das er eine bräuchte.Andersherum sieht das halt im Bereich 'Desktop'-System aus. Da würde ich auch sagen, das es da im Bereich macOS oder Windows besser aussieht. Das sind aber keine Kriterien für den Betrieb als Server.
Zurück zum Thema: Auch im Juli 2019 war ein Start über initd (mit rc-Files) schon nicht mehr der Stand der Technik (auf den meisten Distributionen jedenfalls nicht mehr, Debian eingeschlossen).
Da ich keine USV betreibe brauche ich auch keinen nut-Server, da kann ich also nicht mit Praxis-Wissen weiterhelfen.
Hier aber ein Blog-Eintrag (aus dem Jahre 2013), der sich da mit systemd beschäftigte:
https://www.kepstin.ca/blog/networkupstoolsnutandsystemd/
7 Jahre später dürfte das aber auch im Detail nicht mehr aktuell sein, aber die Grundrichtung ist da.Die offizielle Dokumentation dürfte auch weiterhelfen:
https://networkupstools.org/docs/user-manual.chunked/ar01s05.htmlDa ist auch explizit von systemd die Rede und wie darüber gesteuert wird, dass der service erst nach der Verfügbarkeit von USB gestartet wird.
Bemerkenswert dann aber auch der letzte Satz der Anleitung:
The unfortunate part is that a lot of this work is fairly system-specific. I’m not sure that it is all suitable for use in the upstream nut package, due to the customization required. I’d appreciate any comments or thoughts.
-
@klassisch sagte in [HowTo] USV: NUT Server auf SBC installieren:
Dazu muß Linux halt auch die entsprechenden Qualitäten erreichen und halten.
Die Wahrnehmung ist aber eine verzerrte. Linux hat mit ganz großer Sicherheit im Bereich 'Server' und dem ganzen Drumherum eine hervorragende Qualität erreicht. Nicht ohne Grund läuft die überwiegende Zahl von Serversystemen auf Linux. Also die Qualitätsanforderungen von 'Profis' erfüllt ein Linux-Server ganz bestimmt.
Für Hobby-Admins sind die Ansprüche aber ganz andere. Und das beißt sich an der Stelle. Ein Linux-Server hat und braucht keine 'Klick-hier-und-klick-da'-Oberfläche, der Hobby-Heim-Admin meint aber oft, das er eine bräuchte.Andersherum sieht das halt im Bereich 'Desktop'-System aus. Da würde ich auch sagen, das es da im Bereich macOS oder Windows besser aussieht. Das sind aber keine Kriterien für den Betrieb als Server.
Zurück zum Thema: Auch im Juli 2019 war ein Start über initd (mit rc-Files) schon nicht mehr der Stand der Technik (auf den meisten Distributionen jedenfalls nicht mehr, Debian eingeschlossen).
Da ich keine USV betreibe brauche ich auch keinen nut-Server, da kann ich also nicht mit Praxis-Wissen weiterhelfen.
Hier aber ein Blog-Eintrag (aus dem Jahre 2013), der sich da mit systemd beschäftigte:
https://www.kepstin.ca/blog/networkupstoolsnutandsystemd/
7 Jahre später dürfte das aber auch im Detail nicht mehr aktuell sein, aber die Grundrichtung ist da.Die offizielle Dokumentation dürfte auch weiterhelfen:
https://networkupstools.org/docs/user-manual.chunked/ar01s05.htmlDa ist auch explizit von systemd die Rede und wie darüber gesteuert wird, dass der service erst nach der Verfügbarkeit von USB gestartet wird.
Bemerkenswert dann aber auch der letzte Satz der Anleitung:
The unfortunate part is that a lot of this work is fairly system-specific. I’m not sure that it is all suitable for use in the upstream nut package, due to the customization required. I’d appreciate any comments or thoughts.
Mir würde es als workarround ja rechen, die beiden Befehle mit Blockly per exec ausführen zu können. Ohne die rc.local.
Da scheint es aber an den rechten zu scheitern. Klappt mit und ohne sudo nicht.
-
Mir würde es als workarround ja rechen, die beiden Befehle mit Blockly per exec ausführen zu können. Ohne die rc.local.
Da scheint es aber an den rechten zu scheitern. Klappt mit und ohne sudo nicht.
-
Mir würde es als workarround ja rechen, die beiden Befehle mit Blockly per exec ausführen zu können. Ohne die rc.local.
Da scheint es aber an den rechten zu scheitern. Klappt mit und ohne sudo nicht.
@Thomas-Braun sagte in [HowTo] USV: NUT Server auf SBC installieren:
Also die Qualitätsanforderungen von 'Profis' erfüllt ein Linux-Server ganz bestimmt.
Dazu kann ich nichts fundiertes sagen, weil ich kein Server-Profi bin - und höchstwahrscheinich keiner mehr werden kann. Face Reality.
Für Hobby-Admins sind die Ansprüche aber ganz andere. Und das beißt sich an der Stelle. Ein Linux-Server hat und braucht keine 'Klick-hier-und-klick-da'-Oberfläche, der Hobby-Heim-Admin meint aber oft, das er eine bräuchte.
Auch hier wieder Face Reality: Ein solcher Hobbyist bin ich. Deshalb besteht hier eine Diskrepanz zu den Profis, die auch immer größer werden wird. So ist das in einer hochspezialisierten Welt. Ähnlich wie die Diskussion über die Fritten. Netzwerkprofis nehmen die nicht. Aber Laien fahren nicht schlecht damit und wahrscheinlich besser als mit einem Profigerät überfordert zu sein.
Das sind aber keine Kriterien für den Betrieb als Server.
Auch hier könnte ich dem Anspruch einen professionellen Server effizient und effektiv zu betreiben sicher nicht gerecht werden. So gebe ich mich derzeit mit den eingeschränkten Möglichkeiten zufrieden, die mir die günstige Laptoplösung bietet. Gut ein paar SATA-Schnittstellen wären noch schön, damit ich meine underpowered Synology in Ruhestand schicken könnte.
Zurück zum Thema: Auch im Juli 2019 war ein Start über initd (mit rc-Files) schon nicht mehr der Stand der Technik (auf den meisten Distributionen jedenfalls nicht mehr, Debian eingeschlossen).
Mag sein, das war die erste Lösung, die ich gefunden habe und die funktioniert hat.
Da ich keine USV betreibe brauche ich auch keinen nut-Server, da kann ich also nicht mit Praxis-Wissen weiterhelfen.
Schade zu beidem. USV kann ich nur empfehlen.
Hier aber ein Blog-Eintrag (aus dem Jahre 2013), der sich da mit systemd beschäftigte:
Als Nicht-Linuxer schaue ich bei den Ubuntuusers nach, da mir die man-pages selten weiterhalfen. Nun, das systemd scheint nicht so schnell gemacht zu sein. Und dunkel erinnere ich mich an viele Überschriften, die vom Ringen um systemd und rc.local zeugten.
The unfortunate part is that a lot of this work is fairly system-specific. I’m not sure that it is all suitable for use in the upstream nut package, due to the customization required. I’d appreciate any comments or thoughts.
Da fehlt mir offen der Ehrgeiz in diese Richtung :-).
-
@Thomas-Braun sagte in [HowTo] USV: NUT Server auf SBC installieren:
Also die Qualitätsanforderungen von 'Profis' erfüllt ein Linux-Server ganz bestimmt.
Dazu kann ich nichts fundiertes sagen, weil ich kein Server-Profi bin - und höchstwahrscheinich keiner mehr werden kann. Face Reality.
Für Hobby-Admins sind die Ansprüche aber ganz andere. Und das beißt sich an der Stelle. Ein Linux-Server hat und braucht keine 'Klick-hier-und-klick-da'-Oberfläche, der Hobby-Heim-Admin meint aber oft, das er eine bräuchte.
Auch hier wieder Face Reality: Ein solcher Hobbyist bin ich. Deshalb besteht hier eine Diskrepanz zu den Profis, die auch immer größer werden wird. So ist das in einer hochspezialisierten Welt. Ähnlich wie die Diskussion über die Fritten. Netzwerkprofis nehmen die nicht. Aber Laien fahren nicht schlecht damit und wahrscheinlich besser als mit einem Profigerät überfordert zu sein.
Das sind aber keine Kriterien für den Betrieb als Server.
Auch hier könnte ich dem Anspruch einen professionellen Server effizient und effektiv zu betreiben sicher nicht gerecht werden. So gebe ich mich derzeit mit den eingeschränkten Möglichkeiten zufrieden, die mir die günstige Laptoplösung bietet. Gut ein paar SATA-Schnittstellen wären noch schön, damit ich meine underpowered Synology in Ruhestand schicken könnte.
Zurück zum Thema: Auch im Juli 2019 war ein Start über initd (mit rc-Files) schon nicht mehr der Stand der Technik (auf den meisten Distributionen jedenfalls nicht mehr, Debian eingeschlossen).
Mag sein, das war die erste Lösung, die ich gefunden habe und die funktioniert hat.
Da ich keine USV betreibe brauche ich auch keinen nut-Server, da kann ich also nicht mit Praxis-Wissen weiterhelfen.
Schade zu beidem. USV kann ich nur empfehlen.
Hier aber ein Blog-Eintrag (aus dem Jahre 2013), der sich da mit systemd beschäftigte:
Als Nicht-Linuxer schaue ich bei den Ubuntuusers nach, da mir die man-pages selten weiterhalfen. Nun, das systemd scheint nicht so schnell gemacht zu sein. Und dunkel erinnere ich mich an viele Überschriften, die vom Ringen um systemd und rc.local zeugten.
The unfortunate part is that a lot of this work is fairly system-specific. I’m not sure that it is all suitable for use in the upstream nut package, due to the customization required. I’d appreciate any comments or thoughts.
Da fehlt mir offen der Ehrgeiz in diese Richtung :-).
@klassisch sagte in [HowTo] USV: NUT Server auf SBC installieren:
Schade zu beidem. USV kann ich nur empfehlen.
Brauch ich nicht. Geht höchstens eine SD-Karte für ein paar Euro über die Wupper. Die sicher ich nicht über eine USV ab. Rechnet sich einfach nicht. Weder die Anschaffung noch der Betrieb.
-
Mir würde es als workarround ja rechen, die beiden Befehle mit Blockly per exec ausführen zu können. Ohne die rc.local.
Da scheint es aber an den rechten zu scheitern. Klappt mit und ohne sudo nicht.
@David-G sagte in [HowTo] USV: NUT Server auf SBC installieren:
Mir würde es als workarround ja rechen, die beiden Befehle mit Blockly per exec ausführen zu können. Ohne die rc.local.
Selbst auf die Gefahr hin, daß mich alle ausbuhen oder auslachen. Wenn sowas nicht in endlicher Zeit erfolgreich erledigt ist, gibt es bei mir eine Güterabwägung: Wie oft wird das noch vorkommen und wie viel Zeit kostet mich der händische Weg. Und dann werden die Befehle in die Notizdatei geschrieben, die die Installation begleitet und doumentiert hat. Und die paar mal, die es noch braucht eben manuell ausgeführt. Bei einigen Themen wie z.B. CCU-Neustart schicke ich mir automatisiert eine Mail mit ToDos zu, die dann halt schnell abgearbeitet werden. Nicht ganz so elegant, aber immerhin eine Lösung :-)
-
@David-G Was für Befehle?
Es geht um die um beiden Befehle aus der rc.local
upsdrvctl start upsdIn der Konsole muss ich sie immer noch mit sudo eintippen.
@Thomas-Braun
Da hast du recht. Habe ich bisher auch gemacht.
Finde für mich, wenn man ein Smart Home hat, dann sollte man es auch so smart machen wie man es schafft.Verstehe alle Argumente für und gegen eine USV.
Ich hab sie am laufen, damit bei Stromausfall noch die Alarmanlage funktioniert und das Internet aufrecht erhalten wird. Und noch, damit mein NAS Zeit zum runterfahren hat. Da geht ggf mehr als eine SD-Karte über die Wupper. -
Es geht um die um beiden Befehle aus der rc.local
upsdrvctl start upsdIn der Konsole muss ich sie immer noch mit sudo eintippen.
@Thomas-Braun
Da hast du recht. Habe ich bisher auch gemacht.
Finde für mich, wenn man ein Smart Home hat, dann sollte man es auch so smart machen wie man es schafft.Verstehe alle Argumente für und gegen eine USV.
Ich hab sie am laufen, damit bei Stromausfall noch die Alarmanlage funktioniert und das Internet aufrecht erhalten wird. Und noch, damit mein NAS Zeit zum runterfahren hat. Da geht ggf mehr als eine SD-Karte über die Wupper.@David-G
Gibt es die Datei bei dir?ls -ls /etc/systemd/system/nut-server.service -
@David-G
Gibt es die Datei bei dir?ls -ls /etc/systemd/system/nut-server.serviceScheinbar nicht.
pi@iobroker:~ $ ls -ls /etc/systemd/system/nut-server.service ls: Zugriff auf '/etc/systemd/system/nut-server.service' nicht möglich: Datei oder Verzeichnis nicht gefunden pi@iobroker:~ $Wenn ich die rc.local manuell ausführe, ist das der ausgegebene Bereich der beiden Befehle:
#additions for nut server sudo upsdrvctl start + sudo upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Megatec/Q1 protocol USB driver 0.12 (2.7.4)Supported UPS detected with megatec protocol Vendor information unavailable No values provided for battery high/low voltages in ups.conf Using 'guestimation' (low: 10.400000, high: 13.000000)! Battery runtime will not be calculated (runtimecal not set) sudo upsd + sudo upsd Network UPS Tools upsd 2.7.4 fopen /var/run/nut/upsd.pid: No such file or directory listening on 192.168.99.33 port 3493 listening on 127.0.0.1 port 3493 Connected to UPS [qnapups]: blazer_usb-qnapups #end additions for nut server -
Scheinbar nicht.
pi@iobroker:~ $ ls -ls /etc/systemd/system/nut-server.service ls: Zugriff auf '/etc/systemd/system/nut-server.service' nicht möglich: Datei oder Verzeichnis nicht gefunden pi@iobroker:~ $Wenn ich die rc.local manuell ausführe, ist das der ausgegebene Bereich der beiden Befehle:
#additions for nut server sudo upsdrvctl start + sudo upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Megatec/Q1 protocol USB driver 0.12 (2.7.4)Supported UPS detected with megatec protocol Vendor information unavailable No values provided for battery high/low voltages in ups.conf Using 'guestimation' (low: 10.400000, high: 13.000000)! Battery runtime will not be calculated (runtimecal not set) sudo upsd + sudo upsd Network UPS Tools upsd 2.7.4 fopen /var/run/nut/upsd.pid: No such file or directory listening on 192.168.99.33 port 3493 listening on 127.0.0.1 port 3493 Connected to UPS [qnapups]: blazer_usb-qnapups #end additions for nut server@David-G
Ich habe jetzt mal zum Spaß nut installiert.systemctl status nut-serverliefert bei dir?
-
@David-G
Ich habe jetzt mal zum Spaß nut installiert.systemctl status nut-serverliefert bei dir?
Danke für deinen Einsatz.
Last login: Thu Nov 5 18:48:48 2020 from 192.168.99.55 pi@iobroker:~ $ systemctl status nut-server ● nut-server.service - Network UPS Tools - power devices inform Loaded: loaded (/lib/systemd/system/nut-server.service; enab Active: failed (Result: exit-code) since Thu 2020-11-05 18:4 Process: 572 ExecStart=/sbin/upsd (code=exited, status=1/FAIL Nov 05 18:45:37 iobroker upsd[572]: not listening on 192.168.99Nov 05 18:45:37 iobroker upsd[572]: not listening on 192.168.99Nov 05 18:45:37 iobroker upsd[572]: listening on 127.0.0.1 portNov 05 18:45:37 iobroker upsd[572]: listening on 127.0.0.1 portNov 05 18:45:37 iobroker upsd[572]: no listening interface avaiNov 05 18:45:37 iobroker upsd[572]: no listening interface avaiNov 05 18:45:37 iobroker upsd[572]: Network UPS Tools upsd 2.7.Nov 05 18:45:37 iobroker systemd[1]: nut-server.service: ControNov 05 18:45:37 iobroker systemd[1]: nut-server.service: FailedNov 05 18:45:37 iobroker systemd[1]: Failed to start Network UPlines 1-15/15 (END)Der Code wird ja garnicht schon formatiert....
-
Danke für deinen Einsatz.
Last login: Thu Nov 5 18:48:48 2020 from 192.168.99.55 pi@iobroker:~ $ systemctl status nut-server ● nut-server.service - Network UPS Tools - power devices inform Loaded: loaded (/lib/systemd/system/nut-server.service; enab Active: failed (Result: exit-code) since Thu 2020-11-05 18:4 Process: 572 ExecStart=/sbin/upsd (code=exited, status=1/FAIL Nov 05 18:45:37 iobroker upsd[572]: not listening on 192.168.99Nov 05 18:45:37 iobroker upsd[572]: not listening on 192.168.99Nov 05 18:45:37 iobroker upsd[572]: listening on 127.0.0.1 portNov 05 18:45:37 iobroker upsd[572]: listening on 127.0.0.1 portNov 05 18:45:37 iobroker upsd[572]: no listening interface avaiNov 05 18:45:37 iobroker upsd[572]: no listening interface avaiNov 05 18:45:37 iobroker upsd[572]: Network UPS Tools upsd 2.7.Nov 05 18:45:37 iobroker systemd[1]: nut-server.service: ControNov 05 18:45:37 iobroker systemd[1]: nut-server.service: FailedNov 05 18:45:37 iobroker systemd[1]: Failed to start Network UPlines 1-15/15 (END)Der Code wird ja garnicht schon formatiert....
@David-G
Eigentlich ist doch alles soweit da.
Nimm mal den Kram aus rc.local raus.
Einfach ein # in die erste Spalte als Kommentarzeichen vor die beiden nicht benötigten upsd-Befehle setzen. -
Danke für deinen Einsatz.
Last login: Thu Nov 5 18:48:48 2020 from 192.168.99.55 pi@iobroker:~ $ systemctl status nut-server ● nut-server.service - Network UPS Tools - power devices inform Loaded: loaded (/lib/systemd/system/nut-server.service; enab Active: failed (Result: exit-code) since Thu 2020-11-05 18:4 Process: 572 ExecStart=/sbin/upsd (code=exited, status=1/FAIL Nov 05 18:45:37 iobroker upsd[572]: not listening on 192.168.99Nov 05 18:45:37 iobroker upsd[572]: not listening on 192.168.99Nov 05 18:45:37 iobroker upsd[572]: listening on 127.0.0.1 portNov 05 18:45:37 iobroker upsd[572]: listening on 127.0.0.1 portNov 05 18:45:37 iobroker upsd[572]: no listening interface avaiNov 05 18:45:37 iobroker upsd[572]: no listening interface avaiNov 05 18:45:37 iobroker upsd[572]: Network UPS Tools upsd 2.7.Nov 05 18:45:37 iobroker systemd[1]: nut-server.service: ControNov 05 18:45:37 iobroker systemd[1]: nut-server.service: FailedNov 05 18:45:37 iobroker systemd[1]: Failed to start Network UPlines 1-15/15 (END)Der Code wird ja garnicht schon formatiert....
@David-G
Wenn ich dem Installationsprotokoll bei mir trauen darf, dann wird das ganze systemd-Zeuch schon richtig eingerichtet:
pi@raspberrypi:/opt/iobroker $ sudo apt install nut Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Die folgenden zusätzlichen Pakete werden installiert: libupsclient4 nut-client nut-server Vorgeschlagene Pakete: nut-monitor nut-cgi nut-ipmi nut-snmp nut-xml Die folgenden NEUEN Pakete werden installiert: libupsclient4 nut nut-client nut-server 0 aktualisiert, 4 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. Es müssen 1.358 kB an Archiven heruntergeladen werden. Nach dieser Operation werden 4.902 kB Plattenplatz zusätzlich benutzt. Möchten Sie fortfahren? [J/n] j Holen:1 http://mirror.netcologne.de/raspbian/raspbian buster/main armhf libupsclient4 armhf 2.7.4-8 [180 kB] Holen:2 http://mirror.netcologne.de/raspbian/raspbian buster/main armhf nut-client armhf 2.7.4-8 [243 kB] Holen:3 http://mirror.netcologne.de/raspbian/raspbian buster/main armhf nut-server armhf 2.7.4-8 [690 kB] Holen:4 http://mirror.netcologne.de/raspbian/raspbian buster/main armhf nut all 2.7.4-8 [245 kB] Es wurden 1.358 kB in 1 s geholt (1.654 kB/s). Vormals nicht ausgewähltes Paket libupsclient4:armhf wird gewählt. (Lese Datenbank ... 85374 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../libupsclient4_2.7.4-8_armhf.deb ... Entpacken von libupsclient4:armhf (2.7.4-8) ... Vormals nicht ausgewähltes Paket nut-client wird gewählt. Vorbereitung zum Entpacken von .../nut-client_2.7.4-8_armhf.deb ... Entpacken von nut-client (2.7.4-8) ... Vormals nicht ausgewähltes Paket nut-server wird gewählt. Vorbereitung zum Entpacken von .../nut-server_2.7.4-8_armhf.deb ... Entpacken von nut-server (2.7.4-8) ... Vormals nicht ausgewähltes Paket nut wird gewählt. Vorbereitung zum Entpacken von .../archives/nut_2.7.4-8_all.deb ... Entpacken von nut (2.7.4-8) ... libupsclient4:armhf (2.7.4-8) wird eingerichtet ... nut-client (2.7.4-8) wird eingerichtet ... Created symlink /etc/systemd/system/multi-user.target.wants/nut-monitor.service → /lib/systemd/system/nut-monitor.service. Job for nut-monitor.service failed because the service did not take the steps required by its unit configuration. See "systemctl status nut-monitor.service" and "journalctl -xe" for details. invoke-rc.d: initscript nut-client, action "start" failed. ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled) Active: failed (Result: protocol) since Thu 2020-11-05 18:57:48 CET; 24ms ago Process: 19720 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS) Nov 05 18:57:48 raspberrypi systemd[1]: Starting Network UPS Tools - power device monitor and shutdown controller... Nov 05 18:57:48 raspberrypi upsmon[19720]: upsmon disabled, please adjust the configuration to your needs Nov 05 18:57:48 raspberrypi upsmon[19720]: Then set MODE to a suitable value in /etc/nut/nut.conf to enable it Nov 05 18:57:48 raspberrypi systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory Nov 05 18:57:48 raspberrypi systemd[1]: nut-monitor.service: Failed with result 'protocol'. Nov 05 18:57:48 raspberrypi systemd[1]: Failed to start Network UPS Tools - power device monitor and shutdown controller. nut-server (2.7.4-8) wird eingerichtet ... Created symlink /etc/systemd/system/multi-user.target.wants/nut-server.service → /lib/systemd/system/nut-server.service. nut-driver.service is a disabled or a static unit, not starting it. nut (2.7.4-8) wird eingerichtet ... Trigger für systemd (241-7~deb10u4+rpi1) werden verarbeitet ... Trigger für man-db (2.8.5-2) werden verarbeitet ... Trigger für libc-bin (2.28-10+rpi1) werden verarbeitet ...Insbesondere die Zeile
Created symlink /etc/systemd/system/multi-user.target.wants/nut-monitor.service → /lib/systemd/system/nut-monitor.service.sollte das korrekt machen. Ich vermute, bei dir beißt sich da jetzt was mit deinem start über initd. Nach Prof. Dr. Highlander gilt: Es kann nur einen geben.
649
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge