Mirror betreiben

F-Droids Sammlung an Apps und Dateien liegen auf Servern, die von den F-Droid-Kernmitwirkenden betrieben werden. Ursprünglich wurde dieses Hauptrepository nur auf f-droid.org gehostet, da F-Droid aber wuchs, war f-droid.org allein nicht mehr in der Lage, die gesamte Last zu tragen. F-Droid unterstützt nun Server, die eine vollständige Kopie der Repositorys reproduzieren. Das Hosting eines Spiegelservers geht mit dem Betrieb eines HTTP(S)-Servers einher, der eine Kopie des Repositorys hostet, das über rsyncsynchronisiert wird.

Anforderungen

Es gibt zwei offizielle F-Droid-Repository-Bereiche, das „Repo“ und das „Archiv“. Am wichtigsten ist es, das „Repo“ zu spiegeln, da es sehr viel mehr genutzt wird als das „Archiv“.

Ein Mirror benötigt in erster Linie Festplattenspeicher und Upload-Bandbreite. Die Bandbreitenanforderungen gehen mit jedem neuen Mirror zurück, die Festplattenanforderungen hingegen wachsen in einem angemessenen Grad. Zum Zeitpunkt des Schreibens (März 2019) benötigt das primäre Repository etwas mehr als 60 GB Festplattenspeicher in 24.000 Dateien und das Archiv benötigt 300 GB Festplattenspeicher verteilt auf 52.000 Dateien. Die benötigte Festplattenkapazität wächst mit jeder neuen App.

Es gibt viele Spiegelserver, die eine rsync-Verbindung anbieten, wählen Sie den, der Ihrem Spiegelserver am nächsten liegt:

Festlandchinarsync -axv mirrors.tuna.tsinghua.edu.cn::fdroid
Deutschlandrsync -axv ftp.agdsn.de::fdroid
Deutschlandrsync -axv ftp.fau.de::fdroid
Indiana, USArsync -axv plug-mirror.rcac.purdue.edu::fdroid
Schwedenrsync -axv ftp.lysator.liu.se::fdroid
Taiwanrsync -axv mirror.ossplanet.net::fdroid
Ukrainersync -axv fdroid.astra.in.ua::fdroid

Aktuelle Informationen zur erforderlichen Festplattenkapazität können ermittelt werden, indem Sie Folgendes im Terminal ausführen:

$ rsync --dry-run --recursive --stats --human-readable ftp.fau.de::fdroid .

Einrichtung

Diese Anleitung geht von einer Verwendung von Nginx mit einer auf Debian basierenden Distribution aus, sowie der Spiegelung des primären Repositorys plus des Archivs. Bitte entsprechend anpassen, falls Alternativen verwendet werden oder die Spiegelung des Archivs nicht beabsichtigt wird. Ersetzen Sie außerdem die in den Beispielen genannten Pfade und Domänen durch Ihre eigenen.

Für Hilfeleistungen zu diesem Verfahren können Sie uns gerne kontaktieren.

  1. Geeignete Verzeichnisse erstellen
$ sudo mkdir -p /var/www/fdroid/fdroid/repo
$ sudo mkdir -p /var/www/fdroid/fdroid/archive
$ sudo chown -R www-data.www-data /var/www/fdroid
  1. Synchronisieren Sie die Repositorys. Diese Befehle werden am besten in einem Terminal-Multiplexer (screen, tmux usw.) ausgeführt, da sie einige Zeit in Anspruch nehmen werden. Mit --info=progress2 können Sie den Fortschritt sehen.
$ sudo -u www-data -E /usr/bin/rsync -aHS  --delete --delete-delay --info=progress2 ftp.fau.de::fdroid/repo/ /var/www/fdroid/fdroid/repo/
$ sudo -u www-data -E /usr/bin/rsync -aHS  --delete --delete-delay --info=progress2 ftp.fau.de::fdroid/archive/ /var/www/fdroid/fdroid/archive/
  1. Einen Cronjob einrichten, damit die Repositorys auf dem neusten Stand bleiben

Eine Cronjob-Datei in /etc/cron.d erstellen

$ vi /etc/cron.d/fdroid

Füllen Sie die Datei mit Einträgen zur Aktualisierung der Repositories. Diese Befehle werden zur Minute 35 nach jeder 6. Stunde ausgeführt, Sie können diesen Zeitpunkt nach Ihren Bedürfnissen ändern.

35 */6 * * * www-data /usr/bin/rsync -aHS  --delete --delete-delay ftp.fau.de::fdroid/repo/ /var/www/fdroid/fdroid/repo/
35 */6 * * * www-data /usr/bin/rsync -aHS  --delete --delete-delay ftp.fau.de::fdroid/archive/ /var/www/fdroid/fdroid/archive/
  1. Den Webserver konfigurieren

