Schlagwort-Archive: mysql

Plesk Onyx – ERROR: Zend_Db_Adapter_Exception: SQLSTATE[HY000] [2002] No such file or directory

bitconnect

Für die Entwicklung einiger eigener Plesk Extensions habe ich einen vServer gemietet auf dem ein Plesk Onyx läuft. Neulich gab es da 100 Paket-Updates und ich hab sie mal machen lassen. Kurz darauf der Schreck: Plesk funktionierte nicht mehr. Die Meldung: ERROR: Zend_Db_Adapter_Exception: SQLSTATE[HY000] [2002] No such file or directory. Und nun?

Ich habe im Internet gelesen und versucht. Nichts half. Etwa 10 Minuten nach dem „Update“-Klick wusste ich, das mysql nicht lief. Etwa 30 Minuten später wusste ich was los war:

Ergab:

Es gab also irgendwelche Probleme mit dem Pfad „/var/lib/mysql-files“. Ich habe geprüft was darin ist und wollte schauen ob die Berechtigungen passen… Der Ordner existierte nicht! OK, daran wird es wohl liegen, doch wo bekomme ich den Ordner her und was gehört da rein.

Die Lösung ist simpel

Ganz ehrlich, ich habe das folgende im Netz als Kommentar gelesen und wollte einfach nicht daran glauben dass es wirklich hilft:

Also: Einfach Ordner anlegen, Dateiberechtigungen setzen und schon startet MySQL wieder.

Im Plesk fand ich einen gelben Warnhinweis, dass ein update nicht lief wie geplant und ich doch bitte die Reperatur (link) starten solle. Geklickt, gewartet: Fertig.

ownCloud – „from source“ in Docker Container [owncloud] [docker]

Genesis Mining

Die eigene Cloud-Lösung dank ownCloud ist eine tolle Sache. Ich habe ja so einige Server. Sowohl im „Managed Service“, also bei denen sich professionelle Serveradmins um das System kümmern als auch einige andere, bei denen ich mich selbst drum kümmere (eigene Systeme wie bspw. ownCloud, bei denen es sich aus kostengründen so ergibt).

Ich betreibe unter anderem eine ownCloud Instanz auf einem der Server die ich halt selbst verwalte. Und noch andere Systeme. Was immer wieder schwierig für mich ist: Zugriffsrechte. Ich habe mich damit anscheinend noch nicht ausgiebig genug bei Linux beschäftigt. Daher hat es eine ganze Weile gedauert, bis die ownCloud wie gewünscht lief.

Nun habe ich etwas Sorge gehabt, als ein anderes System auf dem Server PHP 5.6 brauchte. Da ich nicht weiß, wie ich mehrere PHP Versionen parallel betreibe, habe ich einfach von PHP 5.4 auf PHP 5.6 umgestellt. Eben mit der Sorge, dass dadurch andere Systeme ggf. Schwierigkeiten bekommen.

Um solche Sorgen nicht mehr zu haben, möchte ich schon seit langem alle Anwendungen dieses Servers in eigene Docker Container umziehen. Mit Docker habe ich mich hier auf dem Blog schon beschäftigt. Ich finde die Idee von Docker genial und habe ja auch seid kurzem meine eigene private Docker Registry.

Docker Container einrichten

Bevor ich groß mit Dateien hantieren wollte, habe ich die Docker Container aufgesetzt. Dazu schreibe ich mit immer ein anwendung.sh-Bash-Script, also in dem Fall owncloud.sh

Nun vergesse ich nie wieder wie ich diese container konfiguriert habe. Kommt eine neue Version von ownCloud, kann ich einfach oben den Image-Namen ändern und das Script erneut ausführen. Praktisch!

Ich habe das Script ausgeführt und auf meine neue Cloud per http://host:81 zugegriffen. Ich wollte sehen, ob alles funktioniert. Der Installations-Wizard war zu sehen, demnach: Läuft.

Datenbank einspielen

Ein spannender Punkt. Denn ich habe ja, wie oben im Script zu erkennen, einen Docker Container für MySQL eingerichtet. Wie bekomme ich da jetzt also die Datenbank rein?

Ich habe mich dazu entschieden, ein SQL-File zu exportieren und dieses in das Docker Volume zu schieben sowie die Berechtigungen richtig zu setzen.

Nun konnte der Datenbankimport stattfinden, vorher muss natürlich erst eine neue DB angelegt werden. Beides geht in jeweils einem einzigen Aufruf:

Konfiguration übernehmen

Nachdem nun die Datenbank steht, muss natürlich die neue ownCloud-Installation mit der Datenbank verbunden werden bzw. generell die ganze Konfiguration übertragen werden.

Damit allerdings nicht getan, die Konfiguration muss geprüft werden. Denn es hat sich zumindest der Datenbank-Host geändert. Die Datenbank findet man nun nicht mehr auf „localhost“, sondern über den Host „mysql“ (siehe Docker Link im Installationsscript).

