Website
Auf dem Server unserer Website läuft folgendes
- Das Wordpress
- Unser SpaceAPI-Endpoint
- Dieses Wiki
Zugriff haben waaaaargh (eigentlicher Kümmerer), sternenseemann und Profpatsch.
Die Maschine scheint[citation needed] Debian “best-practices” zu folgen.
Nginx
Configs in /etc/nginx/sites-available
& Symlinks
nach /etc/nginx/sites-enabled
. Daten in
/var/www
.
Let’s Encrypt
Für eine neue Domain den DNS-Record richtig setzen, eine nginx-Config
schreiben, systemctl reload nginx
, dann
certbot run --nginx -d <neue domain>
.
Zertifikate sollten zweimal am Tag automatisch geupdated werden, siehe
certbot.timer
.
Wiki
Dieses Wiki verwendet eine von sternenseemann und Profpatsch gepatchte Version von gitit. Sie läuft auch auf dem selben Server wie die restliche Website. Die Änderungen sind folgende:
- Visueller Markdown Editor (SimpleMDE)
- Komplett gehostetes CSS/JS (font awesome, MathJax, SimpleMDE) statt nachladen über CDNs
Setup
- Die nginx configuration liegt in
/etc/nginx/sites-available/wiki.openlab-augsburg.de
, sie reicht Requests an den lokalen gitit service durch. gitit.service
liegt in/etc/systemd/system/gitit.service
LC_ALL=C.UTF-8
ist wichtig, um gitit UTF-8-Problematiken zu umgehen- zusätzlich deaktivieren wir mit
+RTS -I0 -RTS
den Haskell Major Garbage Collect, der recht häufig passiert und einiges an CPU-performance verbraucht. (Siehe GHC Doku)
- Alle gitit-Daten (config, log, user db und wikiseiten) liegen in
/home/gitit/gitit-db
/home/gitit/gitit-VERSION
ist ein symlink auf den nix build vongitit
, der so mittles gc-roots dagegen gesichert wird gelöscht zu werden.
Bauen, Aktualisieren
Unser gitit wird mit nix
gebaut, da wir damit alle Frontend-Dependencies automatisiert für gitit
installieren können und so nicht unmengen an minified JavaScript im Repo
einchecken müssen. Grundsätzlich kann man bei installiertem nix einfach
im Repository nix-build
ausführen und erhält ein
funktionierendes gitit in ./result
.
Der Build ist in default.nix
geregelt. Darin sind auch statisch versionen von SimpleMDE, MathJax,
font-awesome und nixpkgs
(was die Versionen der Haskell-Dependencies und den Build-Prozess von
gitit vorgibt) festgelegt. Diese kann man alle ggf. auch dort
aktualisieren (man muss neben den URLs auch die checksums jeweils
anpassen!).
Theoretisch kann man gitit auf dem Server bauen, es ist aber wahrscheinlich sinnvoller es lokal zu bauen. Das funktioniert folgendermaßen:
- Lokal im gitit repository
nix-build
ausführen (muss natürlichx86_64
sein, sonst muss man crosscompilen) - Den nix store path, den die letzte Zeile output von
nix-build
zeigt (bzw. auf den der symlinkresult
zeigt), kopieren wir jetzt mitnix-copy-closure
(odernix copy
) auf den Server:nix-copy-closure --gzip --to ssh://root@SERVER <STORE PATH>
- Den store path müssen wir jetzt auf dem Server noch vor dem
Löschen schützen:
nix-store --add-root /home/gitit/gitit-VERSION --indirect --realize <STORE PATH>
- Jetzt hat man unter
/home/gitit/gitit-VERSION/bin/gitit
das aktuelle gitit binary und kann es im systemd service file (s. o.) ändern. Alte builds kann man löschen, indem man ihre symlinks löscht undnix-store --gc
ausführt.
Das git repo kann man aktualisieren, indem man sich mit
git fetch --all
die tags des upstream gitits besorgt und
dann den entsprechenden neuesten release tag merged. Da gibt es in der
Regel ein paar Konflikte, die man entsprechend lösen muss.
Backup
Hier sollte es bald mal eine automatische Lösung geben und der Abschnitt aktualisiert werden.
/home/gitit/gitit-db/wikidata
enthält alle Wikiseiten und ist selbst eine git repository. Man kann also git selbst verwenden, um ein Backup von ihr an einem anderen Ort zu erstellen (z. B. zu einer anderen remote pushen)/home/gitit/gitit-db/{static,templates}
kann man ganz klassisch als Dateien kopieren.- Änderungen in
gitit.config
am besten im Repository angleichen, da wir sowieso schon den Fork maintainen müssen. /home/gitit/gitit-db/gitit-users
ist die user Datenbank, die personenbezogene Daten enthält (email adressen), und dementsprechend gesichert werden sollte