Schlagwort-Archive: Homeserver

Homeserver 37: Server als Videorecorder 2 – Die Grundeinstellungen

Nun ist das Grundgerüst installiert, aber in diesem Zustand ist das alles noch nicht viel wert. Das Aufnahmeverzeichnis muss noch konfiguriert werden, Kanäle müssen noch gesucht und sortiert werden und einiges weitere.

Das Antennenkabel habe ich zwar schon von Kabeldose bis zum Server gezogen, aber noch nicht angeschlossen. Schließlich muss die Dreambox noch Aufnahmen tätigen. Aber bis es soweit ist, ist auch noch viel zu tun.

Aber bevor ich an der Konfiguration Änderungen vornehme, muss VDR erst mal gestoppt werden, falls es bereits läuft.

sudo service vdr stop

Nun kann ich mich um die Konfiguration kümmern.

Aufnahmeverzeichnis festlegen

Auf meinem Server ist ordentlich Platz, also gibt es damit schon mal keine Probleme. Ich verbinde mich also per SSH mit meinem Server und gebe dort folgende Befehle ein:

sudo mkdir /raid1/daten/Videos/TV

Damit ist zwar das Verzeichnis auf dem RAID angelegt, aber es gehört Root. Also muss die Eigentümerschaft und die Gruppe dieses Verzeichnisses geändert werden.

VDR startet unter seinem eigenen Benutzer. Man könnte das sicher auch ändern, aber diese Verrenkungen mit den damit einhergehenden Fehlersuchen erspare ich mir. Also muss dieses Verzeichnis dem Benutzer „vdr“ gehören, damit Aufnahmen hier auch geschrieben werden können.

sudo chown vdr:vdr /raid1/daten/Videos/TV

Das Verzeichnis ist jetzt zwar angelegt, aber irgendwer muss dem VDR noch Bescheid sagen! Sonst würde er in seinem Standardverzeichnis, /var/lib/video, aufnehmen. Das wäre blöd, weil das Verzeichnis auf der System-SSD liegt, und da reicht der Platz für so was nicht… 🙂

Hierzu editiere ich die Datei /etc/vdr/conf.d/00-vdr.conf. Hier werden alle Standardwerte festgelegt, unter denen VDR startet, wenn man keine Befehlszeilenparameter angibt. Und da ich VDR eigentlich immer mit seinen Standardwerten starten lasse, ist diese Datei die richtige.

sudo nano /etc/vdr/conf.d/00-vdr.conf

Ich lasse alles so stehen, wie es da steht. Das ist schon alles ganz OK. Nur die eine Zeile ändere ich. Standardmäßig steht da:

--video=/var/lib/video

Das ändere ich zu:

--video=/raid1/daten/Videos/TV

So, zumindest weiß VDR jetzt schon mal, wo die Aufnahmen hingehören!

Netzzugriffe konfigurieren

Man kann den Netzzugriff für SVDRP beschränken. Das ist, und ich habe das sicher nicht völlig verstanden, eine Schnittstelle für diverse Plugins, um auch über das Netz kommunizieren zu können. Wie auch immer, es ist sicher sinnvoll, hier eine Beschränkung einzubauen.

sudo nano /etc/vdr/svdrphosts.conf

In dieser Datei stehen einige Beispiele, wie so ein Eintrag aussehen könnte. Diese sind alle auskommentiert, außer natürlich der für den localhost, und der sollte auch bleiben. Will man einen Zugriff erlauben, der nur aus dem eigenen Netz kommt, trägt man am besten folgende Zeile am Ende ein:

192.168.0.0/24

Somit würde VDR und die SVDRP-Dienste nur noch Zugriffe aus dem eigenen Netz erlauben. Dieser Wert sollte an die eigenen Gegebenheiten angepasst werden. Hat man z. B. eine Fritz!Box als Router, müsste der Wert also so aussehen:

192.168.178.0/24

Mittels der SVDRP-Schnittstelle kann man vieles per Kommandozeile erledigen. Als Beispiel:

svdrpsend scan

Dieser Befehl startet einen EPG-Scan über alle Kanäle. Weitere Möglichkeiten kann man auf der SVDRP-Seite des VDR-Wikis nachlesen.

EPG Aktualisierung

Der obige Befehl startet ja eine EPG-Aktualisierung. Dies ist aber in der Regel nicht nötig. VDR kann so eingestellt werden, dass es bei einer bestimmten Inaktivität selbst nach den Daten sucht. Ein Plugin, wie das EPGRefresh-Plugin für die Dreambox, ist also nicht nötig. Standardmäßig aktualisiert VDR die EPG-Daten, wenn der Tuner für 5 Stunden inaktiv war. Man kann diese Zeit einstellen, dazu aber später.

Zugriff auf den VDR per Telnet

Ja, Telnet, ich weiß, böse böse! 🙂 In diesem Falle sollte es aber verschmerzt werden. 🙂

Ich möchte, wie ich im vorigen Beitrag schon schrieb, an die OSD-Einstellungen des VDR ran. Ich könnte auch alles über die Konfigurationsdatei /etc/vdr/setup.conf einstellen, aber dazu müsste ich genau wissen, was welcher Eintrag tut. Aber zum Glück gibt es die Möglichkeit, über TCP und einer Telnet-Verbindung, das OSD zu nutzen. Wie gut das mit Screen Readern geht, weiß ich noch nicht, sehen wir ja gleich… 🙂

Ich hatte ja bereits diverse Plugins installiert, um dieses zu ermöglichen. Nun müssen diese konfiguriert werden. Um genau zu sein, muss das Remote-Plugin konfiguriert werden. Die Konfigurationsdatei hierfür muss editiert werden:

sudo nano /etc/vdr/conf.d/50-remote.conf

Hier gibt es die Sektion [remote], in der bereits eine Zeile zu finden ist:

[remote]
-i autodetect

Die Zeile -i autodetect muss gelöscht werden.

folgendes muss nun in die Datei eingefügt werden:

-p tcp:3333

Das sorgt dafür, dass auf dem Port 3333 auf die Tastatur und die Bedienung des VDR gelauscht wird. Diese Datei nun speichern und zur nächsten Datei übergehen.

Nun müssen die Tastendrücke angegeben werden, auf die der VDR reagieren soll. Hierzu muss die Datei remote.conf editiert werden.

sudo nano /etc/vdr/remote.conf

In diese Datei muss folgender Inhalt kopiert werden:

