Kaputt gemacht und wieder hingekriegt

Heute habe ich gemerkt, dass mein GitLab Server hoffnungslos veraltet und das darunterliegende Ubuntu (17.10) am Ende seines Lebens war. Ich dachte, es sei schnell erledigt: GitLab Community Edition aktualisieren und danach ein Distributions-Upgrade auf das aktuelle Ubuntu 18.04.

Weit gefehlt. Die Probleme begannen nach «sudo apt-get upgrade». Der Upgrader teilte mir mit, dass meine GitLab Version kein direktes Upgrade auf 11.1.4 erlaubt, weil sie nicht die neueste 10.x ist. Ich solle also zuerst auf 10.8 gehen und es dann noch einmal versuchen.

Gut. Eine kurze Suche brachte mich auf die Downloadseite der GitLab Versionen für die vielen Linux-Geschmacksrichtungen: Link zur Downloadseite der Community Edition.

Dort fand ich den neuesten 10.8-Build für ubuntu/xenial, und die Seite gab mir gleich den passenden wget-Befehl:

Nachdem das Paket auf dem Server lag, konnte ich GitLab mit «sudo dpkg -i [Pfad zur heruntergeladenen Datei]» auf die neueste 10.8 heben.

Erster Schritt geschafft, GitLab ist auf 10.8 und läuft.

Als Nächstes wieder «sudo apt-get upgrade», und diesmal kam das Upgrade auf 11.4.1 tatsächlich durch. Danach war mein GitLab aber nicht mehr erreichbar. Ohne erkennbaren Grund. Mein erster Gedanke: Ich laufe auf einer nicht mehr unterstützten Ubuntu-Version, also mache ich das Upgrade auf 18.04, und vielleicht löst sich das Problem von selbst.

Der Befehl «sudo do-distribution-upgrade» lief durch, konnte aber nicht alle alten Linux-Kernel aus früheren Upgrades aufräumen. Weil GitLab immer noch nicht lief und ich einiges an Altlasten aus den früheren Ubuntu-Installationen hatte, habe ich mich für eine neue Ubuntu-VM entschieden.

Das aktuelle Server-Image von der offiziellen Downloadseite war schnell geladen, und die neue VM stand. Die Details der Installation erspare ich dir, sie ist einfach, folge einfach der Anleitung.

Die Daten meines bisherigen GitLab Servers wollte ich natürlich behalten. Dieser Befehl sichert alles:

«sudo gitlab-rake gitlab:backup:create»

Die vollständige Anleitung steht hier.

Nachdem ich GitLab nach dieser Anleitung aufgesetzt hatte, wobei du gitlab-ee durch gitlab-ce ersetzen musst, konnte ich das Backup zurückspielen. Ich habe die Daten auf den neuen Server kopiert und bin der Anleitung hier gefolgt.

Leider antwortete mein GitLab Server immer noch nicht auf HTTPS-Anfragen.

Nach einigen verlorenen Stunden stiess ich auf das Log:

/var/log/gitlab/nginx/current

Darin standen Einträge, die mir endlich sagten, dass meine Zertifikate auf dem neuen System nicht am richtigen Ort lagen. Den Meldungen folgend konnte ich GitLab wieder zum Laufen bringen.

Der Vollständigkeit halber hier ein paar Fehlermeldungen aus diesem Log, vielleicht findet sie jemand über die Suche:

2018-08-09_17:07:53.24790 nginx: [emerg] BIO_new_file(“/etc/gitlab/ssl/HOSTNAME.crt”) failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen(‘/etc/gitlab/ssl/HOSTNAME.crt’,‘r’) error:2006D080:BIO routines:BIO_new_file:no such file)

2018-08-09_17:11:05.37776 nginx: [emerg] SSL_CTX_use_PrivateKey_file(“/etc/gitlab/ssl/HOSTNAME.key”) failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen(‘/etc/gitlab/ssl/HOSTNAME.key’,‘r’) error:20074002:BIO routines:FILE_CTRL:system lib error:140B0002:SSL routines:SSL_CTX_use_PrivateKey_file:system lib)

Nach etwas Nachdenken und weiterer Recherche weiss ich jetzt, warum dieses Upgrade so mühsam war. GitLab hat Letsencrypt-Funktionen eingebaut, die standardmässig aktiv waren. Das System versuchte also, meine Zertifikate durch Letsencrypt-Zertifikate zu ersetzen. Das ging schief, und übrig blieb ein System mit kaputten Zertifikaten.

Jetzt geniesse ich das gelungene Upgrade mit meinem prächtigen Login-Screen: