TeamSpeak Server in unter 5 Minuten [teamspeak] [docker]

TeamSpeak Server in unter 5 Minuten. Alles was man dafür benötigt ist irgendeinen (v)Server, da können auch bereits andere Applikationen drauf laufen.

Um mit anderen Applikationen nicht in Konflikt zu kommen empfehle ich den Einsatz von Docker. Ich selbst nutze Docker immer mehr, da es die einzelnen Applikationen eines Servers kapselt sodass sie sich gegenseitig nicht beeinflussen.

Mit folgenden zwei Zeilen startet ihr euren Server:

Ihr könnt euch dann direkt per Client auf euren Server verbinden und mit der finalen Konfiguration beginnen.

Die wichtigen Dateien wie die sqlite-DB oder die Logs werden dabei unter /srv/docker/teamspeak abgelegt.

ownCloud-Docker-Image Update-Prozess

ownCloud Update 8.1 zu 9.1 [owncloud] [docker]

Man was war das für ein Abend neulich… Eigentlich wollte ich „nur“ von ownCloud 8.1.10 auf 9.1.3 aktualisieren. Dank Docker sollte das recht simpel sein. Da ich mir schon gedacht habe, dass es holprig wird, bin ich von Version zu Version gegangen. Erst auf Version 8.2.9 und dann auf 9.0.7, hier fingen dann die Probleme an. Während das Update ohne Fehler durchlief, konnte ich mich nicht mehr einloggen. Im Log laß ich dann: Base table or view not found: 1146 Table ‚oc_external_mounts‘ doesn’t exist

Fehler nach Update auf ownCloud 9.0.7

Na Klasse, da existiert irgendeine Tabelle nicht. Nach kurzem Googlen wusste ich dann, dass es an der App files_external liegt. Da ich diese meines Wissens nach nicht verwende, habe ich sie deaktiviert

Und schon konnte es weitergehen. Der letzte Schritt wäre jetzt ja sicher einfach getan, denn von Version 8.2.9 auf 9.0.7 wäre sicher ein größerer Sprung, als von 9.0.7 auf 9.1.3… Pustekuchen.

Fehler nach Update auf ownCloud 9.1.3

Direkt beim Update eine fette Meldung: Call to undefined method OCA\Federation\AppInfo\Application::setupCron() in /var/www/html/apps/federation/appinfo/update.php on line 23

Nach einigem Suchen bin ich darauf gestoßen, dass ein Update der Cloud im Docker doch nicht immer so ohne Aufwand aktualisiert werden kann. Kurzum: der apps-Ordner, der über ein Mapping eingebunden wird, muss halt mit den neuen Apps aus Version 9.1 gefüllt werden.

Nun sind die neuen Apps verfügbar und die Exception der federation-App sollte nicht mehr fliegen.

Bei mir lief das Update dann sauber durch, warum auch immer wurde der Maintenance-Mode aber aktiv gelassen.

Nach ca. einer Stunde war also alles aktualisiert und es läuft auch prima. Die Daten sind alle da, die User-Zugänge sind unverändert und die geteilten Inhalte sind ebenfalls noch da. Zusätzlich sind die Share-Links erhalten geblieben.

Docker statt vServer – Wie ich 770GB verloren habe

Ich habe vServer gemietet. Das ist eine tolle Sache. Dort kann ich tun und lassen was mir beliebt. Doch nicht für jeden Anwendungsfall muss gleich ein vServer her. Denn es gibt inzwischen Docker, dort entfällt eine Menge overhead, den so ein vServer mit sich bringt.

Ich habe ja den ein oder anderen Server und auch ein paar vServer. Damit ich vor Datenverlusten geweiht bin, habe ich einen Server dafür gemietet, sich um Backups zu kümmern. Die Anforderungen an diesen Backup-Server: Massiv Speicherplatz, möglichst günstig. Und so endete es in einem Server der mit 100Mbit Anbindung nicht der schnellste, aber mit 2x2TB (bewusst ohne RAID) viel Speicher hatte und günstig war. Da ich für Kunden ebenfalls Server sichern wollte habe ich mich vor über einem Jahr auf diesem Server dazu entschieden, zwei vServer aufzusetzen. Beide lediglich mit Backuppc ausgestattet. Und jeder vServer hatte seine eigene Festplatte. So konnte ich den Speicherbedarf gut regeln. Ich behaupte nicht dass dies die einzige Lösung ist/war aber es ging schnell und funktionierte.

Nun hat eine Festplatte defekte Sektoren bekommen und musste getauscht werden. Ich habe also den betroffenen vServer gestoppt und seine VDI auf einen anderen Server übertragen, was bei 770GB und der schwachen Anbindung etwa 30 Stunden dauerte. Dann wurde die Festplatte getauscht und ich habe die VDI wieder zurückgespielt (also nochmal etwa 30 Stunden). Resultat: Der vServer ließ sich nicht mehr booten. Die Datei ist beschädigt gewesen, sicherlich folgend aus den kaputten Festplattensektoren. Demnach: 770GB Datenmüll. Es ist nicht dramatisch, es handelte sich lediglich um ein Backup anderer Daten, die ja weiterhin auf ihrem Server lagen und funktionierten.

Ich hatte schon länger darüber nachgedacht, die zwei vServer zu deaktivieren und hier Docker in den Einsatz zu nehmen um beide Backuppc-Instanzen zu betreiben und auf die zwei verschiedenen Festplatten zu schreiben. Ich hatte nur nie einen Anlass dazu. Nun hatte ich bedarf und habe mich rangesetzt.

Fazit: Es läuft prima. Doch was ist jetzt der Unterschied?

Docker vs. Virtualisierung

Ich möchte darauf hinweisen, dass ich kein Virtualisierungs-Profi bin. Ebenso bin ich auch kein Docker-Profi. Ich habe konkrete Anwendungsfälle und benutzte dann eine passende Technik. Sobald es läuft und ich die Situation als „stabil“ einschätze, bin ich zufrieden.

Für mich gibt es zwischen Docker und Virtualisierung in dem obigen Beispiel einen gravierenden Unterschied: Durch das defekte VDI-File, habe ich nun 770GB Daten verloren. Mit Docker hätte ich sicherlich auch Daten verloren, aber eben nur jene, die in den entsprechenden Sektoren gespeichert wurden. Es ist davon auszugehen, dass ein Großteil der Daten erhalten geblieben wäre.

Ein weiterer Punkt ist das Thema Sicherheit: Ich habe natürlich quasi nie die vServer aktualisiert. Auch den Host nicht. Ich hatte einfach schiss, dass dann vbox nicht mehr startet oder irgendwas auf den vServern nicht mehr läuft. Demnach hatte ich einen Host und zwei vServer die potenziell angreifbar wären oder um die ich mich hätte potenziell kümmern müssen.

Nun mit Docker habe ich nur noch den Host. Die Container haben keine Möglichkeit den Host anzugreifen und die Container sind von außen lediglich über einen einzigen Port erreichbar. Mit jedem Update von Backuppc wird ein neues Image bereitgestellt, welches wiederum auf einem aktualisierten Linux-Image beruht und somit werden „Systemupdates“ implizit mit dem aktualisieren des Images eingespielt. Den Host werde ich fortan aktualisieren, ich betreibe einige Docker-Hosts und habe bisher noch nie erlebt, dass es zu einem Problem innerhalb eines Docker-Container kam, dadurch dass ich den Host aktualisiert hätte…

Einfache Wartung: Ich habe ein Script geschrieben welches beide Docker-Instanzen gleichzeitig verwaltet. Ich gebe in dem Script das Basis-Image und einige weitere Parameter an. Und dann kann ich mein Script aufruren und ein Update ausführen, die Container stoppen / starten oder in die Logs schauen. Alle Aktionen werden dann auf beiden Containern ausgeführt. Das ist praktisch und spart Zeit.

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

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]

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.