remote-tcp:3333.Up         0000000000415B1B
remote-tcp:3333.Down       0000000000425B1B
remote-tcp:3333.Menu       000000000000006D
remote-tcp:3333.Ok         0000000000000A0D
remote-tcp:3333.Back       000000000000007F
remote-tcp:3333.Left       0000000000445B1B
remote-tcp:3333.Right      0000000000435B1B
remote-tcp:3333.Red        0000000000000072
remote-tcp:3333.Green      0000000000000067
remote-tcp:3333.Yellow     0000000000000079
remote-tcp:3333.Blue       0000000000000062
remote-tcp:3333.0          0000000000000030
remote-tcp:3333.1          0000000000000031
remote-tcp:3333.2          0000000000000032
remote-tcp:3333.3          0000000000000033
remote-tcp:3333.4          0000000000000034
remote-tcp:3333.5          0000000000000035
remote-tcp:3333.6          0000000000000036
remote-tcp:3333.7          0000000000000037
remote-tcp:3333.8          0000000000000038
remote-tcp:3333.9          0000000000000039
remote-tcp:3333.Info       0000000000000069
remote-tcp:3333.Play       0000000000000070
remote-tcp:3333.Pause      0000000000000020
remote-tcp:3333.Stop       000000007E345B1B
remote-tcp:3333.Record     00000000415B5B1B
remote-tcp:3333.FastFwd    00000000425B5B1B
remote-tcp:3333.FastRew    00000000435B5B1B
remote-tcp:3333.Next       00000000445B5B1B
remote-tcp:3333.Prev       00000000455B5B1B
remote-tcp:3333.Power      000000000000001B
remote-tcp:3333.Channel+   000000007E355B1B
remote-tcp:3333.Channel-   000000007E365B1B
remote-tcp:3333.PrevChannel 000000007E315B1
remote-tcp:3333.Volume+    000000000000002B
remote-tcp:3333.Volume-    0000000000000023
remote-tcp:3333.Audio      0000000000000061
remote-tcp:3333.Schedule   0000000000000073
remote-tcp:3333.Channels   0000000000000063
remote-tcp:3333.Timers     0000000000000074
remote-tcp:3333.Recordings 0000000000000075
remote-tcp:3333.Setup      0000000000000065

Somit sind alle Keycodes, also alle Tastenzuordnungen, im VDR eingetragen. Nun heißt es, mit PUTTY eine Telnet-Verbindung aufzubauen. vorher muss VDR aber wieder gestartet werden:

sudo service vdr start

PUTTY starten

Um nicht den Windows-eigenen Telnet-Client nutzen zu müssen, greife ich auf PUTTY zurück. Früher habe ich ihn auch für SSH benutzt, bin aber schon länger davon abgekommen. Jedenfalls kann man es auch sehr gut für Telnet und andere Protokolle nutzen. Ich habe es in einem Verzeichnis liegen, wo auch noch andere Tools liegen, daher habe ich in der Systemvariable „PATH“ einen Eintrag zu diesem Verzeichnis gelegt.

Ich gehe mit der Windowstaste+R in den Ausführen-Dialog und gebe dort einfach putty ein. Nun öffnet sich der Verbindungsassistent von PUTTY, in dem wir noch ein paar Einstellungen machen müssen.

  • Host name (or IP adress): Hier gebe ich die IP des Servers ein.
  • Port: Hier gebe ich den VDR-Port ein, also 3333.
  • Protokoll: Hier ist SSH voreingestellt, ich wähle Telnet aus.

