Kategorie: Code

Codeschnipsel, Inspirationen, kleine Anleitungen

WordPress mit Docker

Viele Jahre habe ich meine WordPress-Entwicklung mit dem MAMP-Projekt erledigt. Das ganze geht aber auch mit docker und das um einiges einfacher.

Das damp – Projekt liefert genau das und ist beim Aufsetzen einer neuen WordPress-Instanz zum Testen um vieles einfacher. Die Installation und Verwendung wird auf den Seiten ganz gut beschrieben und funktioniert.

Das einzige kleine Problem war, dass WordPress keine Schreibberechtigung auf den wp-content – Ordner hatte. Das merkt man spätestens, wenn man ein Plugin installieren oder aktualisieren oder aber ein Bild in einen Post hinzufügen möchte.

Das Problem hatten auch andere und nach 38 Stunden Internetrecherche hatte mir diese Github-Antwort geholfen. Es kann sein, dass das ein OSX-Problem ist und auf anderen Host-Betriebssystemen gar nicht auftritt. Ohne weiter ins Detail zu gehen wieso und weshalb, ist die Lösung für das Problem relativ einfach.

Man meldet sich auf der WordPress-Maschine an und führt die folgenden Befehle aus und startet die Maschine dann neu:

usermod -u 1000 www-data
chown -R www-data:www-data .

Im Detail geht es so:

Auf einer Konsole wurde damp gestartet.

damp up

Die Docker-Umgebung von damp einstellen

eval $(docker-machine env damp)

Die entsprechende WordPress-Maschine heraussuchen

docker ps

Die Liste mit den Docker-Maschinen-Ids und Namen wird angezeigt.

Nun eine interaktive Shell auf der entsprechenden WordPress-Maschine öffnen

docker exec -it <docker-wordpress-maschine-id> bash

Und dort die magischen Befehle zum Ändern des Besitzers der WordPress-Installation eingeben

usermod -u 1000 www-data
chown -R www-data:www-data .

Nun mit exit wieder von der Maschine abmelden.

Damit die Änderungen nun auch wirksam werden, muss der docker-container neu gestartet werden.

docker restart <docker-wordpress-maschine-id>

Voilá

git zum deployen nutzen

Wenn irgendwann alle Tests für eine Webseite abgeschlossen sind, muss sie auf den Webserver deployt werden. Das erfolgt in der Regel über FTP. Es geht aber auch einfacher, wenn man auf dem Webserver git installiert hat.

Auf dem Webserver wird ein bare-Repository angelegt. In diesem gibt es einen Branch production, der die Produktionsversion der Webseite hält. Nach jedem push in das Repository auf dem Webserver wird der production-Branch automatisch in das Webseitenverzeichnis ausgecheckt.

Das Bare-Repository

Auf dem Webserver wird das leere Repository angelegt.

cd repositories
mkdir webseite.git
cd webseite.git
git init --bare

Das lokale Repository

Als nächstes wird das Bare-Repository in ein lokales Verzeichnis geklont. Der Vorteil ist, dass damit die remotes bereits konfiguriert werden:

git clone ssh://..../webseite.git

Nun kann man erstmal auf dem Repository arbeiten und dann den Arbeitsstand comitten bzw. pushen.

z.B.

git add "index.php"
git commit -m"Initialisierung"

Der Branch production muss noch angelegt werden:

git branch production

Hat man irgendwann einen Produktionsstand erreicht, kann in den Branch production gewechselt werden und der Stand vom master-Branch (oder einem Tag etc.) gemergt werden.

git checkout production
git merge master

Dann wird alles auf den Webserver in das Bare-Repository gepusht.

git push origin master production

Das Repository auf dem Webserver

Zuerst wird das repository in das Verzeichnis geklont. Anschließend wird der aktuelle Stand des production-Branches ausgecheckt.

git clone ../../repositories/webseite.git
cd webseite
git pull origin production

Der Hook

Nun soll genau das automatisch passieren. Dafür gibt es in jedem repository einen post-receive-hook. Hierbei wird die Datei webseite.get/hooks/post-receive nach einem push ausgeführt. Der Inhalt sieht also so aus:

#!/bin/sh

cd ~/webseite || exit
unset GIT_DIR
git pull origin production

Es ist wichtig, dass diese Datei auch als ausführbar markiert ist.

Nach dem Anlegen des Hooks muss noch kontrolliert werden, ob er tatsächlich funktioniert.

Hostname in OSX ändern

Bei einer Neuinstallation von OS X wird der Name des Macs im Netzwerk automatisch festgelegt. Diesen kann man im den Freigabe-Bereich in den Systemeinstellungen ändern. Der Name dort ist aber nur der Anzeigename des Macs im Finder. Den technischen Namen der Arbeitsstation im Netzwerk kann man nur über das Terminal ändern.

Angenommen, der neue Name ist jupiter, dann sind folgende Befehle auf der shell einzugeben:

Den primären Hostnamen ändern:

sudo scutil --set HostName jupiter

Den Bonjour Hostnamen ändern:

sudo scutil --set LocalHostName jupiter

Den im Finder angezeigten Namen ändern:

sudo scutil --set ComputerName jupiter

