ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://kleine-photo-com.docker:9000/usr/src/myapp/$1

Soweit, so gut. Apache läuft bei mir übrigens nicht in einem Container. Warum eigentlich nicht? Könnte ich mir auch noch überlegen.

Jedenfalls habe ich dann das Problem, dass mein Host diese Domain nicht auflösen kann! Also habe ich anfangs die einzelnen Seiten in die etc/hosts eingetragen. Blöd ist dabei nur, dass die IPs natürlich rotieren können, sobald der Server mal neugestartet wird. Also habe ich plötzlich andere Inhalte hinter den Domains – extrem nervig. Das ist mir jetzt 2x passiert und nun habe ich mich mit einer Lösung beschäftigt. Am einfachsten war dabei für mich der Weg über einen weiteren Docker-Container für DNS.

docker run -itd --restart=always --hostname dns.docker --name dns-proxy-server -p 5380:5380 -v /var/run/docker.sock:/var/run/docker.sock -v /etc/resolv.conf:/etc/resolv.conf defreitas/dns-proxy-server

Nun werden alle DNS-Anfragen in den Container gejagt. Außerdem werden nun die Hostnamen der Docker-Container richtig aufgelöst und alles funktioniert wunderbar wie ich mir das vorgestellt habe. Sobald man den Container stoppt ist übrigens wieder alles wie vorher. Also kein Risiko. Danke restart=always wird der Container also nun auch immer brav mitgestartet und alles überlebt ebenfalls einen Neustart des Servers. Puh, das war einfacher als ich dachte!

Nun bin ich kein Sysadmin, sondern Softwareentwickler. Daher lese ich mir solche Themen immer an und bin froh, dass es so einfache Lösungen wie diese gibt. Wenn Du eine bessere oder einfachere Idee hast: Immer her damit!

Attempted to open a previously opened tablespace. Previous tablespace mysql/slave_relay_log_info uses space ID

Nicht cool, immerhin startet mySQL dann gar nicht mehr. Meine Datenbanken hatte ich schon fast abgeschrieben. Auch, wenn es nur Entwicklungsdatenbanken sind, wäre ein Verlust doch extrem ärgerlich. Also ein wenig recherchiert und schnell auf die Lösung gekommen. Diese nennt sich „innodb_force_recovery“.

Dazu öffnet man einfach die my.cnf und fügt irgendwo unter [mysqld] den folgenden Eintrag ein:

innodb_force_recovery = 1

Je höher der Wert gesetzt wird, desto wahrscheinlich ist es, dass die Datenbanken kaputt gehen! Also auf jeden Fall mit 1 starten.

Danach startet man mySQL. Sollte das klappen, wird der Dienst sofort wieder gestoppt und der Wert aus der Konfiguration entfernt. Danach kann mySQL erneut gestartet werden.

In meinem Fall war das Problem damit aus der Welt.

Weitere Details gibt es hier. Dort kann man auch nachlesen was die einzelnen Level genau tun.

Also musste eine andere Lösung her. Diese nennt sich in diesem Konkreten Fall dblib. Hiermit können über PDO dann Datenbankverbindungen zu MSSQL aufgebaut werden. Unter Linux / Ubuntu war das Ganze relativ schnell eingerichtet. Jetzt mussten wir es nur noch unter Mac OS X zum laufen bekommen, um lokal auch entsprechend entwickeln zu können.

Als Basis dient hier FreeTDS, welches die grundlegende Datenbankverbindung dann öffnet. Dblib ist dabei „nur“ eine PHP-Extension, welche entsprechend mit FreeTDS kommuniziert. Soweit so gut.

brew install freetds

Dazu hatte ein Arbeitskollege die Idee, PHP7 mit brew zu installieren, welches die entsprechende .so-Datei ebenfalls enthielt. Obwohl ich lokal unter MAMP noch auf Version 7.0.15 bin, konnte ich die .so-Datei von 7.0.19 nutzen. Diese wurde dann in das richtige Verzeichnis unter MAMP gelegt und in der php.ini geladen. Danach konnte die erste DB-Verbindung auch schon aufgebaut werden.

[mysqld-auth]
enabled = true
logpath = /var/log/mysql/error.log

Und den Filter musste ich wie folgt anpassen:

