Schlagwort-Archive: Tutorial

RHEL/CentOS 7 – Root Passwort zurücksetzen

In diesem Tutorial wird beschrieben, wie das root-Passwort bei RHEL/CentOS 7 mit Bordmitteln zurückgesetzt werden kann. Mit Bordmitteln bedeutet, dass hierbei keine externen Bootmedien verwendet werden.

Aufgepasst! Macht man bei der Ausführung der folgenden Prozedur Fehler, können diese dazu führen, dass man jeglichen Zugang zu einem System verliert. Möchte man die Vorgehensweise üben, empfehle ich, dies ausschließlich auf Testsystemen zu tun.

Die Ausgangssituation

Das root-Passwort eines RHEL/CentOS 7 Servers ist unbekannt und muss zurückgesetzt werden. Es ist keine geöffnete root-Shell vorhanden und es ist kein Benutzer am System angemeldet, welcher über vollständige sudo-Berechtigungen verfügt.

Das Passwort soll ohne Einsatz externer Bootmedien zurückgesetzt werden.

Update 2019-12-17: Alternativ zur unten beschriebenen Vorgehensweise, kann bei Systemen, mit sehr großen Dateisystemen die in KB4661061 beschriebene Vorgehensweise genutzt werden.

Vorgehensweise

Schritt 1: Es wird ein Neustart des Systems durchgeführt. Sobald das Grub2-Boot-Menü erscheint, wird der Bootloader-Countdown durch Drücken einer beliebigen Taste unterbrochen.

Nun wählt man den gewünschten Eintrag (dies ist meist der erste in der Liste) aus und wechselt mit Drücken der Taste ‚e‘ in den Bearbeitungsmodus (siehe Abbildung 1).

abb1-grub2-menu

Abbildung 1: Grub2-Bootmenü

Schritt 2: Der Cursor wird zur Kernel-Kommandozeile bewegt. Diese beginnt üblicherweise mit dem Wort linux16. Hier wird, wie in Abbildung 2, ein „rd.break“ an das Ende der Zeile angefügt.

edit-kernel-command-line

Abbildung 2: Bearbeitete Startparameter für den Kernel

Die Bearbeitung wird durch Drücken der Tastenkombination Strg+x beendet und der Bootvorgang fortgesetzt. Der Bootvorgang wird an der Stelle angehalten, an der man sich in der Initial-Ram-Disk befindet, direkt bevor das eigentliche System gestartet wird. An dieser Stelle findet man den Inhalt des eigentlichen /-Dateisystems unterhalb von /sysroot.

Schritt 3: Nach Schritt 2 befindet man sich nun in einer root-Shell. Da das eigentliche Dateisystem unterhalb von /sysroot schreibgeschützt eingehängt wurde, muss dieses zunächst remountet werden. Dies geschieht mit dem folgenden Kommando (vgl. Abbildung 3):

switch_root:/# mount -oremount,rw /sysroot
remount-sysroot

Abbildung 3: Remount /sysroot

Schritt 4: In diesem Schritt wechselt man mittels chroot[1. chroot – wiki.ubuntuusers.de] in das /sysroot-Verzeichnis und setzt ein neues Passwort für den Benutzer root.

switch_root:/# chroot /sysroot
sh-4.2# passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Wichtig: SELinux[2. Einführung in das grundlegende Konzept von SELinux] ist zu diesem Zeitpunkt noch nicht aktiv. Dies bedeutet, dass alle neuen Dateien ohne einen entsprechenden SELinux-Kontext erstellt werden. Das Programm passwd arbeitet so, dass es erst eine neue Datei erstellt und mit dieser anschließend die alte Datei überschreibt. Die neue Datei /etc/shadow besitzt damit keinen SELinux-Kontext.

Um sicherzustellen, dass alle Dateien (inkl. der /etc/shadow) während des Bootvorgangs mit einem SELinux-Label versehen werden, muss die Datei autorelabel im aktuellen Verzeichnis erstellt werden:

sh-4.2# touch /.autorelabel

Wichtig: Sämtliche Dateien und Verzeichnisse werden erneut mit einem SELinux-Label versehen. Dies kann bei großen Dateisystemen einige Zeit dauern. Um Zeit zu sparen, können Dateisysteme (außer dem Dateisystem auf dem sich die /etc/shadow befindet) in der /etc/fstab auskommentiert werden. Nachdem das SELinux-Relabeling durchgeführt und das System gestartet wurde, können diese wieder eingehängt werden.

Abschließend verlässt man durch zweimalige Eingabe von exit zuerst die chroot-Umgebung und anschließend die Debug-Shell der Ram-Disk (vgl. Abbildung 4). Das System setzt den Bootvorgang an der Stelle fort, an der dieser unterbrochen wurde.

autrelabel

Abbildung 4

Es werden zunächst sämtliche Dateien von SELinux relabelt und anschließend ein Neustart ausgeführt.

Hinweis: Vergisst man die Datei .autorelabel zu erstellen und wird SELinux im Modus „Enforcing“ ausgeführt, kann man sich nach einem Neustart nicht am System anmelden. Man muss dann erneut booten und obige Schritte ausführen, um die Datei erstellen zu können.

Wurden die oben aufgeführten Schritte erfolgreich angewendet, kann man sich nun mit dem vergebenen Passwort am System anmelden und hat damit die Kontrolle zurückgewonnen.

Auch wenn ich diese Anleitung mehrere Male erfolgreich getestet habe, wünsche ich uns allen, dass wir sie möglichst niemals brauchen werden.

Einführung in das grundlegende Konzept von SELinux

