Wie bei den meisten anderen Diensten die ich zu Hause betreibe gibt es ein paar Vorbereitungen zu treffen um die Umgebung herzurichten.
Damit Gitea die ganzen Daten von und über meinen Code speichern benötigt es eine Datenbank. Ich habe mich für PostgreSQL entschieden. Das Packet ist auch schnell installiert:
sudo apt-get update
sudo apt-get install -y postgresql postgresql-client
Anschließend empfehle ich noch eine Anpassung der Konfiguration um das völlig veraltete Hashverfahren MD5 durch was moderneres zu ersetzen. Dazu lege ich die Datei /etc/postgres/13/main/conf.d/ an und füge darin die Zeile password_encryption = scram-sha-256
ein.
Die eigentliche Softwareinstallation von Gitea beginnt dann mit dem anlegen des Benutzers gitea:
sudo adduser --system --home /opt/gitea --disabled-login --disabled-password --group gitea
Gitea stellt zwar das Webinterface bereit, die eigentliche Verwaltung des Codes übernimmt aber Git. Daher muss Git natürlich auch installiert sein:
sudo apt-get install -y git
Anschließend komme ich schon zum Download. In diesem Schritt inkludiert, prüfe ich auch die Signatur damit ich keine korrupten oder manipulierten Binaries installiere:
sudo wget -P /opt/gitea/ https://dl.gitea.io/gitea/1.16.8/gitea-1.16.8-linux-amd64
sudo wget -P /opt/gitea/ https://dl.gitea.io/gitea/1.16.8/gitea-1.16.8-linux-amd64.asc
sudo gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
sudo gpg --verify /opt/gitea/gitea-1.16.8-linux-amd64.asc /opt/gitea/gitea-1.16.8-linux-amd64
Wenn die Signaturprüfung ein positives Ergebnis hervorbringt kann es weitergehen mit dem anlegen von verschiedenen Ordnern und dem vergeben der passenden Berechtigungen:
sudo mkdir -p /etc/gitea /var/lib/gitea/{custom,data,log}
sudo chown -R gitea:gitea /var/lib/gitea/
sudo chmod -R 750 /var/lib/gitea/
sudo chown root:gitea /etc/gitea
sudo chmod 770 /etc/gitea
Zu beginn habe ich zwar PostgreSQL installiert aber die eigentliche Datenbank innerhalb des Datenbankservers fehlt noch. Der folgende etwas längliche Befehl übernimmt mehrere Aufgaben auf einmal. Zuerst einmal meldet er sich mit dem Datenbankadmin an der Datenbank an. Im Anschluss wird dann der Datenbankbenutzer gitea erzeugt (bitte ein eigenes Passwort anstelle von $pwd einsetzen), eine Datenbank giteadb angelegt und dann der User aus dem vorherigen Schritt mit allen Rechten auf dieser Datenbank versehen.
sudo -u postgres psql -p 5432 --command "CREATE USER gitea WITH PASSWORD '$pwd';" --command "CREATE DATABASE giteadb OWNER gitea ENCODING UTF8 LC_COLLATE 'de_DE.UTF-8' LC_CTYPE 'de_DE.UTF-8';" --command "GRANT ALL PRIVILEGES ON DATABASE giteadb to gitea" postgres
Gitea ist nach der Installation erreichbar unter http://localhost:3000. Das ist natürlich nicht so hilfreich um vom eigenen Arbeitsrechner aus zuzugreifen. Darum schalte ich Nginx als HTTP-Server davor, der kann dann auch gleich eine HTTPS-Verbindung ermöglichen. Dazu ist eine neu Datei /etc/nginx/sites-available/gitea.local mit dem folgenden Inhalt nötig:
server {
listen 192.0.2.10:80;
listen [fc00::10]:80;
return 301 https://$host$request_uri;
}
server {
listen 192.0.2.10:443 ssl http2;
listen [fc00::10]:443 ssl http2;
ssl_certificate /etc/nginx/ssl/gitea.local.cert.chain.pem;
ssl_certificate_key /etc/nginx/ssl/gitea.local.key.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_session_tickets off;
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
server_tokens off;
client_max_body_size 200M;
location / {
proxy_pass http://localhost:3000;
}
error_log /var/log/nginx/gitea_error.log;
access_log /var/log/nginx/gitea_access.log;
}
Die IPv4- und IPv6-Adressen, genauso wie die SSL-Zertifikatsdateien müssen natürlich zu den eigenen Gegebenheiten passend ersetzt werden.
Anschließend muss ich die Seite noch aktivieren:
sudo ln -s /etc/nginx/sites-available/gitea.local /etc/nginx/sites-enabled/gitea.local
Eine Sache, die dabei besonders wichtig ist, versteckt sich in der Zeile die mit client_max_body_size
beginnt. Dort wird nämlich festgelegt wie groß die Dateien in eurem Code maximal sein dürfen damit Nginx sie nicht ablehnt. In meinem Beispiel sind es großzügig dimensionierte 200 Megabyte.
Um Gitea bei jedem Neustart des Computers nicht wieder manuell starten zu müssen bietet es sich an, einen Dienst einzurichten. Dazu braucht es wiederum eine neue Datei /etc/systemd/system/gitea.service mit folgendem Inhalt:
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=postgresql.service
[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535
RestartSec=2s
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini
Restart=always
Environment=USER=gitea HOME=/opt/gitea GITEA_WORK_DIR=/var/lib/gitea
[Install]
WantedBy=multi-user.target
Aktivieren muss ich auch diese Datei dann wieder und kann bei der Gelegenheit auch alles andere einmal durchstarten:
sudo systemctl daemon-reload
sudo systemctl enable --now gitea
sudo systemctl restart networking
sudo systemctl restart nginx.service
Wenn alles gut gelaufen ist sollte Gitea jetzt unter dem Hostnamen oder der IP aufrufbar sein. Aufrufbar ist aber nicht gleich nutzbar, zu erst muss noch die Grundkonfiguration auf der geöffneten Webseite vorgenommen werden. Insbesondere ist es nötig die Datenbankverbindungsparameter anzugeben. Anschließend können Benutzer und Repositories angelegt werden.
Ich beschränke dann noch die Schreibrechte auf die jetzt entstandene Konfigurationsdatei auf ein Minimum. Sicher ist sicher.
sudo chmod 750 /etc/gitea
sudo chmod 640 /etc/gitea/app.ini
Für das Backup ist es wichtig die Datenbank zu sichern. Das erreiche ich über ein kleines Script:
#!/bin/bash
echo "Init target folder..."
if [ ! -d "/backup/postgres" ]; then
mkdir /backup/postgres
chown postgres:postgres /backup/postgres
chmod 770 /backup/postgres
fi
echo "Create a dump of the database giteadb"
cd /var/lib/postgresql
sudo -u postgres pg_dump --file /backup/postgres/gitea.dump giteadb
Dieses Script rufe ich dann in meinem eigentlich Backup mit Dirvish auf.
Das wiederherstellen der Datenbank aus dem zuvor erstellten Dump ist auch mit wenigen Befehlen getan:
sudo -u postgres psql --command "DROP DATABASE IF EXISTS giteadb;" --command "CREATE DATABASE giteadb OWNER gitea;" --command "GRANT ALL PRIVILEGES ON DATABASE giteadb to gitea;" postgres
sudo -u postgres psql --set ON_ERROR_STOP=on giteadb < /backup/postgres/giteadb.dump
Ich musste noch kein Update machen aber es sollte sich auf den Austausch der Binärdatei beschränken. Aber die Lektüre der Dokumentation ist sicher angebracht.
Bevor man jetzt auf dem Entwicklungsrechner loslegen kann… Ich sagte ja oben das ich selbst ausgestellte Zertifikate nutzte. Damit die von der Git-Client akzeptiert werden muss man sie natürlich in eine Vertrauensstellung bringen.
Unter Debian hat mir der Artikel von Grumpy Techie dabei geholfen.
Unter Windows ist es etwas irritierend. Git benutzt standardmäßig nicht den Zertifikatsspeicher von Windows sondern einen Eigenen. Dabei handelt es sich um eine Textdatei deren Pfad man mit dem Befehl git config --list
herausfinden kann. Die Zeile die mit http.sslcainfo beginnt gibt den Speicherort an. In diese Datei kann man die eigenen Zertifikate einfach anfügen. Anschließend kann der Spaß beginnen.
Unter Debian ist dieses Vorhaben einfach umzusetzen. Es gibt bereits ein fertiges Paket das man nur Installieren muss, ein paar Konfigurationswerte anpassen und schon kann es losgehen. Aber der Reihe nach…
Zuerst die Installation mit…
sudo apt-get -y install dropbear-initramfs
Danach Dropbear konfigurieren um den Port festzulegen und den Befehl zum Entschlüsseln direkt nach dem Verbindungsaufbau auszuführen. Dazu in der Datei /etc/dropbear-initramfs/config
die folgende Zeile einfügen:
DROPBEAR_OPTIONS="-c cryptroot-unlock -p 2222"
Anschließend ist es notwendig für Dropbear eine IP-Adresse festzulegen um den Server auch zu diesem frühen Zeitpunkt im Bootprozess ansprechen zu können. Dies geschieht in einer anderen Datei /etc/initramfs-tools/initramfs.conf
:
IP=192.168.1.20::192.168.1.1:255.255.255.0:server.example:eno1
Dabei nicht vergessen die IP, das Gateway und die Netzmaske an die eigenen Gegebenheiten anzupassen.
Die eigentliche Konfiguration ist damit abgeschlossen. Was allerdings noch fehlt sind die öffentlichen Schlüssel der Personen die sich anmelden sollen. Diese müssen jeweils als eine Zeile in die Datei /etc/dropbear-initramfs/authorized_keys
eingefügt werden. Die Schlüssel können unter Windows mit dem Tool PuTTYgen erzeugt werden. Das Tool erhält man zusammen mit dem SSH-Client PuTTY.
Damit alles wirksam wird muss man noch das Initial RAM Filesystem aktualisieren:
sudo update-initramfs -u
Anschließend kann man den Server neustarten und versuchen eine eine SSH-Verbindung herzustellen. Dabei nicht vergessen den Port 2222 anzugeben. Der Benutzer ist immer root und zur Authentifizierung kommt einer der privaten Schlüsseln zum Einsatz deren Konterparts vorher in die Datei authorized_keys
eingetragen wurden.
Vor der Installation ist ein Installationsmedium zu präparieren. Heutzutage ist das bevorzugte Medium ein USB-Stick. Mittels Rufus lässt sich dieser als bootfähiges Installationsmedium herrichte. Zusätzlich braucht man noch ein Installations-Image für Debian. Bei den heutigen Bandbreiten, selbst in Deutschland, ist es nicht nötig eines der umfangreichen Images runterzuladen. Das recht kompakte Net-Install-Image reicht völlig.
wenn der Server vom USB-Stick gebotet wurde gibt es eine erste Auswahl zu treffen. Es gibt die Auswahl zwischen dem grafischen Installer und einem der klassisch auf der Kommandozeile. Dazu kommen noch „Advanced Options“ und zwei Optionen für Menschen die nicht oder nicht gut sehen können. Ich wähle den grafischen Installer, der ist recht komfortabel und leitete durch die nachfolgenden Schritte zu einem funktionierenden System.
In den ersten Schritte legt man Sprache, Land und Tastaturlayout fest. Anschließend bekommt der Server einen Namen und eine Domain. Im Fall von einem lokalen Netzwerk kann man da einfach local nehmen oder sonst irgendwas das nicht zu Konflikten mit „echten“ Webadressen führt.
Als nächstes werden die Benutzer eingerichtet. Mit dem Superuser root fängt es an. Dieser kann mit einem Passwort versehen werden. Ich verzichte aber darauf was dazu führt das dieser für die Anmeldung gesperrt wird. Damit man trotzdem noch Dinge anstellen kann muss deshalb gleich noch ein persönlicher Account angelegt werden. Dieser erhält gleich alle Recht um sich mit dem Kommando sudo
als Root auszugeben.
Der Schwierigste Teil, finde ich, ist die Partitionierung. Ich habe auf einer Disk bzw. SSD einen verschlüsselten Container angelegt der alles aufnimmt außer den nachfolgend genannten Verzeichnissen. Dafür gibt es auch einen kleinen Assistenten der alles schon so hinbastelt. Für die Verzeichnisse /var
und /opt
habe ich dann die restlichen Festplatten in meinem Server mit LVM zu einer großen virtuellen Platte zusammengefast und auch darauf einen Crypto-Container angelegt. In diesem sind dann zwei Partitionen für die genannten Verzeichnisse enthalten. /var
nimmt dabei alle veränderlichen Daten, also das wichtige Zeug, auf und in /opt
wird die Software installiert die ich in meinem Heimnetz haben möchte.
Nach diesem Punkt gibt es noch ein paar Dinge zu erledigen die aber schnell von der Hand gehen. Für den Paketmanager mit den vielen tollen Dingen die Debian so zu bieten hat wird ein Spiegelserver möglichst in der Nähe des eigenen Standorts festgelegt. Zusätzlich kann ein Proxy, falls vorhanden, festgelegt werden. Auch kann man nach eigenem ermessen zustimmen das statistische Daten über die Nutzung erhoben werden dürfen.
Anschließend kann man noch ein paar zusätzliche Module installieren von denen das Debian-Team wohl ausgeht das sie häufig benötigt werden. Ich beschränke mich dabei auf SSH um gleich nach der Installation vom Sofa aus weiterarbeiten zu können.
Zum Abschluss wird noch der Bootloader installiert und ein Neustart durchgeführt. Fertig!
20.02.2022: Diesen Artikel habe ich komplett neu geschrieben. Wenn jemand den ursprünglichen Text noch für historische Forschung 😊 braucht habe ich davon noch einen PDF-Export gemacht.
]]>/opt/seafile/
, die Daten hingegen in /var/seafile/
.
Wer noch eine ältere Version von Seafile nutzt muss erst mal auf 7.0.5 updaten da der Updateprozess zu 7.1 sonst nicht funktioniert.
Um ein Update von Seafile vorzubereiten ist der erste Anlaufpunkt bei mir immer die Upgrade Notes für das gewünschte Release. Dort erfährt man auch sofort das jetzt von Python 2 zu Python 3 gewechselt werden muss. Leider nicht so offensichtlich ist die Tatsache das die Version die Debian 9 davon ausliefert nicht ausreicht um Seafile zu betreiben. Ich habe daher auf die harte Tour gelernt das zu den Mindestvoraussetzungen Debian 10 gehört.
Nach einer Migration des Servers auf Debian 10, die reibungslos funktioniert hat, kann man dann die benötigte Python 3 Installation durchführen und auch gleich die zusätzlichen Bibliotheken runterladen. Die Befehle dafür sind in den Upgrade Notes angegeben:
sudo apt-get install python3 python3-setuptools python3-pip -y
sudo pip3 install --timeout=3600 Pillow pylibmc captcha jinja2 sqlalchemy \
django-pylibmc django-simple-captcha python3-ldap
Die Reihenfolge, erst Debian updaten dann Python 3 installieren, ist dabei wichtig. Anderenfalls sind nach dem Update veraltetet Stände der Bibliotheken aus PIP auf dem System und es funktioniert trotzdem nicht. In diesem Fall kann man den zweiten Befehl aber mit dem Parameter --upgrade
erneut ausführen um alles zu aktualisieren. Wichtig dabei: Wer das nicht berücksichtigt erhält keine Fehlermeldung im Log. Seahub wird einfach ohne Angabe von Gründen nicht gestartet.
Das Update selbst lief dann wie gewohnt ab:
Mein Setup ist echt einfach, lest also wirklich die Upgrade Notes für die Details.
Nachdem das soweit alles erfolgt ist bin ich gleich auf das nächstes Problem gestoßen. Aus irgendeinem Grund berücksichtig Seafile 7.1 nicht mehr das die Datenbank und die Dateien nicht innerhalb des Installationsverzeichnisses liegen. Der Updateprozess legt zwar einen Sym-Link auf das richtige Verzeichnis unter /opt/seafile/seafile-data/
an. Genutzt wird der aber offensichtlich nicht. Als Folge wird eine leere Datenbank unter /opt/seafile/seafile-data/
angelegt, was natürlich nicht funktioniert.
Ich weiß nicht warum, wieso und weshalb aber ich habe mir beholfen indem ich alle Dateien vom bisherigen Speicherort nach /opt/seafile/seafile-data/
kopiert habe. Das bedingt aber eine Anpassung am Backup-System. Ich werde in ein paar Monaten den ganzen Server mit Debian 11 neu aufsetzen und investiere bis dahin keine weitere Energie in die Recherche zu diesem Problem.
Nachdem die genannten Probleme umschifft sind startet Seafile wieder und kann bislang auch problemlos genutzt werden. Ich bin mal gespannt ob noch irgendwelche Probleme auftauchen die sich bisher versteckt haben.
]]>Im Fall von Debian gibt es im erwähnten Paketmanager, wie könnte es anders sein, ein passendes Script das sich um alles nötige kümmert: unattended-upgrades.
Auch Aufgaben die automatisch erledigt werden sollten nicht ganz aus den Augen verloren gehen. Daher kann unattended-upgrades Mails verschicken wann immer es ein Update installiert hat. Das ist besonderst dann wichtig, wenn auf einmal irgendwas nicht mehr wie gewohnt funktioniert. In dem Fall hilft unter Umständen ein Blick in die Mails um den Schuldigen einzugrenzen.
Wie ein MTA so eingerichtet werden kann, dass er Mails auch außerhalb des Servers zustellt, habe ich in meinem Artikel „Wissen was geht mit E-Mail-Benachrichtigungen“ aufgeschrieben.
Die Installation des Scriptes unattended-upgrades erfolgt ganz einfach mit folgendem Befehl:
sudo apt-get install unattended-upgrades
Dadurch wird auch gleich eine funktionierende Standardkonfiguration eingerichtet. Damit werden auf täglicher Basis alle Sicherheitsupdates für Debian installiert.
Die Häufigkeit der der Updates, standardmäßig täglich, ist in der Datei /etc/apt/apt.conf.d/20auto-upgrades festgelegt. Am Ende jeder der Zeilen in dieser Datei steht eine Zahl. Diese legt fest wie viele Tage zwischen den Aufrufen vergehen soll. Hier würde ich aber nichts ändern.
Die wichtigerer Konfigurationsdatei ist /etc/apt/apt.conf.d/50unattended-upgrades. Hier wird alles eingestellt außer dem vorab genannten Scheduling.
Um auch andere als die sicherheitsrelevanten Updates automatisch zu installieren, muss man die Software-Repositiories ergänzen aus denen diese Updates stammen können. Diese kann man über den Befehl apt-cache policy
ermitteln. Der Befehl gibt eine Reihe von Attributen für jedes Repository aus das auf dem Computer eingerichtet ist. Diese Attribute nutzt man dann um die Konfigurationsdatei 50unattended-upgrades zu erweitern. Dazu wird pro Repository eine Zeile im Block Unattended-Uprade::Origins-Pattern {} hinzugefügt. Dabei können Variablen genutzt werden um unabhängig vom Debian-Release zu sein.
Die folgenden drei Zeilen decken die drei „normalen“ Repositories von Debian Stretch ab:
"origin=Debian,codename=${distro_codename}";
"origin=Debian,codename=${distro_codename}-updates";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
Im Fall von Raspian, der Variante von Debian für den Raspberry Pi, ist leider ein Fehler in der Standardkonfiguration enthalten. Diese verweist auf die Repositories des originalen Debian und würde so nicht funktionieren. Die korrekten Einträge lauten wie folgt:
"origin=Raspian,codename=${distro_codename}";
"origin=Raspberry Pi Foundation,codename=${distro_codename}";
Im unteren Teil der Konfigurationsdatei sind bereits alle anderen Optionen zusammen mit beschreibenden Kommentaren aufgeführt. Allerdings sind diese Zeilen auskommentiert.
Um per E-Mail benachrichtigt zu werden muss die Option Unattended-Upgrade::Mail aktiviert werden. Anstelle von „root“ kann auch ein anderer Benutzer oder eine Mailadresse angegeben werden.
Manchmal benötigen Updates auch einen Neustart des Servers um wirksam zu werden. Damit dieser ebenfalls automatisch durchgeführt wird, sollte die Option Unattended-Upgrade::Automatic-Reboot aktiviert werden. Für die Option Unattended-Upgrade::Automatic-Reboot-Time ist es ratsam eine günstige Zeit zu setzen. Der Zeitpunkt ist so zu wählen das der Neustart möglichst nicht stört.
Um die Konfiguration zu testen kann man das Script auch manuell aufrufen. Wenn man dabei die Debug-Option wählt erhält man mehr Informationen:
sudo unattended-upgrade --debug
Wenn mal etwas nicht funktioniert kann man dem Fehler in den Logfiles nachspüren. Diese findet man im Verzeichnis /var/log/unattended-upgrades/. Dort sollte man die Analyse in der Datei unattended-upgrades.log beginnen.
]]>Recht einfach funktioniert unter Debian der Mailversand mit der Software Exim4. Der erste Schritt ist dabei die Installation zusammen mit ein paar zusätzlichen Tools:
sudo apt-get update mailutils exim4-daemon-light
Nach der Installation ist Exim für den lokalen Betrieb eingerichtet. Das heißt, es werden nur Mail von lokalen Benutzern für lokale Benutzer entgegengenommen. Das ist jetzt keine Verbesserung da die E-Mails ja gerade außerhalb des Servers gelesen werden sollen. Daher ändern wir die Konfiguration auf ein anderes Profil:
sudo dpkg-reconfigure exim4-config
Dieser Befehl startet einen Konfigurationsdialog in dem verschiedene Profile ausgewählt und deren Parameter angegeben werden können. Zuerst wird das grundlegende Profil (Configuration Type) auf den Wert „mail sent by smarthost; no local mail“ festgelegt. Als „Mail Name“ ist der Name des Servers vorbelegt und kann so übernommen werden. Auch die Werte für die IP-Adressen kann auf der Vorgabe „172.0.0.1; ::1“ belassen werden. Damit wird verhindert das Exim von außen angreifbar ist da er nur Verbindungen von sich selbst (localhost) entgegennimmt. Danach werden die „Local Domains“ abgefragt, das Feld hierzu bleibt leer. Im nächsten Schritt geht es um die „Visible domain names for local users“. Dieser Wert kann, korrespondierend zum Mail Name, auf dem vorgegebenen Wert verbleiben. Die nächste Angabe die abgefragt wird ist die relevante: Als „Outgoing Smarthost“ wird der externe Server angegeben der zukünftig die Mails zustellen soll. Hier sollte man den SMTP-Server seines Mail-Providers angeben. Wenn man dabei einen Port angeben muss braucht man zwei Doppelpunkte anstelle des bei URLs üblichen Einzelnen. Die beiden nächsten und letzen Einstellungen sind Ja-Nein-Fragen die beide mit Nein beantwortet werden können.
Zusätzlich zu den obigen Angaben muss man noch Benutzernamen und Password für den Smarthost angeben damit dieser die zu versendenden E-Mails auch entgegennimmt. Dies geschieht in der Datei /etc/exim4/passwd.client indem man pro Server dessen Hostnamen, den Benutzer und das Passwort in eine Zeile schreibt. Getrennt werden die drei Angaben durch je einen Doppelpunkt.
smtp.mailserver.example:benutzername:passwort
Eine bebilderte Anleitung für die gleiche Konfiguration findet man auf dem Blog root@home:~#.
Mit der neuen Konfiguration kann man jetzt E-Mails an externe Adressen verschicken. Der Versuch die Mail an einen lokalen Benutzer zu senden führt aber voraussichtlich zu einem Fehler weil die Adresse, zusammengesetzt aus dem Benutzernamen und dem FQDN des Servers, auf dem Smarthost nicht bekannt ist.
Um das Problem zu umgehen kann die Datei /etc/aliases manipuliert werden. Die genannte Datei enthält Zuordnungen von Benutzern auf Aliasnamen. Ein Alias kann ein anderer Benutzername oder eine externe E-Mail-Adresse sein.
Dabei kann auch eine ganze Kette von Aliasen aufgebaut werden. So führt, unter Debian, der Benutzer postmaster zum Benutzer root und dieser wiederum zu dem bei der Installation angelegten primären User. Wenn man für diesen Benutzer nun einen weiteren Alias auf die eigene E-Mail-Adresse einträgt landen die Mails auch im entsprechenden Postfach.
sebastian: me@mailserver.example
Um die ganze Konfiguration wirksam werden zu lassen ist es angeraten die Konfiguration für Exim neu einzulesen und einen Neustart durchzuführen:
sudo update-exim4.conf
sudo service exim4 restart
Um die Konfiguration zu testen kann man über folgendes Kommando eine Mail versenden. Diese sollte nun im gewünschten Postfach ankommen. Wenn nicht, muss man die Logs unterhalb von /var/log/exim/ nach dem Fehler durchsuchen.
echo 'Test Mail' | mail -s 'SMTP Test' root
]]>Als neuesten Service auf meinem Homeserver habe ich mir Dateisynchronisation auserkoren. Dadurch möchte ich Dateien zwischen den verschiedenen Computern in meinem Haushalt auf dem gleichen Stand halten ohne dabei die Möglichkeit zu verlieren auch offline mit ihnen zu arbeiten.
Eine Software die so etwas ermöglicht ist Seafile. Im Gegensatz zu bekannten Services wie Dropbox oder Google Drive kann man Seafile auf einem eigenen Server betreiben und es gibt eine Community Edition die Open Source ist. Wenn man sich mit Seafile beschäftigt sollte man etwas darauf achten, das es zwei verschiedene Forks gibt. Einerseits das „orginal“ aus China (seafile.com) und einen deutsche Variante unter seafile.de. Wer dazu näheres Wissen will, kann bei Wikipedia mit der Recherche anfangen. Ich beziehe mich im folgenden, ohne bestimmte Gründe, auf die Version der Seafile Ltd. aus China.
Beim Betrieb von Seafile werden verschiedene Informationen in Datenbanken abgelegt. Die Software unterstützt zwei Datenbanksysteme: Zum einen kann man das dateibasierte SQLight verwenden oder man nutzt einen MySQL-Server. Ich verwende erst mal SQLight. Wer gerne MySQL benutzen möchte findet entsprechende Informationen in der Dokumentation von Seafile.
Für die folgende Anleitung ist es wichtig zu wissen das Seafile aus drei Komponenten besteht. Der Seafile Deamon (kurz: Seafile) ist für das Hochladen, Runterladen und Synchronisieren zuständig. Der Seahub ist das Webfrontend in dem unter anderem die Benutzer und die Bibliotheken mit den Dateien verwaltet werden. Die dritte Komponente Ccnet wird vom Seafile-Server intern verwendet. Ein Schaubild dazu gibt es in der Dokumentation.
Bevor ich mich mit der eigentlichen Installation von Seafile beschäftige müssen ein paar Vorbereitungen getroffen werden. Als erstes erzeuge ich einen Benutzer unter dem Seafile später laufen soll:
useradd -r -m -d /opt/seafile -s /bin/false seafile
Dieses Kommando erzeugt einen System-Benutzer (-r) seafile ohne Passwort. Der Benutzer kann sich nicht anmelden weil seine Shell (-s) nicht wirklich eine ist. Als Home-Verzeichnis (-m -d) habe ich das Verzeichnis /opt/seafile/ gewählt da ich dort die Installation vornehmen möchte. Das Verzeichnis /opt/ ist für Software gedacht die am Paketmanager vorbei installiert wird.
Außer einem Benutzer lege ich auch noch ein neues Verzeichnis an in dem später die, durch Seafile verwalteten, Dateien abgelegt werden und berechtige den neuen Benutzer auf diesem Verzeichnis:
mkdir /var/seafile
chown seafile:seafile /var/seafile
Für den Betrieb richte ich auch noch eine eigene IP-Adresse ein damit ich die einzelnen Services auf meinem Server ordentlich voneinander separieren kann. Dazu lege ich eine neue Datei eth0-1 im Ordner /etc/network/interfaces.d/ an. In dieser definiere ich ein neues Interface mittel der folgenden Zeilen:
auto eth0:1
iface eth0:1 inet static
address 192.0.2.11
netmask 255.255.255.0
iface eth0 inet6 static
address 2001:DB8::11
netmask 32
Die Adressen sind natürlich an das lokale Netzwerk anzupassen. Anschließend initialisiere ich das neue Interface durch den Befehl if-up eth0:1
.
Um später die richtige Datei von Seafile herunterladen zu können benötige Ich noch eine Information über mein System. Es gibt nämlich unterschiedliche Downloads für 32-Bit und 64-Bit Systeme. Wenn man diese Information nicht weiß kann man sie mit folgendem Befehl ermitteln:
uname -m
Um die Vorbereitungen abzuschließen installiere ich noch die benötigten Pakete über die Paketverwaltung von Debian:
apt-get install nginx python2.7 libpython2.7 python-setuptools python-imaging python-ldap python-urllib3 sqlite3
Die im folgenden beschriebene Installation von Seafile ist angelehnt an die offizielle Dokumentation, berücksichtigt aber meine spezifischen Anpassungen. Insbesondere führe ich die Installation mit dem oben eingerichteten unprivilegierten Benutzer durch.
Damit später alles gut funktioniert wechsle ich vor der eigentlichen Installation zu dem neuen Benutzer seafile:
su - seafile -s /bin/bash
Dadurch befinde ich mich praktischer weise auch gleich in dessen Home-Verzeichnis /opt/seafile/ wo die Installation vorgenommen werden soll.
Auf der Webseite von Seafile kann man im Download-Bereich die benötigte Fassung des Seafile-Servers (32- oder 64-Bit) für Linux ermitteln. Die entsprechende URL hinter dem jeweiligen Link benutze ich im folgenden um das Archiv herunterzuladen und anschließend zu entpacken:
mkdir -p /opt/seafile/installed
cd /opt/seafile/installed
wget --content-disposition https://bintray.com/artifact/download/seafile-org/seafile/seafile-server_6.0.7_x86-64.tar.gz
tar -xzvf *tar.gz -C ../
cd ..
Für die Installation wechsele ich in das Verzeichnis /opt/seafile/seafile-server_6.0.7/ das durch das Entpacken des Downloads im vorangegangenen Schritt entstanden ist und führen das darin enthaltene Script setup-seafile.sh aus.
cd /opt/seafile/seafile-server-*
./setup-seafile.sh
Das Script fragt vier Parameter ab die es für die Konfiguration benötigt. Zu erst muss ich einen beliebigen Namen für meine Installation festlegen. Danach wird die IP-Adresse des Servers abgefragt. Hier muss ich diejenige eintragen die ich in den Vorbereitungen festgelegt habe. Als nächstes wird der Port für den Seafile-Server erfragt. Den belasse ich auf dem vorgegebenen Port 8082. Als letztes muss ich noch angeben in welchem Verzeichnis die zu verwaltenden Dateien abzulegen sind. Hierfür habe ich ja extra den Ordner /var/seafile/ vorbereitet.
Um die Installation abzuschließen starte ich Seafile und Seahub erstmalig. Dabei wird auch der Administratoraccount angelegt. Das starten erledigt man mittels spezieller Scripte aus dem Verzeichnis /opt/seafile/seafile-server-latest welches bei der Installation angelegt wurde.
/opt/seafile/seafile-server-latest/seafile.sh start
/opt/seafile/seafile-server-latest/seahub.sh start 8000
Beim Start von Seahub muss ich dazu eine E-Mail-Adresse und ein Passwort eingeben mit denen ich mich später als Administrator anmelden kann. Jetzt kann ich schon mal einen ersten Blick auf Seahub werfen indem ich http://192.0.2.11:8000 in meinem Browser aufrufe.
Außerdem habe ich bemerkt das beim Start eine Warnmeldung ausgegeben wird:
LC_ALL is not set in ENV, set to en_US.UTF-8
./seahub.sh: Zeile 207: Warnung: setlocale: LC_ALL: Kann die Locale nicht ändern (en_US.UTF-8): Datei oder Verzeichnis nicht gefunden
Diese hat etwas mit den Spracheinstellungen zu tun und wird von mir erst mal ignoriert. Beim erstelle des Init-Scripts weiter unten komme ich aber noch einmal darauf zurück.
Anschließend muss ich sowohl Seafile als auch Seahub wieder beendet werden um die nächsten Schritte vornehmen zu können:
/opt/seafile/seafile-server-latest/seahub.sh stop
/opt/seafile/seafile-server-latest/seafile.sh stop
Obwohl Seafile einen eigenen Webserver mitbringt möchte ich doch Nginx verwenden. Das hat den einfachen Grund das ich so eine Transportverschlüsselung einrichten kann. Nach dem ich die im Folgenden beschriebenen Schritte durchgeführt habe, wird Nginx die HTTP-Requests für den Seafile-Server entgegennehmen und die Verschlüsselung managen. Dann reicht er die Anfrage an Seafile und Seahub weiter und gibt die Antwort von diesen, wiederum verschlüsselt, an den Aufrufer zurück. Die Art wie ich Nginx in diesem Fall einsetze nennt man einen Reverse Proxy.
Meine Vorgehensweise ist wiederum angelehnt an die offizielle Dokumentation von Seafile. Die beiden Artikel Config Seahub with Nginx und Enabling Https with Nginx fasse ich im folgenden, angereichert um meine eigenen Vorstellungen, zusammen.
Die Datei /opt/seafile/conf/ccnet.conf muss für den Betrieb mit Nginx geändert werden so das die Service-URL darauf zeigt. Dazu ändere ich den momentanen Wert von SERVICE_URL so ab, dass TLS (HTTPS) genutzt wird und statt dem Port 8082 von Seafile der Standard-TLS-Port 443:
SERVICE_URL = https://192.0.2.11
Ebenfalls ändere ich die Datei /opt/seafile/conf/seahub_settings.py um auch hier den Verweis auf Nginx zu ergänzen. Dazu füge ich die folgende Zeile an die Datei an:
FILE_SERVER_ROOT = https://192.0.2.11/seafhttp
Als drittes ändere ich auch noch die Datei /opt/seafile/conf/seafile.conf. Hier füge ich ebenfalls eine Zeile ein:
host=127.0.0.1
Dadurch erreiche ich das der Seafile Deamon nur noch lokal auf dem Server, und nicht zusätzlich zu Nginx von außen erreichbar ist.
Damit ist die Konfiguration von Seafile abgeschlossen und ich wechsele zu Nginx. Dazu kehre ich mit dem Kommando exit
auch vom Benutzer Seafile zu root zurück.
Als erste Maßnahme erzeuge ich ein neues Zertifikat für die neue IP-Adresse um damit TLS einrichten zu können:
mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
openssl genrsa -out seafile.key 4096
openssl req -new -sha256 -key seafile.key -out seafile.csr
openssl x509 -req -sha256 -days 3650 -in seafile.csr -signkey seafile.key -out seafile.crt
Damit erzeuge ich ein selbstsigniertes Zertifikat das für meine Zwecke ausreichen ist.
Der Weg um Seafile mit Nginx zu verknüpfen führt über eine zusätzliche Konfigurationsdatei. Dazu lege ich in /etc/nginx/sites-available/ eine neue Datei namens seafile an. Darin wird die Verknüpfung zum Seahub mittels der Schnittstellentechnik FastCGI hergestellt. Auch der Proxy für den Seafile-Server wird hier eingerichtet. Ich lehne mich dabei an die Vorgaben aus der Dokumentation von Seafile an.
Der erste Server-Block in dieser Datei befasst sich mit „normalen“ HTTP für die gewählte IP auf Port 80. Das einzige was ich hier einstelle ist eine Weiterleitung auf HTTPS welches ich wiederum im nächsten Block konfiguriere.
server {
listen 192.0.2.11:80;
listen [2001:DB8::11]:80;
return 301 https://$server_name$request_uri;
}
Der zweite Server-Block hat vier Abschnitte. Im ersten definiere ich die allgemeinen Parameter wie IP, Port, TLS-Zertifikate und ein paar einfache Sicherheitseinstellungen.
server {
listen 192.0.2.11:443 ssl;
listen [2001:DB8::11]:443 ssl;
ssl_certificate /etc/nginx/ssl/sync.files.home.crt;
ssl_certificate_key /etc/nginx/ssl/sync.files.home.key;
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
server_tokens off;
proxy_set_header X-Forwarded-For $remote_addr;
…
}
Anschließend konfiguriere ich die Fast-CGI-Schnittstelle zum Seahub und mache diesen somit unter dem Wurzelverzeichnis (/) der Nginx-Webseite verfügbar.
server {
…
location / {
fastcgi_pass 127.0.0.1:8000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param HTTPS on;
fastcgi_param HTTP_SCHEME https;
fastcgi_read_timeout 36000;
access_log /var/log/nginx/seahub.access.log;
error_log /var/log/nginx/seahub.error.log;
}
…
}
Die Synchronisationsmechanismen für die Dateien (der Seafile Deamon) binde ich über eine Proxy-Anweisung an den Pfad /seafhttp/. Dieser ist damit ebenfalls über HTTPS erreichbar.
server {
…
location /seafhttp {
rewrite ^/seafhttp(.*)$ $1 break;
proxy_pass http://127.0.0.1:8082;
client_max_body_size 0;
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
proxy_send_timeout 36000s;
send_timeout 36000s;
}
…
}
Abschließend definiere ich auch noch den Pfad /media/. Dieser Pfad stellt einige statische Dateien für Seahub bereit und verweist einfach auf einen Ordner innerhalb des Installationsverzeichnisses.
server {
…
location /media {
root /opt/seafile/seafile-server-latest/seahub;
}
}
Nach einem Neustart von Nginx mittels /etc/init.d/nginxs restart
ist dessen Konfiguration abgeschlossen. Jetzt noch einen Test bevor ich weiter mache. Dazu wieder mit dem Benutzer Seafile sowohl den Deamon als auch den Seahub starten. Wobei Seahub im Fast-CGI-Modus laufen muss:
su - seafile -s /bin/bash
/opt/seafile/seafile-server-latest/seafile.sh start
/opt/seafile/seafile-server-latest/seahub.sh start-fastcgi
exit
Jetzt sollte über https://192.0.2.11/ das Webinterface aufrufbar sein. Dabei muss die Warnung des Browsers vor dem unbekannten TLS-Zertifikats weggeklickt werden.
Um Seafile besser in Debian zu integrieren bedarf es eines Init-Scripts. Dieses sorgt dann dafür das Seafile beim Booten des Servers gestartet wird und auch beim herunterfahren oder beim Neustart sauber beendet wird. Eine passende Vorlage kann, mal wieder, dem Artikel Start Seafile at System Bootup aus der Dokumentation von Seafile entnommen werden. Damit das Script allerdings funktioniert muss der Befehl sudo ersetzt werden da dieser unter Debian nicht unbedingt zur Verfügung steht. An den relevanten Stellen bin ich daher auf su ausgewichen.
Eine zweite Änderung am Init-Script führt mich zu der Warnmeldung bezüglich der Locale zurück die beim Starten von Seafile auftritt. Die Ursache für diese Fehlermeldung liegt darin das ich bei der Installation von Debian die deutsche Sprache ausgewählt habe. Seafile versucht nun auf eine englisch Umgebung umzustellen was der Benutzer seafile aber gar nicht darf. Daher setzte ich eine Umgebungsvariable LC_ALL auf die gewünschte deutsche Locale de_DE.UTF-8 und der Server startet ohne Fehler.
#!/bin/sh
### BEGIN INIT INFO
# Provides: seafile-server
# Required-Start: $local_fs $remote_fs $network
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Starts Seafile Server
# Description: starts Seafile Server
### END INIT INFO
# Change the value of "user" to linux user name who runs seafile
user=seafile
# Change the value of "seafile_dir" to your path of seafile installation
# usually the home directory of $user
seafile_dir=/opt/seafile
script_path=${seafile_dir}/seafile-server-latest
seafile_init_log=${seafile_dir}/logs/seafile.init.log
seahub_init_log=${seafile_dir}/logs/seahub.init.log
# Change the value of fastcgi to true if fastcgi is to be used
fastcgi=true
# Set the port of fastcgi, default is 8000. Change it if you need different.
fastcgi_port=8000
#
# Write a polite log message with date and time
#
echo -e "\n \n About to perform $1 for seafile at `date -Iseconds` \n " >> ${seafile_init_log}
echo -e "\n \n About to perform $1 for seahub at `date -Iseconds` \n " >> ${seahub_init_log}
case "$1" in
start)
su -c "${script_path}/seafile.sh ${1} >> ${seafile_init_log}" -s /bin/bash ${user}
if [ $fastcgi = true ];
then
su -c "export LC_ALL='de_DE.UTF-8' && ${script_path}/seahub.sh ${1}-fastcgi ${fastcgi_port} >> ${seahub_init_log}" -s /bin/bash ${user}
else
su -c "${script_path}/seahub.sh ${1} >> ${seahub_init_log}" -s /bin/bash ${user}
fi
;;
restart)
su -c "${script_path}/seafile.sh ${1} >> ${seafile_init_log}" -s /bin/bash ${user}
if [ $fastcgi = true ];
then
su -c "${script_path}/seahub.sh ${1}-fastcgi ${fastcgi_port} >> ${seahub_init_log}" -s /bin/bash ${user}
else
su -c "${script_path}/seahub.sh ${1} >> ${seahub_init_log}" -s /bin/bash ${user}
fi
;;
stop)
su -c "${script_path}/seahub.sh ${1} >> ${seahub_init_log}" -s /bin/bash ${user}
su -c "${script_path}/seafile.sh ${1} >> ${seafile_init_log}" -s /bin/bash ${user}
;;
*)
echo "Usage: /etc/init.d/seafile-server {start|stop|restart}"
exit 1
;;
esac
Dieses Script speichere ich unter /etc/init.d/seafile-server und mache es ausführbar:
sudo chmod +x /etc/init.d/seafile-server
Anschließend registiere ich das Script noch damit es beim Hochfahren auch ausgeführt wird.
sudo update-rc.d seafile-server defaults
Wenn nach einem Neustart des Servers, diesmal ist die Hardware gemeint, Seahub im Browser aufrufbar ist hat alles geklappt und die Installation ist vollständig.
Einige Aspekte lasse ich hier bewusst außen vor – der Artikel ist auch so schon lang genug:
Wer nicht gern mit IP-Adressen hantiert kann natürlich auch Hostnamen festlegen und diesen an stelle der IP benutzen.
Wen die Fehlermeldungen zum TLS-Zertifikat stören kann man auch eine eigene CA(Certificate Authority) aufsetzen um hier Besserung zu schaffen.
Etwas mehr Sicherheit? Firewallregeln für Seafile sind recht einfach umzusetzen.
Für den laufenden Betrieb sollte man nötige Updates im Auge behalten und einspielen.
Auch Backups sind ein wichtiges Thema um nicht eines Tages in einem Scherbenhaufen zu stehen.
]]>02.11.2020: Angepasst an Version 0.7.2 von Baïkal sowie an Debian 10 (gilt auch für Raspberry Pi OS).
Baïkal basiert auf PHP und speichert die Daten mittels SQLight (MySQL geht aber auch). Dadurch bedingt muss ein Webserver, ein PHP-Interpreter und die Bibliotheken für die Datenbank installiert sein. Wie das mit dem Server Nginx auf einem Raspberry Pi, gelingt hat Jan Karres in seinem Blogbeitrag Raspberry Pi: Webserver Nginx installieren sehr schön dargestellt. Ich empfehle daher diese Anleitung zu befolgen bevor es hier weitergeht.
Die Kurzfassung ist mit folgenden drei Befehl gegeben:
sudo apt-get install nginx php-fpm
sed -i "s/worker_processes 4;/worker_processes 1;/g" /etc/nginx/nginx.conf
sed -i "s/worker_connections 768;/worker_connections 128;/g" /etc/nginx/nginx.conf
Zusätzlich zu Nginx als Webserver und PHP-FPM benötigen wir noch SQLight für PHP. Außerdem werden noch ein paar PHP-Funktions-Module benötigt. Die nötigen Pakete können wir ganz einfach installieren:
sudo apt-get install php-sqlite3 php-curl php-mbstring php-xml
Um Baïkal möglichst problemlos betreiben zu können empfehle ich die Software unter einer eigenen IP-Adresse laufen zu lassen. Dazu muss eine neue Datei _/etc/network/interfaces.d/eth0_1 angelegt und wie folgt befüllt werden.
auto eth0:1
iface eth0:1 inet static
address 192.0.2.11
netmask 255.255.255.0
iface eth0:1 inet6 static
address 2001:DB8::11
netmask 32
Hierdurch wird ein virtuelles Netzwerkinterface mit Namen eth0:1 angelegt und diesem Interface sowohl eine neue IPv4- als auch eine neue IPv6-Adresse zugewiesen. Unter diesen Adressen kann man dann Baïkal in Nginx einrichten.
Um die Kommunikation mit Nginx zu verschlüsseln braucht es ein Zertifikat. Ein solches lässt sich recht einfach erstellen. Die folgenden Befehle legen erst einen Schlüssel und darauf basierend ein selbst signiertes Zertifikat an. Dieses Zertifikat verwendet man dann in der Definition des Nginx-Hosts die später erstellt wird.
sudo mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
sudo openssl genrsa -out baikal.key 4096
sudo openssl req -new -sha256 -key baikal.key -out baikal.csr
sudo openssl x509 -req -sha256 -days 3650 -in baikal.csr -signkey baikal.key -out baikal.crt
Nach den obigen Vorbereitungen nun zu eigentlichen Installation. Auch hier hat Jan Karres wieder Vorarbeit geleistet und einen passenden Artikel veröffentlicht. Ich habe jedoch ein paar Dinge anders gemacht und gehe daher noch einmal gesondert auf die Installation ein:
cd /opt
sudo wget https://github.com/sabre-io/Baikal/releases/download/0.7.2/baikal-0.7.2.zip
sudo unzip baikal*.zip -d .
sudo chown -R www-data:www-data baikal/
sudo find baikal/ -type d -exec chmod 550 {} \;
sudo find baikal/ -type f -exec chmod 440 {} \;
sudo rm baikal-regular-*.tgz
Diese sieben Befehle wechseln in das Verzeichnis opt (wie optional), laden dort die Version 0.7.2 von Baïkal herunter, entpacken dieses Archive, wechseln den Besitzer des Ordners und setzen ein paar Rechte. Der letzte Befehl löscht das Download-Archiv wieder, Ordnung muss sein.
Baïkal benötigt Schreibrechte für die Datenbank mit den Einträgen und die Konfigurationsdateien. Glücklicherweise sind diese Dateien in zwei Ordner config und Specific versammelt. So lässt sich die Rechteausweitung auf diese beschränken:
sudo chmod u+w baikal/config/baikal.yaml
sudo chmod u+w baikal/Specific/db
sudo chmod u+w baikal/Specific/db/db.sqlite
Baïkal enthält bereits eine Konfigurationsdatei für Nginx. Diese kopiert man nach /etc/nginx/sites-available.
sudo cp Specific/virtualhosts/baikal.nginx /etc/nginx/sites-available/baikal
Die Datei muss allerdings noch ein wenig angepasst werden. Unter anderem passt die Angabe zum PHP-Interpreter nicht. Die Angabe fastcgi_pass muss wie folgt angepasst werden:
fastcgi_pass unix:/var/run/php7.3-fpm.sock;
Außerdem muss der block mit den Servereinstellungen durch zwei neue Blöcke ersetzt werden. Der erste dieser Blöcke leitet HTTP-Requests auf verschlüsseltes HTTPS weiter. Der Zweite lässt Nginx auf eben dieses Protokoll hören. Hier kommt das oben erzeugte Zertifikat zum Einsatz.
server {
listen 192.0.2.11:80;
listen [2001:DB8::11]:80;
return 301 https://$host$request_uri; # enforce https
}
server {
listen 192.0.2.11:443 ssl;
listen [2001:DB8::11]:443 ssl;
ssl_certificate /etc/nginx/ssl/baikal.crt;
ssl_certificate_key /etc/nginx/ssl/baikal.key;
...
Die dritte Anpassung betrifft den Speicherort von Baïkal. Dieser weicht in meinem Fall von der Vorgabe ab und muss daher geändert werden:
root /opt/baikal/html;
In obigen Beispielen müssen natürlich die IP-Adressen angepasst werden. Danach kann Baïkal aktiviert werden. Dazu wird ein Link zur Konfigurationsdatei im Ordner /etc/nginx/sites-enabled angelegt und Nginx neu gestartet.
sudo ln -s /etc/nginx/sites-available/baikal /etc/nginx/sites-enabled/baikal
sudo /etc/init.d/nginx restart
Es ist soweit: Unter der URL https://192.0.2.11/admin/install/ kann man mit der Nutzung von Baïkal beginnen. Nach ein paar allgemeinen Fragen kann man den ersten Benutzer einrichten und schon ist der Server einsatzbereit.
Baïkal bietet kein Webinterface um auf die Kalender oder Adressbücher zuzugreifen. Hierfür braucht man entsprechende Client-Software. Ich benutze auf dem PC das Gespann aus Thunderbird und Lightning (für Kalender) ergänzt um das Plugin SOGo Connector. Unter Android die beiden Apps CalDAV-Sync und CardDAV-Sync. Es gibt aber weitere Alternativen die die beiden Protokolle CardDAV und CalDAV unterstützen.
Die nötigen URL’s die man bei der Konfiguration braucht lauten wie folgt:
Die IP und die in eckigen Klammern gesetzten Variablen sind natürlich anzupassen.
Damit nichts verloren geht sollte man natürlich ein Backup machen. Baïkal speichert die Daten im Ordner Specific. Darin enthalten ist die SQLight-Datei mit der Datenbank. Dazu kommt eine Einstellungsdatei im Ordner config. In diesen werden die Angaben gespeichert die man im Webinterface von Baïkal eingibt.
Vor dem Backup sollte man kurz den Webserver anhalten damit keine aktiven Verbindungen im Moment des Backups Änderungen vornehmen.
Das folgende, ganz einfache, Script erledigt das Backup. Es schließt dabei auch die Konfiguration von Nginx inklusive des SSL-Zertifikats ein. Da auch der Key für dieses Zertifikat im Backup enthalten ist sollte man dieses sicher verwahren. In der vorliegenden Fassung werden die Dateien nach /var/backups/ geschrieben. Von dort aus kann man sie dann jederzeit an einen sicheren Ort kopieren.
#!/bin/bash
mkdir /var/backups/nginx
mkdir /var/backups/nginx/ssl
mkdir /var/backups/nginx/sites-available
chmod -R 600 /var/backups/nginx
find /var/backups/nginx/ -type d -exec chmod 700 {} \;
mkdir /var/backups/baikal
mkdir /var/backups/baikal/config
mkdir /var/backups/baikal/Specific
mkdir /var/backups/baikal/Specific/db
chmod -R 600 /var/backups/baikal
find /var/backups/baikal/ -type d -exec chmod 700 {} \;
/etc/init.d/nginx stop
cp /etc/nginx/ssl/baikal.* /var/backups/nginx/ssl/
cp /etc/nginx/sites-available/baikal /var/backups/nginx/sites-available/baikal
cp /opt/baikal/config/baikal.yaml /var/backups/baikal/config
cp /opt/baikal/Specific/db/db.sqlite /var/backups/baikal/Specific/db/db.sqlite
/etc/init.d/nginx start
]]>29.10.2020: Ich überarbeite den Artikel gerade Stück für Stück. Die Einkaufsliste ist noch recht alt dafür ist der Installationsprozess jetzt überarbeitet.
Zu erst muss man natürlich Einkaufen gehen. Als erstes auf der Liste steht der Raspberry Pi selbst. Es gibt mittlerweile sechs Varianten. Die Älteren Varianten A und B (mit 256 MB oder 512 MB RAM) lasse ich mal links liegen. Der Pi A+ hat kein Netzwerkinterface also bleibt für meine Zwecke der Raspberry Pi B+ oder der neue Raspberry Pi 2 B. Letzteres Modell ist erst erschienen als ich mit meiner Einkaufstour schon fertig war. Alles folgende bezieht sich also auf das Model B+.
Anstelle der Festplatte benötigt der Pi eine Micro-SD-Card. Ich nehme üblicherweise 8GB oder 16GB Karten. Die Geschwindigkeit ist dabei von hoher Bedeutung. Die schnellste spezifizierte Art von Karten entspricht der sogenannten Class 10. Innerhalb dieser Klasse gibt es aber trotzdem noch Unterschiede. Wer also die Wahl hat sollte auf die Übertragungsrate achten.
Die Stromversorgung erledigt ein externes Micro-USB-Netzteil. Die meisten Smartphones und Tablets haben heute ein derartiges Netzteil. Die Spannung von 5 Volt ist bei USB genormt. ich achte immer auf eine Stromstärke von zwei Ampere. Damit hat man genug Leistung um auch ein wenig Peripherie zu versorgen. Wenn man noch ein Netzteil herumliegen hat kann man es meist problemlos verwenden.
Der Pi muss auch noch schön verpackt werden. Ich habe mich zuletzt für ein schickes Gehäuse von oneninedesign entschieden. Es ist zwar etwas schwergängig aber wenn der Pi erst mal eingebaut ist passt alles.
Als Zubehör sollte man auch noch über Anschlusskabel für Netzwerk und einen Monitor (HDMI) nachdenken. Eventuell braucht man auch noch einen Adapter von HDMI auf DVI. Am Anfang, bevor die Fernwartung eingerichtet wurde, braucht man auch noch eine USB-Tastatur.
Der Pi hat kein BIOS, wie ein üblicher PC. Aus diesem Grund kann man auch nicht einfach einen USB-Stick einstecken und ein Betriebssystem installieren. Stattdessen überträgt man auf einem anderen Computer ein Image auf die SD-Karte. Diese kann man dann in den Pi einsetzen und diesen Booten.
Auf raspberrypi.org gibt es den Raspberry Pi Imager um eine solche SD-Karte zu erzeugen. Das Tool lässt einem die Wahl zwischen verschiedenen Betriebssystemen. Für den Zweck eines Homeservers ist Raspberry Pi OS (32-bit) Lite geeignet.
Raspberry Pi OS (früher Raspian genant) basiert auf Debian. Somit sind die anderen Artikel die ich hier geschrieben habe auch anwendbar.
SD-Karte einstecken, Monitor und Tastatur anschließen, Netzwerkkabel reinstecken, Strom an…
Nach dem ersten Start muss man erst mal die Anmeldung überwinden. Der Benutzer ist pi und das Passwort raspberry. Aber Achtung: Die Tastatur ist auf englisches Layout eingestellt. Das „y“ ist als auf der Z-Taste.
Nach der Anmeldung startet man als erstes das Konfigurationsprogramm namens „raspi-config“ (auch hier wieder Achtung mit dem Tastaturlayout, der Bindestrich ist beim „ß“). Hier kann man einige grundlegende Dinge einstellen bevor es weiter geht.
Ein Image aufzuspielen hat einige Nachteile gegenüber einer herkömmlichen Installation. Unter anderem ist das Dateisystem immer nur so groß wie das aufgespielte Image. Mit diesem Menüpunkt, zu finden unter „Advanced Options“, wird der gesamte Speicher der SD-Karte nutzbar gemacht.
In den Einstellungen zur Internationalisierung (Localisation Options) sollte man drei Änderungen vornehmen. Zu erst nimmt man eine weitere Locale für deutsch auf (de_DE.UTF-8). Dann ändert man die Timezone um die Uhr richtig zu stellen. Hier hangelt man sich von Europa nach Berlin durch. Als drittes wird das Tastaturlayout passend eingestellt. Für die meisten Tastaturen sollten man hier „Generic 105-key PC (Intl.)“ wählen. Danach sitzt man vor einer Liste für englische Tastaturen. Hier wählt man „Other“ und dann „German“. Danach wieder „German“. Danach bestätigt man noch dreimal die Vorgaben und ist fertig. Jetzt sind die Sonderzeichen alle da wo sie hin sollen.
Vertraue niemals einem voreingestellten, default Passwort. Der Anmeldename zu diesem Passwort ist übrigens „pi“. Diesen Schritt sollte man übrigens nicht machen bevor die Tastatur richtig eingestellt ist da man sich sonst mit den Sonderzeichen im gewählten Password selbst ein Bein stellt.
In den „Network Options“ kann man den Namen des Rasperry Pi festlegen. Muss man zwar nicht machen empfiehlt sich aber spätestens wenn man mehrere der kleinen Kisten im Einsatz hat.
In den „Interfacing Options“ sollte man ”SSH” aktivieren. SSH braucht man um den Pi über das Netzwerk zu administrieren.
Wenn man die Konfiguration verlässt, landet man auf der Shell. Hier empfiehlt es sich erst einmal alle verfügbaren Updates einzuspielen.
sudo apt-get update
sudo apt-get upgrade
Die beiden Befehle bringen zuerst einmal die Datenbank mit verfügbarer Software auf den aktuellen Stand und installiert danach die neuesten Versionen der bereits vorhandenen Software.
Wer mag kann den Pi danach über sudo shutdown r now
neu starten. Muss man aber nicht unbedingt, ist ja nicht Windows.
Ein Server muss erreichbar sein. Ohne manuelle Eingriffe besorgt sich der Pi zwar eine IP-Adresse mittels DHCP vom Router.
Eine mehr oder weniger zufällige IP-Adresse die über DHCP vergeben wurde ist aber nicht ausreichend. Was gebraucht wird ist eine feste IP die sich nie ändert. Um das zu erreichen muss man eine Datei unter /etc/network/interfaces.d anlegen.
nano /etc/networks/interfaces.d/eth0
Das nach nachfolgende Beispiel legt jeweils eine IPv4 und eine IPv6 fest und weißt auch den Router für den Internetzugang zu:
auto eth0
iface eth0 inet static
address 192.0.2.10
netmask 255.255.255.0
gateway 192.0.2.1
iface eth0 inet6 static
address 2001:DB8::10
netmask 32
gateway 2001:DB8::1
Die ersten beiden Zeilen definieren das Loopback-Interface, auch als Localhost bekannt. Danach folgt jeweils eine Block für IPv4 und IPv6. Nach einem Neustart des Pi sind die gewählten IP-Adressen aktiv.
Die hier angegebenen Adressen sind natürlich nur Beispiele und müssen an die lokalen Gegebenheiten angepasst werden.
Mit den hier beschriebenen Schritten kann man einen Pi im Keller aufstellen und über das Netzwerk administrieren. Was jetzt noch fehlt sind sinnvolle Services. Für Kalender kann man zum Beispiel Baikal nutzen. Für Datei-Synchronisierung will ich Seafile ausprobieren.
Genaueres habe ich schon über Baikal geschrieben. Damit habe ich jetzt ein paar Jahre Erfahrung gesammelt und bin mit Kalendern und Adressbüchern dieser Software recht zufrieden.
]]>(29.10.2020 – Angepasst an aktuelles Rasperry Pi OS und raspberry-config)
]]>Bevor man Umbaumaßnahmen vornimmt ist es immer gut sich anzusehen wo man herkommt. Das hilft ungemein wenn etwas schiefgeht. Alle folgenden Befehle habe ich unter Debian ausprobiert und gehe so vor das ich am ende eine zusätzliche Platte zur Verfügung habe.
Anfangen kann man damit alle Festplatten und Partitionen auflisten zu lassen:
ls /dev/sd*
/dev/sda /dev/sda1 /dev/sda2
Hier ist eine Festplatte zu sehen (sda) auf der zwei Partitionen verfügbar sind (sda1 und sda2). Dabei handelt es sich um sogenannte Gerätedateien die Linux als Stellvertreter für die tatsächliche Hardware benutzt und im Verzeichnis dev(Devices) anlegt.
Was genau hinter dieser Festplatte steckt kann man den Computer auch entlocken. Der folgende Befehl liefert alle Meldungen zu SATA-Festplatten auf die beim Booten gefunden wurden. Diese Meldungen liefern Informationen über ATA-Level, Hersteller, Modell und Firmware:
dmesg | grep ATA-[789]
[ 1.885207] ata9.00: ATA-8: SAMSUNG HD502HJ, 1AJ100E4, max UDMA/133
Als nächstes kann man sich anzeigen lassen wo diese Partitionen verwendet werden:
mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
…
Hier sieht man das die Partition /dev/sda1 als Root-Directory genutzt wird, also die grundlegende Partition für das ganze System ist. Das Dateisystem auf ist übrigens “ext3” Die Partition /dev/sda2 ist hier nicht aufgeführt weil es sich um eine Swap-Partition handelt die nicht zum speichern von Daten genutzt wird. Wie wir das erkennen zeige ich gleich.
Etwas mehr Informationen über als den Mountpoint liefert folgendes Kommando:
blkid -o list -w /dev/null
Wie man schön an der tabellarischen Ausgabe sehen kann sind hier auch die Swap-Partitionen aufgeführt und die UUID. Die brauchen wir später noch.
<pre>device fs_type label mount point UUID
-------------------------------------------------------------------------------
/dev/sda1 ext3 Debian / c91074ad-4843-4b86-9407-52ce4e1a187e
/dev/sda2 swap <swap> cd59162a-87c3-4274-89e6-f3cd77a080d5
Noch mehr Informationen über einzelne Partitionen liefert der Befehl tune2fs
. Hier bei muss natürlich die konkrete Platte angeben werden anstelle meines Platzhalters “/dev/sd?#”.
tune2fs -l /dev/sd?#
Wer jetzt noch Hilfe braucht die einzelnen Platten in seinem System zu identifizieren kann sich auch die Plattengröße und -belegung anzeigen lassen;
df -h
Dateisystem Size Used Avail Use% Eingehängt auf
/dev/sda1 444G 379G 43G 90% /
…
Nachdem einbauen einer neuen Platte ist diese noch zu nichts nutze. Zuerst muss sie mal Partitioniert werden. Dazu verwende ich das Programm Parted das mit aptitude install parted
aber erst mal installiert werden muss. Danach muss man mittels ls /dev/sd*
herausfinde welche Gerätedatei der neuen Festplatte zugeordnet wurde. Mit dieser Information kann man dann Parted aufrufen. Dabei ist im folgenden das Fragezeichen immer durch den entsprechende Buchstaben zu ersetzen.
parted /dev/sd?
Dieser Befehl öffnet eine interaktive Konsole in der man Parted-Kommandos eingeben kann. Der erste dieser Befehle erzeugt eine Partitionstabelle gemäß dem Standard GPT
mktable gpt
Der zweite erzeugt eine Partition vom ersten (1) bis zum letzten Sektor (-1):
mkpart primary ext3 1 -1
quit
Wer mag kann auch noch ein Label für die neu erzeugte Partition vergeben:
tune2fs -L Label /dev/sd?1
Bei Linux gibt es ja anders als in der Windows-Welt keine Laufwerksbuchstaben. Stattdessen verwendet man die Partition wie einen Ordner. Dazu muss man einen leeren Ordner haben und die Partition dort hin mounten.
mkdir /media/wohin
mount /sd*1 /media/wohin
Diese beiden Befehle erzeugen erst mal einen leeren Ordner “wohin” im Ordner “/media” und mounted im zweiten Schritt die oben angelegte Partition in diesen Ordner. Ab jetzt wird alles was in den Ordner “/media/wohin” gespeichert wird in Wirklichkeit auf der Festplatte abgelegt.
Leider geht diese Zuordnung zwischen Verzeichnis und Partition beim nächsten Neustart verloren. Um das zu verhindern sollte man die Datei “/etc/fstab” (File System Table) editieren. In dieser Datei stehen nämlich alle Zuordnungen die beim Systemstart vorgenommen werden sollen. Um die nötigen Informationen zu bekommen wird noch einmal der Befehl blkid -o list -w /dev/null
ausgeführt. Dieser verrät uns die UUID, eine eindeutige und unveränderliche Kennung, der Partition. Mit dieser können wir dann eine neue Zeile nach folgendem Muster in “/etc/fstab” eintragen:
<file system> <mount point> <type> <options> <dump> <pass>
UUID=2cc507f3-0e6d-41cc-adf4-880a769a7cc3 /mount/wohin ext3 errors=remount-ro 0 1
]]>Seit diesem Vorfall tritt das Problem immer etwa 5 bis 90 Minuten nach einem Neustart auf. Wenn man dann schnell genug war bekam man die folgende Fehlermeldung zu sehen:
[ 2995.720211] [drm:drm_fb_helper_panic] *ERROR* Panic occurred, switching back to text console
Das hat mit erst mal nicht sehr weitergeholfen. Einige Internet-Recherchen ergaben lediglich eine wage Vorstellung das die Grafikkarte beziehungsweise der Treiber des NVIDIA-Chips daran beteiligt waren.
Also habe ich die Grafikkarte ausgebaut und den Server neu gestartet. seit dem läuft mein Linux wieder. Ein genauerer Blick auf die Grafikkarte offenbarte einen defekten Kondensator. Das ist recht einfach erkennbar: Wenn einer der kleinen Tönnchen auf der Platine nach oben ausgebeult ist, ist das entsprechende Bauteil defekt.
Zum Glück läuft ein Server ja auch ohne Grafikkarte, zu mindestens bis ich eine neue besorgt habe.
]]>Bevor ich mit dem Upgrade auf eine neue Version beginne, führe ich erst noch alle ausstehenden Updates für die alte Version durch. Leider führte das diesmal zu einer Fehlermeldung über fehlenden Speicherplatz auf der Partition /boot. Was ist da aber bitte so groß? Im Grunde liegen dort doch nur der Kernel und die zugehörige RAM-Disk. Bei Ubuntu ist es aber nicht nur ein Kernel sondern alle Kernel die jemals installiert wurden.
Um Platz zu schaffen muss man demzufolge erst mal wissen welcher Kernel gerade aktive ist und welche sonst noch installiert sind.
Den aktiven Kernel gibt man mit uname -r
im Terminal aus. Die Liste aller installierten Kernel kann man dem Paketmanager von Ubuntu entlocken:
dpkg -l | grep linux-image
Um eine Kernelversion loszuwerden kann man das zugehörige Kernelimage und die Header-Dateien deinstallieren. Aber Achtung: den aktuellen Kernel und einen weiteren “Reservekernel” sollte man nicht entfernen.
apt-get remove linux-image-3.5.0-17-generic
apt-get remove linux-headers-3.5.0-17-generic
Bei den beiden obigen Befehlen muss man natürlich die Versionsnummer austauschen. Wenn alle überzähligen Kernel auf diese Weise deinstalliert wurden ist wieder genug Platz für den neuesten Kernel.
Das Update verlief nach den obigen Aufräumarbieten Reibungslos. Allerdings drängt sich mir der Verdacht auf das eine Neuinstallation schneller gegangen wäre – das Prozedere hat schon eine gefühlte Ewigkeit gedauert.
Etwas überrascht war ich über einige optische Änderungen. Einige Symbole wurde verändert. Leider nicht zum besseren wie ich finde. Am auffälligsten aber ist die Auswahl die man beim beenden des Systems bekommt. Die Transparenz ist zu hoch und der Kontrast so schwach das man schon sehr genau hinsehen muss um zu erkennen was man da anklicken soll:
]]>Genau zu diesem Zweck gibt es das Network Time Protokoll, kurz NTP. Damit ist es möglich direkt von einer angeschlossenen Uhr oder indirekt von einem Server die Zeit zu erfragen.
Unter Linux gibt es üblicherweise zwei Wege das NTP zu nutzen: Ein einfacher Client namens ntpdate ermöglicht auf einfache Weise einen Zeitservern abzufragen und die Systemzeit danach zu setzen. Etwas umfangreicher ist der Daemon ntpd. Dieser dient gleichzeitig als Server und Client.
In diesem Fall habe ich mich für die umfangreichere Lösung entschieden. Dadurch kann ich nicht nur den Server “up-to-date” halten sondern auch diese Zeit weiterreichen. Im optimalen Fall sind so alle Computer im Netzwerk auf der selben Zeit.
Die Installation unter Debian ist ganz einfach:
aptitude install ntp ntpdate
Das Paket ntp enthält den eigentlichen Daemon und Verwaltungstools. Der NTP-Client aus dem Paket ntpdate dient nur zum anfänglichen Stellen der Zeit:
ntpdate -b 1.de.pool.ntp.org
Mit diesem Befehl wird ein Serverpool mit deutschen Servern als Zeitquelle genutzt. Diesen und weitere Pools mit öffentlichen NTP-Servern werden auf www.pool.ntp.org bereitgestellt. Wer möchte darf hier auch selbst Server beisteuern.
Die anfängliche Synchronisierung ist nötig da der ntpd nur dann seine Arbeit machen möchte wenn ein Mindestmaß an korrekter Zeit vorliegt. Wer also mag kann die Uhr seines Computers auch von Hand stellen bevor ntpd seine Arbeit aufnimmt..
Abschließend startet man den NTP-Server noch mittels…
/etc/init.d/ntp start
Die Konfiguration des ntpd befinden sich in der Datei /etc/ntp.conf.
Die Standarteinstellungen von Debian für den ntpd sind in meinen Augen wirklich brauchbar. Ich habe lediglich die voreingestellten Zeitserver gegen vier Pools mit Servern aus Deutschland ausgetauscht.
Wer sich den unteren Teil der Konfigurationsdatei ansieht findet einige Einträge mit dem Schlüsselword restrict. Mit diesen wird festgelegt wer wie auf den ntpd zugreifen darf.
Auf das Schlüsselwort folgt der zu berechtigende Client. Das kann entweder eine IP-Adresse, ein ganzes Netzwerk (mit Netzwerkmaske) oder ein DNS-Host-Name. Wer die Standardeinstellungen ändern will kann hier statt der genanten Dinge auch Default angeben.
Als nächstes folgt eine Liste von Berechtigungen oder Verweigerungen:
Diese Möglichkeiten sind nur eine Auswahl. Weitere Schlüsselwörter sind in der Dokumentation aufgeführt.
Für den Betrieb im lokalen Netzwerk sind die hier vorgestellten Möglichkeiten mehr als ausreichend. Mein Server geht jetzt jedenfalls auf die Sekunde genau.
]]>Wie mein Server seine Uhr mit NTP selber stellt.
]]>Dirvish kopiert angegebene Ordner auf ein anderes Laufwerk. Der Clou daran ist, dass es nur die Dateien kopiert seit dem vorangegangen Backup geändert oder neu hinzugekommen sind. Für alle anderen Dateien wird ein Verweis, ein sogenannter Hardlink, gesetzt. Dadurch wird nur einmal Speicherplatz benötigt egal wie oft ein Backup von einer Datei gemacht wird. Aus diesem Vorgehen ergeben sich in meinen Augen zwei Vorteile: Das Backup kann man wiederherstellen indem man die Dateien zurückkopiert – spezielle Software ist nicht nötig und alle Dateien sind immer vorhanden – kein hantieren mit differentiellen oder inkrementellen Updates.
Für das Backup sollte ein externer Speicher, eine USB-Festplatte zum Beispiel, verfügbar sein. Diesen sollte man zwischen den Backups auch vom Computer entfernen. Das ist zwar etwas umständlich schützt aber davor das Backup zu beschädigen oder gar zu löschen.
Von Dirvish gibt es ein fertiges Installationspaket in den Repositories von Debian
aptitude install dervish
Als Vorbereitung wird für die externe Festplatte ein Mountpoint angelegt:
mkdir /mnt/backup
In diesen wird die Festplatte eingehängt und dann kann man eine Ordnerstruktur für seine Backups anlegen. Ich legen immer einen Ordner für das Backupsystem, hier also dirish, und darin jeweils einen Ordner für jedes System das auf der Festplatte gesichert werden soll:
cd /mnt/backup
mkdir /mnt/backup/dirvish
mkdir /mnt/backup/dirvish/homeserver
Diese Ordner verwendet man dann in der Grundkonfiguration von Dirvish um das Ziel aller Backups anzugeben. Diese Konfiguration befindet sich in der Datei /etc/dirvish/master.conf:
bank:
/media/backup/dirvish/homeserver
exclude:
lost+found/
Runall:
Streaming
PublicDocuments
expire-default: +360 days
In der Zeile unterhalb von bank wird festgelegt, wo alle Backups abgelegt werden sollen. Mittels exclude lassen sich einzelne Ordner ausschließen und unter Runall legt man die Namen der Backupjobs fest, die ausgeführt werden sollen. expire-default legt fest wie lange ein Backup aufgehoben werden soll.
Die Jobs, die unter Runall aufgeführt sind, werden jeweils in einer eigenen Datei definiert. Diese Dateien liegen auf dem Backupspeicher. Dort in einem Unterordner dirvish innerhalb eines Ordners, der gemäß dem Namen des Jobs benannt sein muss.
cd /media/backup/dirvish/homeserver/
mkdir Streaming
mkdir dirvish
Innerhalb einer Datei namens default.conf in diesem Ordner wird angegeben wie der Rechner heißt von dem ein Backup gemacht werden soll (client) und welcher Ordner gespeichert werden soll (tree). xdev schließt Mountpoint innerhalb des zu sichernden Ordners ein oder aus. Ein wert von 1 schließt alle Mountpoints vom Backup aus. Mittels image-default wird angegeben wie der Name des Unterordners für jedes einzelne Backup aufgebaut sein soll. Dabei können Variablen verwendet werden die zum Beispiel das Jahr oder die Stunde in den Namen einfließen lassen.
client: homeserver
tree: /var/streaming
xdev: 1
image-default: %Y-%m-%d_%H-%M
Bevor ein reguläres Backup ausgeführt werden kann muss jeder einzelne Job einmalig initialisiert werden:
dirvish --vault Streaming --init
Wenn alle Jobs initialisiert sind kann man nun mittels eines einzigen Befehls alle Backups auf den aktuellen Stand bringen:
dirvish-runall
Um nicht wirklich jeden Stand aus den letzten 10 Jahren aufzuheben kann man auch aufräumen:
dirvish-expire
Dieser Befehl löscht gemäß der Aufbewahrungsregel expire-default in der /etc/dirvish/master.conf alle Backups die älter sind als die angegebene Anzahl von Tagen.
Die hier vorgestellten Möglichkeiten sind für den Normalfall schon ausreichend, wer aber besondere Bedürfnisse hat sollte sich die Dokumentation noch einmal ansehen. Zum Beispiel kann man einen Index über den Inhalt der Backups anlegen um diese schnell durchsuchen zu können.
]]>Die Verschlüsselung kann man recht unproblematisch auf der Komandozeile durchführen. Dazu muss man zu erst herausfinden welche Gerätedatei für den USB-Stick zuständig ist. Normalerweise wird ein externes Gerät unter Ubuntu automatisch gemountet. Daher findet man in der Ausgabe des Befehls mount
eine Zeile mit den Label des Sticks und der Gerätedatei. Im folgenden nehme ich an das es /dev/sdb ist.
Vor der eigentlichen Arbeit sollte man den Stick gleich wieder aushängen und wenn man das für nötig erachtet auch noch komplett überschreiben:
sudo umount /dev/sdb
sudo dd bs=2M if=/dev/urandom of=/dev/sdb
Danach kann man mittels cryptsetup die Verschlüsselung einrichten. Bei mir war Cryptsetup unter Ubuntu 11.10 bereits installiert so das ich hier nicht nachhelfen musste. Wenn es aber nicht vorhanden ist kann man es mittels sudo apt-get install cryptsetup
nachinstallieren.
Mit dem folgenden Befehl wird auf dem Gerät ein Verschlüsselter Container angelegt und dazu einige Metainformationen in einem LUKS-Header abgelegt. Diese Metainformationen ermöglichen es später komfortabel mit der Stick zu arbeiten da er es Linux ermöglicht den Container als solchen zu identifizieren und das nötige Passwort abzufragen:
sudo cryptsetup luksFormat /dev/sdb
sudo cryptsetup luksOpen /dev/sdb crypt_device
sudo mkfs.ext4 /dev/mapper/crypt_device
Der zweite Befehl öffnet den Container und legt eine Gerätedatei /dev/mapper/crypt_device an. Mit dieser kann man dann ganz normal arbeiten und zum Beispiel ein Dateisystem anlegen. Der dritte Befehl tut genau das und legt eine ext4-Partition an.
Jetzt ist man bereits in der Lage seine vertraulichen Dateien zu verschlüsseln. Einfach den verschlüsselten Container mounten:
mount /dev/mapper/crypt_device /mnt
Dateien kopieren und hinterher wieder aufräumen:
umount /dev/mapper/crypt_device
sudo cryptsetup luksClose crypt_device
Beim täglichen Arbeiten würde das manuelle Mappen und Mounten des Containers natürlich stören. Aber das ist auch gar nicht nötig. Ubuntu 11.10 erkennt bei anschließen des Sticks anhand des LUKS-Headers die Verschlüsselung und fragt automatisch das Passwort ab. Fertig!
]]>