failregex = ^%(__prefix_line)s(\d{6} \s?\d{1,2}:\d{2}:\d{2} )?\[Warning\] Access denied for user '\w+'@'<HOST>' (to database '[^']*'|\(using password: (YES|NO)\))*\s*$
            ^%(__prefix_line)s(?:\d+ |\d{6} \s?\d{1,2}:\d{2}:\d{2} )?\[\w+\] Access denied for user '[^']+'@'<HOST>'

Die erste Zeile habe ich dabei nicht angefasst, sondern nur die zweite hinzugefügt. Statt einer Warning erscheint bei mySQL 5.7 nur noch „Note“. Der reguläre Ausdruck ist natürlich relativ allgemein, aber funktioniert für mich wunderbar. Endlich werden die ganzen Login-Versuche auf root entsprechend geblockt.

Testen kann man das ganze wie folgt:

fail2ban-regex /var/log/mysql/error.log /etc/fail2ban/filter.d/mysqld-auth.conf

Bei mir sieht die Ausgabe nun so aus:

Lines: 492 lines, 0 ignored, 54 matched, 438 missed [processed in 0.07 sec] 
Missed line(s): too many to print.  Use --print-all-missed to print all 438 lines

Sieht also sehr gut aus!

Die Lösung dafür ist relativ einfach – man darf die Regeln nur nicht als INPUT definieren, sondern muss diese für Forward definieren. Damit Ihr ein etwas leichteres Leben habt, habe ich eine neue Action geschrieben, welche ganz einfach angewendet werden kann:

[INCLUDES]

before = iptables-common.conf

[Definition]

actionstart = <iptables> -N f2bd-<name>
              <iptables> -A f2bd-<name> -j <returntype>
              <iptables> -I FORWARD -p <protocol> -m multiport --dports <port> -j f2bd-<name>

actionstop = <iptables> -D FORWARD -p <protocol> -m multiport --dports <port> -j f2bd-<name>
             <iptables> -F f2bd-<name>
             <iptables> -X f2bd-<name>

actioncheck = <iptables> -n -L FORWARD | grep -q 'f2bd-<name>[ \t]'

actionban = <iptables> -I f2bd-<name> 1 -s <ip> -j <blocktype>

actionunban = <iptables> -D f2bd-<name> -s <ip> -j <blocktype>

[Init]

blocktype = DROP
chain = FORWARD

Für alle Jails, welche für Docker-Container gelten, verwende ich als „banaction“ nur eben diese. Funktioniert bisher einwandfrei!

Also musste der Apple-Support helfen. Anfangs dachte ich nicht, dass das Problem für den Support so ohne weiteres lösbar sei, aber ich habe mich geirrt. Die Schritte lauten wie folgt (für MacOS Sierra 10.12.1):

• Unter id.apple.com mit der aktuellen E-Mail anmelden und das entsprechende Gerät löschen (in diesem Fall ein MacBook Pro 15″).
• Danach ein paar Dateien auf dem Mac löschen (siehe unten)
• Unter Systemkonfiguration / iCloud mit den neuen Daten anmelden
• Rechner einmal zur Sicherheit neustarten

Diese Dateien und Verzeichnisse müssen gelöscht werden (<Benutzername> muss natürlich durch Euren Account-Namen auf dem Mac ersetzt werden):

rm /Users/<Benutzername>/Library/Preferences/com.apple.accounts.plist
rm /Users/<Benutzername>/Library/Preferences/com.apple.accountsd.plist
rm /Users/<Benutzername>/Library/Preferences/com.apple.icloud.fmfd.notbackedup.plist
rm /Users/<Benutzername>/Library/Preferences/com.apple.icloud.fmfd.plist
rm /Users/<Benutzername>/Library/Preferences/com.apple.identityservicesd.plist
rm -rf /Users/<Benutzername>/Library/Application\ Support/iCloud

Oder alternativ auch über den Finder. Dazu den Finder öffnen, mit gedrückter ALT-Taste auf „Gehe zu…“ klicken und dann „Library“ auswählen. Danach die Dateien aus der Liste oben löschen (bitte keine anderen und wirklich nur die genannten). Bei dem letzten Eintrag handelt es sich um ein Verzeichnis.