SELinux[1. SELinux – Wikipedia] (Security-Enhanced Linux; engl. „sicherheitsverbessertes Linux“) ist eine Erweiterung des Linux-Kernels, mit der eine zusätzliche Sicherheitsschicht in das Betriebssystem eingezogen wird.

In dieser Einführung wird das zu Grunde liegende Konzept kurz vorgestellt und erläutert, welche Modi SELinux besitzt, wie diese angezeigt und umgeschaltet werden können. An einem einfachen Beispiel mit dem Apache Webserver wird dargestellt, wie SELinux in der Praxis wirkt. Des Weiteren wird mit Hilfe des Beispiels das Vorgehen bei einer Fehleranalyse erläutert.

SELinux ist dazu gedacht, das bestehende Berechtigungskonzept unter Linux zu erweitern, um zu verhindern, dass kompromittierte Dienste auf Daten zugreifen, auf die kein Zugriff erforderlich ist.

Als einfaches Beispiel mag hier der Webserver Apache[2. Apache HTTP Server – Wikipedia] dienen.

Dieser liest die Dateien, welche er ausliefern soll, in der Standardkonfiguration aus dem dem Verzeichnis /var/www/html. Daneben darf der Dienst z.B. auch alle Verzeichnisse und Dateien unterhalb der Verzeichnisse /tmp und /var/tmp lesen.

user@host:~$ ls -ld /tmp
drwxrwxrwt. 5 root root 4096 Nov 27 19:05 /tmp
user@host:~$ ls -ld /var/tmp
drwxrwxrwt. 2 root root 4096 Nov 10 06:34 /var/tmp
user@host:~$

Grundsätzlich hat der Dienst Zugriff auf alle Verzeichnisse und Dateien, welche den Lese- bzw. Schreibzugriff für alle Benutzer erlauben.

SELinux kann nun dazu genutzt werden, um genau diesen Zugriff zu unterbinden. Die folgende Abbildung soll dies verdeutlichen:

selinux-example-apache

Mögliche Zugriffe mit und ohne SELinux am Beispiel des Apache

SELinux stellt einfach gesprochen ein Regelwerk dar, nach welchem bestimmt wird, auf welche Verzeichnisse, Dateien, Prozesse und Ports ein Dienst zugreifen darf. Dazu erhalten diese Objekte ein Label mit einem Security Context. Nur wenn das SELinux-Regelwerk den Zugriff von einer Ressource auf eine weitere Ressource explizit erlaubt, ist der Zugriff gestattet. Andernfalls wird die Interaktion unterbunden. Dabei unterscheidet SELinux die verschiedenen Label nach Kontexten. Diese sind:

  • user
  • role
  • type
  • sensitivity

Im Folgenden wird ausschließlich der Kontext „type“ weiter betrachtet. So besitzt z.B. der Dienst Apache das Label httpd_t, während Dateien unterhalb von /var/www/html das Label httpd_sys_content_t tragen. Da SELinux eine Regel besitzt, welche den Zugriff des Kontext httpd_t auf Dateien und Verzeichnisse mit dem Kontext httpd_sys_content_t gestattet, kann der Apache die Datei index.html aus dem Verzeichnis /var/www/html anzeigen:

output-index-html

Ausgabe der Datei /var/www/html/index.html

Obiger Screenshot enthält neben dem obligatorischen „Hallo Welt“ auch noch die Ausgabe des Verzeichnis-Listings, welches neben den üblichen Angaben wie Berechtigungen, Benutzer und Gruppe auch den SELinux-Kontext mit ausgibt. Wie man SELinux steuert und sich den Kontext von Verzeichnissen, Dateien und Prozessen anzeigen lässt, wird im Folgenden Abschnitt erläutert.

Steuerung von SELinux

SELinux kennt drei Modi:

  • Enforcing
  • Permissive
  • Disabled

In welchem Status sich SELinux befindet, kann mit dem Kommando getenforce abgefragt werden:

[root@centos ~]# getenforce
Enforcing
[root@centos ~]#

Obige Ausgabe bedeutet, dass SELinux im Modus „Enforcing“ ausgeführt wird. In diesem Modus verhindert SELinux Zugriffe, welche nicht explizit durch das Regelwerk erlaubt werden. Im Unterschied dazu werden diese Zugriffe im Modus „Permissive“ nicht verhindert, sie werden jedoch protokolliert. Dieser Modus eignet sich daher hervorragend, um das aktuelle Verhalten von Diensten zu analysieren und die Konfiguration ggf. anzupassen. Die Umschaltung zwischen den Modi „Enforcing“ und „Permissive“ kann zur Laufzeit erfolgen:

[root@centos ~]# getenforce
Enforcing
[root@centos ~]# setenforce 0
[root@centos ~]# getenforce
Permissive
[root@centos ~]# setenforce 1
[root@centos ~]# getenforce
Enforcing
[root@centos ~]#

Der Standard-Modus wird in der Datei /etc/selinux/config festgelegt.

Anzeige der SELinux-Kontexte

Der kleine Punkt (im Screenshot rot markiert) hinter den Berechtigungen zeigt an, dass ein SELinux-Kontext für eine Datei bzw. ein Verzeichnis existiert:

Der Punkt zeigt einen vorhandenen SELinux-Kontext an

Der Punkt zeigt einen vorhandenen SELinux-Kontext an

Welchen Kontext eine Datei bzw. ein Prozess besitzt, kann angezeigt werden, indem bekannte Kommandos mit der Option „-Z“ benutzt werden. Das folgende Listing zeigt einige Beispiele:

