Bereitstellung der Internetseite

Bei der Erstellung der F-Droid-Internetseite wird Jekyll und gitlab-ci verwendet. Die gesamte Internetseite funktioniert nun durch Nutzung eines Standard-Git “fork”-Workflows, der völlig von GitLab unterhalten wird und von Diensten wie GitHub bestens bekannt ist. Alle Seiten und Informationen über Apps und Pakete, die von f-droid.org vertrieben werden, werden mithilfe unseres Plugins jekyll-fdroid erzeugt, das die Inhalte aus der f-droid.org Indexdatei bezieht.

Staging auf Entwicklungs-Forks

Alle Entwicklungs-Forks der fdroid-Website haben automatisch einen Staging-Server eingerichtet und werden von der gitlab-ci Konfiguration gepflegt. Dadurch wird der Inhalt des Branches master des Forks automatisch nach GitLab Pages verteilt. Zum Beispiel, nicoalt’s git Fork ist auf https://gitlab.com/nicoalt/fdroid-website und der master Branch davon wird automatisch auf https://nicoalt.gitlab.io/fdroid-website verteilt.

Staging der offiziellen Website

Wie bei Forks wird der master-Zweig des Haupt-Git-Repos für die Website, https://gitlab.com/fdroid/fdroid-website, automatisch nach https://fdroid.gitlab.io/fdroid-website deployed. Das ist der Ort, um den aktuellen Zustand der Website zu überprüfen, bevor man eine Veröffentlichung markiert.

Bereitstellung auf https://f-droid.org

Wenn ein Update der Website getestet wurde und bereit steht, erstellt ein Release-Manager ein PGP-signiertes Release-Tag im Haupt-Git-Repo. Der Deployment-Server überwacht das Haupt-Git-Repo auf neue Tags. Wenn er ein neues Tag sieht, prüft er zuerst die PGP-Signatur auf dem Git-Tag mit einem manuell konfigurierten GnuPG-Schlüsselring, der nur die öffentlichen Schlüssel der PGP-Schlüssel enthält, die zur Kennzeichnung von Website-Releases berechtigt sind.

Nachdem der Git-Tag verifiziert wurde, wird das Ziel f-droid.org in .gitlab-ci.yml ausgeführt, um die eigentlichen Dateien für die Website zu generieren. Diese Dateien werden dann auf die f-droid.org Server kopiert.

Die Deploy-Tags verwenden ein Namensschema mit “semantischer Versionierung”:

  • <major>.<minor>
  • <minor> wird bei jedem Deployment erhöht
  • <major> wird nur erhöht, wenn es größere Veränderungen gibt

Einrichten und Ausführen des Deploy-Verfahrens

Das Bereitstellungsverfahren wurde auf einer Maschine mit Debian/Stretch getestet. Es sollte immer dann ausgelöst werden, wenn der Repo-Index veröffentlicht wird, damit er mit den neuesten App-Informationen neu aufgebaut werden kann. Die gesamte Prozedur kann als root oder einfach als gitlab-runner ausgeführt werden. Das letzte Verfahren ist nicht Teil eines Skripts, das in das git-Repo der Website übergeben wird, so dass die Befehle, die außerhalb des Dockers ausgeführt werden, nicht über git geändert werden können.

  1. Docker einrichten
  2. GitLab-CI-Multi-Runner einrichten
  3. deploy-allowlist-keyring.gpg mittels GnuPG vorbereiten:
    $ gpg --recv-keys 00aa5556
    $ gpg --fingerprint 00aa5556  # Überprüfen Sie es!
    $ gpg --export 00aa5556 > /pfad/zum/deploy-allowlist-keyring.gpg
    
  4. Website-Quellcode beziehen:
    $ git clone https://gitlab.com/fdroid/fdroid-website
    
  5. Generierung ausführen:
    $ cd fdroid-website
    $ git fetch --tags
    $ sudo gitlab-runner exec docker f-droid.org \
              --pre-build-script ./tools/prepare-for-deploy.py \
              --docker-volumes "/pfad/zum/deploy-allowlist-keyring.gpg:/root/.gnupg/pubring.gpg:ro" \
              --docker-volumes `pwd`/_site:/builds/output
    
  6. Dateien der Seite auf dem Webserver bereitstellen, dabei die von jekyll erzeugten Dateien davon abhalten, Teile der Webseite, die andere Dinge steuern, zu überschreiben:
    $ rsync -ax --delete --exclude-from=_site/build/.rsync-deploy-exclude-list  _site/build/  f-droid.org:/var/www/
    