Das alles ist natürlich ohne Gewähr (wenn auch vom offiziellen Apple-Support so für unseren Fall vorgeschlagen).

Testen kann man dies wie folgt:

openssl s_client -connect repo.magento.com:443 -tls1_2 # Verbindung wird aufgebaut
openssl s_client -connect repo.magento.com:443 -tls1_1 # Verbindung wird aufgebaut
openssl s_client -connect repo.magento.com:443 -tls1   # Verbindung fehlgeschlagen!

Dass das nicht erfüllt werden kann, sieht man in er phpInfo hier:

• SERVER_SOFTWARE Apache/2.2.29 (Unix) mod_wsgi/3.5 Python/2.7.10 PHP/5.6.10 mod_ssl/2.2.29 OpenSSL/0.9.8zh DAV/2 mod_fastcgi/2.4.6 mod_perl/2.0.9 Perl/v5.22.0
• Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, sslv2, tls, tlsv1.0

php -i | grep "Registered Stream Socket Transports"

Nun habe ich gelernt, dass man mindestens folgende Versionen braucht, damit das überhaupt irgendwie klappen könnte:

• PHP 5.6
• OpenSSL 1.0.1

Ersteres ist ja eh schon gegeben, aber der zweite Teil ist etwas schwieriger. Gelöst habe ich es (wie so oft) mit brew:

brew update
brew install openssl
brew link --force openssl

Wenn alles richtig gemacht wurde, sieht die Version nun so aus:

openssl version
OpenSSL 1.0.2h  3 May 2016

(oder eben neuer)

Folgende Bemühungen waren danach erfolglos:

• cURL für MAMP in einer neueren Version neu bauen (das hat zwar geklappt, löst aber das Problem in composer nicht)
• PHP mit openssl shared bauen (wie schon einmal beschrieben) – das klappt zwar zu bauen, aber da das Binary in MAMP mittlerweile inklusive OpenSSL gebaut wird, kann die Version nicht einfach über eine Extension ausgetauscht werden

Die Lösung

Ich habe mir nun einfach AMPPS installiert, welches ich nutze um die composer Updates auszuführen. Die zusätzlichen 1,7 GB auf der Festplatte sind zwar etwas übertrieben für das Problem, dafür kann ich alles wieder ohne Probleme löschen wenn endlich MAMP 4 mit einer neueren OpenSSL-Version released wird. Am Ende sprechen wir hier also von wenigen Wochen.

AMPPS muss dazu noch etwas konfiguriert werden.

Als erstes muss in die php.init der folgende Eintrag geschrieben werden:

openssl.cafile=/usr/local/etc/openssl/cert.pem

Sonst klappt es nach wie vor nicht!

Dann müssen noch einige PHP-Extensions aktiviert werden – ich schreibe hier einfach mal eine Liste von allen Extensions auf, welche in meiner Installation nun aktiv sind:

• bz2
• ctype
• curl
• gd
• iconv
• intl
• mbstring
• mcrypt
• mysql
• mysqli
• openssl
• pdo_mysql
• pdo_sqlite
• soap
• sockets
• sqlite3
• tokenizer
• xsl
• zip
• zlib

Solltet ihr davon eine vergessen, wird euch aber composer auf jeden Fall darauf hinweisen.

So, damit ich aber nicht alles auf AMPPS neu einstellen muss, möchte ich es nicht für den Entwicklungsprozess nutzen. Also bleibe ich bei MAMP und meinem mySQL usw. Das hat den Vorteil, dass ich nichts großartig transferieren muss. Also nutze ich ausschließlich das enthaltene PHP für ein composer update.

Damit das etwas einfacher wird, lege ich mir einen Alias in meiner .bash_profile an:

vi ~/.bash_profile
alias phpamps="/Applications/AMPPS/php-5.6/bin/php"

Jetzt kann ich es verwenden, um wie gewohnt meine Composer-Quellen zu aktualisieren:

phpamps composer.phar update

Ein ganz schöner Umweg, welcher mich viel Zeit gekostet hat! Nur, weil Magento TLS 1.0 bei einem Open-Source Projekt für nicht mehr sicher genug hält. Danke an dieser Stelle.

phpamps -i | grep "Registered Stream Socket Transports"
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls, tlsv1.0, tlsv1.1, tlsv1.2

Und schon ist alles da.