[root@centos ~]# ps -eZ | grep httpd
system_u:system_r:httpd_t:s0     2876 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2920 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2921 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2922 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2923 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2924 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2925 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     3152 ?        00:00:00 httpd
[root@centos ~]# ls -lisaZ /var/www/html/
total 12
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 ..
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
[root@centos ~]# ls -lisaZ /var/tmp
total 28
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       .
drwxr-xr-x. root root system_u:object_r:var_t:s0       ..
drwxr-xr-x. abrt abrt system_u:object_r:abrt_var_cache_t:s0 abrt
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-colord.service-MczkBW
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-cups.service-c3Aouq
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-httpd.service-oAqhlb
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-rtkit-daemon.service-xpSsO2
[root@centos ~]# ls -lisaZ /tmp |head -n4
total 96
drwxrwxrwt. root      root      system_u:object_r:tmp_t:s0       .
dr-xr-xr-x. root      root      system_u:object_r:root_t:s0      ..
-rw-r--r--. root      root      system_u:object_r:tmp_t:s0       anaconda.log
[root@centos ~]#

Die Datei index.html hat bei ihrer Erstellung im Verzeichnis /var/www/html automatisch den korrekten Kontext httpd_sys_content_t erhalten und kann daher im Webbrowser angezeigt werden. Wird eine Datei im Verzeichnis /tmp erstellt, erhält diese automatisch den Kontext user_tmp_t:

[root@centos ~]# echo 'TEST' > /tmp/test.txt
[root@centos ~]# ls -lisaZ /tmp/test.txt
-rw-r--r--. root root unconfined_u:object_r:user_tmp_t:s0 /tmp/test.txt
[root@centos ~]#

Was tun, wenn’s klemmt?

Um zu erläutern, wie man einem Fehler auf die Spur kommt, baue ich zuerst einen ein. Dazu verschiebe ich die im vorangegangenen Abschnitt erzeugte Datei in das DocumentRoot des Apache und versuche, diese im Browser aufzurufen.

forbidden

Forbidden

SELinux verhindert den Zugriff des Dienstes „httpd“ auf die Datei „text.txt“, da keine Regel existiert, welche den Zugriff vom Kontext httpd_t auf user_tmp_t explizit erlaubt. Doch wie kann man dies feststellen, wenn man nicht bereits zu Beginn um den falschen Kontext weiß?

Zuerst wirft man einen Blick auf die Dateiberechtigungen, welche aber keinen Fehler erkennen lassen:

[root@centos ~]# ls -lZ /var/www/html/
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
-rw-r--r--. root root unconfined_u:object_r:user_tmp_t:s0 test.txt
[root@centos ~]#

Da die Dateiberechtigungen als Fehlerquelle ausscheiden und in diesem Beispiel keine POSIX-ACL[3. ACL – wiki.ubuntuusers.de] verwendet werden, bleibt nur noch SELinux als Fehlerquelle übrig. Daher suchen wir einmal in /var/log/audit/audit.log nach Ereignissen vom Typ „AVC“:

[root@centos ~]# tail /var/log/audit/audit.log | grep AVC
type=AVC msg=audit(1480277043.225:537): avc:  denied  { open } for  pid=2922 comm="httpd" path="/var/www/html/test.txt" dev="sda1" ino=924457 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

Treffer! Um die Sache weiter zu analysieren, untersuchen wir als nächstes /var/log/messages (Ausgabe gekürzt). Hinweis: Unter RHEL 7 muss das Paket ’setroubleshoot-server‘ installiert sein, damit SELinux-Ereignisse auch in /var/log/messages geloggt werden (siehe Abschnitt 4.2. Which Log File is Used).

Nov 27 21:29:13 centos setroubleshoot: SELinux is preventing /usr/sbin/httpd from open access on the file /var/www/html/test.txt. For complete SELinux messages. run sealert -l 7a6417b8-06e2-4499-8f0f-ed0bb16f2b2a

Hier findet sich eine Bestätigung, dass SELinux den Zugriff blockiert hat und ein Vorschlag, wie dieser Vorfall genauer analysiert werden kann. Damit lassen sich umfassende Informationen abrufen, welche sogar die Lösung mit ausgeben (Ausgabe gekürzt):

[root@centos ~]$ sealert -l 7a6417b8-06e2-4499-8f0f-ed0bb16f2b2a
SELinux is preventing /usr/sbin/httpd from open access on the file /var/www/html/test.txt.

*****  Plugin restorecon (92.2 confidence) suggests   ************************

If you want to fix the label. 
/var/www/html/test.txt default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/html/test.txt

*****

Der Bericht gibt an, wie das Standard-Label für die Datei text.txt gesetzt sein sollte. Darüber hinaus ist dem Bericht der Befehl zu entnehmen, mit dem die Label wieder auf den Standardwert zurückgesetzt werden können. Nachdem dieser Befehl ausgeführt wurde, kann die Datei text.txt im Webbrowser geöffnet werden.

[root@centos ~]# /sbin/restorecon -v /var/www/html/test.txt
/sbin/restorecon reset /var/www/html/test.txt context unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
[root@centos ~]#
correct-selinux-context

Aufruf von test.txt mit korrektem SELinux-Kontext

Schlusswort

Es wurde in das grundlegende Konzept von SELinux und die möglichen Betriebsmodi eingeführt. Darüber hinaus wurde erläutert, wie man sich die zu einem Objekt gehörenden SELinux-Kontexte anzeigen lassen kann und wie diese auf einen Standard-Kontext zurückgesetzt werden können. Abschließend wurde ein kleiner Einblick in das Vorgehen zur Fehleranalyse gegeben.

Damit bin ich am Ende dieser kleinen Einführung angekommen, wobei das Thema SELinux damit noch lange nicht abschließend behandelt ist. Für weiterführende Informationen sei an dieser Stelle auf die Dokumentation der einzelnen Distributionen verwiesen.[4. RHEL 7: SELinux User’s and Administrator’s Guide: Basic and advanced configuration of Security-Enhanced Linux (SELinux) {en}] [5. SELinux – CentOS Wiki {en}] [6. SELinux – Fedora Project {en}]

