Schlagwort-Archive: Linux

Homeserver 38: Server als Videorecorder 3 – Die Benutzung

Das System ist fast fertig! Alle Plugins sind installiert und konfiguriert, die Senderliste wurde erstellt, die Kabel angeschlossen. Nun können wir eigentlich loslegen!

EPG aktualisieren

Der VDR hat im Augenblick kaum EPG-Daten, daher muss erstmalig ein Update angestoßen werden. Ich habe keine Lust darauf zu warten, bis er das selber macht, also lege ich mal Hand an.

Am einfachsten geht das über die Weboberfläche des VDRAdmin. Also gebe ich in die Adresszeile meines Browser folgendes ein:

server01:8001

Ich verwende die VDR Administrationsoberfläche, weil ich hier auch SVDRP-Befehle abschicken kann, ohne auf die Linux-Konsole zu müssen. Nun gebe ich noch Benutzernamen und Passwort ein und bin auf der Seite.

Hier wähle ich den Link „Befehle“ aus. In diesem Bereich kann ich so einiges machen. Mich interessiert das Eingabefeld, in das ich einen SVDRP-Befehl eingeben kann. Im Eingabefeld steht schon der Befehl „help“, den lösche ich und gebe dort „scan“ ein. Anschließend klicke ich auf „Ausführen“.

Ganz unten auf der Seite steht jetzt die Ausgabe „EPG scan triggered“, also EPG scan ausgelöst. Dies kann jetzt eine Weile dauern. Ich sehe leider den Fortschritt nicht, daher gehe ich mal davon aus, dass er so eine Stunde brauchen wird. Ich kann jetzt nichts anderes machen, weil er sonst den Scan abbrechen würde.

Suchtimer einrichten

Ich gucke eigentlich nicht viel fern. Aber es gibt ein paar Sendungen, die ich doch recht regelmäßig gucke. Natürlich will ich diese nicht verpassen. Bei der Dreambox war ich es gewohnt, diese in einen Autotimer einzutragen. Wann immer diese Sendung mit dem entsprechenden Suchkriterium im EPG auftauchte, hat die Dreambox die Sendung selbst eingetragen und aufgenommen.

Dies geht auch mit dem VDR und dem Plugin EPGSearch. Dieses Plugin kann dazu verwendet werden, das EPG sehr komfortabel zu durchsuchen. Diese Suchaufgaben können aber auch gleichzeitig einen Timer für das gefundene Ergebnis setzen. Ein Mal eingerichtet, braucht man sich also nicht mehr kümmern, ob man eine regelmäßig kommende Sendung verpasst.

Einrichten eines Suchtimers

Ich kann den Suchtimer über beide Weboberflächen programmieren. Weil ich aber gerade schon auf der vdradmin-Oberfläche bin, bleibe ich gleich da.

Hier wähle ich den Link „EPG Search“. Mit dem Schalter „Neue Suche“ richte ich eine neue Suche ein.

  • Im Feld „Suche:“ gebe ich den Begriff ein, nach dem gesucht werden soll. Hier ist es zum Beispiel „nano“, weil ich diese Sendung als Autotimer programmieren möchte.
  • Bei „Suchmodus:“ wähle ich „Ausdruck“. Dadurch wird die Sendung „nano“, aber auch die Sendung „nano Spezial“ gefunden.
  • Ich kann auch einstellen, dass auf Groß/Kleinschreibung geachtet wird. Dieses Kontrollkästchen lasse ich leer.
  • Im Bereich „Zu suchen in:“ kann ich die Bereiche auswählen, in denen nach dem Wort gesucht wird. Titel, Untertitel und Beschreibung können ausgewählt werden. In diesem Fall reicht ein Kontrollkästchen bei Titel.
  • Bei „Verwende Kanal:“ kann ich wählen, ob es auf „nein“ steht, wobei er dann alle Kanäle durchsucht, oder z. B. Bereich. Ich wähle Bereich, weil ich einen festen Kanal einstellen möchte. Bei den nächsten 2 Ausklapplisten kann ich den Bereich der Kanäle definieren, in denen gesucht wird. Ich wähle bei beiden Ausklapplisten „3Sat“. Somit sollte auch nur auf 3Sat gesucht werden. Hinzuweisen wäre noch auf die Option „Ohne PayTV“, weil man diese Sender so von der Suche ausschließen kann. Da ich keine PayTV-Sender abonniert habe, schließe ich diese bei den Suchtimern aus, die über alle Kanäle suchen sollen. Sonst muss ich diese Timer manuell löschen.
  • Verwende Uhrzeit schalte ich ein und definiere in den folgenden Feldern einen Zeitraum.
  • Start nach: Ist ein bisschen blöd ausgedrückt, meint aber, dass es nach einer bestimmten Uhrzeit startet. In diesem Falle startet nano ja immer so um 18:30 Uhr, also sage ich, es startet nach 18:00 Uhr.
  • Start vor: Ist auch blöde ausgedrückt, meint aber, dass es definitiv vor einer bestimmten Uhrzeit startet. Ich sage hier 20:00 Uhr. In diesem Falle wird also zwischen 18:00 Uhr und 20:00 Uhr nach nano gesucht.
  • Verwende Dauer: Hier könnte ich eine Dauer festlegen, die die Sendung haben soll. Das lasse ich aus.
  • Verwende Wochentag: Das markiere ich und setze dann einen Haken für die Tage, an denen nano läuft. Also nicht am Wochenende. 🙂
  • Verwende Ausschlusslisten: Das lasse ich auf „Nein“, da ich keine Ausschlusslisten habe.
  • Als Suchtimer verwenden: Hier wähle ich „Ja“ aus der Ausklappliste. In der darunterliegenden Ausklappliste kann ich wählen, was passieren soll, also ob aufgenommen wird, angekündigt wird oder nur umgeschaltet wird. Es steht schon auf „Aufnehmen“, und da belasse ich es auch.
  • Automatisch löschen: Das lasse ich auf „Nein“, ich lösche die Aufnahme selbst, wenn ich sie gesehen habe.
  • Hiernach kommen einige Felder für die Aufnahme. Die lasse ich alle unberührt.
  • VPS verwenden: Dies ist einer der letzten Punkte, den schalte ich ein. Wenn im EPG VPS-Zeiten hinterlegt sind, wird ein Timer basierend auf diesen Daten erstellt. Dies erspart mir die Vorlauf- und Nachlaufzeit und erzeugt auch kleinere Dateien. Sind keine VPS-Daten vorhanden, wird automatisch mit den vorgegebenen Vor- und Nachlaufzeiten ein Timer erstellt.

Ganz unten klicke ich noch auf den Schalter „Speichern. Hiermit ist der Suchtimer erstellt. Nun bin ich in der Liste der eingestellten Suchtimer. Hinter jedem Suchtimer gibt es eine Reihe von Schaltern. Ich aktiviere den Schalter „Find“, damit er die Suche auslöst. So sehe ich, ob meine Einstellungen die Sendungen finden, die ich aufgenommen haben will. Um das Update der Timer muss ich mich nicht kümmern. Ich habe über das VDR-OSD die Einstellung gewählt, dass die Suchtimer alle 60 Minuten aktualisiert werden.

Nun gebe ich über diese Funktion alle Suchtimer ein, die ich aufgenommen haben möchte.

Plugin für Kodi installieren

Für die Dreambox habe ich das Plugin in Kodi bereits installiert. Hierüber kann ich aufgenommene Sendungen gucken oder auch das Live-TV. Timer und EPG sind etwas blöd dargestellt, weswegen ich dieses eigentlich immer über die dreaMote-App auf dem iPhone erledigt habe. Die Dreambox bleibt auch noch eine Weile in Betrieb. Sie nimmt zwar nichts mehr auf, alle Autotimer sind bereits im VDR hinterlegt, jedoch sind hier noch Sendungen drauf. Leider kann ich diese nicht einfach auf den Server kopieren um sie mit dem VDR zu gucken. Der nimmt die Aufnahmen der Dreambox nicht an. Macht aber nichts, sind ja nicht so viele.

Auch für den VDR gibt es ein Plugin. Ich habe ja das Plugin VNSIServer für VDR installiert. Und unter Kodi gibt es einen VDR VNSIClient. Dieser ist denkbar einfach zu installieren.

Ich gehe also in die Einstellungen von Kodi, suche hier die Sektion „Addons“ und wähle „Aus Repository installieren“. Ab hier kann es Unterschiede geben. Hat man Kodi unter Windows oder Ubuntu, könnte das Addon bereits mit installiert worden sein. Ich habe hier LibreELEC. Hier muss ich das Addon aus dem LibreELEC Repository nachinstallieren. Dieses Repository wähle ich nun an und gehe in die Sektion „PVR Clients“.

In dieser Rubrik gibt es die unterschiedlichsten Clients für die unterschiedlichsten TV-Systeme und Anwendungen. Relativ weit unten findet sich der VDR VNSIClient. Hier gehe ich hin und drücke auf der Fernbedienung OK. In diesem Fenster wähle ich „Installieren“. Es dauert nun eine Weile, bis das Addon heruntergeladen wurde.

Nun muss das Addon noch konfiguriert werden, was auch denkbar einfach ist. Ich stehe wieder in der Liste der Addons, wobei mir neben dem Namen des Addons nun auch gesagt wird, dass es aktiviert ist. Ich drücke hier noch mal OK und wähle aus den Optionen nun „Konfigurieren“ aus.

Viele Optionen gibt es hier ja nicht, aber die interessieren mich alle nicht. Die einzige Angabe, die ich hier ändere, ist die IP-Adresse zu meinem Server. Hier ist 127.0.0.1 vorgegeben. Das ist ja nur die Localhost-Adresse, was auch richtig wäre, würde VDR auf dem gleichen Gerät laufen. Hier drücke ich also OK und gebe die IP-Adresse des Servers ein. Anschließend wähle ich mit den Pfeiltasten die Schaltfläche OK und bestätige diese. Somit sind die Konfigurationen gemacht und das Plugin ist bereit. Kodi muss nun noch neu gestartet werden.

Anschließend ist alles genau so zu bedienen, wie es mit dem Dreambox-Plugin auch ging. Die Möglichkeiten sind hier zu umfangreich, um diese einzeln aufzuzählen. Ich kann meine Timer sehen, ich kann meine Aufnahmen sehen, wobei die Liste hier noch leer ist und ich kann die TV- und Radio-Kanäle ansteuern. Auch die Umschaltzeiten beim Live-TV sind erfreulich kurz, sogar Timeshift geht. 🙂

Falls nach der Aktivierung des Plugins und des Kodi Neustarts die Menüpunkte TV und Radio nicht zu sehen sind, muss man evtl. noch eine Datei auf dem VDR-Server editieren. Denn auch hier, das Plugin beschränkt den Netzwerkzugang, damit nicht jeder an dem Plugin Timer löschen oder Aufnahmen löschen kann. also öffnet man auf dem Server folgende Datei:

sudo nano /etc/vdr/plugins/vnsiserver/allowed_hosts.conf

Diese Datei sieht genau so aus wie die svdrphosts.conf, und genau den gleichen Effekt hat sie auch. Hier stehen natürlich wieder die obligatorischen Beispiele, die natürlich auch erst mal so in Ruhe gelassen werden. Ganz unten fügt ihr dann noch den Adressbereich für euer lokales Netz hinzu. Bei mir ist es, weil ich alles an einer Fritz!Box hängen habe, folgender Eintrag:

192.168.178.0/24

Nun muss Kodi erneut gestartet werden, damit sich das Plugin in Kodi mit dem Server verbinden kann. Jetzt findet ihr im Hauptmenü auch die Einträge TV und Radio.

Fazit

Ja, die Einrichtung des VDR war umfangreich. Und zunächst wirkte es alles auf mich auch etwas zu viel. Wenn man sich aber mal kurz zurücklehnt und eine Aufgabe nach der anderen erledigt, ohne ins Schwitzen zu kommen, weil man noch nicht dort ist, wo man gerne wäre, ist es halb so schlimm. Und die Konfigurationsdateien habe ich alle gesichert, so dass ich diese wiederherstellen kann, sollte es mal nötig sein.

An die Suchtimer muss ich mich noch gewöhnen, weil ich erst noch nach und nach herausfinden muss, wie die Optionen die Suche beeinflussen. Und auch die Einstellungen hierfür über den Webbrowser zu machen, ist zwar erst mal ungewohnt, geht aber mittlerweile gut. Ich verwende übrigens überwiegend VDRADMIN-AM, weil dieser sich erstaunlich gut bedienen lässt. Auch Timerkonflikte sind schnell ausgemacht und leicht korrigiert. Ich finde diese Oberfläche weit zugänglicher, als es die integrierte Live-Oberfläche ist.

Jetzt hat der VDR genau die Funktionalität, die ich bei der Dreambox bisher auch genutzt habe. Nur eine App für das iPhone habe ich noch nicht gefunden. Es gibt wohl eine, aber die ist nur zum Streamen gedacht. Das kann ich aber viel komfortabler über Kodi. Timer und Suchtimer bearbeite ich dann lieber über die recht aufgeräumte Weboberfläche. Die ist um vieles bedienbarer, als es die Oberfläche der Dreambox je war. Daher habe ich bei der Dreambox auch lieber die dreaMote-App genutzt.

Nun muss ich also nur noch die Sendungen auf der Dreambox weggucken, dann kann das Ding meinethalben den Geist aufgeben… 🙂

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 36: Server als Videorecorder verwenden 1 – Installation

Bisher verwende ich eine Dreambox DM8000 als TV-Receiver und Aufnahmegerät. Mit einigen Plugins erweitert und mit einer iPhone-App steuerbar ist es für mich die perfekte TV-Zentrale. Jedoch kommt sie so langsam in die Jahre und fängt an, Ausfallerscheinungen zu zeigen. Zeit also, sich um Ersatz zu kümmern. Was liegt da näher, als den Homeserver als Aufnahmegerät zu verwenden?

Mit dem Wegfall der Dreambox habe ich auch einen Stromfresser weniger, wodurch sich auch noch bares Geld sparen lässt. Der Server läuft sowieso ständig, also kann der auch die TV-Zentrale werden.

Vorüberlegungen

Was muss also getan werden? Nun, der Server braucht erst mal eine TV-Karte. Dann braucht es ein Kabel, welches von meiner Kabel-Dose zum Server gelegt wird. Last, but not least, braucht es auf dem Server Software, die die Aufgaben erfüllt.

Zwar habe ich mit den umfangreichen Plugins der Dreambox das Teil um viele Funktionen erweitert, jedoch nutze ich davon nicht wirklich alle. Ein bisschen oversized, das Gerät. Überlegen wir also mal, was mein Server an Aufgaben wirklich übernehmen muss:

  • Aufzeichnung von 2 Sendungen parallel sollte gehen. Also muss ein Dualtuner her, oder 2 TV-Karten.
  • Eine Autotimer-Funktion, wie es sie in der Dreambox gibt, brauche ich ebenfalls.
  • Bedienbarkeit über eine Weboberfläche wäre auch nett.
  • Von meinem Mediacenter Kodi sollte ich auf Aufnahmen und Live-TV zugreifen können.

Meine Dreambox läuft noch eine Weile, noch ist sie nicht ganz hinüber. So kann ich also ohne Panik und in Ruhe den Server einrichten. Und oberflächlich recherchiert scheint alles zu gehen, was ich haben will. Vielleicht gehen noch das eine oder andere Extra, aber meine Grundanforderungen scheinen sich umsetzen zu lassen.

Hardware

Fangen wir also mit dem Einfachsten an, der Hardware. Ich benötige eine TV-Karte, die auch von Linux unterstützt wird. Dies ist nicht schwer, bedarf aber gewisser Vorsicht. Ist die Karte zu neu, sind deren Treiber noch nicht im Linux-Kernel enthalten. Dann kann die Einbindung der Karte zu einem Abenteuer werden.

Ich benutze zur Zeit Debian 9 (Stretch), und der läuft mit dem Kernel 4.9. Also sollte es eine TV-Karte sein, die vorzugsweise schon Treiber in diesem Kernel hat. Weiter sollte es eine TV-Karte mit 2 Tunern sein. Klingt erst mal schwer, war es dann aber nicht.

Ich habe mich für eine DVBSky T982 V2 entschieden. Diese hat zum Zeitpunkt des Kaufs 94,90 € gekostet. Diese hat einen Dualtuner, ist für DVB-C, also Kabel, und auch für DVB-T/T2 ausgelegt und hat bereits seit Kernel 3.19 Treiber enthalten.

Die Installation ist denkbar einfach. Zunächst muss man von der Herstellerseite die Firmware für diese Karte herunterladen. Linux hat zwar bereits die Treiber, benötigt aber die Firmware, damit sie korrekt funktionieren kann. Der Vorteil ist, die Firmware ist denkbar einfach zu installieren.

Zunächst geht man also auf die Support-Seite von DVBSky und lädt sich dort die Firmware herunter. Das ist eine sehr kleine ZIP-Datei, die bereits alle Firmware-Dateien des Herstellers beinhaltet. Man muss also nicht umständlich nach der Firmware eines bestimmten Gerätes oder einer bestimmten Karte suchen.

Diese ZIP-Datei habe ich nun ausgepackt und auf mein Home-Verzeichnis auf dem Server kopiert. Da ich mein Home-Verzeichnis auf meinem Laptop als Laufwerk eingebunden habe, geht das mit Windows-Bordmitteln hervorragend.

Nun habe ich in meinem Home-Verzeichnis also einen Ordner, in dem einige Dateien mit der Endung FW liegen, eine Readme-Datei, die mir sagt, was ich damit machen muss und ein kleines Shellscript. Abgekürzt, alle Dateien mit der Endung FW sind Firmware-Dateien. Diese müssen in /lib/firmware kopiert werden. Man könnte dies nun per Hand tun, braucht man aber zum Glück nicht, denn dafür ist das kleine Shellscript da. Dieses kopiert alle Firmware-Dateien dort hin, wo sie hingehören.

Man verbindet sich also per SSH mit seinem Server und gibt dort folgende Befehle ein:

cd firmware
sudo ./copy-firmware.sh

Alles in allem sind die Firmware-Dateien keine 100 Kilobyte groß, also macht es auch nichts, wenn alle kopiert werden. Und dieses Shellscript copy-firmware.sh tut dies! Das vorangestellte „sudo“ ist nötig, da man sonst keine Schreibrechte auf /lib/firmware hat.

Fertig, die Software für die Karte ist damit installiert. Nun braucht man nur noch den Server abschalten, die Karte einbauen und den Server wieder hochfahren.

Einbau

Bei der DVBSky T982 V2 handelt es sich um eine Low Profile Karte. Das heißt, sie ist sehr niedrig und für schmale Gehäuse gedacht. Daher würde sie so, wie sie aus dem Karton kommt, nicht in das Gehäuse passen. Die Rückblende der Karte muss ausgetauscht werden. Die passende Rückblende für normalgroße PC-Gehäuse liegt der Verpackung bei. Man muss also erst mal die 2 kleinen Schräubchen lösen und die neue Blende anbringen und festschrauben. Dies bedarf einiger Fingerfertigkeit, weil die Schräubchen echt klein sind. Man kann aber, wenn man keine rohe Gewalt anwendet, dabei nichts kaputt machen.

Nun habe ich die Karte in einen der freien PCIe-Slots eingesetzt und festgeschraubt. Auf der Rückseite des Servers habe ich jetzt 2 Eingänge für Antennenkabel, ob nun DVB-C oder DVB-T/T2. Die Tuner können beides.

Prüfen

Es gibt sicher eine Menge Wege zu prüfen, ob die Karte vernünftig eingebaut wurde. Ich lasse mir einfach anzeigen, ob der Kernel einen Device-Eintrag generiert hat. Würde die Karte nicht funktionieren, würde das nicht gehen. Zumindest mal oberflächlich reicht es.

Hierfür zeige ich einfach das Verzeichnis an, welches zum Gerät führt:

ls -l /dev/dvb

Bevor die Karte eingebaut war, gab es dieses Verzeichnis nicht. Da löste dieser Befehl eine Fehlermeldung aus. Nun aber sehe ich folgendes:

total 0
drwxr-xr-x 2 root root 120 Oct 23 17:06 adapter0
drwxr-xr-x 2 root root 120 Oct 23 17:06 adapter1

Wie man hier sehr schön sehen kann, hat jeder der beiden Tuner seinen eigenen Gerätepfad. Somit tauchen die beiden Tuner als separate Geräte auf.

Weiteres

In der Verpackung der TV-Karte war noch ein IR-Sensor und eine Fernbedienung. Würde man diese Karte also in einen Mediacenter-PC einbauen, könnte man diesen hierüber steuern. Ein Anschluss für den Sensor gibt es hinten an der TV-Karte. Dies brauche ich aber nicht, ich erwähne es nur der Vollständigkeit halber.

Kabel verlegen und anschließen

Nun ziehe ich ein Antennenkabel von der Kabeldose im Wohnzimmer bis zum Server. Hierfür habe ich mir dieses 20 Meter Antennenkabel von CSL gekauft. Das reicht aber nicht, ihr braucht noch ein T-Stück und 2 weitere kurze Antennenkabel, damit ihr auch beide Tuner anschließen könnt. Diese habe ich bereits, weil ich diese ja auch schon für die Dreambox benötige. Falls ihr also so ein T-Stück noch sucht, könnte ich euch diesen Hama Antennenverteiler empfehlen. Damit könnt ihr beide Eingänge der TV-Karte anschließen, so dass ihr auch 2 Sendungen gleichzeitig aufzeichnen könnt.

Das war erst mal der Hardware-Teil, der war, zumindest für mich, ja noch einfach zu bewältigen. Nun kommt völliges Neuland, die Software. Ich bin ja seit Jahren Dreambox-verwöhnt, mal sehen, was nun passiert!

Software

Damit der Server auch als Recorder funktionieren und TV zu meinem Kodi Mediacenter streamen kann, braucht es Software und jede Menge Plugins. Ich werde hierfür VDR (Video Disk Recorder) nutzen. Diesen gibt es schon sehr lange für Linux. Abgesehen davon gibt es viel Dokumentation und Hilfe im VDR-Wiki und im entsprechenden Forum VDR-Portal.

Ich werde zunächst nur die benötigte Software installieren. Um die Konfiguration und Erweiterbarkeit kümmere ich mich so nach und nach.

VDR installieren

Nun, wie man Pakete installiert, habe ich in den vorangegangenen Teilen ja schon ausführlich erwähnt. Also installiere ich VDR wie folgt:

sudo apt-get install vdr

Je nach bisher installierten Paketen werden noch ein paar zusätzliche Pakete installiert.

Während der Installation werden noch ein paar Fragen gestellt. Als erstes geht ein Fenster auf, welches darüber informiert, dass VDR standardmäßig die Aufnahmen in /var/lib/video speichert. Man könne das später ändern. Die Frage lautet also, ob man das Verzeichnis, wie es vorgeschlagen wird, erstellen möchte. Hier wähle ich „Yes“ aus. Das kann ich später alles noch ändern.

Als nächstes wird nach der Art der TV-Karte gefragt. Da ich DVB-C nutze, wähle ich „Cable“ aus dem Menü aus.

Anschließend läuft die Installation der Pakete durch und VDR ist erst mal installiert.

Nun braucht es noch einige Plugins, damit gewisse Funktionalitäten vorhanden sind. Zum Beispiel braucht es eine Weboberfläche, Kodi-Unterstützung und so einiges weitere.

Kodi-Unterstützung

Damit ich auf das Live-TV und die Aufnahmen auch vom Mediacenter Kodi aus zugreifen kann, braucht es ein Plugin für Kodi und eines für den VDR. Um Kodi und seine Konfiguration kümmere ich mich später, nun muss erst mal das Plugin für VDR installiert werden.

sudo apt-get install vdr-plugin-vnsiserver

In Kodi muss später noch der VDR-VNSI-Client installiert werden.

Weboberfläche

Um VDR mittels eines Webbrowsers nutzen und steuern zu können, muss das Plugin VDR-Live installiert werden.

sudo apt-get install vdr-plugin-live

Wie man hierauf nun zugreift und es nutzt sehen wir uns später an.

EPG-Suche

Das Plugin EPG-Search erweitert die Suchmöglichkeiten innerhalb des EPG und kann Aufnahmen basierend auf Suchkriterien erstellen. Das wäre z. B. so eine Autotimer-Option.

sudo apt-get install vdr-plugin-epgsearch

Web-Administrationstool für VDR

Ich muss zugeben, so ganz genau weiß ich nicht, was dieses Plugin zusätzlich tut. Ich habe mir ja noch nicht angesehen, was sich über die Live-Oberfläche machen lässt. Von der Beschreibung gehe ich aber aus, dass sich hier viel weitreichendere Einstellungen des VDR vornehmen lassen. Daher installiere ich das mal. Sollte es sich als falsch erweisen, kann ich es ja immer noch deinstallieren.

sudo apt-get install vdradmin-am

Streamen

Damit man auch mittels Webbrowser TV-Programme streamen kann, falls man das mal möchte, muss der Streamdev-Server installiert werden.

sudo apt-get install vdr-plugin-streamdev-server

Nun kann man z. B. mit dem Firefox das aktuelle TV-Programm streamen.

Nachtrag

Es ist mir bisher nicht gelungen, mit der Weboberfläche das aktuelle Programm mit dem VLC zu streamen. Vielleicht fehlt noch was, aber darum kümmere ich mich in der nächsten Zeit mal. Einen Hinweis, wie ich es gelöst habe, wird es dann im Blog geben.

OSD fernsteuern

Der VDR ist eigentlich eine Anwendung, die lokal betrieben wird. Also werden auch alle Einstellungen auf einem OSD, also über ein Menü am eigentlichen Bildschirm getätigt. Nun läuft VDR hier aber auf einem Server und ein Bildschirm ist nicht angeschlossen. Wie kommt man nun also an die Einstellungen ran? Nun, dafür gibt es einen Weg, den ich in diesem Blogbeitrag gefunden habe. Der Weg ist recht umfangreich, und ob er überhaupt für mich mit Screen Reader und Braillezeile funktioniert, muss sich noch herausstellen. Ihr müsst den langen Beitrag jetzt nicht lesen, wir gehen das nach und nach durch. Ich installiere aber erst mal die benötigten Pakete.

sudo apt-get install vdr-plugin-remote vdr-plugin-svdrposd vdr-plugin-svdrpservice

Kanalsuche

VDR selbst sucht eigentlich nicht nach Kanälen. Jedenfalls ergibt sich das aus den Texten, die ich im VDR-Wiki und in den Foren so lese. VDR greift auf die channels.conf zu, die aber erstellt werden muss. Zwar hat VDR bei der Installation schon eine channels.conf installiert, aber wie aktuell diese ist, lässt sich nicht sagen. Also braucht es ein Tool, um die Sender zu scannen und die channels.conf zu erzeugen.

sudo apt-get install w-scan

Hiermit können die Sender gesucht und die channels.conf erzeugt werden.

Als nächstes…

Im nächsten Teil werde ich VDR konfigurieren. Ein anderes Aufnahmeverzeichnis muss erstellt werden, die Grundeinstellungen vom VDR müssen gemacht werden, meine bisherigen Autotimer von der Dreambox müssen irgendwie in den VDR und so weiter und so fort.

Auch, wenn es erst mal kompliziert klingt, scheint es doch ganz problemlos zu laufen. Ich bin von den Fertiglösungen, wie der Dreambox, verwöhnt, daher ist es erst mal ungewohnt, alles einzeln per Hand zu tun. Und manchmal weiß ich auch nicht, wo ich jetzt anfangen oder weitermachen soll.

Ich werde zu diversen Dingen erst mal noch die Manpages lesen, damit ich weiß, wo sich was wie einstellen lässt. Dann sehen wir weiter. Ich denke aber, als erstes dürfte ein Sendersuchlauf auf dem Programm stehen.

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

Projekt Homeserver im Eigenbau 11: Geplante Aufgaben mit cron

Was auch sehr wichtig ist, sind wiederkehrende Aufgaben. Das ist das, was man unter Windows wohl die Tasks, oder die geplanten aufgaben nennt. Am Server sind sie daher sehr nützlich, da sie immer wiederholte Aufgaben ausführen können, ohne dass ein Administrator etwas dazu tun muss.

Hierfür ist „cron“ zuständig, der die Aufgaben jeweils abarbeitet. Um einen „cron job“ zu erstellen, braucht man eigentlich nur eine Datei editieren, die sogenannte crontab. Jeder Benutzer kann seine eigene Crontab haben, aber weil dies ein Server ist, nutzen wir die systemweite Crontab.

sudo nano /etc/crontab

Damit wäre die Datei offen. Übrigens muss die Crontab mit einem # (Nummernzeichen) enden, oder mit einer Leerzeile. In diesem Falle endet sie mit einem Nummernzeichen.

Geht mit den Pfeiltasten bitte zeilenweise runter, bis ihr zu den Zeilen kommt, die mit „SHELL=“ und „PATH=“ anfangen. Darunter schreibt ihr die Zeile:

MAILTO=root

Wenn es bei der Ausführung der Jobs nun zu Fehlern kommt, erhaltet ihr eine Mail mit dem Inhalt der Fehlermeldung. Ich habe das mal mit einem fehlerhaften Script probiert. Es kommt dann tatsächlich eine Mail mit dem Betreff „cron /home/kamil/fehlerscript.sh“. Im Text steht dann die eigentliche Fehlermeldung. Das war zu erwarten, weil ich im Script absichtlich einen falschen Befehl eingegeben hatte. 🙂

Weiter unten beginnt die Liste mit den einzelnen Jobs. Hier sind auch schon einige Aufgaben eingetragen. Man kann hier recht einfach sehen, welche Struktur jede Zeile haben muss:

  • m: Minuten
  • h: Stunden

Wenn also m und h die Werte 30 10 haben, so wird die Aufgabe um 10:30 Uhr ausgeführt.

  • dom: Tag des Monats, also am wievielten des Monats der Task ausgeführt werden soll.
  • mon: An welchem Monat soll der Task ausgeführt werden
  • dow: Tag der Woche, 1, Montag, bis 7, Sonntag.
  • user: Unter welchem Benutzer soll der Befehl ausgeführt werden?
  • command: Der Befehl, der ausgeführt werden soll.

Die einzelnen Elemente können durch Leerzeichen oder Tabstops voneinander getrennt werden.

Zwei Beispiele

Der NTP-Dienst synchronisiert die Uhrzeit des Systems mit einem Internet-Server, wenn der Server neu gestartet wird. Was ist aber, wenn der Server mehrere Wochen lang läuft? Dann kann man eben einen Cron Job einrichten, der das Problem löst. Ein solcher könnte so aussehen:

30 7    * * 1   root    ntpd -q -g

Dieser Job synchronisiert die Systemzeit jede Woche am Montag um 7:30 Uhr. Der Befehl ntpd -q -g erledigt das. Und der Befehl wird als root, also als Admin, ausgeführt.

Und jetzt kommen wir mal zu einer Besonderheit: Linux setzt die Systemzeit nämlich nur im laufenden Betrieb. Die Hardware-Uhr, die sich auf dem Mainboard befindet und per Batterie weiter betrieben wird, wenn der Rechner aus ist, wird nicht angerührt. Ist diese also falsch, und schaltet man den Rechner ein, startet man den Rechner mit einer falschen Uhrzeit. Das kann, wenn die Differenz zur tatsächlichen Zeit größer als 1000 Sekunden ist, zu Problemen führen. Dann kann es nämlich passieren, dass NTP die Zeit nicht synchronisiert. Jedenfalls habe ich die Informationen, die ich darüber gelesen habe, so verstanden. Daher müssen wir von Zeit zu Zeit auch die Hardware-Uhr nachstellen. Auch dies kann ein Cron Job tun:

31 7    * * 1   root    hwclock --systohc

Wie ihr seht, wird eine Minute nach der Zeitsynchronisation die Hardware-Uhr nachgestellt. Nun brauche ich mich nicht mehr darum kümmern, weil das alles jetzt jeden Montag um 7:30 Uhr passiert.

Übrigens habe ich mir mal die Crontab meines QNAP NAS angesehen. Auch hier befindet sich ein Cron Job, der die Systemzeit jeden Tag sogar in die Hardware-Uhr schreibt. Und noch etwas ist mir dabei aufgefallen. Während ich die S.M.A.R.T. Tests in der Konfigurationsdatei smartd.conf geplant habe, ist hier für jede Platte in der Crontab ein Job hinterlegt. Kann man auch machen, aber ich überlasse das lieber dem smartd-Dienst.

Ausführen von Scripts

Auch das kann man zeitgesteuert machen. Hier mal ein kleines Beispiel. Ich lege ein Script mit der Datei „dateikopieren.sh“ an und schreibe folgendes da rein:

#!/bin/bash
cp /etc/crontab /home/kamil/Server
cp /etc/samba/smb.conf /home/kamil/Server

Dieses Script liegt nun in meinem Home-Verzeichnis. Nun muss es also von Cron nur noch ausgeführt werden. Ich möchte, dass jeden Freitag um 18:00 Uhr diese Dateien gesichert werden. Also lautet die Zeile in crontab wie folgt:

00 18   * * 5   root    /home/kamil/dateikopieren.sh

Fazit

Insbesondere das letzte ist wirklich nur ein Beispiel. Das Script zur Sicherung meiner Konfigurationsdateien führe ich in größeren Abständen selbst aus. Das sollte nur illustrieren, dass, und wie es geht. So kann man auch komplexere Aufgaben zeitlich steuern.

Die beiden Zeilen für die Zeitsynchronisation habe ich tatsächlich so in meiner crontab stehen. Manche machen das öfter, aber ich denke, ein Mal die Woche reicht völlig.

Übrigens ist zu bedenken, dass der Server zum Zeitpunkt der Ausführung laufen muss. Denn cron kann keine Jobs nachholen. Er wird also erst zum nächsten Ausführungstermin wieder ausgeführt.

Falls mir in der Zwischenzeit keine wichtigen Themen mehr einfallen, kommt als nächstes das Einrichten des RAIDs. Und da mir hierzu noch Festplatten fehlen, kann das noch ein Weilchen dauern. Habt etwas Geduld, es geht hier noch weiter. 🙂

Projekt Homeserver im Eigenbau 10: Der Dateiserver Samba

Der Samba Server ist vielleicht einer der wichtigsten Teile des Servers überhaupt. Letztlich wird der gesamte Dateiaustausch zwischen dem Server und Windows-Rechnern hierüber abgewickelt. Sogar mein XBMC-Mediacenter oder mein MacBook können über das SMB-Protokoll auf den Server zugreifen.

In diesem Beitrag geht es daher ausschließlich um Samba, dessen Grundkonfiguration und das Einrichten einer Freigabe, auf die von einem Windows-Rechner aus zugegriffen werden kann.

Geht mal an euren Windows-Rechner, drückt Windowstaste+R und gebt in das Dialogfeld mal folgendes ein:

\server01

Es wird zwar ein Fenster aufgehen, aber es wird leer sein. So, wie Samba zur zeit konfiguriert ist, werden wir auf keine Daten des Servers zugreifen können.

Samba konfigurieren

Um den Samba-Dienst zu konfigurieren, öffnen wir die Konfigurationsdatei von Samba.

sudo nano /etc/samba/smb.conf

Geht jetzt mit den Pfeiltasten zeilenweise durch die Datei. Hier sind in kommentierten Zeilen die Optionen einzeln erläutert. Stellt ein, was ihr für nötig haltet. Aber im Grunde ist erst mal nur eine Option wirklich wichtig:

workgroup: Tragt hier die Arbeitsgruppe eures Heimnetzwerks ein. Bei mir ist das „KAMIL“. Die Zeile sieht dann so aus:

workgroup = KAMIL

Um euch mal einen Überblick darüber zu verschaffen, welche Optionen in der smb.conf noch alles eingestellt werden können, könnt ihr euch mal die Manpage zu smb.conf ansehen.

Das Home-Verzeichnis als Freigabe

Um auf unser Home-Verzeichnis auch von Windows aus zugreifen zu können, damit wir z. B. Dateien davon sichern oder welche hochladen können, muss am Ende der Konfigurationsdatei ein Block mit diversen Parametern angefügt werden. Die Freigabe meines Home-Verzeichnisses sieht dann so aus:

[Home]
path = /home/kamil
comment = Home-Verzeichnis
browseable = yes
writeable = yes
create mask = 0775
directory mask = 0775
force user = kamil

So, nun noch mit STRG+X die Datei speichern und das Überschreiben bestätigen.

Und hier mal eine Beschreibung, was jede der Optionen eigentlich tut:

  • [Home]: In eckigen Klammern kommt der Freigabename, wie er später auch angezeigt wird.
  • path = /home/kamil: Das ist der Pfad zu dem Verzeichnis, welches ich freigeben möchte. In diesem Falle ist das mein Home-Verzeichnis.
  • comment = Home-Verzeichnis: Ein Kommentar oder Beschreibung, die ebenfalls in der Auflistung der Freigaben zumindest als Tooltip angezeigt werden.
  • browseable = yes: Die Freigabe soll in Auflistungen angezeigt werden und man soll sich den Inhalt der Freigabe anzeigen lassen können.
  • writeable = yes: Standardmäßig sind Freigaben schreibgeschützt, damit macht man sie auch beschreibbar.
  • create mask = 0775 und directory mask = 0775: Das sind die Standard-Dateiattribute, die den Dateien beim Erstellen zugewiesen werden. Das gilt für Dateien und Verzeichnisse.
  • force user = kamil: Dateien, die erstellt werden, gehören dem Benutzer Kamil.

Nach diesem Schema werden alle Freigaben nacheinander erstellt.

Mit dem Befehl „sudo service samba restart“ können wir den Samba Dienst neu starten, ohne den ganzen Server neu starten zu müssen. Und sofort danach steht uns auch die Freigabe zur Verfügung. Wir können da aber jetzt noch nicht rein, da Samba uns noch nicht kennt. Die Samba Benutzerverwaltung ist getrennt von der Benutzerverwaltung in Linux selbst. Um also als Benutzer kamil auch über Samba reinzukommen, müssen wir dem Samba Server noch den User kamil hinzufügen. Der User muss aber auf dem Server schon als normaler Linux-User angelegt sein, was bei kamil ja der Fall ist:

sudo smbpasswd -a kamil

Anschließend werden wir noch nach unserem Passwort gefragt, dann noch mal wiederholen, fertig. Jetzt können wir auch über Windows zugreifen. Das Samba-Passwort muss übrigens nicht unbedingt das gleiche sein, wie das Linux-Passwort.

Einfach mal mit Windows+R wieder ins Ausführen-Dialog gehen und folgendes reinschreiben:

\server01

Nun ist das Fenster nicht mehr leer, sondern enthält die Freigabe „Home“. Öffnen wir diese mit Enter, werden wir nach Benutzername und Passwort gefragt. Hier geben wir dann die Werte ein, die wir am Server zuvor festgelegt hatten beim Erstellen des Samba-benutzers.

Sinnvoll ist es hier, weil wir ja öfter mal zugreifen wollen, diesen Ordner als Netzwerk-Laufwerk zu speichern. Aber wie das geht, soll hier nicht weiter besprochen werden.

Was kommt nun?

Leider erst mal nichts mehr. Um weiteres anstellen zu können, brauche ich das RAID. Aber dafür fehlen mir noch ein paar Festplatten. Ich will ja mindestens ein RAID5 einrichten, und dafür benötige ich mindestens 3 Platten. Also gibt es leider erst dann wieder was zu lesen, wenn ich alle nötigen Platten habe, um das RAID aufzubauen.

Oh, Moment, da fällt mir ein, im nächsten Teil kann ich euch mal die crontab erklären, die ist für die Administration des Servers nämlich sehr hilfreich.

Projekt Homeserver im Eigenbau 8: Kernel aktualisieren

Na toll! Eher so zufällig fällt mir auf, dass wir hier unter einem völlig veralteten Kernel arbeiten! Und ich dachte, wenn ich Debian 7.6.0 installiere, wird der aktuellste Kernel installiert? Nun, entweder habe ich bei der Installation was falsch gemacht, oder es wird tatsächlich nur ein veralteter Kernel installiert.

Um herauszubekommen, welcher Kernel derzeit installiert ist, gibt man den folgenden Befehl ein:

uname -r

Dann kommt eine Ausgabe wie diese hier:

3.2.0-4-amd64

Das ist der Kernel, der bei mir auf dem Server läuft, und der ist schon ein paar Tage alt. Wir sind doch jetzt schon irgendwo bei 3.17 oder zumindest mal 3.16? Gerade wegen der Hardware muss ich eigentlich den aktuellen Kernel installieren.

Ist ein Kernelupdate nötig?

Darüber streiten sich die Geister. Kurz gesagt, es passiert auch nichts schlimmes, wenn man es nicht tut. Andererseits, ich habe einen teuren Haswell-Prozessor und einen neuen Chipsatz eingebaut, dessen Funktionen ich auch gerne nutzen möchte. Zwar wird der Rechner auch mit dem 3.2er Kernel laufen, aber es könnte gut sein, dass manche der neuen Funktionen nicht optimal genutzt werden. Zum Beispiel bringt der Haswell neue Ruhemodi mit, wobei ich nicht weiß, ob er sich selbst bei Inaktivität in diese versetzt, oder vom Kernel in diese versetzt werden muss. Neue Prozessoren bringen oft neue Befehlssätze mit, die vom alten Kernel evtl. noch nicht unterstützt werden.

Nachdem ich den Kernel aktualisiert hatte, bootete der Rechner bedeutend schneller. Klar ist das kein Beweis dafür, dass der neue Kernel besser ist. Aber es ist doch ein Indiz. Es zeigt mir halt, dass die höheren Durchsatzraten des Chipsatzes oder eine ausgereiftere Multikern-Unterstützung eingesetzt wird. Zumindest vermute ich das.

Das ist das Problem, Sicherheit und Stabilität sind eine Sache, Aktualität eine andere. Ubuntu aktualisiert in meinen Augen zu oft, so dass man ständig sich um das System kümmern muss, Debian aktualisiert zu selten, so dass man mit neuer Hardware hinterherhinkt. Die Wahrheit, oder besser gesagt das Optimum, liegt wahrscheinlich irgendwo in der Mitte… Wie auch immer, ich werde den Kernel aktualisieren. Ob ihr das auch machen möchtet, könnt ihr ja anhand eurer Hardware entscheiden. Sollte es ein neuerer Rechner sein, würde ich aktualisieren, ist es eher ein älteres Modell, wird es wohl eher nicht nötig sein.

Editieren von Konfigurationsdateien

Das ist eine Aufgabe, die wir noch öfter machen müssen. Viele bevorzugen den Editor VI, aber ich kann dem absolut nichts abgewinnen. Total kompliziert und unhandlich. Ich bevorzuge Nano, der sich genau so benimmt, wie man es von einem Editor irgendwie erwartet…

Hier kommen jetzt ein paar Probleme zum Tragen, die sonst eher zu vernachlässigen sind. Ich benutze Putty mit Jaws. Der tatsächliche Cursor und der auf der Braillezeile angezeigte Cursor sind nicht gleich. Tatsächlich ist es so, dass der tatsächliche Cursor 1 oder 2 Felder links des Cursors ist, der auf der Braillezeile angezeigt wird. Das ist nicht schlimm, aber man muss es wissen, sonst löscht man evtl. die falschen Zeichen. Bis ihr euch daran gewöhnt habt, arbeitet hier sehr vorsichtig.

Die wichtigsten Tastenkombinationen für Nano sind am unteren Bildschirmrand angezeigt. Hier wird fast nur mit der STRG-Taste gearbeitet. STRG+X z. B. schließt den Editor und fragt gegebenenfalls nach, ob Änderungen gespeichert werden sollen.

Hinzufügen von Paketquellen

Debian holt sich ja Pakete von seinen Paketquellen. Hier liegen die Dateien, die für die Installation von Programmen nötig sind. Die neuen Kernel, ist jetzt das Plural kernels?, liegen in einem eigenen Repository, den Backports. Backports sind Rückportierungen. Neuere Pakete, wie z. B. eine neuere Kernelversion, werden so angepasst, dass sie auch unter einer älteren Distribution arbeiten. So muss der Kernel 3.16 z. B. rückportiert werden, damit er mit der Debian 7.6.0 Distribution kompatibel ist.

Also muss das Repository der Backports auch dem Server mitgeteilt werden, damit er auch dort nach Paketen sucht.

Die Liste der Paketquellen ist eigentlich eine simple Textdatei, in die wir nur 3 Zeilen einfügen müssen. Also öffnen wir die Datei im Editor Nano mit folgendem Befehl:

sudo nano /etc/apt/sources.list

Den Rest der Datei lassen wir mal ganz in Ruhe, das sind die Paketquellen, woher Debian ohnehin seine Pakete holt. Das ist ja in Ordnung, wir wollen unten nur 3 Zeilen hinzufügen. Mit den Pfeiltasten gehen wir also ganz runter, und geben dort folgende Zeilen ein:

# Backports Paketquellen
deb http://ftp.de.debian.org/debian/ wheezy-backports main contrib non-free
deb-src http://ftp.de.debian.org/debian/ wheezy-backports main contrib non-free

Ihr könnt die Zeilen auch markieren und kopieren. Um sie in das Putty-Fenster einzufügen, wechselt dann in dieses, zieht die Maus zum Cursor und drückt dann auf der Maus die rechte Maustaste. Dann wird die Zwischenablage ins Putty-Fenster eingefügt. Das könnt ihr auch mit Befehlen machen.

Mit STRG+X schließen wir den Editor. Nano fragt noch, ob er die Datei überschreiben soll, ich antworte mit „y“, ich hab ja alles noch in Englisch. Der Dateiname wird mir angezeigt, auch hier drücke ich Enter, fertig! Wir haben erfolgreich eine Paketquelle hinzugefügt.

Den neuen Kernel installieren

Mit dem schon bekannten Befehl

sudo apt-get update

aktualisieren wir eben noch schnell die Paketliste. Um den Kernel nun aber installieren zu können, müssen wir apt-get explizit mitteilen, dass wir das Paket aus dem Backports-Repository haben wollen. Mit folgendem Befehl wird der Kernel installiert:

sudo apt-get install -t wheezy-backports linux-image-amd64 linux-headers-amd64

Es werden nun eine Menge Pakete installiert. Wie ich schon sagte, auch Pakete, von denen der Kernel abhängig ist, werden mit installiert.

Nun muss noch mit sudo reboot der Rechner neu gestartet werden.

Und wenn wir uns jetzt wieder am Server anmelden und wieder mit uname -r die Kernel-Version abfragen, erhalten wir folgende Ausgabe:

3.16-0.bpo.2-amd64

Das sieht doch schon wesentlich besser aus! nachdem wir das gerettet haben, kann’s ja normal weitergehen. 🙂

One more thing…

Also einer meiner besten Freunde ist Kumpel Zufall! Ich suche ja schon nach einer Möglichkeit, auch ohne Monitor zu wissen, wann der Server nun hochgefahren ist. Und beim relativ unmotivierten Herumsurfen bin ich regelrecht über die Lösung gestolpert.

Die Linux Kommandozeile kennt tatsächlich einen einfachen Befehl, den PC-Lautsprecher piepsen zu lassen. Gedacht ist das für Skripte, und genau für so was nutzen wir den jetzt. Gebt mal in der Eingabeaufforderung „beep“ ein. Passiert nix? OK, dann müssen wir das eben noch nachinstallieren:

sudo apt-get install beep

Nun müssen wir eine Datei editieren, die sich rc.local nennt. Wer noch mit DOS-Begriffen was anfangen kann, das ist so was wie die autoexec.bat. 🙂 Nachdem alle Dienste und Systemkomponenten gestartet sind, wird diese Datei ausgeführt. Was hier drin steht, kommt also als letztes dran. Das bietet sich ja geradezu an, oder? 🙂

sudo nano /etc/rc.local

Damit wäre die Datei offen. Geht nun mit den Pfeiltasten ganz bis an das Ende der Datei. Als letzte Zeile steht da:

exit 0

Genau über diese Zeile schreiben wir jetzt den Beep-Befehl rein, so dass die beiden letzten Zeilen so aussehen:

beep -f 800 -l 500
exit 0

Nun noch mit STRG+X die Datei speichern, fertig.

Der Parameter -f legt die Frequenz des Tons fest, der parameter -l die Länge. Probiert auf der Konsole ruhig erst mal ein paar Variationen aus, aber ich finde, diese Kombination ist so ganz in Ordnung. Beep ohne Parameter gibt einen viel tieferen und kürzeren Ton aus. Ich finde, der ist etwas zu leise und könnte leicht überhört werden.

Gebt mal „sudo reboot“ ein, um den Rechner neu zu starten. Wenn er fertig hochgefahren ist, wird als letztes der Piepton abgespielt. Nun braucht man nicht mehr raten, wann der Server bereit ist!

Projekt Homeserver im Eigenbau 7: Schreiben von Bash-Scripts

Weil das später vielleicht noch öfter vorkommt, und weil das auch ganz sinnvoll ist, seine Konfigurationsdateien zu sichern, will ich mal kurz auf die Shellscripts eingehen. Im Grunde sind Shellscripts nichts anderes als kleine Textdateien, in denen eine Sammlung von Befehlen stehen. Ganz ähnlich der Batch-Dateien, die unter Windows auch noch gelegentlich eingesetzt werden. Allerdings sind Shellscripts bedeutend mächtiger. Ich habe schon welche gesehen, die Programme installieren, und nach genauer Überprüfung sogar Konfigurationsdateien editieren können. Wer sich eingehend mit den Möglichkeiten von Linux auseinandersetzt, kann hier durchaus hochkomplexe Programme schreiben.

Das ist jetzt aber nicht das, was ich machen möchte. Ich möchte, dass meine Scripte auf Knopfdruck Konfigurationsdateien kopieren oder Pakete nachinstallieren können. Und das ist mit ein paar simplen befehlen gemacht.

Aufbau des Scripts

Jede Zeile, die mit einem # (Nummernzeichen) beginnt, ist ein Kommentar. Unterschätzt das nicht, in ein paar Jahren wisst ihr vielleicht nicht mehr genau, was ein bestimmter Befehl eigentlich tun sollte, daher kommentiert das nach Möglichkeit. Vielleicht habt ihr den Script auch einfach nur einem Bekannten gegeben, der weiß dann nicht, was ihr damit machen wolltet. Nutzt das also ausgiebig.

Jedes Script beginnt mit einem Shebang. Jetzt fragt mich aber nicht, wer auf den merkwürdigen Namen gekommen ist. Aber was es ist, kann ich euch erklären.

Jedes Script wird von einem Interpreter ausgeführt. Dieser kennt die befehle und tut, was im Script steht. Ich meine zwar, auch mal Scripte gesehen zu haben, wo diese erste Zeile fehlt, aber verschiedene Interpreter kennen unterschiedliche Befehle. Daher sollte man diese Zeile auch festlegen. ich verwende immer Bash als Interpreter, daher beginnen meine Scripte alle mit der Zeile:

#!/bin/bash

Ein kleines Script

Schreiben wir doch also einfach mal unser erstes kleines Script. Dieses soll die Konfigurationsdatei für das Netzwerk in das Unterverzeichnis „Server“ in unserem Home-Verzeichnis kopieren.

Zunächst legen wir das Verzeichnis an mit dem Befehl:

mkdir Server

Hier werde ich jetzt alle Konfigurationsdateien, die ich je ändere, reinkopieren lassen, damit ich diese auf einen USB-Stick kopieren kann. Heute soll es aber erst mal nur die Konfiguration des Netzwerks sein.

Öffnen wir also einen Editor, und zwar Nano, mit der Scriptdatei. Die gibt es zwar noch nicht, Nano legt die dann aber an.

nano filecopy.sh

Da wir ja in unserem eigenen Home-Verzeichnis arbeiten, braucht es keine Admin-Rechte und deshalb auch kein sudo vor den Befehlen.

Und nun schreiben wir folgendes in die offene Datei hinein:

#!/bin/bash

## Konfigurationsdateien kopieren

# Konfigurationsdatei für das Netzwerk kopieren
sudo cp /etc/network/interfaces ~/Server

Wie ihr sehen könnt, habe ich alle Aktionen und den Grund des Scriptes in Kommentaren eingefügt. Die letzte Zeile ist der eigentliche Kopierbefehl.

Nun drücken wir STRG+X um Nano zu schließen. Wir werden gefragt, ob wir die Datei erstellen wollen, noch mal den Namen bestätigen, fertig! Unser erstes Script ist da. Aber es kann noch nicht genutzt werden.

Script ausführbar machen

Mit dem Befehl „ls -l“ könnt ihr euch das Inhaltsverzeichnis des Verzeichnisses anzeigen. Da wir ja im Home-Verzeichnis stehen, sehen wir dann folgendes:

total 8
-rw-r--r-- 1 kamil kamil  139 Oct 17 15:14 filecopy.sh
drwxr-xr-x 2 kamil kamil 4096 Oct 17 15:13 Server
kamil@server01:~$

Uns interessiert die obere Zeile, die für die Datei filecopy.sh. Ich werde mal die einzelnen Abschnitte erklären:

  • -rw-r--r--: Das sind die Zugriffsrechte. Der Benutzer darf lesen und schreiben (rw-), die Gruppe und jeder andere dürfen nur lesen (r--). Der erste Bindestrich zeigt, dass es eine Datei ist, Stünde da ein kleines d, wäre es ein Verzeichnis. Das könnt ihr leicht in der Zeile mit dem Verzeichnis „Server“ sehen.
  • 1: Ist nur eine Datei, wäre es ein Verzeichnis, könnte man die Anzahl darin befindlicher Dateien sehen.
  • kamil kamil: Benutzer, Gruppe. Ja, kamil ist auch eine Gruppe, weil jeder Benutzer beim Anlegen auch eine gleichnamige Gruppe angelegt bekommt.
  • 139: Größe der Datei.
  • Oct 17 15:14: Datum, ist ja offensichtlich. 🙂
  • filecopy.sh: Ein Keks! Nee, quatsch, natürlich der Dateiname selbst. 🙂

Sieht auch erst mal komplizierter aus, als es tatsächlich ist. Aber ich habe das so ausführlich gemacht, weil das noch öfter gebraucht wird. Schließlich will man ja mit Dateien arbeiten.

OK, jetzt müssen wir die Datei aber noch ausführbar machen:

chmod +x filecopy.sh

Jetzt gucken wir uns die Zeile doch nochmal an:

-rwxr-xr-x 1 kamil kamil  139 Oct 17 15:14 filecopy.sh

Das x zeigt jetzt an, dass die Datei ausführbar ist. Nun können wir sie mal testen.

Aufruf eines Scripts

Unser Script ist nun bereit, ausgeführt zu werden. Jedes Script wird aus dem Verzeichnis, wo es liegt, folgendermaßen aufgerufen:

./filecopy.sh

Geben wir diesen Befehl so ein, so scheint es, als wäre nichts passiert. Oder doch, evtl. werdet ihr noch nach eurem Passwort gefragt, es wird ja ein sudo-Befehl ausgeführt im Script. Aber sonst? Es erscheint wieder die Eingabeaufforderung.

Ergebnis prüfen

Schauen wir doch mal nach, ob das Kopieren geklappt hat. Also gehen wir mit dem Befehl „cd Server“ in das Verzeichnis „Server“ und rufen mal das Inhaltsverzeichnis auf:

-rw-r--r-- 1 root root 514 Oct 17 15:35 interfaces
kamil@server01:~/Server$

So, das hat also geklappt. Gut, dann können wir ja wieder mit dem Befehl „cd ..“ eine Verzeichnisebene höher gehen ins Home-Verzeichnis.

Fazit

Auf ganz genau diese Weise trage ich jetzt jede geänderte Konfigurationsdatei in dieses Script ein, welches ich von zeit zu Zeit mal ausführe, um diese Dateien dann auf einem USB-Stick zu sichern. Dann schreibe ich noch ein Script, dass all diese Konfigurationsdateien auch wieder an ihren Ursprungsort kopiert, und bei einer Neuinstallation habe ich so in wenigen Sekunden meine Konfiguration des Servers wiederhergestellt. Und in das Script installserver.sh schreibe ich dann all die sudo apt-get install xxx Befehle rein, so dass diese auch nicht mehr per Hand gemacht werden müssen.

Je mehr wir über Linux lernen, können wir sicher auch mal komplexere Scripts schreiben, aber ich halte diese Scripte für wichtig. Später, wenn ihr viel am Server konfiguriert habt, müsstet ihr sonst Stunden damit verbringen, alles wieder richtig zu konfigurieren. So sind es nur paar Sekunden.

Viel ausführlichere Informationen über Scripting findet ihr auch im Wiki ubuntuusers.de. Zwar bezieht sich das Wiki auf Ubuntu, aber diese Informationen sind universell einsetzbar.

Ich hoffe, ihr seid soweit mitgekommen. Falls nicht, können wir das gerne in der Liste noch ausdiskutieren, und evtl. passe ich dann mit euren Vorschlägen den Artikel noch an.

Projekt Homeserver im Eigenbau 6: Erste Schritte am Server

Noch mal kurz ein kleiner Nachtrag zur Installation. Ich habe mit dem System noch etwas herumgespielt, um einiges auszuprobieren. Dabei habe ich so viel durcheinander gebracht, dass eine Neuinstallation schneller ging als das Problem zu beheben. Das wäre gegangen, aber ich war zu faul. Und dabei habe ich das System zwar genau so installiert, wie im vorigen Beitrag beschrieben, aber mit einer kleinen Änderung: Da, wo ich die Software-Pakete auswähle, die installiert werden sollen, habe ich Web Server und SQL Database nicht mehr ausgewählt. Das Debian Desktop Environment habe ich wieder abgewählt. Damit wird tatsächlich eine grafische Oberfläche mit allen Zusatzprogrammen installiert, das war übrigens eines meiner Experimente. Ich will das nur erwähnt haben, falls ihr euch zu gegebener Zeit fragt, warum ich Web Server usw. manuell installiere.

Übrigens, macht das ruhig mal paar mal. Installiert Linux, spielt damit herum, macht es kaputt, installiert es erneut, spielt wieder rum, versucht dann, das Problem zu finden und zu lösen. So lernt man fast mehr, als trocken irgendwelche Bücher zu lesen. Durch viel Rumprobieren an meiner Mediacenter-Installation habe ich das meiste über Linux gelernt. Und es ist ja nicht wie Windows, was man aktivieren muss. Es kostet euch nur etwas Zeit, sonst nichts.

Neuinstallation leicht gemacht?

Zur Zeit ist es ja egal, ich habe ja noch nichts produktives mit dem System angestellt, aber das ändert sich jetzt sehr schnell. Und damit ich bei einer eventuellen Neuinstallation nicht alles per Hand wieder machen muss, führe ich während meiner Arbeit 3 kleine Dateien. Das sind Shellscripte, die haben unter Linux in etwa die Funktion von Batch-Dateien. Allerdings sind die unter Linux um ein beträchtliches mächtiger.

Die erste Datei ist filecopy.sh. Die Dateiendung *.sh findet ihr bei diesen Scripts. Hier schreibe ich einen Kopierbefehl rein, wenn ich z. B. eine Konfigurationsdatei ändere. Ändere ich z. B. die Konfigurationsdatei für das Netzwerk, so trage ich hier folgenden Befehl ein:

sudo cp /etc/network/interfaces ~

Dieser Befehl kopiert mir die Datei in mein Home-Verzeichnis.

Die zweite Datei ist filerestore.sh, die kopiert die gesicherten Konfigurationsdateien wieder dort hin, wo sie hingehören. Hier z. B:

sudo cp interfaces /etc/network/interfaces

