Schlagwort-Archiv: Planet

Tag für den Ubuntuusers.de Planeten.

Defekte Einträge im ownCloud-Kalender finden und löschen

Schreibe eine Antwort

Vor ein paar Wochen trat ein Problem mit einem meiner ownCloud-Kalender auf, welches nun endlich gelöst werden konnte.

Einer der Kalender ließ sich plötzlich nicht mehr mit dem Thunderbird Lightning Kalender oder dem Kalender unter Android synchronisieren. Zu meiner großen Freude fand ich nun auf GitHub Hilfe und konnte das Problem lösen.

Die Ursache für das Problem waren zwei defekte Einträge in diesem Kalender.

Defekte Kalendereinträge lassen sich mit folgender MySQL-Abfrage in der Datenbank finden:

SELECT * FROM oc_clndr_objects WHERE calendardata NOT LIKE '%END:VCALENDAR%'\G

Die defekten Einträge können anschließend mit dem folgenden Befehl gelöscht werden:

DELETE FROM oc_clndr_objects WHERE calendardata NOT LIKE '%END:VCALENDAR%'\G

Nachdem ich mit diesen beiden Befehlen die defekten Kalendereinträge entfernt habe, konnte ich den Kalender erneut sowohl mit Lightning als auch mit Android synchronisieren.

Logging und logrotate mit NGINX

2 Antworten

In diesem Artikel wird beschrieben, wie ich das Logging und logrotate meines NGINX-Servers konfiguriert habe. Dabei gehe ich kurz auf die beiden verwendeten Direktiven error_log und ngx_http_log_module ein.

Damit dient dieser Artikel meiner Dokumentation und evtl. euch als Anregung, ein eigenes Logging zu konfigurieren.

Logging

Informationen zum Logging findet man in der offiziellen NGINX-Dokumentation.[1. NGINX-Dokumentation] Im folgenden werden die Direktiven error_log[2. NGINX core module error_log] und ngx_http_log_module[3. NGINX – ngx_http_log_module] verwendet.

Mein Server liefert mehrere Webseiten aus. Ich möchte gern für jede Webanwendung ein separates Error-Log und Access-Log schreiben. Dabei wird folgendes Muster verwendet:

  • Log-Verzeichnis: /var/www//logs
  • Name für error_log: _error.log
  • Name für access_log: _access.log

Konfiguration des Error-Log

Die Error_log-Syntax ist denkbar einfach:

error_log log_file [ log_level ]

log_file gibt den Pfad zur Log-Datei an. Mit log_level wird bestimmt, wie viele Informationen protokolliert werden sollen.

Log-Level[4. How To Configure Logging and Log Rotation in Nginx on an Ubuntu VPS]

  • emerg: Notfall, in dem sich das System in einem nicht nutzbaren Zustand befindet
  • alert: Ernste Störung. Sofortiger Eingriff ist erforderlich
  • crit: Kritische Probleme, um die man sich kümmern sollte
  • error: Ein Fehler ist aufgetreten. Hier funktioniert etwas nicht
  • warn: Ein ungewöhnliches Ereignis ist aufgetreten. Dies ist jedoch kein Grund zur Sorge
  • notice: Normale Vorgänge werden ebenfalls protokolliert
  • info: Unnützes Wissen – Nice to know
  • debug: Debugging-Informationen, welche helfen, ein Problem näher zu analysieren

Die Log-Level sind nach Priorität angeordnet. Wird das Level auf „error“ gesetzt, so werden alle Events der Level error, crit, alert und emerg protokolliert.

Möchte man rein gar nichts protokollieren, muss das Log nach /dev/null umgeleitet werden.

error_log /dev/null crit;

Konfiguration des Access-Log

Das Modul ngx_http_log_module besteht aus den Direktiven access_log, log_format und open_log_file_cache, von denen ich hier nur die ersten beiden verwenden werde.

Mit der Direktive log_format kann das Format der Log-Dateien konfiguriert werden. Die einzelnen Formate werden über einen Bezeichner ausgewählt. Dies kann z.B. wie folgt aussehen:

log_format compression '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $bytes_sent '
                       '"$http_referer" "$http_user_agent" "$gzip_ratio"';

access_log /spool/logs/nginx-access.log compression buffer=32k;

Eine detaillierte Beschreibung aller verfügbaren Parameter kann der offiziellen Dokumentation entnommen werden.[5. NGINX -log_format]

Ich selbst verwende aktuell ausschließlich das Format combined. Dieses ist bereits in der Standardinstallation enthalten. Es sieht wie folgt aus:

log_format combined '$remote_addr - $remote_user [$time_local]  '
		    '"$request" $status $body_bytes_sent '
		    '"$http_referer" "$http_user_agent"';

Für die Protokollierung meiner Webanwendungen wird daher folgendes in die jeweiligen Server-Direktiven eingetragen:

server {
...
access_log /var/www//logs/_access.log combined;
...
}

Falls man das Access-Log deaktivieren möchte, kann man dies durch den folgenden Eintrag erreichen:

access_log off;

Nun werden schon mal alle Log-Dateien nach Webanwendungen getrennt in das Verzeichnis /var/www//logs geschrieben.

Im nächsten Abschnitt gehe ich darauf ein, wie man verhindert, dass die Festplatte mit Log-Dateien vollgeschrieben wird.

Rotation der NGINX Log-Dateien

Zum Rotieren der Logs verwende ich die Anwendung logrotate. Diese ist bei Ubuntu bereits in der Standardinstallation enthalten.

Es wird ein Skript im Verzeichnis /etc/logrotate.d erstellt und folgender Inhalt eingefügt.

/var/www//logs/*.log {
        daily
        missingok
        rotate 31
        compress
        delaycompress
        notifempty
        sharedscripts
        postrotate
                [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
        endscript
}

Mit diesem Skript wird logrotate angewiesen, die Log-Dateien im Verzeichnis /var/www//logs/ täglich zu rotieren und die letzten 31 Log-Dateien zu behalten. Die Log-Datei wird nicht rotiert, falls sie leer ist, also keine Einträge enthält. Die älteren Dateien werden dabei komprimiert, um Speicherplatz zu sparen.

Die generelle Beschreibung von logrotate würde den Rahmen dieses Artikels sprengen. Weitere Informationen sind in der Manpage zu finden.[6. logrotate(8) – Linux man page]

Damit ist der verspätete Frühjahrsputz auf diesem Server beendet.

SSL-Schwachstelle bedroht Web- und Mail-Server

Schreibe eine Antwort

Diverse Seiten im Internet berichten über eine neue SSL-Schwachstelle, die durch eine sogenannte Logjam-Attacke ausgenutzt werden kann.[1. Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet] [2. Tausende Web-Server betroffen: Neue HTTPS-Sicherheitslücke aufgetaucht] [3. Guide to Deploying Diffie-Hellman for TLS]

Dieser Artikel beschreibt, wie sich NGINX, Postfix und Dovecot härten lassen. Damit sind diese Dienste nicht mehr verwundbar für die aktuelle SSL-Schwachstelle.

Ich beschreibe die drei genannten Dienste, da ich diese selbst auf mehreren Ubuntu-Servern betreibe. Für weitere Dienste schaut bitte in der Quelle unter Punkt „3.“ nach.

Zu Beginn wird eine Diffie-Hellman-Group für den Server generiert:

openssl dhparam -out dh_params.pem 2048

Anschließend folgt die Härtung der einzelnen Dienste.

NGINX

Im server Block der jeweiligen Webpräsenz werden die zu verwendenden „Cipher Suites“ und Diffie-Hellman-Parameters angegeben:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /pfad/zur/dh_params.pem;

Anschließend wird der Dienst zur Übernahme der Einstellungen neu geladen:

sudo service nginx reload

Postfix

Beim MTA Postfix werden beide Parameter in der Datei /etc/postfix/main.conf eingetragen:

smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_dh1024_param_file = /pfad/zur/dh_params.pem

Auch hier werden die Einstellungen anschließend neu eingelesen:

sudo service postfix reload

Dovecot

Die beiden Parameter werden in die Datei /etc/dovecot/conf.d/10-ssl.conf eingetragen:

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes

#regenerates every week
ssl_dh_parameters_length = 2048

Und auch hier werden die Änderungen anschließend eingelesen:

sudo doveadm reload

Damit sollte man vor dieser Schwachstelle vorerst geschützt sein.

Thunderbird Adressbuch mit ownCloud Kontakten synchronisieren

4 Antworten

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.

Cisco AnyConnect VPN Client unter Ubuntu installieren

2 Antworten

Dieser Artikel beschreibt die Installation des Cisco AnyConnect VPN Client unter Ubuntu Trusty Tahr.

Laut einem Dokument[1. AnyConnect – Unterstützte Betriebssysteme und Systemvoraussetzungen], dass ich bei der Universität Bielefeld gefunden habe, werden Ubuntu 9.x und 10.x unterstützt. Ich konnte den Client jedoch auch problemlos unter Ubuntu 14.01.1 LTS installieren.

Dazu habe ich einfach das Installationsskript vpnsetup.sh heruntergeladen, ausführbar gemacht und ausgeführt.

:~$ wget https://github.com/Tronde/Schriftrolle/blob/master/vpnsetup.sh
:~$ sudo chmod u+x vpnsetup.sh
:~$ sudo ./vpnsetup.sh

Ist das Setup durchgelaufen, kann der Client aus dem Anwendungsmenü heraus gestartet werden.

cisco anyconnect secure mobility client

Cisco AnyConnect Secure Mobility Client

In das Feld „Connect to“ müsst ihr nun nur noch eureb Verbindungsserver eintragen und schon kann es losgehen.

Die Installation ist damit abgeschlossen. Das war es schon. :-)

Das lokale Paketarchiv aufräumen

Schreibe eine Antwort

Während ich im Artikel „Automatische Installation von Sicherheitsupdates“ beschrieben habe, wie man Sicherheitsupdates unter Ubuntu automatisch installieren lassen kann, werde ich hier kurz beschreiben, wie das lokale Paketarchiv automatisch bereinigt werden kann.

In der Datei /etc/apt/apt.conf.d/10periodic gibt es unter anderem den folgenden Eintrag:

APT::Periodic::AutocleanInterval "0";

Dieser Wert gibt an, in welchem Intervall (in Tagen) das lokale Archiv der Paketquellen bereinigt werden soll. Dieser Wert steht standardmäßig auf „0“. Damit wird das Paketarchiv gar nicht automatisch bereinigt. Um dies zu ändern trägt man hier einfach einen Wert seiner Wahl ein. So lasse ich das Paketarchiv bspw. alle 28 Tage bereinigen:

APT::Periodic::AutocleanInterval "28";

Viele Grüße
Tronde

Installation von VMware Tools in einer Ubuntu VM

3 Antworten

Update 2021-06-09

Um den Netzwerkadapter VMXNET3[1. Choosing a network adapter for your virtual machine (1001805)] in einem virtuellen Ubuntu verwenden zu können, müssen die VMware Tools installiert sein. In den aktuellen Versionen von Ubuntu und weiteren Distributionen wie z.B. RHEL, SLES, etc. sind inzwischen Treiber für die VMXNET3-Netzwerkkarte enthalten. Dennoch ist die Installation der VMware Tools empfohlen.
Dieser Artikel beschreibt zwei Methoden, wie dies getan werden kann. Ich gehe dabei ausschließlich auf die Installation unter Verwendung der Kommandozeile (CLI) ein.

Methode 1 – Open-VM-Tools

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB2073803[2. VMware support of open-vm-tools (2073803)].