Anschließend drücke ich einige Male Tab, um in die Strukturansicht an der Seite zu kommen, wo derzeit „Sessions“ ausgewählt ist. Ich muss nämlich noch das Tastaturverhalten einstellen. Also gehe ich mit den Pfeiltasten runter bis „Terminal“, darunter zum Eintrag „Keyboard“, mit Tab weiter, bis man „ESC[N~“ hört. Hier wählt man „Linux“ aus.

Ich gehe, weil ich diese Verbindung sicher noch öfter brauche, in der Seitenleiste wieder zurück zu „Session“. Hier kann ich die Settings speichern, die ich sinnvollerweise „VDR Telnet“ nenne und dann auf den Schalter „Safe“ gehe und Enter drücke.

Wenn ich nun mit „Open“ die Verbindung öffne, habe ich ein leeres PUTTY-Fenster. Eigentlich müssten die Tasten ja jetzt funktionieren. Das lässt sich am einfachsten mit der Taste „m“ testen, welche das OSD öffnen sollte.

Und tatsächlich, das OSD öffnet sich! Es ist mit der Braillezeile sogar lesbar, nur der Menübalken wird nicht mitverfolgt. Das ist schade, aber nicht zu ändern. Heißt es also, mit den Pfeiltasten mitzählen. 🙁 Ich drücke also wieder „m“, um aus dem OSD rauszukommen.

Nun drücke ich die Taste „e“, um ins Setup zu gelangen.

Die einzelnen Punkte sind nummeriert, also könnte ich ja versuchen, durch Drücken der entsprechenden Zifferntaste zum Ziel zu gelangen.

Ich will jetzt auch nicht jede einzelne Einstellung beschreiben. Viele davon sind selbsterklärend und durchaus gut im Benutzerhandbuch des VDR-Wikis dokumentiert. Vieles ist ja auch Geschmackssache.

Einige Zeit später…

Ich habe jetzt die Grundkonfiguration von VDR gemacht. Wenn man mit der Taste „e“ das Setup-Menü öffnet, hat man die einzelnen Punkte, wie „OSD“, „EPG“ usw. Diese wählt man mit den Pfeiltasten hoch und runter aus und drückt Enter. Die Einstellungen, die sich dort präsentieren, wählt man mit Pfeil hoch und runter aus und ändert die Werte mit Pfeil links und rechts. Mit Enter bestätigt man alles und ist wieder im Setup-Hauptmenü.

Es funktioniert, ist aber anstrengend. Der Menübalken wird von der Braillezeile nicht verfolgt. Man muss die Braillezeile manuell nachführen. Dann allerdings geht es recht gut.

Viele Einstellungen habe ich auch nicht geändert, die meisten beziehen sich eh darauf, TV direkt auch mit dem VDR zu gucken. Ich habe nur ein paar Einstellungen im EPG-Bereich geändert, zum Beispiel, dass er nicht nach 5, sondern schon nach 3 Stunden ein EPG-Update machen soll. Und bei den Timer-Aufnahmen habe ich die Vorlauf- und die Nachlaufzeit geändert. Viel mehr habe ich auch nicht gemacht, nur hier und da ein paar Einstellungen, die, wie ich schon sagte, eher Geschmackssache sind.

Wenn man fertig ist, kann man das PUTTY-Fenster einfach schließen. Da es keine Möglichkeit gibt, die Telnet-Verbindung über einen Befehl zu schließen, ist das auch kein Problem.

Web-Interface

Ich habe ja 2 Web-Schnittstellen installiert. Beide haben so ihre Vor- und Nachteile, weswegen ich auch beide behalten werde. Beide Schnittstellen sind mit dem Firefox und Jaws gut zu bedienen, daher gehe ich jetzt nicht auf jeden Aspekt ein. Ich will nur kurz die Einrichtung und Nutzung erklären.

VDR-Live

Dies ist eine recht einfach gehaltene Weboberfläche, mit der man das aktuelle Programm, die Timer, die Aufnahmen und Senderlisten sehen kann. Aufnahmen oder das TV-Programm kann man hierüber auch streamen.

Um die Oberfläche aufzurufen, gibt man folgendes in die Adresszeile des Browsers ein, wobei man die IP-Adresse des Servers nehmen kann, aber auch den Servernamen.

server01:8008

Nun wird man nach einem Benutzernamen und Passwort gefragt. Standardmäßig ist der Benutzername „admin“ und das Passwort ist „live“. Anschließend ist man auf einer recht einfachen Weboberfläche.

Nun sollte man den Link „Setup“ aufrufen und die Oberfläche nach den eigenen Wünschen anpassen. Dabei würde ich auch den Benutzernamen und das Passwort ändern. Die restlichen Einstellungen sind Geschmackssache und selbsterklärend.

vdradmin-am

Diese Oberfläche unterscheidet sich in ihren Funktionen nicht sehr von der Live-Oberfläche, für meinen Geschmack ist sie aber schöner zu bedienen. Allerdings ist dies kein Plugin vom VDR, sondern scheint etwas externes zu sein. Dies ist z. B. eine der Tools, die über das SVDRP-Protokoll mit dem VDR kommuniziert. Diese Oberfläche muss also per Hand gestartet werden.

Um die Grundkonfiguration dieses Plugins durchzuführen, ruft man es also folgendermaßen auf:

vdradmind -c

Nun werden einige Fragen gestellt, wie Aufnahmeverzeichnis, Port, Benutzername, Passwort usw. Am Ende ist die Grundkonfiguration gemacht und der Service läuft.

Damit vdradmin-am auch immer beim Start des Servers mitgestartet wird, habe ich es in die Datei rc.local eingetragen.

sudo nano /etc/rc.local

Hier trägt man die Zeile mit dem Befehl „vdradmind“ direkt über der Zeile „exit“ ein.

Die Oberfläche hierzu ist ähnlich aufzurufen, wie die Live-Oberfläche. Gebt also in die Adresszeile des Browsers folgendes ein:

server01:8001

Alternativ könnt ihr an Stelle von „server01“ auch die IP-Adresse eingeben:

192.168.178.12:8001

Hier gebt ihr natürlich die IP-Adresse ein, die euer Server tatsächlich hat.

Nun gibt man noch die im Konfigurationsdialog erstellten Benutzernamen und Passwort ein, dann ist man schon auf der Oberfläche. Auch hier, erst mal in den Link „Configuration“ gehen und Anpassungen machen. Diese Oberfläche ist z. B. auch auf Deutsch umstellbar.

Welche nutzen?

Ich bin mir noch nicht wirklich sicher, welche der beiden Oberflächen ich nutzen will. Beide gefallen mir, aber die Zeit wird zeigen, welche mir dann doch besser gefällt. Die andere bleibt trotzdem, man weiß ja nie, und so viel Platz nehmen die jetzt auch nicht weg… 🙂

Sendersuchlauf

OK, kommen wir also zu einem der wichtigsten Teile, dem Sendersuchlauf. Denn noch hat der VDR nur die Standardsender, die bei der Installation dabei waren, und wie aktuell die sind, weiß ich nicht. Also werde ich eine neue channels.conf erstellen und die Sender darin nach meinen Wünschen sortieren.

Als erstes muss wieder der VDR gestoppt werden:

sudo service vdr stop

Nun werde ich das Antennenkabel mit der Dose verbinden und danach den Suchlauf starten. Und so sieht der Aufruf für den Suchlauf aus:

w_scan -f c -c DE -o 21>kanal.txt
  • -f c: Dieser bestimmt das Frontend, also die Art des Scans. Das „c“ steht hierbei für Cable, hier könnte auch ein „t“ für terrestrisch oder auch ein „s“ für Satellit stehen. Ich habe hier aber nur einen Kabelanschluss. Wie der Aufruf für Sat-Empfang sein muss, müsst ihr evtl. in den Manpages zu w_scan nachlesen.
  • -c DE: Dies legt das Land fest. Hier natürlich Deutschland, wonach Frequenzen, Symbolraten und dergleichen festgelegt sind.
  • -o 21: Ausgabe der channels.conf im Format für VDR 2.1. Ich habe zwar VDR 2.2.0 installiert, aber offenbar gibt es keinen Unterschied. Gibt man den Parameter -o 21 nicht an, wird eine channels.conf im Format für VDR 2.0 erzeugt.
  • >kanal.txt: Dies sorgt dafür, dass das Ergebnis in die Datei kanal.txt im Home-Verzeichnis geschrieben wird. Irgendwie gelingt es mir nicht, direkt in die channels.conf zu schreiben, daher schreibe ich das Ergebnis erst hier rein und kopiere es dann per Hand in die channels.conf.

Dieser Vorgang kann nun eine ganze Weile dauern, also erst mal einen Kaffee machen… 🙂

Fertig, der Scan hat ungefähr 22 Minuten gedauert. Die Daten sind jetzt in der kanal.txt. Aber das Programm hat die Kanäle so reingeschrieben, wie es sie gefunden hat, also total durcheinander. Da sind auch Fernsehkanäle mit Radiokanälen vermischt. Das werde ich nicht komplett sortiert bekommen, das ist zu viel! Was ich aber tun werde ist, die paar Fernsehsender, die ich immer wieder gucke, an den Anfang der Datei zu stellen.

Sortierung

Die Sortierung der Sender ist denkbar einfach, wenn auch umständlich. Vor allem, weil die Datei 512 Zeilen hat. Jede Zeile ist ein Sender. Hier mal ein Beispiel:

Das Erste;ARD:314000:M256:C:6900:101=2:102=deu@3,103=deu@3;106:104;105:0:28106:41985:1101:0

Tja, die einzelnen Parameter könnt ihr im Artikel zur channels.conf im VDR-Wiki nachschlagen.

Wichtig zu wissen ist ja erst mal nur, dass jede Zeile also ein eigener Sender ist. Ich muss jetzt die Datei also nur durchgehen und die Sender ganz an den Anfang der Datei packen, die ich immer wieder sehen will. Die anderen können meinethalben unsortiert bleiben…

In die channels.conf kopieren

Zum Sortieren habe ich den Editor Notepad++ benutzt. Dies ist auch wichtig, weil dieser zum einen Zeilennummern hat, damit man die Stelle wiederfindet, wo man was ausgeschnitten hat, aber auch wegen des Zeilenumbruches. Linux-Dateien haben einen anderen Zeilenumbruch als Windows-Dateien. Die kanal.txt hat Linux-Zeilenwechsel, diese müssen in Windows konvertiert werden. Drückt man also die Alt-Taste, navigiert zum Menü „Bearbeiten“ und sucht dort den Menüpunkt „Format Zeilenende“, so findet sich dort als oberstes die Option, die Zeilenende-Zeichen in Windows zu konvertieren. Das muss man auch, sonst gibt es beim Einfügen in die channels.conf ein heilloses Durcheinander. Damit hatte ich gerade schon etwas Spaß! 🙁

Hat man die Zeilenende-Zeichen konvertiert, kann man mit Strg+A alles auswählen und mit Strg+C kopieren. Nun verbindet man sich per SSH mit seinem Server und öffnet die channels.conf:

sudo nano /etc/vdr/channels.conf

Hier sind viele alte Einträge drin, die ist so alt, da gab es Premiere noch … 🙂 Wie auch immer, drückt die Umschalttaste und Bild nach unten, bis ihr alles markiert habt. Drückt dann Strg+K zum ausschneiden.

Das Einfügen ist jetzt so eine Sache. Das hängt davon ab, mit welchem SSH-Client ihr arbeitet. Ich habe hier ein Notebook mit Windows 10, und der hat einen SSH-Client integriert. Hier geht das, indem man Alt+Leertaste drückt, das Menü „Bearbeiten“ auswählt und hier „Einfügen“. Die Tastenkombination Strg+V funktioniert nicht.

Nun hat es eine ganze Zeit gedauert, bis alles eingefügt war, aber eine oberflächliche Kontrolle zeigt, dass alles gut aussieht. Also kann man mit Strg+X Nano verlassen und die Datei speichern.

Und jetzt kann man auch den VDR wieder starten.

sudo service vdr start

Als nächstes

Im nächsten Teil werde ich einen EPG-Scan anstoßen, die EPG-Suche anschauen, EPG-Suchtimer einrichten und das Plugin für Kodi installieren.

Homeserver 35: Fang den Podcast!

Seit einiger Zeit nun quäle ich mich mit diesem blöden Podcatcher unter Windows ab. Ich benutze den Juice Podcast Downloader, der früher, ich glaube iPodder hieß. Aber seit einiger Zeit nun will er einige Podcasts nicht mehr runterladen. Darunter ist zum Beispiel auch der Podcast c’t Uplink.

Erst ein Hinweis aus der Mailingliste, „Du hast doch einen Server, lass den das doch machen“, hat das Problem gelöst. Manchmal sieht man halt den Wald vor lauter Bäumen … Naja, ihr kennt den Spruch sicher zu genüge. Wie auch immer, dieser Vorschlag enthielt auch gleich ein konkretes Linux-Paket, welches ich jetzt einsetze, und welches extrem einfach zu konfigurieren war.

Installation

Das ist, wie bei bisher allen Paketen, der gleiche Schritt. Meldet euch am Server per SSH an und gebt folgenden Befehl ein:

sudo apt-get install podget

Das war’s schon, sehr viel mehr ist da gar nicht zu machen. Nur noch konfigurieren, aber dazu kommen wir gleich.

Ziel der Podcasts

Irgendwo müssen die Podcasts ja hin. Und ich habe auf meinem RAID einen Ordner Namens Audio. Hierunter lege ich ein Verzeichnis Namens Podcasts an. Das könnte ich über SSH machen, aber da mein RAID auch als Netzlaufwerk an meinem Windows-PC eingebunden ist, mache ich es der Einfachheit halber hierüber.

In diesen Ordner werden später die ganzen Podcast-Episoden heruntergeladen. Zum Einen kann ich so mit meinem Kodi Mediacenter drauf zugreifen, mit meinem Mac per robocopy synchronisieren, und zum Anderen könnte ich sie über iTunes mit meinem iPhone synchronisieren.

Podget konfigurieren

Nun muss aber noch podget konfiguriert werden. Und damit podget seine Konfigurationsdateien erstellt, müsst ihr es per Hand starten. Hierzu gebt ihr einfach den Befehl „podget“ im SSH-Terminal ein.

Podget beginnt sofort damit, Episoden des Linux-Link Podcasts herunterzuladen. Hier drücke ich CTRL+C, dann wird der Download unterbrochen. Ich möchte den Podcast nicht, daher werde ich alles bisher heruntergeladene auch wieder löschen.

Podget hat im Home-Verzeichnis jetzt zwei Ordner angelegt, POD und .podget. Der Ordner POD enthält die heruntergeladenen Episoden, den lösche ich. im Ordner .podget liegen nun zwei Konfigurationsdateien, die wir jetzt editieren möchten:

nano .podget/podgetrc

Vieles, was hier drin ist, könnt ihr nach eigenen Vorlieben einstellen. Die Standardwerte hingegen sind schon sehr brauchbar gesetzt. Ich habe nur zwei Werte geändert:

  • DIR_LIBRARY: Hier legt man fest, wo die Podcasts hin sollen. Bei mir lautet die Zeile daher: „DIR_LIBRARY=/raid1/daten/Audio/Podcasts“, natürlich ohne die Anführungsstriche.
  • NO_PLAYLIST: Diese Option findet ihr weiter unten. Podget erstellt Playlists für die heruntergeladenen Episoden. Das möchte ich nicht, daher habe ich das umgestellt: „NO_PLAYLIST=1“. Standardmäßig steht es auf 0.

Alle anderen Werte könnt ihr anders einstellen, die Standardeinstellungen sind aber schon ziemlich sinnvoll. Noch mit CTRLX speichern und beenden.

Nun müssen wir ja noch festlegen, welche Podcasts es nun zu downloaden gilt. Auch hierfür editieren wir eine Datei:

nano .podget/serverlist

Da steht erst mal viel Erklärung drin, wie die Podcasts eingetragen werden können. Könnt ihr erst mal überspringen. Ganz unten ist der Eintrag für den Linux-Link-Podcast, den könnt ihr behalten, wenn ihr möchtet, ich habe ihn gelöscht.

Die Einträge sind denkbar einfach. Ein Podcast-Eintrag besteht aus drei Elementen, der URL, einer Kategorie die nur aus einem Wort bestehen darf und dem Namen des Podcasts.

Die Kategorie ist sehr interessant, da ihr so festlegen könnt, welche Podcasts in welche Unterordner kommen. Hier mal 2 Beispiele:

http://www.tuksub.de/?feed=podcast Kommunikation TuKSuB Podcast
http://www.heise.de/ct/uplink/ctuplink.rss IT c't Uplink

Jetzt passiert folgendes: Im Ordner Podcasts wird ein Unterordner Kommunikation erstellt, in dem dann der Unterordner TuKSuB Podcast erstellt wird. Und ein Ordner IT, in dem dann der Unterordner c’t Uplink erstellt wird. So könnt ihr die Podcasts prima thematisch gruppieren.

Besondere Ordner

Im Ordner Podcasts befindet sich nun auch ein Ordner Namens .LOG. Hierin befinden sich zwei Dateien, done und errors.

Jede erfolgreich heruntergeladene Episode wird in die Datei done geschrieben. Belasst sie dort, sonst wird sie erneut heruntergeladen. Steht eine Episode also dort, wird sie beim nächsten Start von podget nicht erneut heruntergeladen. Andererseits, wollt ihr eine Episode erneut herunterladen, weil sie aus Versehen gelöscht wurde, so müsst ihr dessen Eintrag aus dieser Datei entfernen.

Jeder fehlgeschlagene Download wird in der Datei errors eingetragen. Wenn es ein temporäres Problem ist, so lasst es einfach dort stehen. Wenn die Datei zwar noch im Feed steht, die tatsächliche Datei aber nicht mehr verfügbar ist, so könnt ihr verhindern, dass podget sie immer wieder zu downloaden versucht. Kopiert die Zeile aus errors einfach in die Datei done. Die Reihenfolge spielt keine Rolle, Hauptsache die URL zur Datei ist in der done-Datei gespeichert.

Diese Dateien sind selbstverständlich noch leer. Wenn ihr jetzt also podget startet, so wird alles heruntergeladen, was verfügbar ist. Macht das ruhig, all diese URLs per Hand in die Datei done einzutragen, ist viel zu umständlich und fehleranfällig. Startet podget also, nachdem ihr alle eure Podcasts in die serverlist eingetragen habt, ein mal per Hand und lasst es durchlaufen. Später könnt ihr dann die Episoden löschen, die ihr nicht behalten wollt.

Regelmäßiges Ausführen

Natürlich wollt ihr, dass eure Podcasts regelmäßig abgerufen werden. Das müsst ihr auch nicht selbst tun, das kann Linux prima auch ganz alleine! 🙂 Alles, was es dazu braucht, ist ein Cron-Job.

Auf dem Server habe ich es mir angewöhnt, alle Cron-Jobs in die systemweite Cron-Datei einzutragen. Ich habe einfach keine Lust, mich mit zwei oder mehr Crontabs herumzuschlagen. Daher mache ich es mir einfach. Trotzdem ist es wichtig, dass podget im Benutzerkontext gestartet wird, in meinem Falle also als kamil. Und so sieht mein Eintrag aus. Öffnet die crontab-Datei:

sudo nano /etc/crontab

Fügt ganz am Ende, aber noch oberhalb des abschließenden Nummernzeichens „#“, folgende Zeile ein:

10 0    * * *   kamil   /usr/bin/podget -s

Podget wird also jeden Tag um 00:10 Uhr im Silent-Modus aufgerufen. Der Silent-Modus ist halt dafür da, weil ja keiner vor dem Monitor sitzt und zuguckt, also braucht Podget auch keine Ausgaben auf den Monitor auszugeben.

Es ist wichtig, dass podget im Kontext vom Benutzer kamil ausgeführt wird, weil ja die Konfiguration von podget im Home-Verzeichnis von kamil liegt. Vielleicht gibt es für podget sogar einen Parameter, um das zu umschiffen, aber ich fand das als die einfachste Lösung.

Fazit

Die Einrichtung hat mich nicht mal ganz eine halbe Stunde gekostet. Der Download der Episoden läuft bisher prima. auch der problematische Download des Podcasts c’t Uplink geht jetzt wieder reibungslos! Falls ihr also so einen Homeserver betreibt, lasst ihn doch die Arbeit machen. Dafür steht er schließlich da rum und verbraucht Strom! 🙂

Homeserver 33: Unterbrechungsfreie Stromversorgung

So, jetzt reicht’s mir! Das war jetzt der dritte Stromausfall innerhalb der letzten paar Monate. Und jedes Mal muss ich den Server überprüfen, ob das Dateisystem Schaden genommen hat, ob das RAID noch funktioniert, ob Daten verloren sind… All das steht in absolut keinem Verhältnis zu einer 60 € USV. Zwar dauern diese Stromausfälle nie lange, meistens zwischen 1 und 5 Minuten, aber das ist ja letztlich auch egal. Der Server ist dennoch ausgegangen, und zwar ohne seine Daten korrekt abzulegen. Jedenfalls im schlimmsten Fall.

Hinzu kommt, dass ich hier öfter mal Spannungsschwankungen habe. Die sind auch nicht wirklich schlimm, können aber zur Folge haben, dass eine Festplatte sich aus dem RAID abmeldet, wieder eingetragen werden muss und Stunden braucht, bis das RAID wieder synchronisiert ist und fehlerfrei läuft.

Also finde ich, ist jetzt der richtige Zeitpunkt gekommen, eine unterbrechungsfreie Stromversorgung anzuschaffen. Die soll gar nicht so sehr den Server im Betrieb halten. Wenn aber der Netzstrom ausfällt, soll der Server kontrolliert und vernünftig heruntergefahren werden. Und am besten wäre das, wenn dies auch noch automatisch gehen würde! Und diese USV soll, nach Möglichkeit, Spannungsschwankungen ausgleichen und auch als Überspannungsschutz dienen.

Diese Wünsche klingen echt teuer, oder? Habe ich auch gedacht, aber ist es zum Glück nicht. Ich habe mich selbst gewundert, aber man kann all dies tatsächlich schon für weit unter 100 € haben. Und zwar bietet APC ein paar USVs an, die für diesen Zweck geradezu ideal sind.

Ich habe mich für eine APC Backups BX700UI entschieden. Zum Zeitpunkt des Kaufs kostete sie 62,99 € bei Amazon. Die hat 390 Watt Ausgangsleistung und soll bei halber Last 9 Minuten überbrücken können. Für meine Zwecke reicht das Dicke, weil mein Server niemals so viel braucht. Selbst wenn, reicht die Zeit locker, um sauber herunterzufahren.

So eine USV hat durchaus Vor-, aber auch Nachteile. Daher werde ich mal ein Paar davon aufzählen.

Vorteile

Diese dürften auf der Hand liegen:

  • Bei Stromausfall sauberes Runterfahren
  • Automatische Spannungsregulierung und Überspannungsschutz
  • Bis zu 4 Geräte können hier angeschlossen werden
  • Gerät ist per PC steuerbar, geht mit Linux genau so gut wie mit Windows

Nachteile

Ja, so ein Teil hat leider auch Nachteile. Aber man muss halt abwägen, ob man sich damit zufrieden geben kann, oder ob die Nachteile die Vorteile überwiegen. Ich persönlich kann mit den Nachteilen leben.

  • Alle Geräte kleiner als 700VA sind nicht steuerbar. Das Modell BX500UI hätte mir auch gereicht, ist aber halt nicht von Linux steuerbar und kann nicht den PC runterfahren.
  • Ich habe das Modell mit 4 Kaltgeräteanschlüssen gewählt. Es gibt das ganze auch mit 4 Schuko-Steckern, das ist aber teurer.
  • Die USV verbraucht selbst ebenfalls Strom. In den Rezensionen gehen die Meinungen aber auseinander, wie hoch der Verbrauch tatsächlich ist, auch wenn die Akkus voll sind.
  • Akkus sind nicht durch den Anwender austauschbar. Das muss der Service tun. Die Kosten für das Hin- und Herschicken, Akku, Arbeit, … So ein Akku soll zwischen 3 und 5 Jahren halten. Wäre zu überlegen, ob eine neue USV dann nicht evtl. billiger ist.
  • USB-Kabel nicht im Lieferumfang. OK, kein Beinbruch, aber wissen sollte man das schon. 🙂 Falls man also kein USB A-B-Kabel hat, sollte man sich noch eines besorgen.

Vorbereitungen

OK, dann mal los! Ein etwas gewichtiges Paket ist bei mir eingetroffen. Ich habe aber, um schon mal vorbereitet zu sein, das PDF-Handbuch zu dem BX700UI gelesen. Danach ist es sogar ziemlich einfach, das Gerät in Betrieb zu nehmen, weil es so viel gar nicht dran einzustellen gibt.

Lediglich 2 Punkte in der Anleitung stören mich: Die Signaltöne und LED-Signale sind in einer Tabelle in der PDF beschrieben, die nur schwer zu lesen ist. Eine andere Tabelle beschreibt die Möglichkeiten, das Verhalten der USV bei Stromschwankungen und dergleichen einzustellen. Auch diese ist mit Jaws nicht gut zu lesen. Da muss ich mir mal helfen lassen, aber abgesehen davon sehe ich keine Probleme.

Der Inhalt des Kartons ist relativ unspektakulär. Ein Handbuch, ein Kaltgerätekabel zum Verbinden der USV mit einem PC, und die USV selbst. Puh, das Teil müffelt! 🙁 Hoffentlich geht das bald weg!

An der Front der USV ist nur der Power-Knopf. An der Rückseite gibt es 4 Kaltgeräteanschlüsse, ein Netzanschluss, eine Unterbrechertaste – so etwas wie eine Sicherung, RJ-11-Anschlüsse zum durchschleifen und den Batteriekonnektor. Und natürlich ist dort auch der USB-Anschluss für die Steuerung.

Die Batterie ist zwar fest eingebaut, aber noch nicht angeschlossen. Hat also keinen physischen Kontakt zum Gerät. Hierfür gibt es hinten eine Art Griff, genau befindet der sich hinten oben. Dieser muss rausgezogen, nach unten geklappt und in das Gerät reingeschoben und fest reingedrückt werden. Sollte man, warum auch immer, die USV länger mal wegpacken wollen, kann man mit einem Schlitzschraubendreher den Griff wieder rausziehen, um die Batterie wieder vom Gerät zu trennen.

Das wär’s eigentlich schon, die USV ist bereits einsatzbereit.

Installation

Die Installation geht in 2 Schritten. Zunächst muss die USV angeschlossen und mit dem Server verbunden werden. Das betrifft die Stromversorgung, aber auch ein USB-Kabel für das Monitoring. Als nächstes muss auf dem Server das Paket für das Strom-Management installiert und konfiguriert werden.

Hardware-Installation

Zunächst fahre ich den Server herunter und trenne ihn vom Strom. Das Netzkabel, welches von der Wandsteckdose in den Server ging, wird jetzt in die USV gesteckt. Sobald die USV Strom aus der Wand bekommt, beginnt sie bereits, ihre Batterien aufzuladen.

Das Kaltgerätekabel wird in einen der 4 hinteren Anschlüsse an der USV eingesteckt, das andere Ende kommt in das Netzteil des Servers.

Und zu guter Letzt kommt ein USB-Kabel an die USV, das andere Ende natürlich in den Server, damit wir die USV steuern, bzw. die USV den Server herunterfahren kann. Ich sagte ja bereits, dass kein USB-Kabel im Lieferumfang der USV war. Nun, in meiner PC-Grabbelkiste findet sich derlei Zeugs zu Hauf. Wer keines hat, sollte beim Kauf der USV dran denken. Ihr braucht eines mit einem A-Stecker an dem einen, und einem B-Stecker am anderen Ende.

Natürlich fährt nicht die USV den Server runter. Das tut die Software, die ich nachher installiere. Die USV meldet über das USB-Kabel nur ihren Zustand, also wie viel Strom noch auf der Batterie ist, ob Strom aus der Wand kommt und mit welcher Spannung usw. Die Software, die auf dem Server läuft entscheidet dann anhand dieser Angaben, ob und was sie dann tut.

Damit der Server aber jetzt hochgefahren werden kann, muss die USV mit dem Power-Knopf an der Front eingeschaltet werden. Es ertönt ein kurzer Ton, man kann noch ein paar mal das Knacken von Relais hören, dann ist das Gerät an. Nun kann man den Server einschalten und hochfahren.

Software-Installation

Nun muss noch die Software installiert werden, damit der Server mit der USV überhaupt etwas anfangen kann. Hierzu logge ich mich wieder über eine SSH-Verbindung auf meinem Server ein.

Um zu sehen, ob die unterbrechungsfreie Stromversorgung überhaupt vom Server erkannt wurde, gebe ich ein mal den Befehl lsusb ein. Nun wird mir eine Liste der USB-Geräte angezeigt, welche auf meinem Server vorhanden sind. Die interessante Zeile ist die hier:

Bus 003 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply

Das zeigt mir, dass die USV erkannt wurde und wir damit auch was anfangen können.

Nun muss das Software-Paket installiert werden, mit dem man die USV steuert:

sudo apt-get install apcupsd

Hiermit wird das Programm und dessen Dokumentation installiert.

Nun muss der Dienst aber noch konfiguriert und gestartet werden. Dazu muss zunächst die Datei /etc/apcupsd/apcupsd.conf editiert werden:

sudo nano /etc/apcupsd/apcupsd.conf

Folgende Werte habe ich geändert. Alle nicht erwähnten Felder sind so, wie sie standardmäßig waren.

  • UPSCABLE: Standardmäßig steht hier „smart“, ich habe es zu „usb“ geändert.
  • UPSTYPE: Standardmäßig steht hier „apcsmart“, ich ändere das auf „usb“.
  • DEVICE: Diese Zeile muss auskommentiert werden, also ein Nummernzeichen „#“ muss vor die Zeile gesetzt werden.
  • POLLTIME: Gibt den Wert in Sekunden an, nach denen die USV nach ihrem Status befragt wird. Die Zeile ist auskommentiert und auf 60 Sekunden eingestellt. Hier das Nummernzeichen entfernen und den Wert auf 15 setzen. Ich erkläre später, warum.

Diese Werte sind wichtig, da die USV sonst vom Dienst nicht erkannt wird. Natürlich werden die Werte ohne Anführungsstriche eingegeben.

Nun muss noch konfiguriert werden, wann der Server heruntergefahren wird. Hier bedurfte es einiger Experimente, weil ich nicht wusste, wie schnell der Server die Akkus der USV verbraucht.

  • BATTERYLEVEL: Wenn dieser Wert in Prozent erreicht ist, wird der Server heruntergefahren. Er steht auf 5 %, das ändere ich auf 15.
  • MINUTES: Wenn die Batterielaufzeit in Minuten diesen Wert erreicht, wird der Server heruntergefahren. Hier ist bereits eingestellt, dass der Server abgeschaltet wird, wenn nur noch 3 Minuten Restlaufzeit auf der Batterie verfügbar sind.
  • NISIP: Hier ist 127.0.0.1 voreingestellt, ändert das auf 0.0.0.0. Sonst funktioniert einiges nicht richtig. Zum Beispiel funktioniert dann die Statusabfrage in einer SSH-Sitzung nicht mehr.

Bei voller Akkuladung kann die USV meinen Server etwa 30 Minuten betreiben. Das ist schon eine Menge, finde ich. Damit aber der Server rechtzeitig heruntergefahren werden kann, muss der Befehl zum Runterfahren kommen, wenn noch Genug Kapazität auf dem Akku ist. Rein rechnerisch würde also 1 Minute Laufzeit etwas um die 3 % Akkukapazität verbrauchen. Um also eine Reserve zu haben, falls die Last doch mal höher ist, habe ich die Schwelle, bei der der Befehl kommt, auf 15 % gesetzt, oder wenn der Akku früher durch hohe CPU-Last nur noch 3 Minuten Laufzeit hat.

Nun kommt noch die Polltime dazu. Die voreingestellten 60 Sekunden sind viel zu viel! Im schlimmsten Fall könnte der Befehl zu spät kommen, und der Saft ist alle, bevor alle Prozesse ordentlich beendet sind. Also stelle ich die Polltime auf 15 Sekunden ein, so dass alle 15 Sekunden der Status der USV-Akkus abgefragt wird. So stelle ich sicher, dass der Befehl kommt, wenn noch 4 bis 5 Minuten Leistung auf dem Akku sind, und nicht erst, wenn nur noch 2 Minuten Restlaufzeit da sind. Das ist mir nämlich in den ersten Tests so passiert.

Das war es für diese Datei, mit Ctrl+X speichern, fertig.

Der Dienst kann aber noch nicht gestartet werden, da er sich erst starten lässt, nachdem er konfiguriert wurde. Also müssen wir dem Dienst noch erklären, dass er nun konfiguriert ist… 🙂 Ich weiß, kompliziert, aber ist halt so. Also müssen wir noch folgende Datei editieren:

sudo nano /etc/default/apcupsd

Hier gibt es ganz unten einen Wert „ISCONFIGURED=no“. Diesen Wert müssen wir auf „yes“ setzen, so dass die Zeile so aussieht:

ISCONFIGURED=yes

Nun wieder mit Ctrl+X speichern, auch hier, fertig!

Der Dienst wird jetzt mit folgendem Befehl gestartet:

sudo service apcupsd start

Benutzung

Viel kann man jetzt gar nicht mehr machen. Der Dienst wird jetzt im Hintergrund arbeiten und schauen, was die USV meldet. Meldet sie, dass sie auf Batterie läuft, wird der Dienst das erkennen. Meldet die USV, dass nur noch 15 % oder nur noch 3 Minuten Restlaufzeit auf der Batterie sind, wird der Server heruntergefahren.

Man kann jetzt aber mal den Status abfragen. Die Ausgabe ist echt umfangreich, daher beschreibe ich mal die wichtigsten Parameter. Man ruft den Status mit:

sudo apcaccess

auf. Die Ausgabe ist, wie ich sagte, umfangreich. Daher hier mal die wichtigsten Werte. Ganz oben kommen ein paar generelle Infos über den Rechner, die Softwareversion und die Konfigurationseinstellungen, die wir früher schon gemacht haben.

  • MODEL: Back-UPS XS 700U: Nun, sagt ja schon, was es ist.
  • STATUS: ONLINE: OK, ist auch recht aussagekräftig.
  • LINEV: 238.0 Volts: Das zeigt die derzeit tatsächliche Spannung an. Das stand vorhin mal bei 232.
  • LOADPCT: 18.0 Percent: Das ist die Auslastung der USV. Da geht noch was… 🙂
  • BCHARGE: 100.0 Percent: OK, die Batterien sind voll!
  • TIMELEFT: 31.1 Minutes: So lange könnte die USV den Server betreiben.

Dann kommen viele Angaben über Firmware, Batteriedatum, Seriennummer usw. Aber das sind die paar wirklich interessanten Infos.

Benachrichtigung per Mail

Man mag sich fragen, wie die Mail gesendet werden soll, wenn doch der Strom ausgefallen ist? Tja, da mag was dran sein. 🙂 Aber für die Zukunft plane ich, auch die Fritz!Box an die USV zu hängen. Dann hätte sich dieses Problem erledigt. 🙂

Aber warum will ich überhaupt eine Mail? Naja, das ist eigentlich ganz einfach: Die USV kann den Server bei Stromausfall kontrolliert herunterfahren. Sie kann ihn aber nicht wieder starten. Wenn ich also eine Mail bekomme, vorausgesetzt, ich kriege das hin, dass die Mail auch noch rausgeht, dann weiß ich wenigstens, dass der Server runtergefahren ist. Nun kann ich später mal versuchen, mich per VPN mit meinem Heimnetz zu verbinden und per Wake on LAN den Server wieder aufzuwecken.

Der Dienst für die USV kann über 5 Zustände eine Meldung verschicken. Dies wird in 5 Skripten eingestellt, demzufolge müssen auch 5 Skripte editiert werden. Ihr könnt zwar auch den versendeten Text anpassen, wenn ihr aber mit dem Standardtext zufrieden seid wie ich, so sind es nur 2 kleine Änderungen in den Skripten, damit die Mailbenachrichtigungen funktionieren.

  • changeme: Dieses Skript informiert darüber, dass die Akkus erledigt sind und gewechselt werden möchten.
  • commfailure: Dieses Skript informiert darüber, dass die USV nicht mehr ansprechbar ist. Vielleicht ist das USB-Kabel defekt, rausgerutscht oder an der USV selbst stimmt was nicht. Das kann man dann prüfen.
  • commok: Das Skript meldet, wenn wieder alles in Ordnung mit der Kommunikation zwischen USV und Server ist. Das USB-Kabel könnte wieder eingesteckt sein? 🙂
  • onbattery und offbattery: Diese Skripte informieren darüber, wenn die USV auf Batteriebetrieb schaltet, und wenn der Strom wieder da ist, bevor die Batterie leer war.

Diese Skripte befinden sich alle in /etc/apcupsd, und können dort editiert werden. Beispielsweise könnte so ein Befehl so aussehen:

sudo nano /etc/apcupsd/onbattery

Diese Skripte sind alle gleich aufgebaut, so dass die Änderungen an allen 5 Skripten gleich sind.

Ganz oben kommen ein paar auskommentierte Zeilen. Die erste aktive Zeile ist:

HOSTNAME=`hostname`

Darunter müsst ihr die Variable SYSADMIN definieren, damit dem Skript eure Mailadresse bekannt ist.

SYSADMIN=mailadresse@beispiel.de

Die vorletzte Zeile im Skript lautet:

) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN

Ändert diese Zeile, und zwar ersetzt $APCUPSD_MAIL durch mail, so dass die Zeile so aussieht:

) | mail -s "$MSG" $SYSADMIN

Fertig! Macht das mit allen 5 Skripten, und die Mailbenachrichtigungen funktionieren.

Abfrage des USV-Status per Webbrowser

Nun, wenn man nicht zu Hause ist, ist es schwierig, zu gucken, was die USV gerade macht. Ich kann sowieso viele Statusmeldungen des Servers per Webbrowser sehen, warum also nicht auch noch die der USV? Und das ist einfacher, als ich dachte!

Man braucht eigentlich nur das Paket apcupsd-cgi zu installieren.

sudo apt-get install apcupsd-cgi

Und schon kann man per Webbrowser drauf zugreifen. In meinem Falle lautet die Adresse:

https://server01/cgi-bin/apcupsd/multimon.cgi

Das funktioniert natürlich nur aus dem lokalen Netz. Zwar ist mein Webzugriff passwortgesichert, aber sicher ist sicher, die öffentliche Adresse behalte ich mal für mich… 🙂

Ich habe mir ja eine index.html-Datei in mein WWW-Verzeichnis gelegt, wo ich diese einzelnen Programme verlinke. So brauche ich mir diese Adressen nicht alle merken. Und hier trage ich natürlich auch den Link zu dieser Applikation ein.

Zum Beispiel würde das so aussehen:

<p><a href="/cgi-bin/apcupsd/multimon.cgi">Unterbrechungsfreie Stromversorgung</a></p>

Nun kann ich diese Seite über meine Index-Seite aus aufrufen.

Hier gibt es einen Überblick über die USV. Man könnte, wenn man denn hätte, auch mehrere USVs damit überwachen, aber ich habe ja mal nur eine. In einer Tabelle sind die Geräte nun mit ihren grundlegenden Parametern aufgelistet.

Will ich jetzt also alles über die USV wissen, die an „Local Host“ angeschlossen ist, klicke ich den Link und bekomme alle Daten, die ich auch mit apcaccess bekommen würde, und noch die paar letzten Ereignisse die die USV betreffen angezeigt.

Zumindest mal mit Jaws ist das alles ziemlich gut bedienbar!

Kleiner Test

So, wollen wir mal sehen, ob das Teil auch funktioniert? Ich ziehe jetzt einfach mal den Stecker der USV aus der Wand. Damit simuliere ich einen Stromausfall!

Die USV gibt jetzt in regelmäßigen Abständen 4 Pieptöne von sich. Der Server läuft noch, aber eben auf Akku. Die USV hat dabei ein leichtes Brummen.

Nun kann ich mit apcaccess immer wieder schauen, wie der Status ist. Momentan ist der Status „ONBATT“, also auf Akku, BCharge ist bei um die 80 % und angeblich kann der Server noch 28 Minuten laufen. Nun, warten wir mal ab… 🙂

