Nextcloud Hoster oder Selfhosting für Android Kalender & Kontakte sync

MikE_GRH

Ensign
Registriert
Dez. 2018
Beiträge
232
Hallo,

ich bin dabei mein Android Handy soweit wie möglich von Google zu befreien.
Jetzt mach ich mir gerade gedanken worüber ich zukünftig meinen Kalender und die Kontakte verwalten möchte.
Als Lösung habe ich mich für Nextcloud entschieden, da es evtl noch weitere Vorzüge für die Zukunft hat.

Nun stehe ich vor der Entscheidung einen Free-Hoster zu verwenden: https://nextcloud.com/signup/
Oder meinen Raspberry 4 4gb dafür zu verwenden.
Der Raspy fungiert gerade als Wireguard-Server und als PiHole-DNS (Das soll natürlich weiterhin neben Nextcloud laufen -> das sollte ja problemlos möglich sein, oder?)

Es sollen im ersten Schritt nur die Kalender und die Kontakte darüber synchronisiert werden.
Eine Dateisicherung in der Cloud ist nicht geplant, deshalb würden mir auch die Free-Angebote reichen, denke ich.

Was sind die Vor- und Nachteile der beiden Lösungen?
Was passiert mit den Daten, wenn der Hoster sein Angebot löscht, oder ähnliches? Kann man die Daten einfach vom Hoster auf einen anderen transferieren?
 
Für die Lösung mit der Raspberry Pi solltest du erst mal schauen, ob du per VPN in dein Heimnetzwerk kommst. Mit z.B. DSLite Internetverbindungen ist das nicht so einfach.
Ohne VPN hättest du sonst nur die Möglichkeit, deine NextCloud zu benutzen, wenn du dich zu Hause in den WLAN einloggst.
 
VPN ist möglich.
Dafür läuft ja bereits der Wireguard-Server = VPN
OS-Unterbau hierfür ist übrigens Raspbian.
 
Also wenn du eine Cloud zum Synchronisieren von Kalender und Kontakte nutzt, und du alle Daten der Cloud auch lokal auf deinem Gerät synchronisiert hast, dann - so blöd es klingt - kann es dir egal sein, wenn die Cloud dicht macht.
Wenn du dann einen anderen Anbieter hast, synchronisierst du deinen aktuellen Stand dort hin.
 
Stimmt, für reine sync-Aufgaben dürfte das ziemlich egal sein. Wenn dann aber doch weitere Nextcloud-Dienste genutzt werden, könnte es vermutlich schon problematischer werden.

Weitere Frage ist, wie es datenschutztechnisch aussieht.
Files könnte man ja easy verschlüsseln, aber wie sieht das mit den Kalender und Kontaktdaten aus?
 
Einfach nextcloudpi mit docker nutzen, pihole und Co ebenfalls im Container und Port 80 & 443 nach außen. Dazu noch ein Letsencrypt-Container als Reverse Proxy und das ganze läuft tadellos. Der Pi ist für die reine Sync von diesen Daten schnell genug. Selbst der Fotos-Sync-Client (automatisierter Upload von Fotos vom Telefon an deine Cloud) sollte performant genug sein.
 
  • Gefällt mir
Reaktionen: MikE_GRH
Yap. Aber für mich sollte die Cloud eigentlich "nur" die Synchronisierungsplattform sein, und nicht bestimmen, wie meine Daten auszusehen haben. So weit halt die Theorie.

Also ich bin kein Experte hier juristisch, aber ich würde davon ausgehen, dass die Datenschutzverantwortung sogar beim Betreiber liegt... also die dürfen nicht einfach so auf die Inhalte deiner Daten zugreifen. Sonst dürfte man ja so gut wie gar nichts in die Cloud synchronisieren, selbst E-Mails dürfte dein Provider nicht speichern ...
Gmail und Co bieten auch Kalender und Kontakte, ist kein wirklicher Unterschied zu einer Cloud aus meiner Sicht.

Aber wie gesagt: Bin da kein Experte.
 
  • Gefällt mir
Reaktionen: MikE_GRH
Naja, ob die Daten nun bei Google oder nem anderen Anbieter liegen. Imho hast du da nichts gekonnt, außer dass halt nicht mehr Google drauf steht. Die Daten liegen trotzdem extern und sind ggf. sogar weniger gut geschützt, da es nun mal kein großer Anbieter wie Google/MS/Apple ist, wo man doch etwas mehr auf Sicherheit achtet als ein "0815 Hoster".

Entweder selbst hosten oder sein lassen, dann sind und bleiben die Daten auch bei dir (weswegen man es ja auch macht). Das Killerargument VPN ist imho unnütz. Hoste einfach Nextcloud in nem Container, nen Reverse Proxy davor, immer mal aktualisieren und gut. Anders machen es große Hoster auch nicht.
MikE_GRH schrieb:
Files könnte man ja easy verschlüsseln, aber wie sieht das mit den Kalender und Kontaktdaten aus?
Gibts nicht mit Cal- und CardDAV. EteSync soll E2EE unterstützen... Aber dann hast du wieder kein offenes Protokoll.

Hoste einfach selbst, dann hast du die volle Kontrolle und kannst dank offenem Protokoll jeden beliebigen Client nutzen. Zur Not ein VServer, wobei du dich dann ggf. um mehr kümmern musst. Beim Homeserver brauchst du halt nur noch einen Dyn-DNS Anbieter. Falls du ne Fritzbox hast, wäre das mit MyFritz bereits möglich. Außerdem sollte dir dein ISP Dual-Stack bereitstellen, mindestens aber IPv4.
 
  • Gefällt mir
Reaktionen: tollertyp, BachUhr und MikE_GRH
Als freie DNS-Anbieter aus Deutschland kann ich selfhost empfehlen oder eben freeDNS. Für beide lassen sich über den Letsencrypt auch wunderbar valide Zertifikate ausstellen.

Edit: Ich würde dir auf jeden Fall zwei weitere Container empfehlen, welche die Performance deiner Cloud massiv steigern: MariaDB und Redis
 
Ok, es spricht quasi nichts gegen das selbsthosten.

Wenn ich das zusätzlich noch in Raspbian installiere ist das vermutlich keine saubere Sache, oder?
Die Variante von riff-raff ist wahrscheinlich aufgrund der Container-Struktur die sinnvollste, oder spricht auch hier etwas dagegen?
 
Wenn du nur CalDAV/CardDAV synchronisieren willst, dann kannst du auch Radicale oder Baikal verwenden, ist weniger Overhead als ein komplettes Nextcloud.

Ich nutze Radical mit einem Selfsigned Zertifikat und dynamischem DNS, auf dem Handy läuft Davx5 zur Synchronisation. Rennt problemlos seit Jahren.
 
  • Gefällt mir
Reaktionen: riff-raff
@Sykehouse Meckert da nicht DAVX5 wegen des Zertifikats?

Baikal ist tatsächlich auch eine gute Empfehlung, wenn es rein bei CalDAV und CardDAV bleiben soll.

@MikE_GRH Wie läuft denn jetzt WireGuard und PiHole? Nativ oder bereits im Container?
 
@riff-raff : läuft momentan alles nativ. Müsste also folglich komplett neu aufgesetzt werden.
Was aber grundsätzlich keine großes Problem wäre.
Allerdings habe ich noch nicht mit Containern gearbeitet.
Wenn das allerdings Vorteile bietet, dann würde ich mich da übers WE auch einarbeiten.
 
Ich hatte anfangs auch Berührungsängste mit den Containern, mittlerweile liebe ich es! Sehr einfach zu pflegen, keine Abhängigkeitsprobleme mehr, fix mal eine weitere Instanz zum testen ziehen geht auch ohne gleich alles abzuschießen. Ich nutze als GUI Portainer, was auch wirklich selbsterklärend ist mMn.

Beim Pi als Basis musst halt schauen, dass du Container für ARM verwendest, aber gerade für den Pi gibts da dank der großen Community zu Hauf.
 
Ok, dann werde ich mich damit mal übers Wochenende spielen.
Falls ich es nicht zum laufen bekommen, werde ich es mit der nativen Installation probieren.
 
So ganz einfach ist das dann wohl doch nicht.
Ich habe soweit alles fertig konfiguriert, nur ich bekomme nextcloudpi als container nicht zum laufen.

Wie folgt sieht mein Setup aus:

Raspi 4 4gb -> 192.168.188.113
Fritzbox -> 192.168.188.1
Pihole nativ installiert und Port auf 90 geändert
Wireguard auch nativ
Docker installiert
Portainer installiert
Nextcloudpi image heruntergeladen

Das kann Image kann ich auch sehen und als container starten.
Ich schaffe es nur nicht auf das webfrontend zuzugreifen.
Gibt es hierfür eine Anleitung?
Im Portainer gibt es unzählige Einstellmöglichkeiten :confused_alt:

Reiter Images
1591447639796.png


Reiter Container
1591447613698.png
 
