WordPress “Nativ-Installation” nach Docker Container umziehen

Nachdem ich nun meine WordPress Docker Container am laufen habe, ist es an der Zeit meine alten WordPress-Installationen umzuziehen. Der Use-Case ist simple:

  • Die WordPress-Installation, welche bisher “nativ” auf www.meinedomäne.ch lief soll nun neu vom neu erstellen Docker-Container beliefert werden.

Das Umziehen einer bestehenden WordPress-Installation war kniffliger als erwartet. Auf diesem Wege hat es dann für mich funktioniert:

  • Als Erstes einen Docker-Container erstellen. Siehe hier. Wichtig war, dass der Container erst ohne die SSL-Erweiterung (inkl. wpinit.sh und apache2vhosts.conf) gestartet wurde.
  • Das so erstellte Image ist nun über http://lokaleIp:port erreichbar.
  • Nun die Installations-Routine von WordPress durchlaufen.
  • Nun auf der WordPress-Installation, welche umgezogen werden soll, das Plugin “All-in-One WP Migration” installieren und damit die WordPress-Export (in ein File) erstellen.
  • Nun wieder auf die Docker-Wordpress Installation wechseln, auch hier das Plugin “All-in-One WP Migration” installieren und anschliessend einen WordPress-Import aus dem erstellten File durchführen.
  • Damit sollte der Umzug schon erledigt sein.
  • Ich habe dann noch das Plugin “SSL Insecure Content Fixer” installiert um sicherzustellen, dass die noch folgende SSL-Aktivierung sicher funktioniert => Das ist evtl. aber gar nicht nötig…
  • Nun Kann die Docker-Instanz gestoppt und wpinit.sh und apache2vhosts.conf im yml-File aktiviert werden. Anschliessend die Docker-Instanz wieder starten:
    docker-compose down
    --- Änderung an yml-File vornehmen (wp-init.sh und apache2-vhosts.conf) ----
    docker-compose up -d

    Damit ist nun auch SSL aktiviert, so dass der Docker-Container über SSL die Seite ausliefert.

Umgebungsvariablen und Alias

Userspezifisch

Aliase und Umgebungsvariablen können spezifisch pro User festgelegt werden. Hierzu verwendet man das ‘.bashrc’ File im eigenen Home-Verzeichnis:

Alias/Umgebungsvariable

vi ~/.bashrc

Neue Zeile

alias ll='ls -l'

einfügen

ll wird nun den Befehl ls -l im Terminal ausführen.

Auf diese Art und Weise können Umgebungsvariablen (z.B. JAVA_HOME) gesetzt werden:

JAVA_HOME=/usr/lib/JDK1.5
export JAVA_HOME

Global

Um globale Aliase und Umgebungsvariablen zu setzen, hat man mehrere Möglichkeiten:

  • /etc/profile
  • /etc/bash.bashrc
  • /etc/environment
  • Wrapper-Skript

 

/etc/profile

Dieses File ist dann der richtige Ort, wenn man von der Console bootet und das GUI (Gnome/KDE) über startx aufruft. Das /etc/profile wird also auch dann gelanden, wenn kein Window-Manager gelanden wird.

/etc/bash.bashrc

Dieses File ist dann der richtige Ort, wenn man direkt per “Login-Manager” grafisch einloggt. Man darf aber nicht vergessen, dass dieses File ignoriert wird, sobald man ein weiteres Terminal (per Alt-F?) öffnet.

/etc/environment

Hier kann man statische Variablen definieren, die für das ganze System von Interesse sind. Als Beispiel werden hier alle Umgebungsvariablen für die Programmiersprache Java definiert, die sowohl für das Ausführen als auch die Entwicklung von Java-Programmen nötig sind. Die Variable PATH kann man auch in

/etc/environment

definieren, sie wird aber in der Regel von der Shell wieder überschrieben. Somit ist es besser, PATH in der Datei

/etc/profile

zu definieren und gegebenenfalls über die benutzerspezifischen Dateien

${HOME}/.bash_profile

(Login-Shell) und

${HOME}/.bashrc

(interaktive Shell) anpassen.

Wrapper-Skript

Es kursiert in der Debian-Welt die Idee, dass Umgebungsvariablen für das Starten eines Programmes nicht nötig sein sollten. Aus diesem Grunde wird oft ein so genanntes Wrapper-Script erstellt, welches die nötigen Variablen setzt und danach das eigentlich gewünschte Programm aufruft. Das kann z.B. folgendermassen aussehen:

#!/bin/sh
export JAVA_HOME=/wo/auch/immer
exec $0.real "$@"

Das speichert man unter dem Namen nachdem das effektive ‘PROGRAMM’ zu ‘PROGRAMM.real’ umbenannt worden ist. Danach noch das execute-Falg setzen:

chmod +x PROGRAMM

 

StartSSL: Gratis-Zertifikat erstellen

Artikel ist deprecated: Siehe neu Let’s encrypt

———————————————————————

Wenn man seinen eigenen Web-Server betreibt, möchte man meist auch über https (SSL/TLS) gesicherte Verbindungen aufbauen. Es gibt dabei mehrere Varianten, wie man vorgehen kann. Folgendes Tutorial zeigt schön auf, welche es gibt und wann welche Variante Sinn macht:

https://workaround.org/ispmail/wheezy/tlsifying-your-server

Ich habe mich für die dritte Variante “Kostenloses Zertifikat von StartSSL” entschieden. Das Zertifikat kostet nichts und sollte von den meisten Browsern als vertrauenswürdig anerkannt werden: Continue reading

SSL Zertifikat für Apache Web-Server

Erstellen eines SSL Zertifikats für Apache Web-Server (self-signed)

Self-Signed Ab Ubuntu Server (2011)

Script laufen lassen (–force-overwrite verwenden, falls schon ein Zetifikat besteht):

sudo make-ssl-cert generate-default-snakeoil --force-overwrite
sudo /etc/init.d/apache2 restart

Über Zertifizierungsstelle

Siehe hier