Daten übernehmen

Tja und als letzter Schritt fehlt nur noch, die Daten zu übernehmen.

Nun ist meine neue ownCloud-Installation Testbereit.

ownCloud umschalten

Nach den Tests kann ich den vHost im Apache des Server einfach als Redirect auf den Port 81 (siehe Port-Mapping im Docker-Script) konfigurieren. Dann ist automatisch meine schöne URL nutzbar, der Apache fungiert in dem Moment einfach als Proxy.

In meinem Fall ist wie gesagt ein Apache im Einsatz, das ganze lässt sich natürlich mit nginx auch realisieren. Diesen habe ich allerdings noch nicht oft eingesetzt und habe hier also zu einem vertrauten Mittel gegriffen.

Und schon kann ich meine Cloud über den Browser aufrufen und bedienen.

GitLab – Von 7.14.3 „from source“ und MySQL nach 8.0.5 als Docker-Container mit PostgreSQL

Bitpetite

Heute gehen wir zusammen mal durch, was ich alles unternommen habe um mein GitLab 7.14.3 auf ein GitLab 8.0.5 zu aktualisieren. Nebenbei habe ich MySQL verlassen und auf PostgreSQL migriert (empfohlen durch GitLab selbst). Zusätzlich läuft mein neuer GitLab dann in einer Docker-Umgebung. Aber erstmal von Anfang an.

GitLab – Ich liebe Quellcodes

Als Entwickler arbeite ich mit Quellcodes. Und das mache ich sehr sorgfältig. Ich kenne derzeit keinen Web-Entwickler der so vorgeht wie ich #selbstlobstinkt 😉

Und ein wichtiger Teil meiner Strategie ist GitLab und GitLab CI. Was genau diese beiden Tools sind, werde ich in einem anderen Artikel behandeln.

Backups – Nichts ist sicher

Wichtig ist den gesamten Prozess über immer ein Backup parat zu haben. Denn nichts ist sicher!

Aktuelle GitLab-Instanz aktualisieren

Da Backups nur in „passende“ GitLab-Systeme integriert werden können, hat man zwei Möglichkeiten:

  1. Erst auf GitLab 7.14.3 in einem Docker-Container umsteigen und dann diesen aktualisieren
  2. Erst auf GitLab 8.0.5 aktualisieren und dann auf den Docker-Container umsteigen

Da ich keinen funktionierenden Docker-Container für GitLab 7.14.3 gefunden habe, habe ich Variante 2 genommen. Dazu gibt es eine Update-Anleitung, diese hat bei mir funktioniert. Was danach nicht mehr ging waren Push oder Pull-Anfragen. Das habe ich aber ignoriert. Ich war schließlich eh dabei, diese GitLab-Instanz zu löschen.

Ich habe also nochmal ein Backup durchgeführt, jetzt nämlich für GitLab 8.0.5.

Auf PostgreSQL migrieren

In den GitLab-Backups ist ein Dump-File der Datenbank hinterlegt. Also in unserem Fall aktuell ein MySQL-Export. Dieser muss migriert werden.

Es gibt dafür ein Tool, welches MySQL-Dumps nach PostgreSQL migriert, das wusste ich bereits. Allerdings hat es nicht geklappt als ich es händisch gemacht habe. Praktischerweise hat GitLab selbst dieses Tool weiter modifiziert sodass es derzeit gut möglich ist, die Migration durchzuführen. Hier lest ihr wie ein GitLab Backup mit MySQL zu einem GitLab Backup mit PostgreSQL migriert wird.

GitLab Docker-Instanzen starten

Ich habe nicht das offizielle GitLab-Docker-Image genommen, sondern die Images von sameersbn. In dem Repository gibt es viele Images, hier kommt ihr zu den Docker GitLab Images.

Der Quick-Start dort ist sehr gut dokumentiert. Ich habe nur Step 3 Launch the GitLab Container angepasst:

Daten wiederherstellen

Nun bleibt nur noch das migrierte Backup in das Backup-Verzeichnis vom Docker-Container zu schieben (bei mir halt /srv/docker/gitlab/gitlab/backups/) und schon kann der Restore beginnen.

Ich bin dazu in die Shell des Docker-Container gewechselt, das geht über

Und dort habe ich gitlab dann angewisen das Backup wiederherzustellen

Das ‚ts‘ bei „BACKUP=ts“ müsst ihr durch den Timestamp ersetzten, der als Prefix im Backup-Dateinamen gesetzt wurde.

GitLab 8.0.5 läuft jetzt im Docker-Container

Und schon haben wir es geschafft. Unser GitLab läuft jetzt in dem Docker-Container. Die Daten wurden vollständig migriert. Ich konnte mich einloggen.

Ein sau gutes Gefühl endlich ein vom restlichen System abgekapseltes GitLab zu haben welches sauber installiert ist. Keine großen Schwierigkeiten mehr. Echt der Hammer 🙂