Private Cloud mit Seafile und Radicale auf einem Raspberry Pi (Teil 2)

Im ersten Teil der Artikelserie „Private Cloud mit Seafile und Baïkal Radicale auf einem Raspberry Pi“ ging es darum, den Raspberry Pi zum Laufen zu bekommen und vorzubereiten. In diesem 2. Teil soll es nun um die Inbetriebnahme des Kalender- und Kontakte-Servers gehen. Bei diesem setzte ich seit Jahren auf den Baïkal-Server, welcher wenig Ressourcen beansprucht und stabil läuft. Eigentlich sollte diese Anleitung auch für diesen geschrieben werden. Während der Recherche stellte sich aber heraus, dass Baïkal nicht mehr weiterentwickelt wird. Anleitungen für Software, welche nicht mehr weiterentwickelt werden und damit schnell veraltet sind, machen keinen Sinn und so werde ich die Anleitung für eine ebenso schlanke Open-Source-Alternative schreiben: Radicale. Bis man den Server installieren kann, sind aber noch ein paar Vorarbeiten zu leisten. Es werden folgende Schritte notwendig sein:

  1. Den Raspberry Pi vom Internet erreichbar machen
  2. Erstellen eines SSL-Zertifikats
  3. Aufsetzen eines Nginx-Webservers
  4. Das PiDrive mounten
  5. Radicale installieren und einrichten

 

Schritt 1: Den Raspberry Pi vom Internet erreichbar machen

Bisher war der RasPi gut versteckt im eigenen Heimnetzwerk und man konnte nur über die interne IP-Adresse auf ihn zugreifen. Für die Nutzung als Wolke ist natürlich eine Zugriff aus dem Internet unerlässlich.

Schritt 1a: DynDNS-Adresse erzeugen
Da die Meisten einen Internetanschluss mit dynamischer IP-Adresse haben, wird sich die IP-Adresse spätestens alle 24 h ändern. Um nicht permanent die Internetadresse anpassen zu müssen, bedient man sich eines DynDNS-Dienstes. Mit Hilfe eines solchen Dienstes, kann man einem Internetanschluss eine feste Internetadresse zuweisen, ohne jeden Tag die IP-Adresse ändern zu müssen. Ich persönlich nutze dafür den Dynamic-DNS-Service spDYN von Securepoint, einem kostenlosen Angebot, mit dem ich bis jetzt durchweg gute Erfahrungen gemacht habe.

Meldet man sich bei diesem Dienst an, kann man eine Adresse in der Form meineAdresse.spdns.de erhalten (oder eine der anderen Domains, die angeboten werden). Am Beispiel für den o.g. Dienst gibt man einfach einen Host-Namen an, welcher dann die Subdomain zu der Hauptdomain bildet, welche man ebenfalls in dem Dialog auswählen kann (s. Abbildung). In der Bedienoberfläche des Routers kann man die aktuelle IP-Adresse ablesen und gibt diese im Feld IP an. Damit wäre der Dienst (zumindest) bei spDYN bereits eingerichtet.

Einen neuen Host hinzufügen

Schritt 1b: DynDNS-Dienst im Router aktivieren
Damit der DynDNS-Dienst aber auch weiß, wie bei einer IP-Adressenänderung die neue IP-Adresse lautet, muss man im Router dies auch einrichten, damit dieser die neue IP-Adresse weitergibt. Am Beispiel der Fritz!Box sieht das folgendermaßen aus (s. Abbildung):

Einstellungen für einen DynDNS-Dienst in der Fritz!Box

In der Regel stellt der DynDNS-Anbieter eine Update-URL bereit (bei spDYN: https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ipaddr>), die man der Fritz!Box mitteilen muss. Weiterhin müssen DynDNS-Domainname und Benutzername des Dienstes angegeben werden. Als Kennwort gibt man hier nicht das Kennwort für die Administrationsoberfläche des DynDNS-Dienst-Nutzerkontos an. Für den Domainnamen stellt der DynDNS-Anbieter einen Update-Token bereit, welchen man in der Fritz!Box als Kennwort eingibt. Nach dem Speichern in der Fritz!Box sollte auf diese nun über die Dyn-DNS-Adresse aus dem Internet zugegriffen werden können.