Quellen und weiterführende Links

Thunderbird Adressbuch mit ownCloud Kontakten synchronisieren

Dieser Artikel basiert auf der offiziellen ownCloud Dokumentation[1. Thunderbird – Synchronize Addressbook] und beschreibt die Einrichtung eines Thunderbird-Adressbuchs zur Synchronisation mit den ownCloud-Kontakten.

contacts-carddav-link

Menü zum CardDAV-Link

Neben dem Thunderbird-Mailclient wird die Erweiterung Lightning[2. Mozilla Thunderbird Lightning Calendar] benötigt. Wie man diese Erweiterung nutzt, um z.B. den ownCloud-Kalender mit Thunderbird zu synchronisieren, habe ich bereits an dieser Stelle beschrieben.

Um neben dem Kalender auch die Kontakte synchronisieren zu können, wird darüber hinaus der Sogo Connector[3. Sogo Connector] benötigt. Am einfachsten installiert man diese Erweiterung, indem man einen Rechtsklick auf die Erweiterung ausführt und „Ziel speichern unter..“ aus dem Kontextmenü auswählt. In Thunderbird richtet man diese Erweiterung ein, indem man im Add-on Menü die Option „Add-on aus Datei installieren…“ auswählt.

Sind die beiden Erweiterungen erfolgreich installiert, kann das Adressbuch eingerichtet werden. Dazu öffnet man das Thunderbird-Adressbuch aus der Symbolleiste. Im sich öffnenden Fenster wählt man Datei->Neu->Remote-Adressbuch.

Der Verbindungsname kann frei gewählt werden. Bei URL wird der CardDAV-Link eingetragen, den man in den Einstellungen der ownCloud-Kontakte findet. Die Einstellungen verbergen sich hinter dem kleinen Zahnradsymbol.

remote-addressbook-settings

Remote-Adressbuch-Einstellungen

Die weiteren Optionen können nach den persönlichen Vorlieben gewählt werden. Einzig den Haken bei „Nur lesbar“ sollte man nicht setzen, wenn man über Thunderbird auch neue Kontakte in der ownCloud anlegen möchte.

Fertig. Damit sind die ownCloud-Kontakte in den Mailclient integriert und lassen sich z.B. für die Autovervollständigung der E-Mail-Adressen in neuen Nachrichten nutzen.

Testinstanz für einen WordPress Blog erstellen

Um Änderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu können, möchte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe benötigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.

Voraussetzungen

Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich über ein Kundencenter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.

Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.

Daten sichern

