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.

Primäre und sekundäre Spiegelserver

Immer wenn F-Droid einen neuen Index erstellt hat, wird dieser proaktiv an eine ausgewählte Gruppe von Spiegelservern, die sogenannten „primären Spiegelserver“, weitergegeben. Mit anderen Worten: die primären Spiegelserver werden fast sofort aktualisiert. Die primären Spiegelserver sind in der (aktuellen Liste) konfiguriert:

• ftp.agdsn.de
• ftp.lysator.liu.se
• plug-mirror.rcac.purdue.edu

Die anderen Spiegelserver sind „sekundäre Spiegelserver“. Diese Spiegelserver sollten regelmäßig (z. B. alle 4 Stunden) mit einem der primären Spiegelserver synchronisiert werden. Daher haben sekundäre Spiegelserver in der Regel eine geringe Übertragungsverzögerung. Beachte jedoch, dass in der Praxis die Zeit zwischen zwei Indexaktualisierungen hauptsächlich durch die Zeit für das Aktualisieren und Erstellen der Apps bestimmt wird (in der Größenordnung von Tagen). Durch die Begrenzung der Anzahl der primären Spiegelserver bleibt die Belastung des f-droid.org originserver gering. Es ist möglich, einen „tertiären Spiegelserver“ zu haben, indem man von einem Sekundärspiegel synchronisiert, was angesichts lokaler Bandbreitenbeschränkungen sinnvoll sein könnte.

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

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“.

Das Betreiben eines Spiegelservers erfordert in der Regel viel Speicherplatz und Bandbreite. Die Bandbreitenanforderungen werden mit jedem neuen Spiegelserver reduziert, aber die Speicherplatzanforderungen steigen mit einer vertretbaren Rate.

• Im März 2019 benötigte das primäre Repository etwas mehr als 60 GB Speicherplatz für 24.000 Dateien, und das Archiv 300 GB Speicherplatz für 52.000 Dateien.
• Im Februar 2024 benötigte das primäre Repository 450 GB für 180.000 Dateien, und das Archiv 1,9 TB für 430.000 Dateien.
• Im September 2025 benötigte das primäre Repository 675 GB für 189.000 Dateien, und das Archiv 3,78 TB für 538.000 Dateien.
• Der benötigte Speicherplatz wächst mit jeder neuen App-Version.

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

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

Wenn ein Spiegelserver die von F-Droid geforderten Standards erfüllt, kann er zu einem offiziellen Spiegelserver werden. Das ist ein Spiegelserver, den der F-Droid-Client standardmäßig verwendet. Um ein offizieller Spiegelserver zu werden, muss ein Spiegelserver unter anderem eine nachgewiesene Zuverlässigkeit, die Einhaltung des Datenschutzes und eine gute TLS-Konfiguration aufweisen. Alle bekannten Spiegelserver werden im Mirror Monitor erfasst. Beispielsweise werden die Protokolle von f-droid.org einige Wochen lang aufbewahrt. Diese Protokolle werden verarbeitet, um alle personenbezogenen Daten (PII) zu entfernen, und die minimierten, sicheren Daten werden dann für immer aufbewahrt. Eine übliche Konfiguration für offizielle Spiegelserver ist es, die Protokolle vier Wochen lang aufzubewahren und sie dann zu löschen.

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. Ersetze außerdem die in den Beispielen genannten Pfade und Domains durch deine eigenen.

Für Hilfeleistungen zu diesem Verfahren kannst du 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

2. Die Repositorys synchronisieren

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 kannst du 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/

3. 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ülle die Datei mit Einträgen, um die Repositorys zu aktualisieren. Diese Befehle werden alle 6 Stunden zur Minute 35 ausgeführt. Du kannst dies an deine Bedürfnisse anpassen.

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/

4. 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. Beachte, dass es wichtig ist, dass deine URI /fdroid/repo lautet, damit die App deinen Spiegelserver automatisch hinzufügen kann.

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

  server_name fdroidmirror.example.com;

  rewrite ^ https://$host$request_uri permanent;
}

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

  server_name fdroidmirror.example.com;

  root /var/www/fdroid/;

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

  # Hier eine TLS-Konfiguration aus dem „Mozilla SSL Configuration Generator“ https://mozilla.github.io/server-side-tls/ssl-config-generator/ einfügen
}

5. Den Spiegelserver auf Funktion testen

Den Spiegelserver manuell zum F-Droid-Client hinzufügen, um ihn auf Funktion zu testen.

Zu Einstellungen -> Paketquellen gehen, auf die Schaltfläche “+” klicken und dann händisch die URL des eigenen Repositorys eingeben (nicht den QR-Code verwenden): https://fdroidmirror.example.com/fdroid/repo?fingerprint=43238D512C1E5EB2D6569F4A3AFBF5523418B82E0A3ED1552770ABB9A9C9CCAB

Dann die anderen Spiegelserver deaktivieren bis auf den neuen, den Index mit pull-to-refresh aktualisieren und einige Anwendungen installieren!

6. Eine Datenschutzrichtlinie erstellen

Bitte füge eine Datenschutzrichtlinie ein, damit die Nutzer verstehen können, was mit ihren Metadaten geschieht, wenn sie deinen Spiegelserver nutzen. Für Inspiration, siehe:

• FAU: https://ftp.fau.de/datenschutz
• Lysator: https://ftp.lysator.liu.se/datahanteringspolicy.txt
• Purdue PLUG: https://plug-mirror.rcac.purdue.edu/info.html

7. Spiegelserver-Aufnahme beantragen

• Forke das Spiegelserver-Monitor-Repo, füge deinen Spiegelserver zur Liste in der README hinzu und eröffne eine Merge-Anfrage.
• Eröffne ein Ticket im Admin-Repo, und füge alle relevanten Informationen hinzu, um die Aufnahme deines Spiegelservers zu beantragen.
• Sobald das Kernteam deinen Spiegelserver als vertrauenswürdig und zuverlässig einstuft, wird er in die offizielle Liste aufgenommen.

Weitere Überlegungen

• Leite E-Mails zu Cronjob-Fehlern weiter, damit du erfährst, wenn die Synchronisation fehlschlägt
• Die Festplattennutzung überwachen, um eine volle Festplatte zu verhindern
• Überwache deinen Spiegelserver, damit du weißt, wenn er ausfällt (idealerweise unter dem Stichwort /srv/mymirror.org/htdocs/fdroid/repo/index-v1.jar)
• Härte deine SSH-Serverkonfiguration (Passwort-Authentifizierung deaktivieren, fail2ban installieren)
• Aktiviere 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