Blog

Das Internet hat mein Gehirn umprogrammiert und irgendwie gefällt mir das Upgrade nicht besonders.

Kennst du diesen Reflex? Man guckt einen Film und greift nur mal kurz zum Telefon und guckt, was so an Push-Nachrichten reinkam. Und fünf bis zehn Minuten später dann noch mal. Und noch einmal. Und noch einmal…

Wie privat darf ein Weblog wie dieses hier eigentlich werden? Auch wenn diese Webseite meinen Namen trägt, handelt es sich schließlich nicht um eine private Seite.

Klar lasse ich im einen oder anderen Text auch mal etwas Privates durchschauen, aber in erster Linie ist das hier eine geschäftliche Seite. Kunden sollen mehr über mich erfahren, potentielle Kunden auf mich aufmerksam werden. Im besten Fall bucht jemand meine Dienste.

Ist es also angemessen über Privates zu schreiben?

Nach einigen Arbeiten an einem VServer, brauchte dieser einen Reboot. Und wie sollte es anders sein, danach wollte GitLab nicht mehr korrekt starten.

Ohne mich zunächst groß um die Gründe dafür zu kümmern, packte ich die Gelegenheit beim Schopfe und dachte mir, ich gönne GitLab mal ein Update. Ich hätte es besser wissen müssen, denn ich hab noch nie ein reibungsloses GitLab-Update vollziehen können…

Das Problem

Auch nach dem Aktualisieren von GitLab ließ es sich nicht dazu bewegen, sich in Gang zu setzen. Irgendwie lief ein Subset der nötigen Prozesse, so dass ich im Browser mal einen Error 502, mal einen Error 500 bekam.

Das Ganze hatte mit Postgresql und dem VServer zu tun, aber der Reihe nach:

Aktualisieren von GitLab unter Ubuntu 14.04

Fangen wir doch bei Schritt eins an und sorgen erst einmal dafür, dass GitLab wieder aktuell ist. Dazu benutze ich unter Ubuntu inzwischen fertige Pakete.

Mit zwei Zeilen auf der Konsole, und alles ist recht schnell installiert. Ratsam ist es, vorher die alte GitLab Instanz zu stoppen sudo service gitlab stop oder sudo gitlab-ctl stop, je nach Version.

Dann kann die Installation losgehen:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce

Nicht wundern, zunächst wird das Paket gitlab deinstalliert, es wird durch das neue gitlab-ce ersetzt. Es laufen einige Informationen den Screen lang. Beim ersten Versuch bekam ich einen Fehler und das Paket konnte nicht vollständig installiert werden. Fragt nicht warum, aber beim zweiten Anlauf klappte es.

Danach nur noch einmal GitLab rekonfigurieren, damit die alte Einstellungen übetragen werden:

sudo gitlab-ctl reconfigure

Fertig! Oder?

Error 502 - Postgresql zum Laufen bewegen

Nach der Installation bekam ich den besagten Error 502. Ein Blick auf gitlab-ctl status verriet mir, dass eigentlich alles wunderbar läuft.

Um ganz sicher zu gehen, ließ ich GitLab mal einen Selbsttest machen:

sudo gitlab-rake gitlab:app:check

Zunächst sah es ganz gut aus, doch dann brach der Test ab. Auf Postgresql konnte nicht zugeriffen werden, weil unter /tmp keine Socket gefunden wurde. Nach einigem Suche und den Hinweisen, man solle doch einen Symlink erstellen, stieß ich auf das eigentliche Problem.

Postgresql, VServer und der RAM

Scheinbar ist Postgresql standardmäßig so konfiguriert, dass es versucht sich 25% RAM zu reservieren. Was auf VServern schief laufen kann. Ein Blick ins Logfile (/var/log/gitlab/postgresql/current) legte etwas in der Art nahe. Also ab in die GitLab-Config.

GitLab kommt mit einer eigenen Postgresql-Instanz daher und auch mit einer eigenen Config und zwar die zentrale GitLab-Config unter /etc/gitlab/gitlab.rb.

Laut Dokumenation von GitLab sollte man dort postgresql['shared_buffers'] = "100MB" setzen. Das tat ich und Postgresql tat es weiterhin nicht. Die Logausgabe meckerte immer shmmax an. Also mal in der Config geschaut und einen entsprechenden Wert (auskommentiert) gefunden. Ich setzte diesen Wert dann auch noch mal runter: postgresql['shmmax'] = 10179869184

Daraufhin habe ich GitLab wieder rekonfigurieren lassen

sudo gitlab-ctl reconfigure

Und dann auch noch einmal neugestartet, damit Postgresql auch wirklich mitspielt.

sudo gitlab-ctl restart

Ein Blick auf /tmp erfreute mich dann mit der Anwesenheit einer Socket-Datei. Wunderbar. Den Browser aufgerufen und anstatt eines Error 502 nun ein Error 500.

Error 500

Da jetzt alle Dienste laufen, starte ich noch einmal den Selbsttest, in der Hoffnung, diesmal ein wenig mehr Informationen zu bekommen.

sudo gitlab-rake gitlab:app:check

Und siehe da! Die Datenbank muss noch migriert werden.

sudo gitlab-rake db:migrate RAILS_ENV=production

Ein weiterer Test bestätigte, alles grün. Also noch einmal GitLab restarten:

sudo gitlab-ctl restart

Ein Blick in den Browser und es wird ein Loginscreen präsentiert. Auch via Git lässt sich nun wieder pullen und pushen.

Wollen wir hoffen, dass das nächste Update dann etwas entspannter läuft.

Update

Nach einem Server-Restart, bestand das Problem wieder. Wahnsinn. Folgender Beitrag half aber.

Quellen:

https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master#postgres-error-39-fatal-could-not-create-shared-memory-segment-cannot-allocate-memory-39

https://gitlab.com/gitlab-org/gitlab-ce/issues/719

Ich habe ja schon das ein oder andere Mal durchblitzen lassen, ich arbeite gerade an einem kleinen Podcastformat. Dafür habe ich ein Plugin für Kirby geschrieben.

Eigentlich hatte ich mir überlegt, ich setze schnell eine WordPress-Seite auf und installiere ein Podcast-Plugin.

Allerdings habe ich mich dann doch anders entschieden. Das gekaufte Theme war nicht mit dem Podcastplugin kompatibel und eine Menge neuer Sicherheitslücken sprachen dagegen, mal eben schnell und sorgenfrei WordPress zum Podcasten zu nutzen.

Also habe ich umgesattelt und angefangen eine einfache Seite mit Kirby zu bauen. Ich will gar nicht viel Aufwand in die Seite selber stecken, das Kernstück soll der Podcast sein und den werden die Meisten sowieso über einen Podcastclient hören.

Etwas sehr Wichtiges fehlte aber zu meinem Glück, ein passender RSS-Feed, der auch alle wichtigen Felder für iTunes und Co beinhaltet. Ein normaler RSS-Feed tut es da nicht.

Also habe ich mich hingesetzt und angefangen ein Plugin zu schreiben. Das Plugin liefert einen RSS-Feed, wie ich ihn für iTunes brauche und analysiert dabei noch alle MP3-Dateien, die ich zum Post hochgeladen habe. Das heißt Dauer und Größe werden erkannt und an iTunes weitergegeben.

Ich habe lange nach Sublime-Text-Erweiterungen gesucht, die mir beim Schreiben von JavaScript-Code unter die Arme greifen und scheine nun eine gute Kombination von Plugins gefunden zu haben.