Technisches und Persönliches

Monat: Februar 2020

Mehrfaches Umbenennen unter Linux mit mmv

Im Rahmen der Migration eines WordPress.com Blogs auf meinen eigenen Webserver kam ich kürzlich an den Punkt, viele Bilder auf einmal umbenennen zu wollen.

Unter MS-DOS gab es dafür den guten alten Befehl rename der zum Beispiel solche Operationen ermöglichte:

C:\> RENAME *.TXT *_OLD.TXT

Dabei matcht MS-DOS den Platzhalter im ersten Ausdruck mit den vorhandenen Dateien und benennt sie dann gemäß dem zweiten Ausdruck um. Alle Textdateien erhalten also im Namen die Erweiterung _OLD. Das klappt natürlich auch entsprechend in umgekehrter Richtung:

C:\> RENAME *_OLD.TXT *.TXT

Nun sind meine MS-DOS Zeiten lange vorbei und ich brauchte etwas Vergleichbares unter Linux um durch WordPress erzeugte Bilder im Format *-scaled.jpg zu *.jpg umzubenennen.

WordPress.com Migration

In der Vergangenheit habe ich verschiedene kleinere Blog-Projekte gestartet und teilweise schnell wieder eingestellt. Manche sind aber auch geblieben und mit der neuen Website-Initiative finde ich es lohnenswert diese auf meine Domain zu übernehmen.

Normalerweise würde man hier alle Dateien und die Datenbank entsprechend kopieren und kann so seine Konfiguration relativ einfach übernehmen. Da ich die Blogs jedoch über WordPress.com angelegt habe, ist ein Zugriff auf die Dateien und die Datenbank nicht so ohne weiteres möglich.

Statt dessen nutze ich die Exportfunktion von WordPress und möchte am Beispiel eines Reiseblogs für meine Italienreise 2019 zeigen, wie man dabei vorgeht und über welche Stolpersteine ich gestoßen bin.

SSL-Browserwarnungen unterdrücken

Wie zuletzt beschrieben, funktioniert das lokale SSL nun grundsätzlich. Aber im Browser bekommt man beim Aufruf von https://gruniversal.mars trotzdem ne Warnung angezeigt, dass die Konfiguration nicht korrekt ist (oder ein böser Mensch sich zu schaffen macht):

Die kann man zwar wegklicken, aber am Ende wünscht man sich doch einen “sauberen” Weg, der ohne Fehlermeldungen auskommt. Was kann man da machen? Und was genau bedeutet der Fehler eigentlich?

Lokale SSL Konfiguration

Im Jahre 2020 sollte Verschlüsselung Standard für die Übertragung von Daten mit Webservern sein. Spätestens seitdem Browser mit dezenten “Not Secure”-Hinweisen auf die Gefahren unverschlüsselter Datenübertragung hinweisen, bietet es sich an konsequent auf SSL (korrekter eigentlich TLS) zu setzen.

Daher macht es Sinn auch die lokale Umgebung SSL-fähig zu machen um gleich während der Entwicklung festzustellen, ob es Lücken in der Verschlüsselung gibt oder ob die Anwendung überhaupt mit SSL sauber funktioniert.

Kernstück der Verschlüsselung sind Zertifikate, die den Webserver identifizieren und den Datenstrom nach außen unleserlich machen. Aber woher bekommt man ein solches Zertifikat für den lokalen Einsatz?

(Hinweis: Um meine lokale Konfiguration und mein Vorhaben besser zu verstehen, ist es sinnvoll vorher Teil 1 und Teil 2 dieser kleinen Artikelserie zu lesen.)

www-Subdomain einrichten

Im letzten Schritt hatte ich erfolgreich die lokale Domain gruniversal.mars für meine lokalen Entwicklungen eingerichtet. Nun möchte ich hierzu die Subdomain www.gruniversal.mars einrichten und Aufrufe von gruniversal.mars automatisch dorthin umleiten.

Die Einrichtung selbst ist vergleichbar zur Einrichtung der Domain. Zunächst wird die Subdomain in der hosts-Datei zusätzlich bekannt gemacht:

