[HowTo] USV: NUT Server auf SBC installieren

[Homoran]

@qqolli sagte in [HowTo] USV: NUT Server auf SBC installieren:

geht nut.0.status.severity von idle(0) nach operating(0)

da gibt es doch auch den State "onBattery" der auf true geht wenn die USV anspringt.
den nutze ich

Wenn false dann "Netz"

[klassisch]

@Homoran klasse, vielen Dank! den gibt es bei mir auch und der arbeitet bei mir auch. Dann haben wir jetzt schon 3 Möglichkeiten

[qqolli]

@Homoran

Bingo, so ist es. Bei mir ändern sich die folgenden, mit rot markierten Status im falle eines Netzausfalls:

@klassisch

Wenn man noch den "UPS" --> "Status" --> von "OL CHRG" nach "OB DISCHRG" mitnimmt wären es 4 Möglichkeiten

[Homoran]

@qqolli Discharging habe ich ebenfalls mit als Monitor, während ich severity nicht benutze

[klassisch]

Zu severtiy findet sich in meinem Script

states of severity: 0:idle;1:operating;2:operating_critical;3:action_needed;4:unknown

Also da kann man noch etwas mehr Info rausholen (falls unterstützt).

[Homoran]

@klassisch sagte in [HowTo] USV: NUT Server auf SBC installieren:

Zu severtiy findet sich in meinem Script

states of severity: 0:idle;1:operating;2:operating_critical;3:action_needed;4:unknown

Also da kann man noch etwas mehr Info rausholen (falls unterstützt).

Ja!

Als Auslöser wollte ich nur boolsche DPs nehmen
Severity bietet eben weitergehende Informationen

[qqolli]

@Homoran @klassisch

Supi, dann haben wir doch alles was es für eine zuverlässige Aktion braucht im Falle eins Stromausfalls!

Echt, ich find das Forum einfach geil!

[klassisch]

sehe gerade, daß ich 2018 schon mal ein Skript eingestellt habe. Wobei das aktuelle wohl etwas anders aussieht

[David G.]

Hallo,

ich habe den Nut-Server jetzt längere Zeit erfolgreich am laufen.

Nur scheitere ich kläglich daran, dass der Server automatisch startet.

Im iobroker Log erscheint

error	(1615) Error happend: Error: connect ECONNREFUSED 192.168.99.33:3493

So sieht meine rc.local aus

GNU nano 3.2            /etc/rc.local                        
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runleve$# Make sure that the script will "exit 0" on success or any ot$# value on error.
#
# In order to enable or disable this script just change the ex$# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi
  GNU nano 3.2            /etc/rc.local                        

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"                        fi                                                             echo "test" > /usr/local/share/test.log
#additions  for nut server
upsdrvctl start
upsd
#end additions for nut server
exit 0

Beim Code kopieren am Handy zerschiest er teilweise die Zeileumbrüche.
Deshalb nochmal ein Bild:

Ausgeführt wird die remote.rc.
Das habe ich mit dem echo getestet.

Wenn ich die Befehle manuell in der Konsole eingebe, klappt im iobroker alles.

Habt ihr eine Idee?

[klassisch]

@David-G Vielleicht ein Rechte-Problem? sudo davor?

[David G.]

@klassisch

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.

[klassisch]

@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.

[Thomas Braun]

@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.]

@klassisch

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 über

sudo sh /etc/rc.local

die 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.

[Thomas Braun]

@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:

https://github.com/courtarro/nut-systemd

[David G.]

@Thomas-Braun

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.

[Thomas Braun]

@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.

[klassisch]

@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.

[David G.]

@klassisch

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]

@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.html

Da 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.