Dir ist schon bewusst, dass dein nextcloudpi Container auf den Ports 32772 (https) bzw. 32773 (http) angesprochen werden will?
Ansonsten steht ja "running" da. Also sollte das Teil laufen. Bei den Quick Actions kannst du dir auch das Log vom Container anschauen, da stehen vielleicht auch noch ein paar nützliche Infos, falls es tatsächlich Probleme geben sollte.

Und die bieten nur eine "latest" Version an? Das ist nicht gerade die feine englische Art.

@riff-raff
Warum wurde eigentlich nextcloudpi benutzt, statt dem offiziellen nextcloud Docker image? https://hub.docker.com/_/nextcloud/
Ich habe mit beiden noch nicht gearbeitet, aber laut meiner kurzen Recherche sollte das offizielle Image auch auf dem Pi laufen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: riff-raff
Hallo miteinander

Ein sehr spannendes Thema. Ehrlich gesagt möchte ich mich auch ein wenig von Google lösen, weswegen ich nun auch verschiedenste Lösungen evaluiere. Ich hätte nie gedacht dass Self-Hosting in Frage kommen könnte (habe da immer ein wenig Bedenken wegen der Sicherheit...).

Eine Frage hätte ich noch zu folgendem Punkt:

riff-raff schrieb:
Einfach nextcloudpi mit docker nutzen, pihole und Co ebenfalls im Container und Port 80 & 443 nach außen. Dazu noch ein Letsencrypt-Container als Reverse Proxy und das ganze läuft tadellos. Der Pi ist für die reine Sync von diesen Daten schnell genug. Selbst der Fotos-Sync-Client (automatisierter Upload von Fotos vom Telefon an deine Cloud) sollte performant genug sein.

Was ist hier mit "nach aussen" gemeint? Also so wie ich das verstanden habe richtet ihr auf eurem Router ein Port-Forwarding ein (für 80 und 443) zu eurem Docker-Server ein, auf welchem ein Reverse-Proxy die Requests abfängt. Dieser Reverse Proxy leitet dann die Anfragen entsprechend an den Nextcloud- oder Pi-Hole Container (ist natürlich abhängig von Proxy-Konfiguration oder?). Wenn jetzt mein Pi-Hole Container nur im internen Netz verfügbar sein soll, muss ich beim entsprechenden Container einen anderen Port fürs Mapping verwenden?

Und so wie ich das verstanden habe können sämtliche Container, die auf dem gleichen Docker-Server laufen, mittels den entsprechenden Container-Namen miteinander kommunizieren oder?

Sehr interessantes Thema (und mit portainer.io ist die Konfiguration der einzelnen Container wirklich ziemlich einfach) aber ich denke ich muss mich hier noch ein wenig einlesen. ^^

Danke für eure Antworten!

Viele Grüsse

@benneq:

https://hub.docker.com/r/ownyourbits/nextcloudpi

Aber laut dem entsprechenden Befehl auf der docker-hub Seite werden die Standard-Ports für den Zugriff verwendet:

docker run -d -p 4443:4443 -p 443:443 -p 80:80 -v ncdata:/data --name nextcloudpi ownyourbits/nextcloudpi $DOMAIN

Ah jetzt sehe ich es (die letzte Spalte). ^^

@MikE_GRH:

Bei der Erstellung des Container unter portainer.io musst du unter "Network ports configuration" die entsprechenden Ports des Docker-Hosts (80 und 443) an den Docker-Cotainer weiterleiten. Ansonsten pickt Docker vermutlich einfach irgendwelche Ports fürs Mapping.

Was auch noch sehr wichtig ist: Unter "Advanced container settings" musst du unbedingt noch Volumes einbinden ("Bind"). Mit dieser Option wird ein Verzeichnis des Docker-Servers dem Container zur Verfügung gestellt. Wenn du das nicht machst und den Nextcloud-Container stoppst, sind alle Daten weg!

Ich denke es ist sicherlich nicht schlecht wenn du dich ein wenig in das Thema einliest! ^^

Viele Grüsse
 
Zuletzt bearbeitet:
@paokara Du kannst auch jedem Docker Container eine eigene IP geben. Ist angeblich ein Anti-Pattern, aber sollte trotzdem ziemlich einfach funktionieren.
Alternativ halt über unterschiedliche Ports auf die Container mappen. Dazu braucht's nicht mal einen extra Reverse Proxy: Man kann die Docker Container auch einfach über das normale Netzwerk Interface im LAN "freigeben" - sollte die Standardeinstellung sein.
Bei mir läuft z.B. Portainer und Pihole jeweils als Docker Container. PiHole erreiche ich dabei über Port 80 und Portainer über Port 9000. Also http://192.168.178.x/ und http://192.168.178.x:9000/
 
Zurück
Oben