david@mars ~ $ sudo vim /etc/hosts
127.0.0.1        gruniversal.mars
127.0.0.1        www.gruniversal.mars

Danach folgt die Konfiguration im Webserver. Dabei muss man keinen neuen Virtual-Host anlegen, sondern kann den bestehenden um den neuen Servernamen ergänzen, indem man ihn als ServerAlias angibt.

david@mars ~ $ sudo vim /etc/apache2/sites-available/001-gruniversal.mars.conf
<VirtualHost *:80>
    ServerName gruniversal.mars
    ServerAlias www.gruniversal.mars
    DocumentRoot /home/david/workspace/websites/gruniversal.de/
</VirtualHost>

Nach einem entsprechenden Reload des Apache ist die Subdomain dann ebenfalls verfügbar. Damit ist der einfache Teil abgeschlossen.

Lokale Domain einrichten

Ich verwende als Betriebssystem aktuell Linux Mint und möchte meine Website auch lokal anschauen und entwickeln können. Dafür bietet es sich an auch ein ähnliches Setup zu haben, was für mich z.B. heißt, dass die Website auch eine eigene lokale Domain bekommt. Da mein Rechner “Mars” heißt, hab ich dazu folgendes in meine hosts-Datei eingetragen um die lokale Domain gruniversal.mars einzurichten:

david@mars ~ $ sudo vim /etc/hosts
127.0.0.1        gruniversal.mars

Damit der Apache die Domain ebenfalls kennt, ist folgendes notwendig:

david@mars ~ $ sudo vim /etc/apache2/sites-available/001-gruniversal.mars.conf
<VirtualHost *:80>
    ServerName gruniversal.mars
    DocumentRoot /home/david/workspace/websites/gruniversal.de/
</VirtualHost>

Damit wird die Domain bekannt gemacht und auf das Hauptverzeichnis verwiesen.

(Hinweis: Bei mir läuft der Apache im Home-Verzeichnis, weil ich ohnehin der einzige Nutzer bin und so die Files im home-Backup gleich mit enthalten sind. Oft wird hier auch /srv/www/ oder /var/www/ genutzt.)

Damit nun die Konfiguration auch wirksam wird, muss die Site im Apache noch aktiviert werden und die Webserver-Konfiguration neu geladen werden:

david@mars ~ $ sudo a2ensite 001-gruniversal.mars.conf
Enabling site 001-gruniversal.mars.
To activate the new configuration, you need to run:
  service apache2 reload
david@mars ~ $ service apache2 reload

Nachdem dies erfolgreich war, funktioniert die Domain wie erwartet:
http://gruniversal.mars/

Im nächsten Schritt möchte ich zusätzlich auch die passende www-Subdomain einrichten und entsprechend alle Aufrufe umleiten.

Gruniversal Website 2020

In den letzten Monaten wurde der Druck sich mal wieder um meine Domain gruniversal.de zu kümmern immer größer. Mein Provider wollte den Server von Confixx auf Plesk umstellen und die PHP-Version zumindest auf 7.0 anheben.

Zudem hatte ich selbst ein paar Ideen, was man mal angehen könnte:

  • Migration bestehender Blogs von mir auf die Website, damit diese werbefrei und besser unter meiner Kontrolle sind.
  • Allgemeine Aktualisierung der Inhalte der Website incl. Berücksichtigung aktueller Projekte.
  • Spielwiese für weitere Projekte z.B. eine Fotogalerie.

In der Folge habe ich Anfang Februar meinen Provider kontaktiert und im ersten Schritt einen neuen Tarif beauftragt. Der hat dann zügig die entsprechende Umgebung eingerichtet und ich konnte loslegen.

Ich werde in der nächsten Zeit meine Erkenntnisse im Rahmen der Migration hier dokumentieren und das gleich zum Anlass nehmen mal wieder einen persönlichen IT-Blog auf WordPress-Basis zu starten.

Präsentiert von WordPress & Theme erstellt von Anders Norén