Die beiden Scripte und die kopierten Konfigurationsdateien kann ich z. B. auf einen USB-Stick kopieren, so dass ich nach einer Neuinstallation einfach nur filerestore.sh ausführen muss. Und innerhalb von Sekunden ist mein Server wieder korrekt konfiguriert.

Die dritte Datei ist die installserver.sh. Hier trage ich die Befehle für alle nachträglich installierten Pakete ein. So brauche ich auch das hinterher nicht mehr per Hand machen, wenn ich den Server mal neu aufsetzen muss.

Näher zu Scripten, wie man sie schreibt und ausführt, gehe ich später noch ein. Aber ich würde mir, um die Arbeit hinterher zu erleichtern, die Befehle für evtl. nachinstallierte Pakete und geänderte Konfigurationsdateien irgendwo notieren.

Jetzt aber, los geht’s!

Nun haben wir es also geschafft, der Server ist installiert. Aber, außer ein bisschen Strom verbrauchen, tut der im Augenblick nichts interessantes. Also müssen wir mal sehen, das wir den Server überhaupt erst mal gesteuert bekommen.

Putty

Putty ist ein SSH-Client, mit dem man sich mit Linux-Rechnern verbinden kann, um an oder auf ihnen zu arbeiten. Das war auch der Grund, warum ich während der Installation auch den SSH Server angewählt habe. Mit Putty haben wir eine Eingabeaufforderung am Server, als würden wir direkt an diesem arbeiten.

Zunächst mal müssen wir Putty runterladen. Das ist nur ein winzig kleines Programm. Putty gibt es hier zum Herunterladen.

Sucht auf der Seite nach der Windows-Version und ladet das Programm runter. Kopiert es nun an einen Ort auf eurem Rechner, wo ihr es leicht wiederfindet. Ich habe auf meinem Laufwerk D: einen Ordner, wo ich all diese kleinen Helferlein reinkopiere.

Verbindung zum Server herstellen

Zunächst mal muss der Server eingeschaltet werden. Da er jetzt keinen Monitor hat, müssen wir raten, wann er fertig mit booten ist. Dafür muss ich mir auch noch mal was einfallen lassen…

Legt euch nun auf dem Desktop eine neue Verknüpfung an, dann braucht ihr das nicht jedes mal per Hand eingeben. Klickt rechts auf euren Windows-Desktop, wählt aus dem Kontextmenü „Neu“ und aus dem Untermenü „Verknüpfung“ aus.

In das Feld „Geben sie den Speicherort des Elements ein“, gebt ihr nun den Pfad zu Putty ein, und natürlich den Parameter, mit dem es gestartet werden soll. Ihr könnt eine IP-Adresse angeben, aber auch einen Rechnernamen. Mein Server heißt ja „server01“. Also heißt die Zeile bei mir:

d:\tools\putty.exe server01

Nachdem ihr auf „Weiter“ geklickt habt, gebt ihr der Verknüpfung noch einen vernünftigen Namen, bei mir heißt sie nun „Server 01“. Fertig, ab jetzt braucht ihr nur noch diese Verknüpfung, um euch mit eurem Server zu verbinden.

Erste Verbindung zum Server

Geht nun auf die neue Verknüpfung und drückt Enter. Das Putty-Fenster geht auf, und ein Dialogfeld erscheint.

Dieser englische Dialogtext sagt euch nichts anderes, als dass Putty den Schlüssel dieses Rechners nicht kennt und man sich nicht sicher sein kann, dass es wirklich der Rechner ist, den ihr erreichen wolltet. Da ich mir aber sicher bin, dass es mein Server ist, klicke ich auf „Ja“, wodurch der Schlüssel gespeichert wird und diese Frage nie wieder kommt.

Anschließend werdet ihr nach Benutzernamen und Passwort gefragt. Loggt euch ein, und es erscheint folgender Bildschirm:

Linux server01 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Oct 15 00:53:50 2014
benutzer@server01:~$

Der obere Text ist eigentlich erst mal uninteressant. Wichtig ist die letzte Zeile. Die sagt nämlich folgendes:

  • benutzer: Der Benutzername, mit dem ihr angemeldet seid.
  • @server01: Der Rechner, an dem ihr angemeldet seid.
  • :~: Das Verzeichnis, in dem ihr euch gerade befindet. Die ~ (Tilde) sagt euch, ihr seid in eurem eigenen Home-Verzeichniss.
  • $: Das Dollar-Zeichen sagt euch, dass ihr als normaler User verbunden seid. Als Root würde da ein # (Nummernzeichen) stehen.

So, und nun könnten wir ja eigentlich schon mal paar Befehle eingeben…

Zeit synchronisieren

Ihr erinnert euch? Bei der Installation gab es ja mal so paar Probleme mit der Internet-Zeit-Synchronisation. Nun, stellt sich raus, dass ich dem Server das noch beibringen muss… Also muss das Paket nachinstalliert werden. Benötigt wird das Paket NTP, Network Time Protocol. Und das installiert man folgendermaßen:

Da dies ein administrativer Eingriff ist, muss man dies als Admin tun. Also kommt vor den Befehl der Zusatz sudo. Das zeigt dem System, dass nun mit Admin-Rechten gearbeitet wird. Um das Paket also zu installieren, sind folgende 2 Befehle nötig:

sudo apt-get update

Dieser Befehl aktualisiert die Paketquellen und lädt die Liste verfügbarer Pakete runter. Gleichzeitig wird eine Datenbank erstellt, in der das System vermerkt, was schon installiert ist, und was nicht und deren Abhängigkeiten.

sudo apt-get install ntp

Dieses installiert nun das Paket NTP und alle seine Abhängigkeiten. Die nachfrage, ob man dies nun installieren möchte, bestätigt man mit Y.

Nachdem der NTP-Dienst installiert wurde, stimmt nun auch endlich meine Uhrzeit, die man immer mit dem Befehl „Date“ abfragen kann.

Kurze Anmerkung zu apt-get

Das Programm, oder Paket, apt-get ist einer der Paketmanager, mit dem man Pakete installieren, deinstallieren, Systemupdates durchführen und vieles mehr machen kann. Auf alle Aspekte des Pakets einzugehen würde zu weit führen.

Ihr könnt übrigens jeder Zeit eine Handbuchseite zu einem Paket oder Befehl aufrufen. Dazu gebt ihr einfach „man“ und den Befehl, über den ihr die Seite sehen wollt, ein. Für apt-get hieße die Zeile z. B.:

man apt-get

BRLTTY entfernen

Wieso denn das jetzt? Nun, BRLTTY hat nur einen Zweck, und zwar die Braillezeile anzusprechen. Da aber niemand mehr direkt am Server arbeiten wird, ist es auch nicht nötig, dass es permanent im Hintergrund läuft. Da ich Linux ja mit Braillezeile installiert habe, hat es BRLTTY auch standardmäßig installiert. Der einzige Grund, je wieder einen Monitor und Tastatur an den Server anzuschließen ist, wenn ich ihn über das Netzwerk nicht mehr erreichen kann. Und dann wird wahrscheinlich sowieso eine Neuinstallation fällig. Daher glaube ich, kann BRLTTY auch runter vom System. Und das geht mit diesem Befehl:

sudo apt-get remove brltty

Abhängigkeiten bereinigen

Wenn man ein Paket entfernt, wird oft eben nur dieses entfernt. Die anderen Pakete, die mit dem eigentlichen Paket installiert wurden, weil sie voneinander abhängig sind, wurden nicht entfernt. Daher müsst ihr gelegentlich mal gucken, ob es nicht mehr benötigte Pakete auf eurem Server gibt. Diese können in einem Rutsch ganz leicht mit folgendem Befehl entfernt werden:

sudo apt-get autoremove

Das müsst ihr nicht oft machen, aber es kann nicht schaden, diesen Befehl auszuführen, wenn ihr mal mehrere Pakete deinstalliert habt. Diese unbenötigten Pakete stören zwar nicht, müssen aber auch nicht unbedingt auf dem Server bleiben.

System update

Eigentlich sollte man meinen, das sei jetzt bei einem gerade aus dem Internet installierten System nicht nötig. Vielleicht ist es das tatsächlich nicht. Aber es würde doch mein Gewissen beruhigen, mal nach Updates zu gucken. Auch hierzu sind zwei Befehle nötig.

sudo apt-get update

Ja, hatten wir eben schon mal, aber wenn wir später mal wieder ein Update machen wollen, müssen beide Befehle sein.

sudo apt-get upgrade

Dieser Befehl führt das eigentliche Update durch.

OK, war nicht nötig, keine Updates vorhanden.

Und eine Vorschau auf den nächsten Artikel erspare ich mir, weil ich wahrscheinlich sowieso wieder was ganz anderes dazwischen schieben werde, als ich vor hatte… 🙂