Basis-Debian/Apache-Setup

Diese Anweisungen basieren auf Debian/Stretch, aber sie sollten sowohl auf älteren als auch auf neueren Versionen von Debian sowie auf allen Debian-Derivaten wie Ubuntu, Mint, Elementary usw. sehr ähnlich sein.

$ sudo su -
# apt install apache2 certbot tor ca-certificates geoip-bin libapache2-mod-geoip \
  python-certbot-apache rsync unattended-upgrades locales
# dpkg-reconfigure unattended-upgrades  # turn them on!
# sed -i 's,^# \(.* UTF-8\)$,\1,' /etc/locale.gen  # enable all UTF-8 locales
# locale-gen
# a2dismod status
# a2enmod headers
# a2enmod rewrite
# a2enmod ssl
# a2enconf security
# apachectl configtest && apachectl restart
# certbot --apache

Apache2 konfigurieren

Die F-Droid-Website wird in mehrere Sprachen übersetzt. Es sind ein paar Dinge notwendig, um zu gewährleisten, dass dies funktioniert.

Das erste wird von .gitlab-ci.yml erledigt, das das Skript ./tools/prepare-multi-langs.sh ohne das Argument --no-type-maps ausführen soll. Dadurch wird sichergestellt, dass jede .html Datei durch eine Apache2 TypeMap ersetzt wird.

Das zweite ist die Aktivierung von mod_rewrite, womit automatisch die richtige Sprache für Browser ausgewählt wird, die kein JavaScript verwenden. Am einfachsten geht das mit sudo a2enmod rewrite.

Das letzte ist, dem Apache2-Server oder der VirtualHost-Konfiguration Folgendes hinzuzufügen, damit die TypeMaps korrekt verwendet werden, die Apache mitteilen, wo die übersetzte Version der Datei zu finden ist (ersetzen Sie /var/wwww/html durch das tatsächliche Web-Stammverzeichnis):

<Directory /var/www/html>
    Options FollowSymLinks
    AllowOverride FileInfo
</Directory>

<Files *.html>
    SetHandler type-map
</Files>

# Virtualize the language sub"directories"
AliasMatch ^(?:/(?:ach|af|ak|sq|am|anp|ar|ar_DZ|ar_MA|an|es_AR|hy|as|ast|de_AT|ay|az|ba|eu|bar|be|be_Latn|bn|bn_BD|bn_IN|brx|bs|bs_Cyrl|bs_Latn|br|bg|my|ca|km|ch|chr|hne|cgg|zh|zh_HK|zh_Hans|zh_Hant|ksh|kw|cr|hr|cs|da|doi|nl|nl_BE|dz|en|en_AU|en_CA|en_IE|en_PH|en_ZA|en_GB|en_US|eo|et|fo|fil|fi|frp|fr|fr_CA|fy|fur|ff|gd|gl|ka|de|el|kl|gu|gun|ht|ha|haw|he|hi|hu|is|ig|id|ia|ga|it|ja|jv|kab|kn|ks|csb|kk|rw|tlh|tlh-qaak|kok|ko|ku|ckb|ky|lo|la|lv|li|ln|lt|jbo|nds|lb|mk|mai|mg|ms|ml|mt|mnk|mi|arn|mr|mni|mn|me|mfe|nqo|nah|nap|ne|se|no|nb_NO|nb|nn|ny|oc|or|oj|os|pap|nso|fa|pms|pr|pl|pt|pt_BR|pt_PT|pa|ps|ro|rm|ru|sa|sat|sc|sco|sr|sr_Cyrl|sr_Latn|sh|sn|szl|sd|si|sk|sl|so|son|st|es|es_US|es_MX|es_PR|su|sw|sv|de_CH|tl|tg|ta|tt|te|th|bo|ti|ts|tr|tk|ug|uk|hsb|ur|ur_PK|uz|uz_Latn|ca@valencia|ve|vec|vi|wa|cy|vls|wo|sah|yi|yo|yue|zu)/)?(.*)?$ /var/www/html/$1