Irgendwann beginnt die USV damit, ständig kurze Pieptöne von sich zu geben, ich kann hören, dass Linux die Festplatten des RAID einzeln abschaltet und der Server geht aus.

Das ist mir bei Linux schon früher aufgefallen, dass die Festplatten nicht einfach alle gleichzeitig abgeschaltet werden, wenn die Prozesse runtergefahren sind, Linux schaltet die Platten einzeln und nacheinander ab. Daran höre ich aber, dass das Herunterfahren einwandfrei geklappt hat.

Nachdem ich den Stecker zurück in die Wand gesteckt und den Server wieder hochgefahren habe, prüfe ich den Status der USV. Da wären noch 9 % Akkukapazität übrig gewesen, also genug Luft, auch wenn das Runterfahren mal länger gedauert hätte. So etwas passiert leider gelegentlich.

Fazit

Puh, das Teil müffelt immer noch! Mit was für einer Chemikalie hat APC das Teil denn eingenebelt? Aber das geht in den nächsten Tagen hoffentlich wieder weg.

Abgesehen vom etwas strengen Geruch finde ich, tut das Teil absolut, was es soll. Überspannungsschutz, geordnetes Herunterfahren und das bitteschön ohne mein Zutun. Nur um das Wiederaufwecken muss ich mich dann kümmern. Aber das ist OK, Hauptsache es sind erst mal keine Datenverluste passiert.

Später will ich noch die Fritz!Box an die USV hängen, damit der Server im Notfall wenigstens Mails schicken kann. Vorausgesetzt natürlich, dass die Vermittlungsstelle, an der mein DSL-Anschluss hängt, nicht auch vom Stromausfall betroffen ist… 🙁 In den letzten paar Fällen war es aber immer ein hausinterner Stromausfall, wahrscheinlich wird am Stromnetz gearbeitet, ich weiß es nicht. Es war jedenfalls kein Stromausfall vom Versorger.

Für diesen doch guten Preis finde ich, sollte man sich so ein Teil gönnen, wenn man einen Server betreibt. Der Aufwand der Dateisystemreparatur, Datenintegritätsprüfung und Backupwiederherstellung steht jedenfalls in keinem Verhältnis zu einer einmaligen Ausgabe von knapp 60 €.