Kategorie-Archiv: Betriebssysteme

Docker-Container per DNS auflösen

Ich habe auf meinem Root-Server alle in Docker-Containern laufen. Also WordPress für mehrere Webseiten. Alles PHP-FPM. Jetzt starte ich meine Docker-Container alle mit einem entsprechenden Hostnamen. Also meistens so wie die Domain heißt plus „.docker“. Also zum Beispiel „klein0r-de.docker“. Dieses Ziel gebe ich dann in meinem Apache für ProxyPathMath an.

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.

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!

mysql Fehler – attempted to open a previously opened tablespace

Heute wollte ich ganz normal meine MAMP-Instanz starten um lokal weiter an meinem Magento 2 Shop zu arbeiten. Dabei konnte mySQL leider nicht gestartet werden. Im log stand dann der folgende Eintrag.

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:

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.

Mit PHP7 auf MSSQL-Datenbanken zugreifen unter Mac OS X & MAMP

Wie der Titel schon sagt, hatte ich vor kurzem die Herausforderung, auf eine MSSQL-Datenbank zugreifen zu dürfen. Unter PHP5 war das Ganze relativ mit dem Paket php5-mssql möglich (außer unter Mac OS X). Mit PHP7 ist das mssql-Paket entfallen und wird nicht mehr entwickelt.

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.

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.

fail2ban und mysql 5.7 – Filter funktioniert nicht direkt

Normalerweise legt man einfach eine neue Datei nach /etc/fail2ban/jail.d/mysql.conf, aktiviert das richtige Jail und schon funktioniert alles. Leider nicht so im Falle von mysql 5.7 – scheinbar hat sich da der Logeintrag etwas geändert. Meine Datei sieht jetzt so aus:

Und den Filter musste ich wie folgt anpassen:

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:

Bei mir sieht die Ausgabe nun so aus:

Sieht also sehr gut aus!

Fail2Ban und Zugriff auf Docker-Container

Ich hatte heute das Problem, dass Fail2Ban (läuft auf dem Host) zwar munter Regeln in den iptables angelegt hat, aber die Regel keine Wirkung auf alle weitergeleiteten Ports der Docker-Container hatte.

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:

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

iCloud-Einstellungen auf dem MacBook ohne Passwort löschen

Nachdem meine Freundin ihre Apple-ID (die Mailadresse) geändert hatte, ohne sich zuvor auf dem MacBook unter iCloud abzumelden, waren wir in einer Patt-Situation. Denn um sich dort abzumelden muss man das Passwort der aktuellen/alten Apple-ID eingeben (welche es nicht mehr gibt). Also klappt das abmelden praktisch nie und man bekommt immer die Meldung, dass die Emailadresse oder das Passwort nicht korrekt seien.

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):

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).

Magento2 Composer Update: Failed to enable crypto

Wie mittlerweile bekannt sein sollte, entwickle ich Magento2 ebenfalls auf einem Mac unter MAMP (3.5) mit PHP 5.6 und PHP 7. Das lief auch alles wunderbar, bis Magento auf ihrer eigenen Repo-Source (https://repo.magento.com/) sich dazu entschlossen hat, TLS 1.0 nicht mehr zu unterstützen. Somit kann man nun mit einem älteren PHP nicht mehr auf die Systeme zugreifen, da keine Verbindung aufgebaut werden kann.

Testen kann man dies wie folgt:

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

Weiterlesen…