# Tell mod_negotiation which language to prefer
SetEnvIf Request_URI ^/(ach|af|ak|sq|am|anp|ar|an|hy|as|ast|ay|az|ba|eu|bar|be|bn|brx|bs|br|bg|my|ca|km|ch|chr|hne|cgg|zh|ksh|kw|cr|hr|cs|da|doi|nl|dz|en|eo|et|fo|fil|fi|frp|fr|fy|fur|ff|gd|gl|ka|de|el|kl|gu|gun|ht|ha|haw|he|hi|hu|is|ig|id|ia|ga|it|ja|jv|kab|kn|ks|csb|kk|rw|tlh|tlh-qaak|kok|ko|ku|ckb|ky|lo|la|lv|li|ln|lt|jbo|nds|lb|mk|mai|mg|ms|ml|mt|mnk|mi|arn|mr|mni|mn|me|mfe|nqo|nah|nap|ne|se|no|nb|nn|ny|oc|or|oj|os|pap|nso|fa|pms|pr|pl|pt|pa|ps|ro|rm|ru|sa|sat|sc|sco|sr|sh|sn|szl|sd|si|sk|sl|so|son|st|es|su|sw|sv|tl|tg|ta|tt|te|th|bo|ti|ts|tr|tk|ug|uk|hsb|ur|uz|ca@valencia|ve|vec|vi|wa|cy|vls|wo|sah|yi|yo|yue|zu)/ prefer-language=$1

# Language codes from Weblate containing capital letters and underscores need to be treated
# differently, namely the language they refer to is lower case with a hyphen
SetEnvIf Request_URI ^/ar_DZ/ prefer-language=ar-dz
SetEnvIf Request_URI ^/ar_MA/ prefer-language=ar-ma
SetEnvIf Request_URI ^/be_Latn/ prefer-language=be-latn
SetEnvIf Request_URI ^/bn_BD/ prefer-language=bn-bd
SetEnvIf Request_URI ^/bn_IN/ prefer-language=bn-in
SetEnvIf Request_URI ^/bs_Cyrl/ prefer-language=bs-cyrl
SetEnvIf Request_URI ^/bs_Latn/ prefer-language=bs-latn
SetEnvIf Request_URI ^/de_AT/ prefer-language=de-at
SetEnvIf Request_URI ^/de_CH/ prefer-language=de-ch
SetEnvIf Request_URI ^/en_AU/ prefer-language=en-au
SetEnvIf Request_URI ^/en_CA/ prefer-language=en-ca
SetEnvIf Request_URI ^/en_GB/ prefer-language=en-gb
SetEnvIf Request_URI ^/en_IE/ prefer-language=en-ie
SetEnvIf Request_URI ^/en_PH/ prefer-language=en-ph
SetEnvIf Request_URI ^/en_US/ prefer-language=en-us
SetEnvIf Request_URI ^/en_ZA/ prefer-language=en-za
SetEnvIf Request_URI ^/es_AR/ prefer-language=es-ar
SetEnvIf Request_URI ^/es_MX/ prefer-language=es-mx
SetEnvIf Request_URI ^/es_PR/ prefer-language=es-pr
SetEnvIf Request_URI ^/es_US/ prefer-language=es-us
SetEnvIf Request_URI ^/fr_CA/ prefer-language=fr-ca
SetEnvIf Request_URI ^/nb_NO/ prefer-language=nb-no
SetEnvIf Request_URI ^/nl_BE/ prefer-language=nl-be
SetEnvIf Request_URI ^/pt_BR/ prefer-language=pt-br
SetEnvIf Request_URI ^/pt_PT/ prefer-language=pt-pt
SetEnvIf Request_URI ^/sr_Cyrl/ prefer-language=sr-cyrl
SetEnvIf Request_URI ^/sr_Latn/ prefer-language=sr-latn
SetEnvIf Request_URI ^/ur_PK/ prefer-language=ur-pk
SetEnvIf Request_URI ^/uz_Latn/ prefer-language=uz-latn
SetEnvIf Request_URI ^/zh_Hans/ prefer-language=zh-hans
SetEnvIf Request_URI ^/zh_Hant/ prefer-language=zh-hant
SetEnvIf Request_URI ^/zh_HK/ prefer-language=zh-hk

Wenn dies nicht oder falsch gemacht wird, dann werden Sie beim Betrachten einer Seite in etwa Folgendes sehen:

URI: index.html.en Content-language: en Content-type: text/html URI: index.html.fr Content-language: fr Content-type: text/html

Dies ist das Ergebnis der Rückgabe der eigentlichen TypeMap an den Browser und nicht der übersetzten Datei.

Beachten Sie, dass dies auch von der Aktivierung von mod_alias und mod_negotiation abhängt, was aber bei der Installation von Apache2 auf Debian standardmäßig geschieht.