Schritt 1c (optional): Eigene Domain auf die DynDNS-Adresse aufschalten
Will man seine eigene Domain für die zukünftige Wolke verwenden, muss man ein wenig in den DNS-Einstellungen der Domain tätig werden (Dieser Schritt ist nicht zwingend notwendig, wenn man mit der DynDNS-Adresse zufrieden ist). Ich persönlich nutze für meine Domainverwaltung den Dienst INWX, der bisher tadellos funktioniert hat.

In der Domainverwaltung gibt man im Bereich DNS-Einträge (u.U. heißt der Punkt auch anders wie Nameserver etc., das ist von Anbieter zu Anbieter unterschiedlich) als Name die Subdomain an, unter der die Wolke aufgerufen werden soll (in diesem Beispiel cloud). Als Typ wählt man CNAME und als Wert die DynDNS-Adresse (s. Abbildung). Nach dem Abspeichern wird es einige Zeit dauern, bis die neue Domain aufrufbar ist, aber der Router sollte nun auch unter der eigenen Domain erreichbar sein (in diesem Beispiel http://cloud.hotzpotz.de)

DNS-Eintrag für Dyn-DNS-Adresse bei INWX

Um zu prüfen, ob die unternommenen Schritte von Erfolg gekrönt waren, kann man die beiden Adressen mal anpingen. Es sollte bei beiden das gleiche Ergebnis herauskommen und die eigene IP-Adresse auftauchen.

 

Schritt 1d: Port 443 im Router freigeben
In der Fritz!Box-eigenen Firewall muss für den RasPi zunächst der Port 443 für die SSL-Übertragung freigegeben werden. Dafür geht man in der Admin-Oberfläche auf Internet >> Freigaben. Im Reiter Port-Freigaben muss man zunächst seinen RasPi hinzufügen.

In dem Fenster, in dem man das Gerät hinzufügt, kann man auch gleich Ports freigeben. Dort wählt man die Option Portfreigabe, als Anwendung HTTPS-Server und als Port 443 (s. Abbildung). Bestätigt man dies mit OK und fügt danach das Gerät hinzu, ist der Port gleich freigegeben.

SSL-Port-Freigabe in der Fritz!Box

Schritt 2: Erstellen eines SSL-Zertifikats

Schritt 2a: Erstellen des Zertifikats
Zum Erstellen eines SSL-Zertifikats bedient man sich am besten der kostenlosen Zertifizierungsstelle Let’s Encrypt. Zunächst installiert man certbot:

Im Anschluss kann man sofort mit der Zertifikaterstellung beginnen:

Hinter der Option -d muss die Domain folgen, für die das Zertifikat ausgestellt werden soll (in diesem Beispiel cloud.hotzpotz.de). Das Zertifikat wird dann im Verzeichnis /etc/letsencrypt/live/cloud.hotzpotz.de/ abgelegt als fullchain.pem.

Schritt 2b: Erstellen eines Cronjobs zur regelmäßigen Erneuerung des Zertifikats
Da ein Zertifikat von Let’s Encrypt nur 90 Tage gültig ist, muss es regelmäßig erneuert werden. Das lässt sich am besten durch einen Cronjob automatisieren:

Mit obigem Befehl kann man die crontab editieren. Dabei wird man, falls man es das erste mal macht, nach dem zu nutzenden Editor gefragt. Wer keine besondere Vorlieben hat, macht mit nano nicht viel falsch. In der crontab setzt man am Ende folgende Zeile:

Zur Erklärung:

  • 0 3 * * *: der Cronjob wird jeden Tag um 3 Uhr früh ausgeführt
  • certbot renew: der Befehl zum aktualisieren des Zertifikats
  • –standalone: Authentifizierungs-Plugin; nur mit dem standalone-Plugin ist eine Authentifizierung über den Port 443 mit (dem noch zu installierenden) Nginx möglich
  • –pre-hook: vor dem Aktualisieren soll der Nginx-Server gestoppt werden
  • –post-hook: nach dem Aktualisieren soll der Nginx-Server wieder gestartet werden
  • -q: da das Zertifikat nur innerhalb etwa eines Monats vor Ablauf aktualisiert werden kann, würden Versuche vorher zu Fehlermeldungen führen, welche mit der Option -q (für quiet) unterdrückt werden

 

Schritt 3: Aufsetzen eines Nginx-Webservers

Schritt 3a: Installation von Nginx
Zunächst installiert man das Paket nginx:

Um den RasPi nicht zu überlasten, müssen die maximalen Prozesse angepasst werden:

Nun muss der Webserver nur noch gestartet werden und dann war es das auch schon:

Zum Testen kann man mal schnell die lokale IP-Adresse des RasPi in den Browser eingeben. Dann sollte eine Willkommens-Seite des Nginx-Servers zu sehen sein.

Schritt 3b: SSL-Zertifikat in Nginx einbinden
Zum Einbinden des in Schritt 2 erstellten SSL-Zertifikats ruft man mit nano die Webserver-Konfiguration auf:

Dort sucht man folgenden Abschnitt:

und fügt danach folgenden Abschnitt ein (statt cloud.hotzplotz.de sollte man seine eigene Domain einsetzen):

Danach kann man die Konfiguration mit Strg+X, Y und Enter speichern. Mit einem Restart von Nginx lädt man die neue Konfiguration:

Zum Test kann man die eigene Domain (also im Beispiel wäre dies dann https://cloud.hotzpotz.de) im Browser eingeben und sollte die gleiche Nginx-Willkommensseite angezeigt bekommen wie schon in Schritt 3a.

 

Schritt 4: Das PiDrive mounten

Als Datenträger für die Wolke habe ich mich für ein PiDrive von Western Digital entschieden, welches extra für den Betrieb mit einem Raspberry Pi konzipiert ist (Update 30.7.2018: Mit der Schließung der WDLabs wurde auch der Vertrieb der PiDrives eingestellt). Zur Einführung des PiDrive hat WD u.a. eine Größe von 314 GB angeboten (in Anlehnung an die Zahl Pi), welche ich auch verwende. Mittlerweile gibt es diese Größe nicht mehr, dafür andere. Um das PiDrive als Datenlaufwerk zu nutzen, sind folgende vorbereitende Schritte notwendig:

Schritt 4a: PiDrive finden, formatieren und mounten
Mit folgendem Befehl kann man erstmal schauen, wo das PiDrive liegt:

Es folgt die Ausgabe von einigen Partitionen. U.a. sollte dann auch ein Eintrag in folgender Form zu finden sein:

Die Größe deutet schon an, dass es sich hier um das PiDrive handeln muss. Es liegt also auf /dev/sda. Zunächst formatiert man das Laufwerk im Ext4-Format. In diesem Beispiel wird die Festplatte als eine 314-GB-große Partition formatiert:

Um das Laufwerk zu mounten, erstellt man zunächst einen Mountpunkt (im Beispiel /mnt/data) und mountet dann das PiDrive auf dieses Verzeichnis:

Im Teil 1 beim Einrichten des RasPi wurde ja der Benutzername geändert. Mit dem Befehl id prüft man, welche UID und GID dieser Nutzer hat. Dabei kommt in etwa folgendes Ergebnis raus:

Wahrscheinlich wird die UID und GID wie bei den meisten und im obigen Beispiel auch 1000 sein. Diese Angaben braucht man, um die Zugriffsrechte für das PiDrive zu setzen:

Damit ist das PiDrive fertig eingerichtet!

Schritt 4b: Das PiDrive dauerhaft mounten
Mit jedem Neustart des RasPi müsste man allerdings jedesmal das PiDrive manuell neu mounten. Um dies zu umgehen, muss man den Mountpunkt in die fstab eintragen, aus welcher beim Start des RasPi jedesmal die einzuhängenden Partitionen gelesen werden. Dazu muss man erst einmal die UUID der Partition wissen:

In der erscheinenden Ausgabe sollte dann u.a. ein Abschnitt in folgender Form auftauchen:

Die hier angezeigte UUID des PiDrive schreibt man dann in die fstab.

Die fstab sollte dann in etwa folgendermaßen aussehen:

Damit wäre auch das PiDrive dauerhaft eingehängt und man kann (endlich) zum eigentlichen Teil übergehen: der Installation von Radicale.

 

Schritt 5: Radicale installieren und einrichten

Schritt 5a: Python und Radicale installieren
Radicale ist in Python geschrieben, sodass zunächst Python installiert werden muss. Anschließend kann dann Radicale mittels pip installiert werden.

Vom Prinzip her wäre Radicale jetzt bereits lauffähig, aber man muss noch ein wenig Arbeit in die Konfiguration und die Absicherung stecken, damit es auch von außen nutzbar wird.

Schritt 5b: Radicale konfigurieren
Radicale ist standardmäßig so konfiguriert, dass es nur über localhost aufrufbar ist. Zum Konfigurieren legt man zunächst ein Radicale-Verzeichnis unter etc an (Zeile 1). Die Kalender- und Kontaktedaten sollen auf dem PiDrive gespeichert werden, wofür man dort vorbereitend ein Verzeichnis erstellt (Zeile 2). Im Anschluss kann die Konfigurationsdatei erstellt werden (Zeile 3):

In die config-Datei schreibt man folgende Zeilen:

Mit der [server]-Zeile kann der Radicale-Server auch im lokalen Netzwerk über die IP-Adresse des RasPis und den Port 5232 aufgerufen werden (je nach im Router vergebener IP-Adresse z.B. http://192.168.2.86:5232). Mit der [storage]-Zeile legt man den Speicherort der Daten fest.

Mit folgender Zeile kann man den Radicale-Server zum ersten Mal testweise starten:

Gibt man zur Kontrolle die IP-Adresse des RasPi mit dem Port in den Webbrowser ein (s.o.), sollte ein Anmeldefenster erscheinen. Damit Radicale auch mit jedem Neustart des RasPi mitgestartet wird, richtet man Radicale als Dienst ein.

Schritt 5c: Radicale als Dienst einrichten
Um den Radicale-Dienst einzurichten, erzeugt man mit nano die Datei radicale.service:

und fügt die folgenden Abschnitte ein:

Mit Strg+X, Y und Enter speichert man die Datei. Mit folgenden Befehlen aktiviert und startet man den Dienst und kontrolliert, ob er ohne Fehler läuft:

 

Schritt 5d: Radicale absichern
Zur Absicherung der Authentifizierung nutzt man bcrypt, wofür einige Abhängigkeiten nachinstalliert werden müssen:

Diese Methode muss auch in der Konfiguration hinterlegt werden. Dazu öffnet man die Config-Datei mit einem Editor und fügt den Abschnit [auth] ein:

Da nur nginx installiert ist, wird das System den Befehl htpasswd nicht kennen, sodass man ihm diesen erst beibringen muss. Dafür wird ein Paket nachinstalliert:

Nun kann man mit htpasswd eine Benutzerdatei erzeugen, wobei der zweite Befehl optional genutzt werden kann, falls man mehr als einen Benutzer anlegen möchte. Dabei werden auch gleich die Passwörter mit erzeugt:

Da die gesamte Kommunikation mit Radicale per SSL abgesichert werden soll, muss man dies in der Config-Datei noch hinterlegen. Man öffnet also mit nano wieder diese Datei und fügt die unterhalb von [server] stehenden Zeilen dem bereits bestehenden Abschnitt [server] hinzu (als Pfad für die Zertifikate/Schlüssel nutzt man jene aus Schritt 3b):

 

Schritt 5e: Radicale für den Zugriff aus dem Internet einrichten
Bisher kann auf den Radicale-Server nur aus dem lokalem Netzwerk zugegriffen werden. Als letzten Schritt richtet man das Ganze so ein, dass man auch von außerhalb des Netzwerkes (also dem Internet) darauf zugreifen kann.

Dazu ruft man die Standard-Webserver-Konfiguration mit nano auf:

sucht folgenden Abschnitt heraus:

und fügt dahinter folgenden Inhalt ein (statt cloud.hotzpotz.de wie immer die eigene Domain einfügen):

Die Datei speichert man mit Strg+X, Y und Enter. Um die neue Konfiguration zu aktivieren, muss der nginx-Webserver neu gestartet werden (1. Zeile). Zusätzlich muss auch der Radicale-Server neu gestartet werden, da man ja im Schritt 5d die Konfiguration geändert hat (2. Zeile):

Nun ist der Radicale-Server theoretisch über das Internet erreichbar. Theoretisch deshalb, weil man im Router noch den Port für Radicale freigeben muss, damit die Anfragen vom Router auch an Radicale weitergeleitet werden. Wie man das macht, ist von Router zu Router unterschiedlich. Am Beispiel der Fritz!Box wurde das bereits in Schritt 1d erklärt, nur dass man statt des Ports 443 den Port 5232 freigibt.

Ist der Port freigegeben, kann man in einem Webbrowser die Adresse seiner Domain mit dem freigegebenen Port eingeben (in meinem Beispiel wäre es https://cloud.hotzpotz.de:5232). Es erscheint dann die Anmeldemaske des Radicale-Servers. Dort kann man sich mit einem der unter Schritt 5d angelegten Benutzer anmelden und Kalender oder Adressbücher erstellen. Ist ein Kalender oder Adressbuch angelegt worden, wird eine (kryptische) URL angezeigt, welche z.B. in Thunderbird zur Verwendung im Kalender genutzt werden kann.

Damit wäre der Radicale-Server vollständig und funktionstüchtig eingerichtet. Viel Spaß damit.

Private Cloud mit Seafile und Radicale auf einem Raspberry Pi (Teil 2)

27 Gedanken zu „Private Cloud mit Seafile und Radicale auf einem Raspberry Pi (Teil 2)

  1. Christoph schreibt:

    Hallo!

    Erstmal danke für den guide, sehr übersichtlich und gut aufgebaut! Ich habe gerade exakt laut deiner Beschreibung nachgebaut, komme aber leider nicht über einen 403 Forbidden mit nginx heraus… ich komme leider nicht mal bis zum auth-Teil und ich finde den Fehler leider nicht… :-/ Muss ich noch was Besonderes beachten?

    1. Ein 403-Fehler deutet auf ein Problem mit den Zugriffsrechten hin. Wann kommt denn der Fehler: schon beim Aufsetzen des Nginx-Servers (Schritt 3a) oder erst beim Testen von Radicale (Schritt 5b)?

      1. Christoph schreibt:

        Der 403 ist weg (hatte keine Benachrichtigung über deine Antwort bekommen, sorry :-/ ), aber der Teil mit dem reverse proxy funktioniert leider nicht.

        Ich komme über Port 5232 direkt auf radicale, aber der Sinn des Ganzen wäre es ja, https über nginx terminieren zu lassen, aber deine proxy config zeigt bei mir leider nur einen 500er error an und ich komm nicht drauf, was das Problem ist…

        1. Ist jetzt schwer, aus der Ferne die Ursache zu finden. Mir fallen da spontan 2 Möglichkeiten ein:
          1. Du hast die beiden abschließenden Schrägstriche in der Nginx-Konfig vergessen: es muss zwingend „location /radicale/“ sowie „http://localhost:5232/“ heißen
          2. Deine SSL-Konfiguration ist fehlerhaft: Funktioniert der Zugriff auf deine Domain ohne die Portangabe über https? Es müsste dann die Nginx-Standardseite kommen, falls du neben Radicale nichts anderes installiert hast.

          1. Christoph schreibt:

            Ich weiß, Ferndiagnose ist nicht leicht… :-/

            ad 1) habe das von dir übernommen, genauso hab ich es in der config stehen.

            ad 2) habe mehrere vhosts parallel, alle anderern funktionieren perfekt, haben aber auch keinen reverse proxy drin.

            Könntest du vielleicht deine komplette nginx conf posten oder ist das eh nicht mehr drin als der Teil da oben?

          2. Mmm … hab jetzt mal bei mir nachgeschaut. Ich habe zwar hier in der Anleitung im Schritt 3b stehen, dass man den Block mit der SSL-Konfiguration einfügen soll (also die 4 Zeilen mit „listen 443“ …), finde diese Zeilen aber nicht in meiner nginx-default-Konfiguration. Da ich bei mir Radicale zusammen mit Seafile nutze und für Seafile einen eigenen vhost angelegt habe (siehe Teil 3 der Artikelreihe), wird dort die SSL-Konfiguration hinterlegt. Ich vermute mal, dass ich es deshalb hier wieder entfernt habe. Versuche mal, ob es was bringt, die 4 Zeilen wieder zu entfernen, sodass nur noch

            listen 80 default_server;
            listen [::]:80 default_server;

            listen 443 ssl default_server;
            server_name cloud.hotzpotz.de;
            ssl_certificate /etc/letsencrypt/live/cloud.hotzpotz.de/fullchain.pem;
            ssl_certificate_key /etc/letsencrypt/live/cloud.hotzpotz.de/privkey.pem;

            steht.

  2. Christoph schreibt:

    Aber das ist es ja gerade: den SSL-Teil will ich ja über nginx abwickeln, weil ich da mehr Einstellungsmöglichkeiten in der config habe. Wie greifst du denn auf deine radicale Instanz zu? Nur per cloud.hotzpotz.de oder mit gesamter URL inklusive Port 5232?

      1. Christoph schreibt:

        Alles klar, so funktioniert es bei mir auch, aber das bedeutet, dass dein nginx proxy nicht greift und du sowieso nur auf deine radicale Instanz direkt zugreifst, genau das wollte ich ja verhindern. 🙂

        1. Christoph schreibt:

          Okay, ich habe es jetzt hinbekommen mit folgendem Proxy-Teil:

          location / {
          proxy_pass http://127.0.0.1:5232/;
          include proxy_params;
          #proxy_set_header X-Script-Name /;
          #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          #proxy_pass_header Authorization;
          proxy_ssl_certificate /etc/letsencrypt/live/DOMAIN/fullchain.pem;
          proxy_ssl_certificate_key /etc/letsencrypt/live/DOMAIN/privkey.pem;
          }

          Danke nochmal für deine Unterstützung!

          1. Ich habe jetzt (ich weiß, es ist lang her, Asche auf mein Haupt) nachvollziehen können, was du meintest. Musste es erst selbst zu spüren bekommen 😉
            Mit einem iPhone hatte die Synchronisierung nicht mehr funktioniert. Auf der Spurensuche stellte ich fest, dass beim Aufruf der Radicale-Seite ein Fehler kam, weil das SSL-Zertifikat angeblich abgelaufen war. Beim Aufruf der normalen Domain ohne Portangabe war das Zertifikat aber gültig. Ich habe nun in der nginx-Konfiguration die eine Zeile von dir include proxy_params; eingefügt und siehe da es ging.

            Vielen Dank für den Hinweis! Ich habe den Artikel entsprechend angepasst.

  3. Frederic schreibt:

    Danke für die gute Anleitung. Hat super funktioniert und ich habe viel bei der Einrichtung gelernt.
    Hast du auch noch eine Möglichkeit parat, die CardDAV- und CalDAV-Daten (automatisch) zu sichern?

    1. Christoph schreibt:

      Hallo!

      Nachdem das nur Files in einem Verzeichnis sind, kannst du es leicht mit einem script sichern, hier ist meines:

      ===Skript Beginn===

      #!/bin/bash
      set -x

      mkcdir ()
      {
      mkdir -p — „$1“ &&
      cd -P — „$1“
      }

      cd /data/backups/radicale
      mkcdir „radicale_backup_$(date ‚+%F‘)“

      cp -a /opt/radicale/collection-root .

      exit 0

      ===Skript Ende===

      Das Ganze per cronjob einrichten und das Backup läuft. 🙂

      1. Frederic schreibt:

        Danke für die schnelle Antwort!
        Kannst du die Einrichtung des Backups in den Blog als „Schritt 6“ hinzufügen?
        Das würde das Tutorial komplettieren und User wie ich (Raspbian- bzw. Raspberry-Neulinge) machen bei dem sehr wichtigen Thema Backup & Restore keinen bösen Fehler 🙂

        Vielen Dank!

  4. Christoph schreibt:

    Mir ist noch was eingefallen, was ich bei meiner radicale Installation konfiguriert habe, das sehr wichtig ist: ein rights file, das den Zugriff auf die files regelt.

    Meine /etc/radicale/rights:

    # Authenticated users can read and write their own collections.
    [owner-write]
    user = .+
    collection = %(login)s(/.*)?
    permission = rw

    [admin]
    user = admin
    collection = .*
    permission = rw

    Wenn das nicht eingestellt ist, kannst du jederzeit ohne Authentifizierung mittels URL auf deine Kalender/Adressbücher zugreifen, was security-technisch eine Katastrophe ist natürlich. 🙂

    1. Mmm, das musst du mir jetzt erklären. Die Absicherung erfolgt eigentlich unter Schritt 5d. In der config-Datei gibst du als auth-type htpasswd an. Wenn du die Benutzer mit htpasswd anlegst, kann man auch nur mit Benutzername und Passwort auf den jeweiligen Kalender oder Adressbuch zugreifen.

      Zumindest kommt bei mir eine Benutzername- und Passwortabfrage, wenn ich direkt auf den Kalender im Webbrowser zugreifen möchte. Von daher sehe ich gerade nicht den Sinn deiner Konfiguration mit einer rights-Datei. Zumal diese offensichtlich für die Radicale-Version 1.1 ist. In der Doku von Radicale 2.0 finde ich keinen Hinweis auf die Notwendigkeit einer rights-Datei. Die Option einer rights-Datei ist in der aktuellen Dokumentation gar nicht vorgesehen: http://radicale.org/configuration/ … zumindest nicht für die Authentifizierung. Für das Rechte-Management schon, aber da als default-Wert in Radicale owner_only vorgesehen ist, muss man dies nicht extra in der config angeben.

      1. Christoph schreibt:

        Interessant… bei mir konnte man direkt mit der URL ohne Passwort-Abfrage zugreifen. 🙂

        Wenn das bei dir eh funktioniert, dann passt das, ich werde am Abend mal checken, welche radicale-Version ich da installiert habe bei mir.

        1. Da musst du mal darauf achten, ob du im Browser in Radicale angemeldet bist. Dann hat der Browser natürlich deine Logindaten im Cache und der Abruf funktioniert ohne Abfrage der Logindaten. Um sicher zu gehen, kannst du die URL mal in einem Browserfenster mit Privat- bzw. Inkognito-Modus ausprobieren. Da sollten deine Logindaten nicht gespeichert sein 😉

          1. Christoph schreibt:

            Keine Sorge, ich habe das Ganze mit anderen Browsern (in denen ich noch nie angemeldet war), anderen Computern (auch VMs) getestet, ich habe alles probiert, was mir eingefallen ist dazu. 😉

  5. Doni schreibt:

    Hallo und danke für die Anleitung erstmal.
    Ich habe Probleme mit Schritt 2a
    er findet die Domain nicht
    obwohl sie anpingbar ist.
    Kannst du mir weiterhelfen?

  6. piRAT schreibt:

    Gut gemacht! Der Ariadne-Faden durch das Labyrinth.
    Nur leider komme ich am Minothaurus nicht vorbei:
    Unter „Schritt 5d: Radicale absichern“ führt das Kommando „sudo python3 -m pip install –upgrade passlib bcrypt“ zu massiven Fehlermeldungen wie:
    1 c/_cffi_backend.c:2:20: fatal error: Python.h: Datei oder Verzeichnis nicht gefunden
    #include
    2 compilation terminated
    3 Failed building wheel for bcrypt
    4 Failed cleaning build dir for bcrypt
    5 Failed building wheel for cffi
    6 Failed building wheel for pycparser
    Das Ganze mit einem Haufen kryptischer Strings mittenmang.

    Zur Ergänzung:
    Die Fehlermeldung: „Command python setup.py egg_info“ failed with error code 1 in /tmp/pip-build-s3 h5uzgc/radicale/, welche aus Schritt 5a und dem Kommando „sudo python3 -m pip install –upgrade radicale“ resultierte, ließ sich für mich als rookie noch mit einer vergleichsweise einfach zu ergooglenden erhofften Kommandozeilenlösung beheben („sudo python3 -m pip install –upgrade setuptools“).
    Leider kamen dann auch hier wieder viele rote Textbausteien, wie „Failed building wheel for radicale/vobject“.
    Nach einem sudo apt-get udate/upgrade lief dann der Befehl „sudo python3 -m pip install –upgrade radicale“ flüssig durch und der radicale-Dienst zeigte sich als aktiv.

    Nur die oben beschriebenen Fehlermeldungen, welche aus Schritt 5d resultieren, treffen bei mir auf absolute Ahnungslosigkeit.
    Wenn hier irgendwas nicht kompiliert/gewheelt wird, ist es doch auch nicht für den Rechner ausführbar, oder?
    Hab auch schon einfach mal „sudo python3 -m pip install cffi“ ausprobiert, weil „cffi“ häufig in den Fehlermeldungen aufgetaucht ist, was leider zu zusätzlichen Fehlermeldungen führt.

    Jetzt die Frage:
    Warum ich?
    Nee, Spaß.
    Was ist das Problem? Und wie behebe ich es?

    Danke an den Spender.

    [PS: Ich nutze einen Banana Pi Pro und armbian als OS auf microSD.]
    [PPS: Wenn jetzt noch OpenVPN und PiHole in der Anleitung Platz fänden, eventuell noch TVHeadend…;)))]

  7. Pi.RAT schreibt:

    Braucht es weitere Abhängigkeiten, um bcrypt zu kompilieren?
    Auf der bcrypt-Seite ist das angeblich mit: „sudo apt-get install build-essential libffi-dev python-dev“ erledigt. Bei mir jedoch nicht.
    Auch dieser Befehl „python3 -m pip install –upgrade radicale[bcrypt]“ brachte nicht den gewünschten Erfolg.
    Kann es sein, dass bcrypt nicht mit Python 3.5 kompatibel ist?
    Kann man das Python z.B. auf 3.4 downgraden ohne das es beim Rest der Anleitung zu weiteren Problemen führt?
    Ist hier überhaupt noch jemand, der das liest?

    Gruß Pi.RAT

    1. Hallo Pi.RAT,
      ja, hier liest noch jemand mit. Aber auch ich brauche manchmal Urlaub 😉 … zu deinem Python-Problem kann ich dir leider wenig helfen. Ich kann dir leider nur soviel sagen, dass die ganze Anleitung mit Raspbian 9 getestet wurde. Ich habe gerade nachgeschaut: bei mir ist Python 3.5.3 installiert. Von daher sollte es kein Kompatibilitäts-Problem von bcrypt sein. Allerdings weiß ich nicht, ob die installierten Pakete von armbian mit denen von Raspbian identisch sind.

  8. Pi.RAT schreibt:

    Vielen Dank. Sören.
    Ich weiß Deine Hilfe über die tolle Anleitung hinaus wirklich zu schätzen.
    Jedenfalls kann ich durch das Rumprobieren Deine sehr nützliche Anleitung noch um ein paar Eigenwünsche erweitern (Public-Key Login, eigene CA statt certbot, TVHeadend, PiHole, OpenVPN, Telemetrie etc.).

    Um das bcrypt-Problem anzugehen, habe ich mit:
    „sudo apt-get install build-essential libffi-dev python-dev “
    „sudo apt-get install python3-dev “
    das Maschinchen soweit bekommen, dass nach:
    „sudo apt-get upgrade passlib bcryp“
    die Meldung: „passlib und bcrypt installiert“ erschien.
    Die wheels konnten aber immer noch gebuildet werden.
    Schade, da ich gerne den binärcode implementiert hätte, da dies wesentlich schneller läuft als das bcrypt Python-Skript.
    Egal, solange bcrypt wenigstens zuverlässig seinen Dienst tut.
    Da rasbpian, wie armbian, debian Derivate sind, sollte es eigentlich keinen Unterschied geben. Bis auf das kompilieren wahrscheinlich, da die Hardware unterschiedlich ist.
    Z.Zt. hänge ich noch in der Seafileinstallation fest, weil ich als user seafile keine Berechtigungen habe die Config-Datei am Ende des Installtionsvorgangs zu schreiben. Das Setup bricht dann ab.
    Werde seafile mal in die sudoers Liste eintragen und es dann versuchen.
    Hast du irgendeine Idee, wie mann fail2ban dazu bringt auch für einen Login per Public-Key Verfahren zu funktionieren?
    In der Standardinstallation ist es leider nur für Passwort-Login zu gebrauchen.

    Übrigens:
    Die Links der Wocher auf deiner Seite sind sehr geil. Viele interessante Dinge dabei. Besten Dank.

    1. Wenn du mit sudo su seafile in den Benutzer seafile wechselst, solltest du eigentlich genügend Rechte zum Installieren haben, sodass der Eintrag in die sudoers-Liste nicht nötig ist (s. Schritt 1a von Teil 3).

      Zu deiner fail2ban-Frage: Leider nein, keine Ahnung.

  9. Pi.RAT schreibt:

    Hallo. Zum bcrypt wheel-building Problem:
    Habe vor „sudo python3 -m pip install –upgrade passlib bcrypt“ folgendes gemacht:

    „sudo apt-get update“
    „sudo apt-get install python-pip“
    „sudo apt-get install python-all-dev python-setuptools python-wheel“
    „sudo apt-get install build-essential libffi-dev python-dev“
    „sudo apt-get install gcc build-essential libffi-dev python3-dev“
    „sudo apt-get install build-essential libssl-dev libffi-dev python3-dev“
    „sudo python3 -m pip install cffi“
    Jetzt können die wheels auch gebuildet werden.

    Für die seafile-Installation mit usr seafile musste ich diesen in die sudoers-Liste eintragen.
    „sudo gpasswd -a seafile sudo“
    Dann hatte ich auch die Schreibberechtigung für die config-File auf die HDD und die Installation läuft durch.
    Mal sehen, was passiert, wenn ich user seafile wieder austrage…:)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.