Flatpress lebt weiter
Nachdem bei Flatpress über Jahre nicht mehr viel weiterging, habe ich Anpassungen (die in dessen Forum genannt wurden) für mich gemacht und gar angefangen ein anderes Blog Tool zu suchen. In meinem Blog sind Inhalte seit 2008. Die Inhalte zu übernehmen, ist so eine gewisse Hürde, die mich abschreckt.
Aber all das entfällt ja nun :-) Am 22. Februar gab es eine neue Version, die gar PHP 7.3 komptibel ist.
Ein Dankeschön an Arvid und seine Helfer!
Anbei die Beschreibung des Updates von 1.0x auf 1.1 mit Übernahme des Inhalts. Bei der Variante “Überschreiben der bestehenden Dateien” bleibt tendeziell Unnützes über.
Anm.: dies ist inoffiziell - es ist die Beschreibung des Vorgehens auf meiner Installation.
- Backup: das Verzeichnis des Blogs “/blog/” wurde umbenannt nach “/blog_OLD/”
- Unzip der version 1.1 nach “/blog/”
- Beiträge und Bilder: Kopieren des Verzeichnisses /blog/fp-content/
- Theme: Kopieren des Verzeichnisses /blog/fp-interface/themes/[theme]
- Plugins: gehe in das Backend des Blogs blog/admin.php?p=plugin … wenn ein fehlendes Plugin gemeldet wird: Kopieren des Verzeichhisses /blog/folder fp-plugins/[pluginname] (Kontrolle mit Reload im Browser)
- Die Toolbar des Editors habe ich mir erweitert - im BBCode plugin wurden einige weitere Buttons hinzugefügt /blog/fp-plugins/bbcode/tpls/toolbar.tpl
- Pretty-Urls waren aktiv? dann die /blog/.htaccess übertragen
- Flatpress-Index neu erstellen: Dazu anmelden, Wartung anklicken und den Link anklicken [Den Flatpress Index neu erstellen]
- Einmal den Browsercache löschen (Ctrl+Shift+Delete), damit Javascript- und CSS Elemente von der neuen Version geladen werden
UPDATE:
3.3.2019 - Dank an Matthias (Laborix): Neuerstellen des Index wurde hinzugefügt.
weiterführende Links:
Unterbinden von Load_file() in Mysql und MariaDB
Ich benötige zum Betreiben von Applikationen keine Dateizugriffe via Mysql. Wenn es weder Dateien vom Server noch vom Client braucht, fühle ich mich wohler, wenn die Funktion komplett deaktiviert ist, weil das ein offenes Scheunentor sein kann.
Um das Laden von Dateien innerhalb SQL zu vermeiden, gibt es in Mysql die Möglichkeit, in der Konfiguration den Dateizugriff zu unterbinden
[mysqld] local-infile = 0|1 oder ON|OFF secure_file_priv = [Wert]
Kurz in der Dokumentation die Werte nachlesen, ins Puppet kippen und auf alle Server verteilen.
Als Test, ob ich erfolgreich bin, dient der Aufruf … dieser muss NULL ausgeben und keinen Dateiinhalt.
# mysql -e "SELECT load_file('/etc/passwd');"
+--------------------------+
| load_file('/etc/passwd') |
+--------------------------+
| NULL |
+--------------------------+
Das war die Idee. Eigentlich klingt es einfach.
Leider verhalten sich aber die Einstellungen von Mysql und MariaDB unterschiedlich.
Der Wert für local-infile muss bei beiden 0 oder OFF sein. local-infile ist aber eine dynamische Variable - das ist aber lediglich der Startwert, der mit einem SQL Befehl in der laufenden Instanz neu gesetzt werden kann.
Heisst: es braucht zwingend den Wert für secure_file_priv, der sich wiederum NICHT zur Laufzeit verändern lässt.
(1)
Variante für Mysql:
[mysqld] (...) local-infile = 0 secure_file_priv = NULL (...)
Danach einmal den Service neu starten systemctl restart mysql … dann habe ich das Verhalten wie in meinem Testaufruf.
Dieses Setup funktioniert nicht auf MariaDB - es wird mit einem Fehler in der Variable secure_file_priv beendet.
Die Dokumentation sagt: wenn secure_file_priv fehlt, würde der Dateizugriff verhindert werden…
Description: LOAD DATA, SELECT … INTO and LOAD FILE() will only work with files in the specified path. If not set, the default, the statements will work with any files that can be accessed.
Aber das ist nicht korrekt! Wenn ich secure_file_priv nicht setze, und es aus der laufenden Datenbank abfrage, ist der Wert leer
# mysql -e "SHOW VARIABLES LIKE 'secure_file_priv';" +------------------+------------+ | Variable_name | Value | +------------------+------------+ | secure_file_priv | | +------------------+------------+
… und ein SELECT load_file(’/etc/passwd’); zeigt mir den Dateiinhalt an!
Wer Percona oder einen anderen Mysql-Abkömmling verwendet, sollte das Verhalten austesten.
MariaDB erwartet einen existierenden Verzeichnisnamen. Ich habe mich entschieden, /dev/null zu nehmen, weil es sowohl existiert als auch ein User hier keine Datei ablegen kann:
(2)
Variante für MariaDB:
[mysqld] (...) local-infile = 0 secure_file_priv = /dev/null (...)
(3)
Bliebe noch die Software-Verteilung… wenn in Puppet die Mysql-Klasse aufgerufen wird, muss diese von irgendwoher wissen, ob das Produkt am Zielsystem MariaDB oder Mysql ist. Die Lazy Variante wäre, auf das OS zu reagieren, weil Defaults in den Repos beispielsweise von Debian oder CentOS sich unterscheiden. Besser und sicherer ist natürlich ein echtes Flag.
Update zu (3):
Meine Variante für ein vom Mysql Daemon nicht verwendbares, aber stets existierendes Verzeichnis für beide Mysql-Varianten ist … “/root”
[mysqld] (...) local-infile = 0 secure_file_priv = /root (...)
weiterführende Links: