Archiv der Kategorie: Linux Homeserver

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 34: Die Fritz!Box an die USV anschließen

Nun, da die USV durchaus noch Kapazitäten frei hat, würde ich sie nun auch dafür nutzen wollen, meine Fritz!Box noch eine Weile zu betreiben. Fällt nur der Strom in unserem Haus, oder nur in der unmittelbaren Straße aus, so habe ich immer noch DSL, und kann also auch noch Mails verschicken. Die Fritz!Box noch eine Weile betreiben zu können ist insofern wichtig, da ich nur noch einen AllIP-VDSL-Anschluss habe. Bei einem Stromausfall könnte ich also nicht einmal mehr telefonieren.

Nennt mich ruhig nostalgisch, aber ich sehne mich schon irgendwie nach ISDN-Zeiten zurück. Das ISDN-Netz bekam seinen Strom durch das Telefonnetz selbst. Fiel also mal der Strom aus, so war zwar eine Telefonanlage ausgefallen, aber man konnte ein Tischtelefon direkt am ISDN-Anschluss für Notfälle betreiben. Somit waren also auch evtl. nötige Notrufe noch möglich. Fällt aber bei einem AllIP-Anschluss der Strom aus, ist Ende im Gelände! Da mag ein Schnurlostelefon noch so voll geladene Akkus haben, Telefonieren is nich! 🙁 Nicht nur, weil die Basisstation des Schnurlostelefons keinen Saft mehr hat, sondern das ganze Netz nicht mehr! 🙁 VoIP mag ja sonst eine Menge Vorteile haben, dies ist definitiv keiner davon!

Mit der USV kann ich aber meine Fritz!Box noch eine Weile betreiben. Zumindest reicht es aus, dass der Server seine Status-Mails los wird, mein WLAN noch für eine Weile steht und mein MacBook z. B. sein Backup abschließen kann und evtl. ich noch eine Weile telefonieren kann. Mein Schnurlostelefon ist nämlich an der Basis der Fritz!Box angemeldet.

Das mit den Backups ist wichtig, da es sonst dazu führen kann, dass so ein TimeMachine-Backup unbrauchbar werden könnte. Und da diese Backups meist nur zwischen 2 und 5 Minuten dauern, reicht auch der Strom der USV dafür noch aus. Selbst wenn der Backup-Vorgang länger dauern sollte, so hat man genug Zeit, den Vorgang über das Menü sauber abzubrechen. Somit verbleibt das TimeMachine-Backup in einem benutzbaren Zustand.

Ist der Stromausfall aber großflächig, also so etwas wie der Stromausfall für einen ganzen Stadtteil, und ist der graue Kasten, an dem man mit seiner VDSL-Leitung angeschlossen ist, nicht mit Notstrom ausgestattet, nutzt das natürlich nichts. Aber man kann sich auch nicht für alle Eventualitäten wappnen. Für den Fall eines Stromausfalls in der eigenen Wohnung, dem Haus oder nur eines Teils der Straße jedoch ist diese Absicherung mehr als ausreichend.

Was brauche ich?

Ich habe mich für die APC Back-UPS BX700UI entschieden, was im Nachhinein vielleicht ein Fehler war. Diese hat nur 4 Kaltgerätestecker. Falls ihr noch keine USV angeschafft habt, nehmt die Varianten mit Schuko-Stecker, das sind die normalen Steckdosen. Diese Modelle sind zwar 8 bis 10 € teurer, aber dafür müsst ihr euch keine Adapter kaufen.

Ich benötige also, um die Fritz!Box anschließen zu können, einen Adapter von Kaltgeräteanschluss auf Schuko-Stecker. An der USV sind 4 Kaltgerätebuchsen, weiblich, also benötige ich einen Kaltgerätestecker männlich auf Schuko-Buchse weiblich. Solche Adapter gibt es eine Menge, ich habe einen von Inline für 5,58 € gekauft.

Anschluss

Das ist denkbar einfach. Man schließt einfach den Kaltgerätestecker an eine der freien Buchsen an der USV an. Am anderen Ende des Kabels baumelt eine normale große Steckdose. Hier steckt man das Netzkabel der Fritz!Box ein, fertig. Man muss die USV oder sonst etwas, was an der USV angeschlossen ist, nicht extra ausschalten dafür.

Der Rest ist selbsterklärend: Einige Zeit später ist die Fritz!Box hochgefahren und hat sich mit der DSL-Vermittlungsstelle synchronisiert. Fällt nun der Strom aus, die Vermittlungsstelle aber arbeitet weiter, so bleibt die DSL-Verbindung bestehen und man kann noch telefonieren, bis der USV der Saft ausgeht. Zwar wird sich der Server irgendwann zwischen 15 und 10 % Kapazität der USV abschalten, die Fritz!Box jedoch wird noch eine Weile weiter mit Strom versorgt werden.

Status der USV mit angeschlossener Fritz!Box

Der Server verbraucht für sich etwa 17 % der Kapazität der USV und kann, laut Statusanzeige, bis zu 32,3 Minuten betrieben werden. Dafür, dass der Server im Leerlauf ist, ist das schon eine ganze Menge. Jeden ersten Sonntag im Monat macht MDADM einen Integritäts-Check des RAIDs. Neugierig, wie ich bin, habe ich mal geguckt, was der Status hierzu zu sagen hatte. Die Last war dann bei 23 % und der Server hätte etwa 21 Minuten betrieben werden können. Das habe ich jetzt aus dem Kopf wiedergegeben, weil ich nicht dran gedacht hatte, die Werte aufzuschreiben. Könnte also sein, dass ich mich etwas in der Laufzeit vertue. Trotzdem, immer noch über 20 Minuten, und auch das ist beachtlich.

Gehen wir aber mal vom Normalfall aus, also 17 % Last auf der USV bei Leerlauf des Servers. Naja, ganz im Leerlauf ist er ja nicht, ein paar Dienste laufen schon noch im Hintergrund. Aber die sind nicht so energiehungrig.

Wenn ich nun die Status-Webseite aufrufe, so sehe ich für die Auslastung der USV einen Wert von 19 % und eine voraussichtliche Batterielaufzeit von 28,7 Minuten. Das heißt, die Fritz!Box belastet die USV mit gerade mal um die 2 %. Wenn der Server also heruntergefahren wird, ist die Fritz!Box noch eine geraume Zeit online!

Fazit

Ob man sich jetzt die USV mit Kaltgerätesteckern und Adaptern für Schuko-Stecker kauft, oder ob man gleich die USV mit Schuko-Steckern kauft, preislich macht es keinen Unterschied. Aber falls ihr noch keine USV gekauft habt, würde ich aus Bequemlichkeit die Variante mit Schuko-Steckern kaufen.

Immer noch ist Luft nach Oben. Aber man muss die USV auch nicht bis zum Zusammenbruch auslasten. Trotzdem, beruhigend, dass der Server beim nächsten Stromausfall nicht einfach ausgeht und die Daten in einem Chaos zurücklässt.

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

Homeserver 32: Eine Backup-Lösung, nicht nur für Server

Ich bin begeistert! Seit einer Ewigkeit, lange vor dem Homeserver-Projekt schon, beschäftige ich mich damit, wie man wohl große Datenmengen zuverlässig sichert. Auch mit meinem NAS von QNAP hatte ich das Problem schon. Was also tun? Ein zweites, teures NAS, nur für ein Backup hinstellen? Ausgeschlossen! Das sprengt nicht nur jeden finanziellen Rahmen, sondern ist auch mit Atombomben auf Ameisen geworfen! Der Aufwand, das zweite NAS zu verwalten, ist viel zu hoch obendrein.

Die Lösung, die ich nun gefunden habe, taugt nicht nur für den Server, sondern für jedes Laufwerk. Auch euren lokalen Windows-Rechner könnt ihr so sichern. Alles, was es dazu braucht ist eine kostenlose Software und externe Festplatten.

Das Problem

Ob es nun ein NAS ist, welches ihr euer Eigen nennt, ein selbst gebauter Server, wie in meinem Fall, oder einfach nur eine Datenpartition eures Windows-Rechners, die Frage ist immer die gleiche: Wie sichere ich meine Daten. Bei einer recht kleinen Partition mag diese Frage ja noch einfach zu beantworten sein. Aber was tun, wenn der zu sichernde Datenbestand größer ist, als jede externe Platte, die ihr euch heutzutage kaufen könntet? Dann wird es schwierig, nicht wahr?

Bislang habe ich eine Bastellösung aus Robocopy und einem ziemlich komplexen Aufruf durch eine Batch-Datei gelöst. Dabei habe ich mich eines uralten Bekannten bedient, welcher mir schon zu DOS-Zeiten gute Dienste leistete, dem Archiv-Attribut. So habe ich Robocopy alle Dateien kopieren lassen, die das Archiv-Attribut hatten. Selbst kleinste Änderungen ließen sich so leicht sichern.

Der Vorteil dieser Methode war, sie funktionierte. Der Nachteil dieser Methode war, ich hatte hinterher keine Ahnung, welche Datei auf welcher Platte gelandet war. So konnte ich zwar das RAID in seiner Gesamtheit problemlos wiederherstellen, suchte ich aber eine bestimmte Datei, wurde es anstrengend… Wir reden hier immerhin schon über 7 einzelne externe Festplatten. Da macht Suchen echt keinen Spaß mehr…

Die Lösung

Wieder einmal durchsuchte ich frustriert das Web nach einer guten und brauchbaren Backuplösung, die wenig kostet und möglichst mit einfachen externen Platten zu realisieren ist. Und eher durch Zufall, in einem Nebensatz eines Forenbeitrags eingestreut, stolperte ich über eine Software. Beinahe hätte ich es übersehen, wer weiß, wie oft ich diese Software schon übersehen habe bei meinen Suchen bisher. Doch nun habe ich sie: AnyBackup. Die Software ist, zumindest größtenteils, mit Jaws bedienbar. Naja, eigentlich ist sie vollständig bedienbar, aber man muss teilweise mit dem Jaws-Cursor arbeiten, um zwischen den Listen hin und her zu wechseln, was etwas umständlich ist. Mit Braillezeile geht das auch.

Funktionsweise

AnyBackup arbeitet mit einer Datenbank im Hintergrund. Man fügt eine oder mehrere Quellen hinzu und eine oder mehrere Ziele. Hier mal ein Beispiel:

Mein RAID hat mehrere Freigaben, auf denen ich Daten hinterlasse. Die wichtigsten, von denen ich auch immer ein Backup haben will, sind meine Daten-Freigabe auf Laufwerksbuchstabe Z: und meine Webserver-Daten auf Buchstabe Y:. Die einzelnen Symbole in der Symbolleiste haben Text und sind mit Jaws daher gut zu lesen. Also suche ich aus der Symbolleiste das Symbol für „Hinzufügen“ aus und klicke dieses. Nun werde ich gefragt, ob ich ein Backup-Laufwerk oder ein Quell-Laufwerk hinzufügen möchte. Ich wähle Quell-Laufwerk und drücke Enter. In dem nun aufgehenden Dialog wähle ich das Netzlaufwerk Z: aus und drücke OK. Jetzt werde ich gefragt, ob ich das Laufwerk indexieren möchte, hier antworte ich natürlich mit „Ja“.

Nun liest AnyBackup alle vorhandenen Dateien auf Laufwerk Z ein und speichert sie in seiner Datenbank. Dies tue ich noch einmal für Laufwerk Y, so dass auch dessen Dateien nun in der Datenbank sind. Wir reden hier nur über die Dateinamen, Größen und Datumsangaben, nicht über die Dateiinhalte selbst. Nicht, dass ihr denkt, alle Dateien werden jetzt vollständig… 🙂

Ich sichere auf verschiedenen einzelnen externen Festplatten. Um dies zu tun, habe ich ein USB 3.0 Festplattendock, in das die Festplatten senkrecht reingestellt werden. So kann man die Platten leicht wechseln. Also stelle ich mal die erste Platte ins Dock und schalte es ein.

In AnyBackup Mache ich das gleiche, wie eben, nur dass ich diesmal Backup-Laufwerk auswähle. Es öffnet sich eine Liste der verfügbaren Laufwerke, ich suche mein externes Laufwerk, markiere mit der Leertaste das Kontrollkästchen und drücke Enter. Auch hier werde ich gefragt, ob ich das Laufwerk indexieren möchte, aber es ist ja leer. Daher ist es ziemlich egal, was ihr hier antwortet. Das gleiche mache ich jetzt mit allen verfügbaren externen Festplatten, die ich für das Backup nutzen möchte.

AnyBackup merkt sich den Laufwerksnamen und Volumeseriennummer. Wenn sich also dessen Laufwerksbuchstabe ändern sollte, spielt das für AnyBackup jetzt keine Rolle mehr, es würde die Platte trotzdem finden.

Backup

Wenn ich jetzt also den Befehl zum Sichern gebe, verlangt AnyBackup nach der ersten Platte, befüllt diese bis es wirklich nicht mehr geht, speichert sich den Inhalt der Platte in seiner Datenbank und verlangt dann die nächste Platte. Wurden im Quell-Laufwerk Dateien entfernt, so werden sie im nächsten Backup-Lauf auch vom Ziel entfernt.

Nie vergessen, vor dem Backup den Index der Quell-Laufwerke im Menü „Aktualisieren“ auffrischen. Jetzt kann man z. B. im Menü „Bearbeiten“ auch nachsehen, welche Dateien noch gesichert werden müssen.

Die Daten werden auf die verschiedenen externen Platten so verteilt, dass diese optimal ausgenutzt werden. Dabei spielt es keine Rolle, ob die einzelnen externen Platten unterschiedlich groß sind. AnyBackup kennt die Größe jedes Laufwerks und verteilt die Daten entsprechend.

Wiederherstellung

Nehmen wir an, mein RAID-Laufwerk Z wäre jetzt leer, könnte ja versehentlich alles gelöscht haben… 🙂 Jetzt lasse ich also das Quell-Laufwerk indexieren und lasse mir dann anzeigen, welche Dateien fehlen. Im Menü „Bearbeiten“ mit dem Punkt „Vorschau: Alte Dateien“. Wenn ich jetzt auf „Wiederherstellung“ gehe, werden alle auf dem Quell-Laufwerk fehlenden Dateien wiederhergestellt.

OK, aber das ist ja eher ein Szenario, das selten vorkommt. Viel häufiger wollt ihr eine ganz bestimmte Datei wiederherstellen. Entweder, weil sie weg ist, oder weil ihr sie bearbeitet habt und die alte Version doch die bessere Variante ist. Das geht über die Suchfunktion. Im Menü „Datei“ oder einfach über Strg+F.

Hier kann man den Suchbegriff eingeben, ob man in Quelle oder Ziel sucht. Klick man nun auf OK, so taucht das Ergebnis im unteren Fenster auf, in das man wieder mit Braillezeile oder Jaws-Cursor klicken muss. Man sucht nun die zu wiederherstellende Datei, simuliert einen Rechtsklick und wählt nun „Kopieren nach“ aus. Nun noch den Zielordner angeben, AnyBackup verlangt dann noch nach der richtigen Backup-Platte, fertig.

OK, nachdem man weiß, auf welcher Backup-Platte die betreffende Datei ist, kann man sie auch per Hand kopieren, ist wohl leichter. Die Dateien werden auf die Backup-Platten einfach nur kopiert, so dass man sie auch von dort per Explorer kopieren kann.

Wichtig: Macht, wenn möglich, keine Änderungen an den Backup-Platten per Hand. Möglicherweise bekommt das AnyBackup nicht mit und macht hinterher Fehler. Überlasst die Verwaltung der Platte AnyBackup.

Fazit

RAID ist kein Backup! Ein RAID schützt euch nur vor einem Festplattenausfall, nicht vor Datenverlust. Es ist also dennoch ein Backup nötig!

AnyBackup ist sicher nicht das bequemste Stück Software, vor allem, weil man mit viel Jaws-Cursor arbeiten muss. Aber es tut was es soll, und das sehr zuverlässig. Und es ist alle mal besser als meine Robocopy-Bastellösung!

Ihr könnt das Tool auch zum Sichern eurer lokalen Datenpartitionen nutzen. Es ist zwar zum Sichern gedacht, arbeitet aber, gerade wegen seiner Funktionsweise, auch gut als Synchronisationswerkzeug. Aber sein eigentliches Ziel ist es, große Datenmengen effektiv auf mehrere externe Festplatten zu verteilen.

Homeserver 31: Time Machine Funktionalität unter Debian 8 wiederherstellen

[Update] Im Script haben ein paar Backslashe gefehlt, das wurde gefixed.

Aus irgendwelchen Gründen scheint das netatalk-Paket aus Debian rausgeflogen zu sein. Ob das nur eine kurzfristige Sache ist, oder das Paket dauerhaft draußen bleibt, weiß ich nicht. Vielleicht finde ich später noch Informationen, die etwas Licht ins Dunkel bringen.

Das ändert aber nichts an der Tatsache, dass ich netatalk brauche. Es macht es nur wesentlich unbequemer, es zu installieren. Denn wenn es als Paket im Debian-Repository enthalten ist, könnte man ja einfach ein „apt-get install netatalk“ machen. Das geht nun nicht. Jetzt muss das Paket quasi selbst erstellt werden.

Vorbereitungen

In meinem Home-Verzeichnis habe ich ein Verzeichnis „Netatalk“ erstellt, in welches die heruntergeladene Datei für Netatalk kopiert wird. Hierin erstelle ich auch ein kleines Shellscript, welches die Installation durchführt. Da es doch eine Menge Befehle sind, die eingegeben werden müssen, und für den Fall, dass ich das mal wiederholen muss…

Die aktuelle Version von Netatalk bekommt man hier. Hier lade ich die aktuelle Version 3.1.7 als bz2-Datei herunter und kopiere es in das Home-Verzeichnis, dort unter Netatalk. Hier erstelle ich auch das Installationsscript.

nano netatalkinstall.sh

Dort schreibe ich jetzt alle Befehle rein, die nötig sind, das Paket zu erzeugen und zu installieren.

Installation

Der Installationsprozess ist recht umfangreich. Falls ihr euch das gerne selbst ansehen möchtet, findet ihr die Installationsanleitung für Netatalk 3.1.7 unter Debian Jessie im Netatalk-Wiki.

Der Einfachheit halber erkläre ich nur grob die Installationsschritte und füge unten am Post dann das Shellscript an, welches ihr bei Bedarf einfach kopieren und selbst in ein Shellscript einfügen könnt.

  • Benötigte Pakete installieren: Damit das Paket läuft, müssen Abhängigkeiten und diverse Entwicklungswerkzeuge installiert werden. Normal braucht man so was nicht, aber manchmal scheint es halt unumgänglich. Und falls später noch mal so ein Paket erzeugt werden soll, hat man die nötigen Pakete dann ja im System.
  • Konfiguration des Pakets: Hier werden mit ein paar kurzen Befehlen ein paar Einstellungen des Paketes gemacht. Das bezieht sich aber eher für die Erstellung, nicht für die Konfiguration des laufenden Dienstes.
  • Installation des Pakets: Damit wird das Paket in das System eingefügt und gestartet. Nun könnte man es konfigurieren und nutzen.

Als letzter Schritt kommt die Konfiguration des Dienstes. Schließlich muss die TimeMachine auch vom Mac aus gefunden werden.

Installations-Script

Kopiert das Script einfach, erstellt im Verzeichnis, wo die heruntergeladene Datei liegt ein leeres Script, meinetwegen nennt es install.sh und fügt den Inhalt dort ein. Wenn ihr das Script startet, werden alle benötigten Pakete installiert, Paketkonfigurationen erledigt und das Paket installiert.

#!/bin/bash

## Installation von Netatalk

# Benötigte Pakete installieren

sudo apt-get install build-essential libevent-dev libssl-dev libgcrypt11-dev libkrb5-dev libpam0g-dev libwrap0-dev libdb-dev libtdb-dev libmysqlclient-dev libavahi-client-dev libacl1-dev libldap2-dev libcrack2-dev systemtap-sdt-dev libdbus-1-dev libdbus-glib-1-dev libglib2.0-dev tracker libtracker-sparql-1.0-dev libtracker-miner-1.0-dev

# Paket entfernen, um Probleme zu vermeiden

sudo apt-get remove libavahi-compat-libdnssd-dev

# Paket erstellen (Build)

tar xvf netatalk-3.1.7.tar.bz2
cd netatalk-3.1.7

# Paket konfigurieren

./configure \
        --with-init-style=debian-systemd \
        --without-libevent \
        --without-tdb \
        --with-cracklib \
        --enable-krbV-uam \
        --with-pam-confdir=/etc/pam.d \
        --with-dbus-sysconf-dir=/etc/dbus-1/system.d \
        --with-tracker-pkgconfig-version=1.0

# Paket installieren

make
sudo make install

# Einrichten und Startreihenfolge einstellen

sudo systemctl enable avahi-daemon
sudo systemctl enable netatalk
sudo systemctl start avahi-daemon
sudo systemctl start netatalk

Dann bleibt ja nur noch die Konfiguration, die hier jetzt etwas anders ist, als die Konfiguration, die wir im Debian 7 gemacht haben.

Konfiguration von Netatalk

Während ich die Konfiguration von Netatalk früher etwas verwirrend fand, weil sie einfach nicht so aussieht, wie viele andere Konfigurationsdateien, finde ich die neue Datei sogar noch übersichtlicher.

Für eine genaue Beschreibung der Parameter könnt ihr euch ja mal die Manpage zu afp.conf anschauen. Ich werde hier mal nur beispielhaft die Konfiguration meiner TimeMachine aufführen.

sudo nano /usr/local/etc/afp.conf

OK, der Ort der Datei ist ungewöhnlich, macht aber nichts. Der Abschnitt für meine TimeMachine-Konfiguration sieht so aus, der Rest der Datei ist unverändert:

[TimeMachine]
path = /raid1/timemachine
vol size limit = 512000
valid users = kamil
time machine = yes

Fertig! Aber da ich jetzt noch nicht so genau weiß, wie man unter Debian 8 Daemons neu startet, reboote ich den Server einfach mal.

Fazit

Was ich damit meine, dass das Starten und Stoppen von Diensten etwas anders ist unter Debian 8? Nun, hier wurde das Init-System, also der Dienst, der alle Dienste startet und verwaltet, geändert. jetzt ist es systemd, und wie der funktioniert, muss ich mir noch anlesen.

Übrigens musste ich unter Mac OS das alte Backup abmelden und das neue Backup einbinden. Das tut ihr unter den Systemeinstellungen und dort bei Time Machine, mit dem Schalter „Volume wechseln“.

Ich habe mir, bei meinen Experimenten gestern, wohl mein Backup zerschossen. Offenbar hat mein MacBook noch mit dem alten Netatalk ein Backup gemacht, und nun ist das Backup nicht mehr zugreifbar. Also musste ich einen neuen Backupverlauf erstellen. Das erste Backup läuft gerade und wird noch eine Weile laufen.

Zwar ist es jetzt wirklich etwas umständlicher geworden, aber nicht unmöglich, zum Glück. Immerhin läuft alles wieder. Aber langfristig kann man jetzt natürlich noch nichts konkretes sagen. Das bleibt abzuwarten.

Homeserver 30: System auf die neue Version upgraden

Gestern, also am 25.04., wurde Debian 8 mit dem Namen Jessie veröffentlicht. Auf meinem Server läuft ja noch Debian 7, also Wheezy. In diesem Artikel soll es also darum gehen, das System zu upgraden.

Der Upgradeprozess ist denkbar einfach, bedarf aber mehrerer Befehle. Mir wäre es, ehrlich gesagt, lieber, wenn es nur ein einziges Programm für diesen Zweck gäbe, aber so geht es auch relativ schmerzfrei.

Wichtiger Hinweis

Es scheint so zu sein, dass das Paket netatalk nicht mehr richtig funktioniert und man es auch nicht neu installieren kann. Aus irgendwelchen Gründen scheint es in den Paketen für Jessie nicht vorhanden zu sein. Vielleicht, aber das bleibt abzuwarten, wird es noch in die Paketliste aufgenommen. Bis dahin, falls ihr die TimeMachine-Funktionalität nicht einbüßen wollt, würde ich mit dem Upgrade warten. Für mich ist das leider zu spät… 🙁

Falls es nicht dazu kommt, also dass netatalk nicht in die offiziellen Quellen aufgenommen wird, werde ich es manuell per Hand installieren. Das ist aber ein derart komplexer Prozess, dass ich dazu einen eigenen Blogeintrag machen werde, falls dies nötig sein sollte.

Vorbereitungen

Bevor ich das Upgrade einspiele, will ich erst mal dafür sorgen, dass das System auf dem neuesten Stand ist, den Wheezy anbietet. Laut der Anleitung zum Upgrade von Debian kann das später Fehler vermeiden helfen. Das kann man ganz einfach mit den folgenden Befehlen erledigen:

sudo apt-get update
sudo apt-get upgrade

Bei mir gab es nur zwei kleinere Updates. Aber weil ich ja schon viele Updates und Pakete installiert, und auch wieder entfernt habe, könnten Reste vorhanden sein, die zu Problemen führen. Diese Paketreste, Init-Scripts und Konfigurationsdateien müssen entfernt werden. Dies geht ganz einfach mit diesen beiden Befehlen:

sudo apt-get autoremove
sudo apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')

Dies entfernt nicht mehr benötigte Pakete. Dies können Pakete sein, die von anderen Paketen automatisch installiert wurden aber jetzt nicht mehr benötigt werden. Und die Überreste der Pakete, evtl. zurückgelassene Init-Scripts und Konfigurationsdateien werden damit ebenfalls entsorgt.

Da das System schon sehr lange läuft, und ich lieber auf Nummer sicher gehen möchte, starte ich den Server neu:

sudo reboot

Systemupgrade

Das eigentliche Upgrade läuft in zwei Schritten ab. Zunächst muss die Quellenliste angepasst werden, danach müssen die neuen Pakete heruntergeladen und installiert werden. Fangen wir also mit der Quellenliste an.

Quellenliste anpassen

Die Quellenliste legt fest, woher Debian seine Pakete herbekommt. Meine ist natürlich zur Zeit auf Wheezy eingestellt und sieht so aus:

# 

# deb cdrom:[Debian GNU/Linux 7.6.0 _Wheezy_ - Official amd64 NETINST Binary-1 20140712-14:09]/ wheezy main

#deb cdrom:[Debian GNU/Linux 7.6.0 _Wheezy_ - Official amd64 NETINST Binary-1 20140712-14:09]/ wheezy main

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

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

# wheezy-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free

# Probosed Updates
deb http://ftp.de.debian.org/debian wheezy-proposed-updates main contrib non-free

Hier müssen wir jetzt einige Änderungen machen, damit Debian die Jessie-Pakete auch finden kann.

sudo nano /etc/apt/sources.list

Damit ist die Quellenliste offen und wir können sie bearbeiten.

Ihr könnt an meiner Quellenliste ganz unten zwei Abschnitte sehen, Proposed Updates und Wheezy-Updates. Diese sollen laut Anleitung vorher deaktiviert werden. Also werden vor diese Zeilen jeweils ein # gestellt.

Bei den vier Zeilen, vor denen kein # steht, muss der Release-Name Wheezy durch Jessie ersetzt werden.

Am Ende sieht meine Quellenliste dann so aus:

# 

# deb cdrom:[Debian GNU/Linux 7.6.0 _Wheezy_ - Official amd64 NETINST Binary-1 20140712-14:09]/ wheezy main

#deb cdrom:[Debian GNU/Linux 7.6.0 _Wheezy_ - Official amd64 NETINST Binary-1 20140712-14:09]/ wheezy main

deb http://ftp.de.debian.org/debian/ jessie main non-free contrib
deb-src http://ftp.de.debian.org/debian/ jessie main non-free contrib

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

# wheezy-updates, previously known as 'volatile'
#deb http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free
#deb-src http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free

# Probosed Updates
#deb http://ftp.de.debian.org/debian wheezy-proposed-updates main contrib non-free

Nun können wir die Quellenliste speichern und mit dem Upgrade weitermachen.

System upgraden

So, nun geht es an das eigentliche Upgrade. Aber, so sehr unterscheidet es sich gar nicht von einem normalen Systemupdate. Aber schaut selbst:

sudo apt-get update
sudo apt-get dist-upgrade

Dies aktualisiert die Paketliste und führt das Upgrade durch. Dabei werden die Updates vorhandener Pakete installiert und nicht mehr benötigte alte Pakete entfernt. Und da bei mir knapp 800 Pakete aktualisiert werden müssen, dauert das jetzt erst mal…

Während des Upgrade-Prozesses könnte es gut sein, dass ihr diverse Fragen beantworten müsst. Dies ist aber sehr davon abhängig, welche Pakete und Dienste ihr installiert habt. Daher gehe ich jetzt darauf nicht weiter ein. Nur, beobachtet den Bildschirm und beantwortet die anfallenden Fragen.

Aufräumarbeiten

Es kann durchaus sein, dass es an meinem System lag, es kann aber auch sein, dass es auch bei anderen Systemen vorkommt. So genau kenne ich Linux nicht, um das mit Sicherheit sagen zu können. Daher schildere ich mal ein paar Dinge, auf die ich während des Upgrades gestoßen bin. Es sind zum Glück nicht viele.

Die Befehle zum Pakete Aufräumen müssen nach dem Upgrade erneut eingegeben werden:

sudo apt-get autoremove
sudo apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')

Ich hatte zwar angenommen, der dist-upgrade-Prozess würde sich darum kümmern, dem war aber leider nicht so.

Ich hatte gravierende Probleme mit phpmyadmin. Hier wollte sich die Datenbank einfach nicht updaten lassen. Hier hilft, die Konfiguration abzubrechen und das Paket erneut nach dem Upgrade zu konfigurieren. Hierzu gibt man nach dem Upgradeprozess einfach folgenden Befehl ein und beantwortet danach die Fragen:

sudo dpkg-reconfigure phpmyadmin

Danach funktioniert bei mir wieder alles prima.

Anschließend, wenn alles durchgelaufen ist, muss das System neu gestartet werden:

sudo reboot

Fertig, nun läuft der Server mit Debian 8 Jessie!

Fazit

Zwar sind es für ein Systemupgrrade eine Menge kleiner Einzelschritte, aber es ist nicht wirklich kompliziert. Wie gesagt, mir wäre ein einzelnes Programm lieber, dass diese Schritte automatisch erledigt und prüft, was nötig ist und was nicht. Dennoch, alles lief problemlos und einfach.

Homeserver 29: Kalender und Kontakte

Jetzt, wo der Server von außen erreichbar ist, kann ich damit beginnen, ein paar der wirklich interessanten Features zu installieren. Ich habe so einiges im Hinterkopf, aber beginnen wir heute mal damit, CalDAV und CardDAV zu installieren.

Diese beiden Dienste ermöglichen es mir, meine Kontakte und Kalender auf meinem eigenen Server zu hosten. Das hat gleich mehrere Vorteile:

  • Ich bin unabhängig von externen Diensten wie iCloud, Google oder sonstigen Anbietern.
  • Die Daten liegen bei mir. Das lässt mich wegen des Datenschutzes beträchtlich ruhiger schlafen.
  • Ich bin geräteunabhängig. Bei Fremddiensten, wie iCloud, bin ich auf Apple festgelegt. Andere Systeme und Geräte sind nur mit umständlichen Kniffen zu nutzen.

Bis jetzt liegen meine Daten in der iCloud. Mit meinem iPhone und meinem MacBook ist das ja kein Problem, aber mit Thunderbird komme ich kaum an die Daten ran. Und was ist, wenn ich mich später mal für ein Android-Gerät entscheide, sei es auch nur zum Ausprobieren?

CalDAV und CardDAV sind mehr oder weniger standardisierte Systeme, die so ziemlich von jedem modernen Gerät oder Programm verstanden werden. Somit bin ich wesentlich flexibler. Zwar muss bei manchen Programmen und Geräten Software nachinstalliert werden, aber das ist in der Regel schnell gemacht.

Nachtrag zur Erreichbarkeit aus dem Netz

Im letzten Teil habe ich beschrieben, wie ich meinen Server von außen zugänglich gemacht habe. Ich muss hierzu einmal einige Kleinigkeiten konkretisieren.

Ich hätte mir bei FreeDNS eine Subdomain als CNAME-Eintrag machen können. Das wollte ich aber nicht, weil es zum Einen nur mit einem CAPTCHA ging, und ich gerade niemanden hatte, der mir helfen konnte, und zum Anderen, weil man sich eine aus einem Pool öffentlicher Domains eine aussuchen müsste. Ich wollte einfach nicht, dass mein Server z. B. unter server.chickenkiller.com oder crabdance.com erreichbar ist. 🙂 Andererseits, wer keine andere Möglichkeit hat, das ist kostenlos.

Ich habe ja schon Domains, also habe ich mal selbst Subdomains angelegt, die aber alle ein Problem haben: Es sind alles HTTP-Weiterleitungen. Das nutzt mir so nichts, weil ich z. B. über diese Subdomains nicht per SSH auf meinen Server zugreifen kann. Aber jetzt habe ich eine Subdomain unter einer meiner Domains mit einem CNAME-Eintrag, der dann auf die Adresse server01.xxx.myfritz.net zeigt. Und jetzt kann ich jeden Dienst mit jedem Port aus dem Internet über meine neue Subdomain erreichen.

Wenn ihr also euren Server, NAS oder sonst was von außen erreichen wollt, und über MyFritz! geht, ist eine Subdomain mit einem CNAME-Record das, was ihr wollt. 🙂 Manche können ihre DNS-Einträge ja selbst verwalten, falls ihr nicht zu denen gehört, fragt mal freundlich bei euren Providern nach. Da werdet ihr dann auch geholfen. 🙂

Auswahl der Software

Kommen wir jetzt also mal zur Auswahl der Software für das CalDAV und CardDAV. Da gibt es ja ein paar, aber ich habe mich für den Baical-Server entschieden. Es gibt hier zwei Downloads, die Regular Version, und die Flat-Version. Dabei unterscheiden die sich nur in ihrer Installationsmethode. Regular war mir zu umständlich, zu kompliziert, keine Lust dazu! Also habe ich die Flat-Version heruntergeladen.

Installation

Wenn man sich also das Flat-Package heruntergeladen und ausgepackt hat, hat man ein Verzeichnis, in dem ein Verzeichnis „baikal“ existiert. Dieses Verzeichnis lade ich nun auf meinen Server ins HTML-Verzeichnis. Ich hatte mir dafür ja eine SMB-Freigabe zugelegt, so dass ich mir den Pfad da nicht merken muss. Stattdessen habe ich mir hierfür einen Laufwerksbuchstaben zugewiesen, in dem sich jetzt das Hauptverzeichnis meines Webservers befindet. Hier kopiere ich das baikal-Verzeichnis rein.

Nun gehe ich auf meinen Server, und da ich ja lokal bin,

http://server01/baikal/admin

Dies startet den Installationsvorgang.

Juhu! Fehlermeldung! Was für eine Freude! Denn davon stand in der Installationsanleitung nix! Aber OK, mach ich doch, was da steht. Denn die Fehlermeldung sagt, die Installationsroutine sei locked, also gesichert. Ist ja auch sinnvoll, sonst könnte man vielleicht eine bestehende Installation beschädigen. Man löst das Problem dadurch, indem man einfach eine leere Datei mit dem Namen „ENABLE_INSTALL“ in Großbuchstaben anlegt. Diese Datei kommt ins Verzeichnis „Specific“ im Baikal-Verzeichnis. Dann klappt’s auch mit der Installation. 🙂

Es werden nur ein paar Fragen gestellt, dann kann es auch schon los gehen:

  • Server Time zone: Hier wählt man die Zeitzone aus. Für mich in Deutschland natürlich „Europe/Berlin“.
  • Enable CalDAV: Natürlich hake ich das an, will ja Kalender synchronisieren.
  • Enable CardDAV: Aktiviere ich ebenfalls für Adresssynchronisation.
  • WebDAV authentication type: Hier wählt man Basic aus.
  • Admin-Passwörter: Hier wählt man das Passwort für den Admin aus.
  • Enable Web Interface: Sollte man anhaken, sonst hat man kein Webinterface mehr… 🙂
  • Web interface autolock: Das lasse ich deaktiviert.

Mit der Schaltfläche „Save“ Speichert man das ganze ab. Und nun geht es zur Datenbank-Konfiguration.

Datenbank anlegen

Bevor ich jetzt weitermachen kann, muss ich erst mal eine Datenbank anlegen. Irgendwohin müssen die Daten ja hingeschrieben werden. Also öffne ich in einem weiteren Tab meines Browsers die Adresse:

http://server01/phpmyadmin

Hier melde ich mich mit Benutzernamen und Passwort an und klicke auf den Link „Datenbanken“.

Die Maske für die Erstellung einer neuen Datenbank ist bereits auf dem Bildschirm, ich brauche sie nur auszufüllen. Eigentlich reicht der Datenbankname schon, dann auf den Anlegen-Schalter klicken, fertig! Den Tab mit PHPMyAdmin können wir wieder schließen und die Konfiguration von Baikal fortsetzen.

Baikal weiter konfigurieren

Bei „Use MySQL“ ist ein Haken gesetzt, so dass Baikal nun eine MySQL-Datenbank nutzen kann. Die weiteren Felder werden wie folgt ausgefüllt:

  • MySQL Host: Hier kommt „localhost“ rein.
  • MySQL database name: Hier kommt der Datenbankname rein, den wir gerade für die neue Datenbank gewählt haben.
  • MySQL username: Benutzername für MySqL.
  • MySQL password: Nun, sagt ja schon der Name… 🙂

Um nun fortfahren zu können, klicke ich auf „Save changes“. Und das war es auch schon. Die Installation ist abgeschlossen und die Installationsroutine ist wieder „locked“.

Erste Schritte

Wenn ich jetzt meinen Browser öffne und folgende Adresse eingebe:

http://server01/baikal/admin

So komme ich auf eine Anmeldungsseite, wo ich mich erst mal mit dem Benutzernamen Admin und dem bei der Konfiguration festgelegten Passwort anmelden muss. Dann öffnet sich das Dashboard mit allerhand nützlichen und statistischen Daten. Hier kann ich auch die Einstellungen einsehen und ggf. ändern.

Bevor ich jetzt aber irgendetwas sinnvolles machen kann, muss ich mir erst mal einen Benutzer anlegen. Dafür klicke ich auf den Link „Users and resources“. Und hier klicke ich auf den Link „Add user“.