Bei den open-vm-tools handelt es sich um die Open Source Implementierung der VMware Tools. Die Vorteile dieser Implementierung sind:

  • Die Open-VM-Tools sind in den offiziellen Paketquellen von Ubuntu enthalten. Dadurch wird das Deployment von virtuellen Ubuntu VMs entschieden vereinfacht. Die Installation kann direkt aus den Quellen durchgeführt werden. Es muss nicht auf separate Quellen zurückgegriffen werden.
  • Keine Downtime für das Update der VMware Tools. Das Paket open-vm-tools wird automatisch über die Paketverwaltung aktualisiert.
  • Keine Kompatibilitätsprüfung erforderlich. Aus den Paketquellen wird automatisch das zum Betriebssystem passende Paket installiert.

Die Installation der Tools ist denkbar einfach und geschieht z.B. mittels:

sudo apt-get install open-vm-tools

VMware empfiehlt ausdrücklich die Verwendung der Open-VM-Tools.[3. VMware Tools in an Ubuntu 14.04 Guest] Wer sich über den aktuellen Entwicklungsstand der Open-VM-Tools informieren möchte, kann dies auch direkt auf GitHub tun. [4. https://github.com/vmware/open-vm-tools]

Methode 2

Diese Methode verbleibt der Vollständigkeit halber im Artikel. Es wird ausdrücklich Methode 1, wegen der dort genannten Vorteile, empfohlen.

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB1022525[5. Installing VMware Tools in an Ubuntu virtual machine (1022525)] und führt die einzelnen Schritte auf, die benötigt werden, um die VMware-Tools in einer VM mit Ubuntu zu installieren.

Abhängigkeiten der VMware-Tools

Um die VMware Tools installieren zu können, müssen folgende Pakete auf dem System installiert sein:

  • gcc
  • binutils
  • make
  • kernel sources

Installation auf der Kommandozeile

Als Erstes wird ein Rechtsklick auf die VM in der Bestandsliste des vSphere-Clients ausgeführt. Aus dem Kontextmenü wählt man „Gast -> VMware Tools installieren/aktualisieren“.

In der laufenden Ubuntu-VM werden nun die folgenden Kommandos ausgeführt:

sudo mkdir /mnt/cdrom
sudo mount /dev/cdrom /mnt/cdrom
tar xzvf /mnt/cdrom/VMwareTools-.tar.gz -C /tmp/
cd /tmp/vmware-tools/distrib/
sudo ./vmware-install.pl -d

Nach Abschluss der Installation ist ein Neustart auszuführen. Nun kann anstatt des veralteten E1000 auch der aktuelle Netzwerkadapter VMXNET3 zur VM hinzugefügt und verwendet werden.

Testinstanz für einen WordPress Blog erstellen

1 Antwort

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

8 Antworten

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.

Enigmail unterstützt zukünftig nur noch GnuPG 2

2 Antworten

Auf meinem Trusty-Notebook läuft Thunderbird mit dem Addon Enigmail in Version 1.8. Heute Morgen informierte mich Enigmail mit folgender Meldung darüber, dass die unter Ubuntu standardmäßig installierte GnuPG-Version 1.4.16 in zukünftigen Versionen von Enigmail nicht mehr unterstützt wird. Es wird ein Update auf GnuPG 2.0 oder neuer empfohlen.

enigmail-message

Enigmail-Meldung

Nichts leichter als das. Schließlich ist GnuPG 2 bereits in den Paketquellen von Ubuntu enthalten und kann aus diesen installiert werden.

sudo apt-get install gnupg2

Fertig. Mehr ist nicht zu tun. Ein Blick in die Enigmail-Einstellungen zeigt, dass das Addon nun automatisch das soeben installierte gpg2 verwendet.

enigmail-settings

Enigmail-Einstellungen

Die vorhandenen GnuPG-Schlüssel stehen automatisch auch in der neuen Version zur Verfügung. Die Bedienung funktioniert im Wesentlichen wie zuvor. Man verwendet nun lediglich das Kommando gpg2, statt des älteren gpg.