Dies ist ein Beispiel-Serverblock für nginx. Wenn verwendet, sollte er nach /etc/nginx/sites-available/ kopiert und mit /etc/nginx/sites-enabled symbolisch verknüpft werden. Beachten Sie, dass es wichtig ist, dass Ihre URI /fdroid/repo lautet, damit die App Ihren Mirror automatisch hinzufügen kann.

server {
  listen [::]:80 ipv6only=off;

  server_name fdroidmirror.example;

  rewrite ^ https://fdroidmirror.example$request_uri permanent;
}

server {
  listen [::]:443 ssl http2 ipv6only=off;

  server_name fdroidmirror.example;

  root /var/www/fdroid/;

  # TODO: https://gitlab.com/snippets/1834032
  location /health {
    proxy_pass http://127.0.0.1:8000/;
  }

  ssl_certificate /etc/letsencrypt/live/fdroidmirror.example/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/fdroidmirror.example/privkey.pem;

  # Hier eine TLS-Konfiguration aus dem Mozilla SSL Config Generator https://mozilla.github.io/server-side-tls/ssl-config-generator/ einfügen
}
  1. Mirror-Aufnahme beantragen
  • Forken Sie das Mirror Monitor Repo, tragen Sie Ihren Mirror in der Liste in der README ein und eröffnen Sie einen Merge Request.
  • Öffnen Sie ein Issue im Admin Repo, das alle relevanten Informationen enthält und um die Aufnahme Ihres Mirrors bittet.
  • Sobald das Kernteam Ihren Mirror als vertrauenswürdig und zuverlässig erachtet, wird er in die offizielle Liste aufgenommen werden.

Außerdem wäre es schön, eine Datenschutzrichtlinie aufzunehmen. Damit die Benutzer verstehen, was mit ihren Metadaten passiert, wenn sie den Spiegelserver benutzen. Purdue PLUG https://plug-mirror.rcac.purdue.edu/info.html und FAU https://ftp.fau.de/datenschutz sind zwei Beispiele.

Weitere Überlegungen

  • Richten Sie eine Datenschutzrichtlinie ein, die beschreibt, was mit den Metadaten geschieht (zum Beispiel FAU, PLUG, Lysator).
  • Leiten Sie E-Mails zu Cronjob-Fehlern weiter, damit Sie erfahren, wenn die Synchronisation fehlschlägt
  • Richten Sie eine Überwachung Ihres Mirrors ein, damit Sie wissen, wenn er abstürzt (idealerweise ein Keyword in /srv/mymirror.org/htdocs/fdroid/repo/index-v1.jar)
  • Härten Sie Ihre SSH-Serverkonfiguration (Passwort-Authentifizierung deaktivieren, fail2ban installieren)
  • Aktivieren Sie unbeaufsichtigte Sicherheitsupgrades (unter Debian einfach apt-get install unattended-upgrades)

Ausführen eines primären Spiegelservers (Empfangen von Synchronisierungen per Push)

Die bevorzugte Einrichtung ist, dass die F-Droid-Aktualisierungen per rsync über ssh mit SSH-Schlüsselauthentifizierung auf den primären Spiegelserver übertragen werden. Dies ist dasselbe wie bei Debian, der Hauptunterschied ist, dass derzeit kein Skript für command="" verwendet wird, sondern stattdessen ein hart kodierter rsync Befehl. Das schränkt die Sicherheitsinteraktion wirklich schön auf das ein, was passieren muss (Least Authority!).

command="rsync --server -logDtpre.iLsfx --log-format=X --delete --delay-updates . /srv/fdroid-mirror.at.or.at/htdocs/fdroid/"

Der einzige anpassbare Teil dieses Befehls ist der endgültige Pfad. Es kann ein beliebiger Pfad sein, aber er muss auf das Verzeichnis /fdroid/ zeigen und den abschließenden Schrägstrich enthalten. Wenn eine der rsync-Optionen geändert wird, unterbricht dies die Synchronisierungseinrichtung.

Als zusätzliche Vorsichtsmaßnahme sollte es ein Benutzerkonto (z. B. fdroid) geben, das für den Empfang der rsync/ssh-Verbindung zuständig ist. Es sollte so wenig Zugriff wie möglich haben. Es sollte auf keinen Fall Schreibzugriff auf die Datei authorized_keys haben, da dies einem Angreifer mit erlangtem Schreibzugriff erlauben würde eine separate Schlüsselkonfigurationszeile hinzuzufügen, die alle dort aufgeführten Einschränkungen umgeht. Dies kann einfach durch die folgende Aktion erreicht werden:

$ sudo chown root.root /home/fdroid/.ssh /home/fdroid/.ssh/authorized_keys
$ sudo chmod 0755 /home/fdroid/.ssh
$ sudo chmod 0644 /home/fdroid/.ssh/authorized_keys