Hier müssen nicht viele Felder ausgefüllt werden:

  • Username: Hier kann man einen Benutzernamen festlegen.
  • Display name: Der Name, der angezeigt werden soll.
  • Email: E-Mail-Adresse des Benutzers.

In den beiden Passwortfeldern gibt man noch ein Passwort an und klickt dann auf „Save changes“. Komischerweise ist das Dialogfeld zum Erstellen von Usern aber noch offen. Macht sinn, wenn man noch welche erstellen will. Das will ich nicht, daher gehe ich ganz nach unten, und klicke auf „Close“.

Nun steht mein User auf der Seite. Daneben befinden sich Links, optisch sehen sie eher aus wie Schalter.

Klicke ich auf „Calendars“, sehe ich, welche Kalender für mich bereits vorhanden sind, ich kann Kalender zusätzlich erstellen, bearbeiten oder löschen. Hier befindet sich bereits ein Kalender, der sich „Default calendar“ nennt. Klicke ich daneben auf „Edit“, habe ich folgende Felder:

  • Display name: Das ist der Anzeigename des Kalenders, hier steht „Default calendar“. Das ändere ich mal…
  • Description: Eine Beschreibung, auch das ändere ich mal.
  • Todos: Aktiviert man dies, so kann man hier auch Aufgaben eintragen. Das ist hier schon aktiv, das lasse ich mal so.
  • Notes: Aktiviert man dies, so sind auch Notizen im Kalender möglich. Das ist hier deaktiviert, ich aktiviere das mal.

Anschließend noch auf „Save changes“ und danach auf „Close“ klicken. Weitere Kalender brauche ich erst mal nicht. Sollte ich aber einen privaten und einen geschäftlichen Kalender haben wollen, so könnte ich mir jetzt einen weiteren anlegen. Da ich das nicht will, klicke ich weiter oben auf „Back to users list“.

Klicke ich nun auf „Adress books“, so habe ich die gleiche Ansicht wie eben, nur halt mit Adressbüchern, und nicht mit Kalendern. Also klicke ich auch hier auf Edit, um einige Einstellungen zu prüfen:

  • Display name: Ändere ich, dort steht „Default adress book“.
  • Description: Auch hier gebe ich eine Beschreibung ein.

Mehr gibt es hier nicht, ich klicke also auf „Save changes“ und dann auf „Close“.

In beiden Fällen, direkt über dem Feld „Display name“, steht ein Wert, der später noch wichtig wird, die „Token ID“. Dies ist für die URL wichtig, wenn wir die Adressbücher und Kalender in die jeweiligen Programme eintragen. Bei beiden stand jetzt „default“, aber bei nachträglich erstellten Kalendern und Adressbüchern müsst ihr euch das angucken.

Mit der Weboberfläche sind wir erst mal fertig.

Kalender und Adressbuch nutzen

Um jetzt das Adressbuch und den Kalender mit dem Server synchronisieren zu können, sind mehrere Schritte von Nöten. Am wichtigsten ist, die Daten aus der iCloud zu befreien um sie in den Server importieren zu können. Hat man einen Mac, ist das sogar recht einfach. Wenn nicht, nun, den Fall kann ich jetzt nicht nachstellen, weil ich dieses Problem nicht habe.

Adressbuch sichern

Am einfachsten kann ich mein Adressbuch mit meinem iPhone sichern. Dafür habe ich eine App, die die Kontakte als Excel-Tabelle exportiert, und auch wieder importiert. Also starte ich Excel Contacts, … oh, Moment, die App heißt ja jetzt anders. OK, dann öffne ich halt die App SA Kontakte. 🙂 Hier kann ich meine Kontakte als Excel-Tabelle in meine Dropbox ablegen.

Nachdem ich dies getan habe, kann ich am Mac in der Anwendung Kontakte alle Kontakte löschen. Somit sind diese alle raus aus der iCloud. Anschließend kann ich auf beiden Geräten, dem iPhone und dem Mac, das Synchronisieren der Kontakte mit der iCloud deaktivieren.

Kalender sichern

Hier wüsste ich nicht, ob und wie das mit dem iPhone geht. Dies geht aber wunderbar mit dem Kalender auf dem Mac. Um den Kalender als ICS-Datei zu exportieren geht man folgendermaßen vor:

  • Ich öffne den Kalender am Mac.
  • Im Menü „Ablage“ im Untermenü „Exportieren“ aktiviere ich den Punkt „Exportieren“.
  • Im Dialogfeld wähle ich nun den Namen der Export-Datei und dessen Ort.

Das war es schon. Nach dem Aktivieren der Schaltfläche „Exportieren“ befindet sich die Datei „Kalender.ics“ in meinem Home-Verzeichnis.

Nun kann ich auch den Kalender in der App Kalender auf dem Mac löschen. Zuvor kann es sein, dass ich einen leeren neuen Kalender erstellen muss, weil sich der Standard-Kalender sonst nicht löschen lässt.

Anschließend kann ich die Kalendersynchronisation auf dem iPhone und dem Mac mit der iCloud deaktivieren.

Kalender und Kontakte auf dem Mac einrichten

Um die Kontakte und den Kalender nun am Mac zu nutzen, müssen noch die Accounts dort eingerichtet werden. Für den Kalender geht das wie folgt:

  • Ich öffne die Kalender-App und gehe mit Befehl+, in die Einstellungen.
  • Ich interagiere mit der Symbolleiste und aktiviere das Symbol für „Accounts“.
  • Mit VO+Pfeil-rechts gehe ich bis zur Optsionsschaltfläche „Account hinzufügen“ und aktiviere diese.
  • Aus der Liste der Accounttypen wähle ich „CalDAV-Account hinzufügen“.
  • Im nächsten Dialogfeld wähle ich als Account-Typ „Manuell“, da Mac OSX bestimmt nicht meine Serveradresse kennt… 🙂
  • Bei Benutzername und Passwort gebe ich die Daten ein, die ich bei der Erstellung des Benutzers im Baikal-System gewählt habe.
  • Als Serveradresse gebe ich folgendes ein: „http://subdomain.domain.de/baikal/cal.php/principals/benutzername“. Die Werte müsst ihr je nach euren Gegebenheiten anpassen. Das betrifft den Teil mit der subdomain und domain, sowie den Benutzernamen am Ende.
  • Anschließend noch auf „Erstellen“ klicken und je nach Wunsch einige Anpassungen im Dialogfeld machen, wie Accountname usw.

Das gleiche mache ich jetzt für die Kontakte:

  • Ich öffne die Kontakte-App und gehe mit Befehl+, in die Einstellungen.
  • Ich interagiere mit der Symbolleiste, gehe zum Symbol „Accounts“ und dann auf „Hinzufügen“.
  • In der Liste der Accounttypen wähle ich „Anderer Account“.
  • Accounttyp: CardDAV.
  • Benutzername und Passwort wie in Baikal eingerichtet.
  • Serveradresse: „http://subdomain.domain.de/baikal/card.php/“. Die Werte müsst ihr evtl. an eure Gegebenheiten anpassen.

Anschließend noch auf Erstellen klicken, evtl. noch die Accountbeschreibung anpassen und in den Server-Einstellungen SSL aktivieren.

Bei dem iPhone geht das übrigens nahezu genau so mit den gleichen Adressen. Ihr geht in den Einstellungen auf „Mail, Kontakte, Kalender“. Hier doppeltippt ihr die Taste „Account hinzufügen“. Jetzt könnt ihr als Account-Typ CalDAV oder CardDAV auswählen. Die einzugebenden Daten sind die gleichen, wie für die Mac-Varianten, daher gehe ich jetzt da nicht weiter drauf ein.

SSL-Verschlüsselung

Der Server ist ja schon SSL-verschlüsselt, was ja sogar durch eine Änderung von mir erzwungen wird. Der Mac, als auch das iPhone, werden über das selbsterstellte Zertifikat meckern. Man kann hier aber einmalig festlegen, dass dem Zertifikat getraut werden kann, somit hat man eine SSL-verschlüsselte Verbindung. Das gilt genau so für die Thunderbird-Synchronisation, wie ich sie weiter unten beschreibe. Auch hier kann man dem Zertifikat einmalig vertrauen. Danach ist auch diese Verbindung mit SSL gesichert.

Importieren des zuvor exportierten Kalenders

Die Kalender.ics-Datei, die ich vorhin exportiert hatte, möchte ich ja wieder im neuen Kalender haben. Also öffne ich mal die Kalender-App am Mac. Im Menü „Ablage“ wähle ich den Punkt „Importieren“. Nachdem ich die Datei in der Liste ausgewählt und auf „Importieren“ geklickt habe, dauert es je nach Größe der Datei eine Weile. Anschließend ist noch der Zielkalender zu wählen, fertig!

Adressen importieren

Hierzu bemühe ich mich wieder der SA Kontakte App. Das ist über das iPhone immer noch die einfachste Möglichkeit. Ich aktiviere den Reiter Import, wähle die zuvor exportierte Datei aus der Dropbox aus und starte den Import-Vorgang. Nach kurzer Zeit sind alle meine Adressen wieder in den Kontakten!

Geht auch Thunderbird?

Aber sicher doch! Es sind nur zwei Addons nötig, Lightning für Kalender und Aufgaben und der SOGO Connector für CardDAV. Lightning ist im Addon-Bereich des Thunderbirds zu finden, den SOGO Connector kann man hier downloaden. Die XPI-Datei des SOGO Connectors muss dann in Thunderbird unter „Extras“ und dort unter „Addons“ aus der Datei installiert werden.

Kalender in Lightning

Um den Kalender in Lightning einzubinden gehe ich wie folgt vor:

  • In Thunderbird, im Menü „Datei“, dort unter „Neu“ wähle ich „Kalender“.
  • Aus der Auswahl wähle ich „Im Netzwerk“.
  • Bei Kalenderformat wähle ich „CalDAV.
  • Die Adresse ist: „http://subdomain.domain.de/baikal/cal.php/calendars/benutzername/default“. Die Werte müsst ihr an eure Gegebenheiten anpassen. Dabei ist „default“ die Token ID des Standardkalenders. Wollt ihr einen zweiten Kalender, den ihr im Baikal-System hinterlegt habt, nutzen, so muss hier dessen Token ID hin. Wie man diese herausfindet, habe ich ja weiter oben schon beschrieben.
  • Offline-Unterstützung habe ich aktiviert und klicke auf „Weiter“.
  • Im nächsten Dialog vergebe ich einen Namen für den Kalender und gebe auch meine Mailadresse an. Anschließend klicke ich auf „Weiter“.
  • Nach einer Weile erscheint ein Dialogfeld, welches einem die Fertigstellung des Kalenders meldet. Hier klickt man auf „Fertig“.

Der Kalender ist jetzt aber noch nicht zu sehen. Zunächst muss ich die Maus irgendwie zum Kalendereintrag bringen, mit rechter Maustaste klicken und aus dem Kontextmenü „Synchronisieren“ wählen. Nun werde ich nach Benutzernamen und Kennwort gefragt, und ob ich die Daten speichern will. Ab jetzt kommen die Kalenderdaten auf meinen Rechner.

Adressbuch in Thunderbird einrichten

Um das Adressbuch in Thunderbird einzubinden, gehe ich wie folgt vor. Dass der SOGO-Connector korrekt installiert wurde, setze ich einfach mal voraus… 🙂

  • In Thunderbird öffne ich aus dem Menü „Extras“ das Adressbuch.
  • Aus dem Menü „Datei“ und dort aus dem Untermenü „Neu“ wähle ich „Remote-Adressbuch“.
  • Verbindungsname: Ein Name für das Adressbuch.
  • URL: „http://subdomain.domain.de/baikal/card.php/addressbooks/benutzername/default“. Gegebenenfalls müsst ihr die Werte für euch anpassen. Auch hier gilt, für ein zweites Adressbuch muss „default“ durch die Token ID des zweiten Adressbuches ersetzt werden.

Die anderen Einstellungen könnt ihr so vornehmen, wie euch danach ist. Das ist sowieso zu meist Geschmackssache, wann man über was informiert werden will. Jedenfalls klicke ich nun auf OK.

Damit die Kontakte nun sichtbar werden, also die erste Synchronisation durchgeführt wird, muss ich auf mein neues Adressbuch mit der rechten Maustaste Klicken und aus dem Kontextmenü „Synchronisieren“ wählen. Nach Eingabe von Benutzernamen und Passwort sollten die Daten eintrudeln. Allerdings, wenn ihr den Kalender schon erfolgreich synchronisiert habt, wird nicht mehr nach Benutzername und Passwort gefragt, weil das ja dieselben sind, und Thunderbird diese ja schon kennt.

Fazit

Jetzt habe ich Kontakte und Kalender auf meinem eigenen Server, mein iPhone, Mac und mein Windows-PC synchronisieren sich damit prima. In der Familie habe ich auch noch jemanden mit einem Android-Gerät. Vielleicht kann ich den ja überreden, sich mal CalDAV-Sync und CardDAV-Sync auf sein Gerät zu installieren und mal zu probieren, ob es damit auch geht. Einen User kann ich ja mit wenigen Klicks erstellen. 🙂