Zum Schluss kann man noch den DNS cache leeren

dscacheutil -flushcache

An einigen Stellen im Netz wird nun empfohlen, das System neu zu starten.

Arbeiten mit git

Wenn man irgendwo einen Webserver stehen hat, zu dem man ssh-Zugang besitzt, kann man auf diesem auch Git-Repositories anlegen, die man dann lokal als Git-Remote-Repository nutzern kann.

Bare-Repository im Webspace anlegen:

ssh username@hostname
cd
mkdir repositories
mkdir repo-name.git
cd repo-name.git
git --bare init

Anschließend

das Remote-Repository zu einem lokalen Repository hinzufügen:

git remote add origin ssh://username@hostname/~/repositories/repo-name.git

Der Parameter origin ist hierbei der Name des Remote-Repositories. Es ist nämlich möglich, mehrere Remote-Repositories zu einem Git-Projekt hinzuzufügen. Wenn man mit github arbeitet, sollte der Klon von Github immer als origin bezeichnet werden. Für das eigene Remote-Repository sollte man sich dann einen anderen Namen überlegen.

Danach kann der aktuelle Stand gepusht werden:

git push

oder man clont das angelegte Remote-Repository:

git clone ssh://username@hostname/~/repositories/repo-name.git

OSX Fusion Drive

Im bestehenden System sind zwei Platten vorhanden. Eine kleine SSD und eine normale 1TB-Platte. Auf der SSD ist das System installiert und auf der anderen alle Nutzerdaten. Das Nutzerverzeichnis ist mit einem Link auf der SSD eingebunden.

Nach der Anleitung von http://www.macworld.com/article/2014011/how-to-make-your-own-fusion-drive.html die getrennten Platten zu einer verbunden. Das ging nur mit einem extra Lion-Install-USB-Stick, weil die vorhandene SSD die Boot-Platte war, von der auch das Rescue-System gestartet wurde.

Die Programme und das System wurden normal wiederhergestellt. Der Nutzer fehlte aber, weil auf der Quellsicherung die Nutzerdaten auf einem anderen Volume gesichert waren. Mit dem Migrationsassistenten (http://www.macuser.de/forum/f24/dateien-time-machine-529518/) die Übertragung der Nutzerdaten angestartet und nach 10 Stunden waren auch die Nutzerdaten auf dem System. Wie erwartet läuft das System dort weiter, wo ich die letzte Sicherung gemacht habe.

Probleme gab es mit Aperture. Hier hat Aperture für alle Bibliotheken die Vorschaudaten neu erzeugt. Das lief schneller durch als gedacht – wohl weil viele Bilder noch auf der SSD lagen.

Die Vorschau für einige Videos kann nicht erzeugt werden. Das Problem stellt sich auch in Quicklook im Finder dar. Nach einigem Suchen im Netz mit den Konsole-Ausgaben habe ich den Support-Eintrag gefunden: https://discussions.apple.com/thread/4165276?start=30&tstart=0

Danach fehlte die Datei com.apple.xpchelper.cache im Verzeichnis /System/Library/Caches/ . Diese konnte ich aber von einem anderen Mac kopieren. Nach dem Neustart war auch das Problem behoben.

 

String-Funktionen

${var:pos[:len]} # extract substr from pos (0-based) for len
${var/substr/repl} # replace first match
${var//substr/repl} # replace all matches
${var/#substr/repl} # replace if matches at beginning (non-greedy)
${var/##substr/repl} # replace if matches at beginning (greedy)
${var/%substr/repl} # replace if matches at end (non-greedy)
${var/%%substr/repl} # replace if matches at end (greedy)
${#var} # returns length of $var
${!var} # indirect expansion

Quelle

Ein bisschen curl

Irgendeine Datei aus dem Netz laden:

curl $url -O -s

Extrahieren von Text mittels grep aus einer Seite:

curl $url 2>&1 | grep -o -E 'src="([^"#]+)"' | cut -d'"' -f2

Inspiration: http://saikotroid.blogspot.de/2011/07/get-links-from-page-with-bash.html

scuttle und 1und1

Scuttle läuft beim Hoster 1und1 nicht einfach so. Die Systemvariable

$_SERVER['PATH_INFO']

ist nicht gesetzt. Damit kann Scuttle die Pfadparameter, die hinter der php-Datei stehen, nicht auswerten. Statt dessen gibt es die Variable

$_SERVER['ORIG_PATH_INFO']

Die Ursache ist, dass PHP im CGI-Modus läuft und dort die Variable nicht gesetzt sind.
Das Problem wird hier beschrieben und auf verschiedene Arten gelöst.
Die einfachste Lösung für 1und1 ist, eine php.ini – Datei im Scuttle-Verzeichnis mit dem Inhalt

cgi.fix_pathinfo=Off

anzulegen.

1und1 URL file-access is disabled in the server configuration

Diese Fehlermeldung wird in der Regel beim 1und1-Hosting geworfen, wenn ein PHP-Skript versucht, mit

fopen()

auf eine URL zu zugreifen. Man schaltet das mittels einer Datei php.ini temporär ein:

[PHP]
allow_url_fopen = On