Um die spätere Testinstanz mit den Daten des Live-Blogs füttern zu können, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.

Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.

Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.[1. http://www.mysqldumper.de/] Mit diesem Werkzeug kann man über eine einfach zu bedienende Weboberfläche ein Backup seiner Datenbank erstellen. Dieses Backup wird anschließend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.

Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.[2. http://www.filezilla.de/]

Serverkonfiguration

Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX.[3. http://nginx.org/]

Für meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:

example.org/
├── logs
│   ├── access.log
│   └── error.log
└── public
    └── index.html

2 directories, 3 files

So wird für jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public. Die Datei index.html stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.

Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public abgelegte Seite auch ausliefert.

Um die spätere Testinstanz über die gleiche URL aufrufen zu können, wie den Live-Blog, wird ein Eintrag in die /etc/hosts eingefügt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.

Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begrüßt.

Zugriff beschränken

Während man eine neue Konfiguration testet, können Fehler passieren. Diese können zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. Für gewöhnlich ist nicht gewünscht, dass ein Benutzer dies sieht. Evtl. möchte man auch einfach nicht, dass Neuerungen zufällig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog überführt wurden.

Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschränken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.

Dazu eignet sich für NGINX-Benutzer das Modul ngx_http_auth_basic_module.[4. http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html] Nutzer von Apache können .htaccess-Dateien[5. .htaccess – Wikipedia] verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.

Zuerst wird die .htpasswd-Datei erstellt, welche Benutzernamen und Passwort für die Authentifizierung enthält.

sudo touch /etc/nginx/conf.d/.htpasswd

Um das Passwort in verschlüsselter Form speichern zu können wird das Paket apache2-utils benötigt. Dieses enthält das Programm htpasswd, mit welchem Benutzername und Passwort erzeugt werden.

:~$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd BENUTZERNAME
New password: 
Re-type new password: 
Adding password for user BENUTZERNAME

Der Benutzer, unter dessen Kontext der Webserver (NGINX) läuft, muss Zugriff auf die .htpasswd erhalten.

:~$ sudo chown www-data:www-data /etc/nginx/conf.d/.htpasswd

Nun öffnet man die Konfigurationsdatei für die Testseite, welche für gewöhnlich unterhalb von /etc/nginx/sites-available/ liegt. Hier ist folgende Konfiguration zu integrieren:

location / {
    auth_basic           "Authentifizierung erforderlich!";
    auth_basic_user_file conf.d/.htpasswd;
}

auth_basic aktiviert die Überprüfung von Benutzername und Passwort. auth_basic_user_file gibt den Pfad an, wo die .htpasswd-Datei liegt, gegen die geprüft wird.

Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler überprüfen und bei Bestehen der Prüfung die Konfiguration neu laden.

:~$ sudo service nginx configtest 
 * Testing nginx configuration                    [ OK ] 
jkastning@rs212997:~$ sudo service nginx reload
 * Reloading nginx configuration nginx            [ OK ]

Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.

Daten einspielen

Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als nächstes die Daten aus dem Live-Blog eingespielt.

Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll genutzt.

DocumentRoot

Die gesicherten Dateien und Verzeichnisse, müssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis /var/www/example.org/public/. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.

sudo chgrp -R www-data /var/www/example.org/public

Die Datenbank

Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.

Wer hierbei Hilfe zur Syntax benötigt, kann im Artikel „Häufig verwendete MySQL-Befele“ nachlesen.

Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.

mysql -u root -p db_name < db_sicherung.sql

Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl überprüfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.

mysql -u db_benutzer -p db_name

Fertig. Mein Testblog läuft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. :-)

Update vom 24.12.2016

Bei der gestrigen Aktualisierung der Testinstanz musste ich feststellen, dass zwar die Startseite des Blogs geladen wird, jedoch alle Artikelaufrufe in einen 404-Fehler laufen.

Die Ursache für diese Fehler liegt darin begründet, dass ich mit Nginx einen anderen Webserver verwendet, als mein Webhoster. Dieser behandelt die Permalinks von WordPress anders, als z.B. ein Apache-Webserver mit dem Modul mod_rewrite.

Eine Lösung für dieses Problem habe ich ziemlich schnell in der Nginx Library[6. Nginx Library - WordPress Permalinks {en}] gefunden. Es wird die try_files-Direktive[7. Nginx try_files directive {en}] verwendet, um aufgerufene URLs zur weiteren Behandlung an die index.php von WordPress weiterzuleiten.

Die Einrichtung ist relativ einfach. Das Vorgehen unterscheidet sich, je nach dem ob WordPress direkt im Wurzelverzeichnis einer Domain oder in einem Unterverzeichnis installiert ist. Im Folgenden werden beide Fälle betrachtet.

WordPress im Wurzelverzeichnis

Liegt die WordPress-Installation im Wurzelverzeichnis der Domain z.B. unter http://www.example.com, sucht man in der Konfigurationsdatei der Seite nach dem Block location /. Diesem Block wird folgende Zeile hinzugefügt:

try_files $uri $uri/ /index.php?$args;

Der vollständige Block sollte anschließend wie folgt aussehen:

location / {
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

WordPress in einem Unterverzeichnis

Liegt die WordPress-Installation in einem Unterverzeichnis der Domain z.B. unter http://www.example.com/wordpress, muss der Konfigurationsdatei ein Block nach dem Muster location /wordpress/ hinzugefügt werden, welcher wie folgt aussieht:

location /wordpress/ {
  try_files $uri $uri/ /wordpress/index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

Ein Kalender für die Terminverwaltung

Nachdem ich in diesem Jahr bereits die Kontrolle über meine E-Mail-Postfächer zurück erlangt habe[1. Der eigene Mailserver – Start der Artikelreihe], gehe ich in diesem Artikel auf die Einrichtung eines Kalenders für die Terminverwaltung im Web und auf diversen Clients ein.

Zu Beginn des Artikels stehen meine Anforderungen an eine Kalender-Lösung. Anschließend gebe ich einen kleinen Überblick über verschiedene kostenlose Lösungen, bevor ich die Lösung näher beschreibe, für die ich mich letztendlich entschieden habe.

Eines sei vorab schon verraten. Bei allen Lösungen handelt sich sich um Software, die auf einem Linux-Webserver installiert werden kann. Die Verwendung eines Root-Servers stellt die größtmögliche Kontrolle über das eigene System und die eigenen Daten sicher.

Anforderungen

Die gesuchte Lösung soll die folgenden Anforderungen erfüllen:

  1. Der Kalender kann auf einem eigenen Server gehosted werden.
  2. Die Terminverwaltung kann über einen Webbrowser erfolgen.
  3. Der Kalender kann unter den mobilen Betriebssystemen Android und iOS genutzt werden.
  4. Eine Nutzung des Kalenders mit dem Mozilla Thunderbird-Plugin Lightning ist ebenfalls möglich.
  5. Mit Hilfe des Kalenders können Termine zwischen den genannten Betriebssystemen und Anwendungen synchronisiert werden.

Kurz angeschaut

Auf der Suche nach einer Lösung habe ich mir die folgenden Projekte kurz angeschaut. Auch wenn ich mich im Endeffekt für ownCloud entschieden habe, führe ich sie hier auf. Evtl. ist jemandem von euch mit einer dieser Lösungen am besten gedient.

Bei sabre/dav[2. Homepage sabre/dav] handelt es sich um einen CardDAV, CalDAV und WebDAV Server. SabreDAV ist komplett in PHP geschrieben und bietet vielfältige Möglichkeiten zum Teilen und Delegieren.

DAViCal[3. DAViCal Homepage] ist ein Server, welcher Kalendereinträge im iCalendar-Format speichern und bereitstellen kann. DAViCal ist in den Ubuntu-Paketquellen enthalten und im Ubuntuusers.de Wiki existiert ein deutschsprachiger Artikel[4. DAViCal im Ubuntuusers.de Wiki] dazu.

Radicale[5. Radicale – CalDAV and CardDAV Server] ist ein sehr einfach einzurichtender Server. Er ist in Python geschrieben und wurde unter der GPL 3 veröffentlicht.

Der ownCloud-Kalender

Meine Entscheidung ist auf den ownCloud[6. ownCloud Documentation Overview]-Kalender gefallen. Er erfüllt alle oben genannten Anforderungen. Darüber hinaus benutze ich bereits eine ownCloud-Instanz zur Verwaltung meiner Kontakte, Bilder und diverser Dateien.

Die Nutzung des ownCloud-Kalenders im Webbrowser ist selbsterklärend. Daher gehe ich an dieser Stelle nur auf die Einrichtung unter iOS, dem Thunderbird-Plugin Lightning und Android ein.

Für alle drei Clients benötigen wir die CalDAV-Adresse des Kalenders. Diese kann man sich anzeigen lassen, indem man auf das Zahnrad unten Links in der Kalenderansicht klickt.

owncloud_calendar

Ansicht eines ownCloud-Kalenders

Einrichtung unter iOS

Die hier beschriebene Einrichtung gilt für iOS 7.1.2. Für andere Versionen müssen die einzelnen Schritte evtl. an die jeweilige Version angepasst werden.

  1. Gehe zu „Einstellungen“ -> „Mail, Kontakte, Kalender“ -> „Account hinzufügen“.
  2. Wähle den Punkt „Andere“ -> „CalDAV-Account hinzufügen“.
  3. Bei „Server“ wird der Hostname eingetragen. Dies ist typischerweise der Name, den man in die Adresszeile des Webbrowsers einträgt, um sich mit der eigenen ownCloud zu verbinden. Benutzername und Kennwort entsprechen den Informationen, mit denen man sich an seiner ownCloud anmeldet. Anschließend kann man noch eine Beschreibung eingeben, um den Kalender in der Übersicht wiederzuerkennen.
  4. Im weiteren Verlauf aktiviert man SSL, falls der eigene Server dies unterstützt.
  5. Bei „Account-URL“ wird die URL eingetragen, welche im ownCloud-Kalender unter „iOS/OS X CalDAV-Adresse“ angezeigt wird.

Viel Spaß mit dem ownCloud-Kalender auf dem iPhone.

Einrichtung in Lightning

Lightning[7. Lightning – Thunderbird Mail DE] ist ein Kalenderplugin für den Mailclient Thunderbird. Es kann über die Thunderbird-Einstellungen -> Add-ons recht simpel gesucht und installiert werden.

In der Ansicht „Erweiterungen“ können die Lightning-Einstellungen konfiguriert werden. Die Dialogfelder sind übersichtlich und zum Großteil selbsterklärend. Anschließend geht es in der Kalenderansicht weiter.

Mit einem Rechtsklick in die Kalenderspalte kann ein neuer Kalender hinzugefügt werden. Im Dialogfenster ist „Im Netzwerk“ auszuwählen und im darauf folgenden Fenster die CalDAV-Adresse des Servers anzugeben.

calendar-caldav-link

CalDAV-Link des Kalenders

Doch Achtung, hier muss der korrekte CalDAV-Link verwendet werden. Dies ist nicht, wie man vermuten könnte, der primäre CalDAV-Link, welcher unter den Kalendereinstellungen der ownCloud zu sehen ist. Statt dessen ist der CalDAV-Link zu verwenden, der direkt neben dem Kalender eingeblendet werden kann.

Im folgenden Dialogfeld kann noch eine Farbe für den Kalender ausgewählt werden und es empfiehlt sich die Offline-Funktionalität zu aktiveren. So kann man den Kalender auch verwenden, wenn keine Online-Verbindung besteht.

Damit ist die Einrichtung des ownCloud-Kalenders in Lightning abgeschlossen.

Einrichtung unter Android

Ich habe den Kalender unter Android 5.0.2 durchgeführt. Die Einrichtung sollte unter den übrigen Android-Versionen jedoch ähnlich verlaufen.

Um den ownCloud-Kalender unter Android nutzen zu können, muss zuerst eine App installiert werden, welche die CalDAV-Unterstützung nachrüstet. Ich habe mich für die kostenlose App „Cal DAV Sync Free Beta“ entschieden. In diese werden Benutzername und Passwort eingetragen, mit denen man sich an seiner ownCloud anmeldet. Hier wird die primäre CalDAV-Adresse aus den Kalendereinstellungen eingetragen, um den Kalender einzubinden.

Damit sind die wichtigsten Einstellungen vorgenommen und der Einrichtungsdialog kann bis zum Ende durchlaufen werden.

Fazit

Die Einrichtung des ownCloud-Kalenders in den verschiedenen Anwendungen und Betriebssystemen ist nicht schwer, sofern man die korrekte CalDAV-Adresse für die jeweilige Anwendung verwendet.

Damit ist ein weiterer Schritt abgeschlossen, die Kontrolle über die eigenen Daten zurückzugewinnen. Der Google-Kalender kann nun in den Ruhestand geschickt werden. :-)

Die Termine können nun auf den verschiedenen Geräten verwaltet und synchronisiert werden. Für mich eine zufriedenstellende Lösung.

Automatische Installation von Sicherheitsupdates

Wie bei jedem Betriebssystem sollten auch bei Ubuntu regelmäßig Updates installiert werden. Dabei handelt es sich um Fehlerkorrekturen, welche die Stabilität des Systems verbessern und insbesondere potenzielle oder erwiesene Sicherheitslücken schließen.[1. Ubuntuusers Wiki: Konfiguration der automatischen Aktualisierung]

Die Installation von Sicherheitsupdates ist eine Aufgabe, die man hervorragend automatisieren kann, um administrativen Aufwand zu sparen. Dazu installiert man unter Ubuntu das folgende Paket:

sudo apt-get install unattended-upgrades

Um die automatischen Updates zu aktivieren, wird die Datei /etc/apt/apt.conf.d/10periodic angelegt bzw. bearbeitet. Diese sollte mindestens die folgenden Einträge enthalten:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";

In der Datei /etc/apt/apt.conf.d/50unattended-upgrades wird festgelegt, welche Art von Updates automatisch installiert werden sollen. Möchte man ausschließlich Sicherheitsupdates automatisch installieren lassen, so ist dies mit der folgenden Konfiguration möglich:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Damit ist schon alles Nötige getan. Unter /var/log/unattended-upgrades findet man noch ein Log, um überprüfen zu können, welche Änderungen am System durch die automatische Updateinstallation durchgeführt wurden.

The_Excerpt in Twenty Twelve mit Child-Theme

Dieser Artikel beschreibt die Anpassung des Standartthemes “Twenty Twelve”. Es wird ein sogenanntes “Child Theme” erzeugt und so angepasst, dass auf der Startseite und den Kategorieseiten nur Auszüge der Artikel angezeigt werden und nicht der komplette Artikel.

Child Theme

Ein WordPress Child Theme ist ein Theme, welches die Funktionalität eines anderen Themes, des sogenannten Parent Themes übernimmt und um eigene Anpassungen ergänzt. Die Verwendung eines Child Themes bietet sich an wenn man ein Theme anpassen/verändern möchte. Diese Anpassungen sollten nicht, im Standardtheme vorgenommen werden, da sie bei einem Update des Themes überschrieben werden und verloren gehen. Lagert man die Änderungen in ein Child Theme aus bleiben sie bei einem Update des Parent Themes erhalten.

Die Themes liegen im Pfad /wp-content/themes eurer WordPress Installation. In diesem Verzeichnis kann man nun ein neues Unterverzeichnis für das Child Theme anlegen. Ein Child Theme benötigt mindestens eine style.css.  In der style.css des Child werden die Einstellungen des Parent Theme importiert und um die eigenen Änderungen ergänzt. Wird das Child Theme aktiviert ersetzt die style.css des Child die style.css des Parent.

Hier ist ein Beispiel für eine entsprechende style.css:

/*
Theme Name: Twentytwelve Child
Description: Child theme for the twentytwelve theme 
Author: Your name here
Template: twentytwelve
*/

@import url("../twentytwelve/style.css");

Hier folgt die Erklärung was der obige Code macht:

  1. /* öffnet den Header des Child Theme.
  2. Theme Name: definiert den Namen des Child Theme.
  3. Description: Eine Beschreibung des Themes. Diese ist optional und kann entfallen.
  4. Author: Name des Autors. Angabe ist optional und kann entfallen.
  5. Template: Definiert das Parent Theme.
  6. */ schließt den Header des Child Theme.
  7. Die Regel @import importiert die Einstellungen aus der style.css des Parent Theme

Damit haben wir alles was wir für das Child Theme brauchen und können dieses im WordPress Backend unter Design -> Themes aktivieren. Noch sehen wir keine Veränderung, da wir ja bisher nur die Einstellungen des Parent Themes importiert haben. Nun passen wir das Theme weiter an.

The_Excerpt

Auf der Startseite des Blogs, den Kategorie Seiten und den Suchergebnisseiten sollen nicht die vollständigen Artikel angezeigt werden, sondern nur Auszüge.

Dazu kopieren wir die Datei content.php aus dem Parent Verzeichnis in das Child Verzeichnis. Diese öffnet man mit einem Editor und geht zur Zeile 33, welche wie folgt aussehen sollte.

<?php if ( is_search() ) : // Display Excerpts only for Search ?>

Diese Anweisung bewirkt, dass die Artikelauszüge nur auf den Suchergebnisseiten angezeigt werden. Um sie auf den Kategorieseiten und der Startseite ebenfalls anzuzeigen ändern wir die Zeile wie folgt ab.

<?php if ( is_search() || is_home() || is_category() ) : // Display Excerpts for Search, Category and Home ?>

Nachdem die Datei gespeichert wurde aktualisiert man die Browseransicht und die Artikel werden nicht mehr komplett sondern nur noch auszugsweise dargestellt. Aber wir können noch mehr tun.

Normalerweise endet ein Auszug mit […]. Wir können statt dessen jedoch auch einen Link mit
einem Benutzerdefinierten Text anzeigen lassen.

“Weiterlesen…” Link hinzufügen

Um die benötigten Änderungen vornehmen zu können erstellen wir im Verzeichnis des Child eine leere functions.php und fügen folgenden Code ein.

 <?php
/**
 * Twenty Twelve functions and definitions.
 *
 * Sets up the theme and provides some helper functions, which are used
 * in the theme as custom template tags. Others are attached to action and
 * filter hooks in WordPress to change core functionality.
 *
 * When using a child theme (see http://codex.wordpress.org/Theme_Development and
 * http://codex.wordpress.org/Child_Themes), you can override certain functions
 * (those wrapped in a function_exists() call) by defining them first in your child theme's
 * functions.php file. The child theme's functions.php file is included before the parent
 * theme's file, so the child theme functions would be used.
 *
 * Functions that are not pluggable (not wrapped in function_exists()) are instead attached
 * to a filter or action hook.
 *
 * For more information on hooks, actions, and filters, see http://codex.wordpress.org/Plugin_API.
 *
 * @package WordPress
 * @subpackage Twenty_Twelve
 * @since Twenty Twelve 1.0
 */

// Remove ... from excerpt and change the text
function change_excerpt_more()
{
  function new_excerpt_more($more)
    {
    // Use .read-more to style the link
     return '<span> <a href="' . get_permalink($post->ID) . '">[Weiterlesen...]</a></span>';
    }
  add_filter('excerpt_more', 'new_excerpt_more');

}
add_action('after_setup_theme', 'change_excerpt_more');

Damit werden die […] hinter dem Auszug entfernt und durch unseren eigenen
Text ersetzt. Das Ergebnis kann man hier auf meinem Blog betrachten.

T-Online Mediencenter in Ubuntu einbinden

Mit dem T-Online Mediencenter bietet die Telekom einen Cloudspeicherdienst mit 25GB
Speicherkapazität. Dieser Artikel schreibt wie man das Mediencenter als Datenspeicher in Ubuntu/Linux einhängen kann, um es komfortabel mit dem Dateimanager oder über die Shell nutzen zu können.

Wie viele andere Speicherdienste kann auch das Mediencenter über den Webbrowser
genutzt werden. Die Software zur Synchronisation und zum Zugriff gibt es jedoch nur für Windows. Ein Softwareclient für Linux ist auch nicht in Planung. Es besteht jedoch die Möglichkeit das Mediencenter mittels WebDAV in das lokale Dateisystem einzuhängen. Die folgende Anleitung beschreibt wie dies funktioniert.

Quelle: http://skripta.de/Davfs2.html

T-Online-Cloud (Mediencenter) unter Linux einbinden
===================================================

Anmerkung: Die folgende Kurzanleitung wurde aus verschiedenen 
aehnlich lautenden Online-Anleitungen zusammengestellt und getestet.
z.B.:
http://anderes-en.de/blog.php?mode=view&blog=11
http://blog.philippklaus.de/2010/04/mount-t-online-mediencenter-via-webdav/

Es wurden nur geringfuegige Aenderungen vorgenommen. 

=======================================================

Paket davfs2 installieren:

    * sudo apt-get install davfs2

Berechtigungen fuer den Benutzer (username = lokaler Linux-Anmeldename) setzen:

    * sudo chmod u+s /usr/sbin/mount.davfs
    * sudo usermod -a -G davfs2 username

Im Home-Verzeichnis den spaeteren Mountpoint (Verzeichnis) erstellen:

    * mkdir ~/Mediencenter

Jetzt zur fstab:

     * cd /etc
     * sudo nano fstab

und folgendes am Ende eintragen (username = lokaler Linux-Anmeldename):

     * # T-Online Mediencenter
     * https://webdav.mediencenter.t-online.de/ /home/username/Mediencenter davfs rw,noauto,user 0 0

Datei secrets erstellen und editieren 

     * cd ~
     * mkdir ~/.davfs2
     * touch ~/.davfs2/secrets
     * chmod 600 ~/.davfs2/secrets
     * nano ~/.davfs2/secrets

In die Datei ~/.davfs2/secrets folgendes eintragen (username = lokaler Anmeldename) und 
fuer anmeldung@t-online.de sowie password die T-Online-Zugangsdaten eintragen:

     * /home/username/Mediencenter anmeldung@t-online.de password

Dann die davfs2.conf kopieren und editieren:

     * cp /etc/davfs2/davfs2.conf ~/.davfs2/
     * nano ~/.davfs2/davfs2.conf

Die dort vorhanden Settings auf folgende Werte aendern und das # davor entfernen:

     * if_match_bug 1
     * use_locks 0
     * cache_size 1 # MiByte
     * table_size 4096
     * delay_upload 1
     * gui_optimize 1

Jetzt kann man mit mount ~/Mediencenter das Online-Verzeichnis einhaengen 
ohne Eingabe der Zugangsdaten.

vSphere: Virtuelle Festplatte klonen

Möchte man mehrere gleichartige Server bereitsellen, lässt sich die Bereitstellung beschleunigen, indem man einen Server installiert und die Festplatte klont.

Man erstellt dazu weitere VMs ohne Festplatte über den vSphere Client. Eine VMDK kann über die SSH-Shell mit folgendem Befehl geklont werden:

vmkfstools -i /path/old/vm/foo.vmdk /path/new/foo.vmdk

TeamDrive Personal Server als Dienst konfigurieren

Dieses Tutorial beschreibt wie man den TeamDrive Personal Server als Benutzer ausführt und ein Startskript anlegt. Es baut dabei auf das Tutorial TeamDrive 3 Server auf NAS installieren auf.

Bisher wird der TeamDrive Server als Benutzer root ausgeführt. Dies birgt gewisse Risiken. So könnte ein Angreifer durch ausnutzen einer evtl. vorhandenen Schwachstelle in der TeamDrive Software Zugriff auf das System erlangen, auf dem der  Server läuft. Um dies zu verhindern soll TeamDrive mit den Berechtigungen eines normalen Benutzers ausgeführt werden. Dieser Benutzer wird nur zum Betrieb des Dienstes benötigt und verfügt deshalb weder über eine Shell noch über ein Home-Directory.

Auf einem Ubuntu-System sind die unten stehenden Befehle mit sudo auszuführen.

Und los geht’s mit dem Anlegen eines Benutzers:
useradd -s /bin/false -d /bin/null tdpsd

Nun vergeben wir ein Passwort für den Benutzer:
passwd tdpsd

Damit der Benutzer den TDPS auch starten kann geben wir ihm die Berechtigungen für das Programmverzeichnis:
chown -R tdpsd:tdpsd /opt/tdpsd/

Als nächstes braucht man das Startscript. Dieses kann unter https://www.my-it-brain.de/wordpress/wp-content/uploads/2012/10/tdpsd.tar.gz heruntergeladen werden. Oder direkt auf dem Server mit:
wget https://www.my-it-brain.de/wordpress/wp-content/uploads/2012/10/tdpsd.tar.gz

Das Script muss aus dem Archiv entpack, im Pfad /etc/init.d abgelegt und mit den notwendigen Dateirechten versehen werden.
chmod 755 /etc/init.d/tdpsd

Und schon können wir den Server mit dem Befehl
service tdpsd start
starten.

Damit der TDPS zukünftig automatisch startet ist noch folgender Befehl notwendig:
update-rc.d -f tdpsd defaults

Und fertig. :-)

Quelle:

Dieses Tutorial enstand aus der Vorlage des englischsprachigen Tutoraials aus dem TeamDrive Forum. Dieses wurde von dem Benutzer SFu erstellt.