When you get the message from pikaur:
Read damn arch-wiki before borking your computer
https://wiki.archlinux.org/title/Arch_User_Repository
(Also, don't report any issues to pikaur, if ure seeing this message)
you need to check your base-devel package is installed.
References:
Nach dem Update auf Debian 12 funktionieren die selbst angelegten logcheck Regeln nicht mehr. Das liegt daran, dass du nun hochpräzise Zeitstempel in den Logs genutzt werden.
Die eigenen Regeln kann man mit einem Befehl für das neue Format einfach konvertieren. Als root muss folgendes Kommando ausgeführt werden:
for rule in /etc/logcheck/*.d*/local-*; do sed --in-place --regexp-extended 's,^\^((\\w|\[\[:alpha:\]\])\{3\} \[ :(0-9|\[:digit:\])\]\{11\}),^(\1|[0-9T:.+-]{32}),' "$rule" ; done
Dabei muss der Ausdruck für die Dateipfade /etc/logcheck/*.d*/local-* an die eigenen Dateinamen der Regeln angepasst werden. Bei mir beginnen sie mit 01-, sodass ich diese Stelle auf /etc/logcheck/*.d*/01-* abgeändert habe.
Die Regel habe ich auch noch auf die postgrey Dateien angewendet, weil diese noch den alten Zeitstempel unterstützt haben und nicht auch den neuen.
Namespaces in logseq are as simple as using a slash in the page’s title. If you have worked with namespaces in a logseq version, which is lower than v0.8.9, you should migrate your existing pages according to the “New file name rules”. These rules are mentioned almost at the end of release note. Otherwise you might notice some weird behaviour with the pages in a namespace.
The migration via GUI can be found in logseq: Settings → Advanced → File name format and there is an Edit button, which should be clicked and the instructions in the popup window need to be followed. In your logseq graph this will rename all pages with a slash, where the slash will be replace by three underscores.
tl;dr: Dieser Artikel beschreibt, wie man mit Map Machine, das in einem Docker Container läuft, Karten als SVG basierend auf OpenStreetMap generieren kann.
Map Machine ist ein Projekt, das die Fülle und Vielfalt der Daten von OpenStreetMap zeigen möchte. Es ist ein Map Renderer, der in Python geschrieben ist und unter MIT License auf GitHub veröffentlicht ist.
Um das das Docker Image für das Map Machine-Projekt bauen zu können, benötigen wir selbstverständlich auf unserem Rechner docker und git. Auf git könnte man verzichten, wenn man sich das Repository als gepacktes Zip herunterlädt. Dann benötigt man halt die Software zum Zip entpacken.
Wenn Docker noch nicht installiert ist, so gibt es Anleitungen z.B. für Ubuntu oder Archlinux.
Zunächst erzeugen wir eine lokale Kopie. Dazu müssen wir das das Repository clonen (oder herunterladen und entpacken):
git clone https://github.com/enzet/map-machine.git
Anschließend können wir in das Verzeichnis map-machine wechseln, um das Docker Image zu bauen:
docker build --pull -t strubbl_mapmachine .
Bei diesem Kommando ist der Punkt am Ende wichtig, denn er steht für das aktuelle Verzeichnis. Das bedeutet, dass im aktuellen Verzeichnis nach der Bauanleitung (Dockerfile) für dieses Image gesucht wird.
Der Name für das Image strubbl_mapmachine ist frei gewählt und kann natürlich anders lauten. In den folgenden docker-Kommandos muss dies dann entsprechend angepasst werden.
Während das Image gebaut wird, können schon einige Vorbereitungen getroffen werden, um gleich einen sinnvollen Aufruf an Map Machine zu formulieren.
$HOME/data/mapmachine/maps und somit die Cache-Daten unter $HOME/data/mapmachine/maps/cache ablegen. Durch die Verwendung der Variablen $HOME wird automatisch das eigene Home-Verzeichnis verwendet, z.B. /home/strubbl. Ich erstelle also die von mir gewünschten Verzeichnisse mit dem Ausführen des Befehls mkdir -p $HOME/data/mapmachine/maps/cache.CSV sein. Dann erkennt man die durch Kommata getrennten zwei Koordinaten.Wenn diese drei Informationen zusammengetragen sind und das Docker Image erfolgreich gebaut wurde, kann man einen Container basierend auf dem Image starten, der die Karte erstellt und sich dann wieder beendet.
Ein Aufruf könnte wie folgt aussehen:
docker run -v $HOME/data/mapmachine/maps:/maps strubbl_mapmachine render \
--cache=/maps/cache -z=17 -o=/maps/stralsund-hafen.svg \
-b=" 13.089452552,54.313679518,13.1049235336,54.3194871239"
Aufgeschlüsselt bedeutet jeder Teil des Kommandos folgendes:
docker run drückt man aus, dass man einen Container starten will.-v kommt zunächst der Pfad auf unserem PC, wo die genierten Karten hingeschrieben werden sollen: $HOME/data/mapmachine/maps. Dann folgt ein Doppelpunkt und der Container-interne Pfad /maps.strubbl_mapmachine.render ist das erste Argument, dass an den map-machine-Befehl gesendet wird, um mitzuteilen, dass eine Karte generiert werden soll.--cache und dem folgenden Pfad /maps/cache gibt man an, wo Daten, die über die OpenStreetMap API abgefragt werden, zwischengespeichert werden. Diese können dann wiederverwendet werden.-z 17 angegeben, das hier auf Stufe 17 festgelegt wird.-o festlegen. Die Datei sollte unterhalb des Container-internen Verzeichnisses /maps/ liegen, sodass wir die Datei auch auf unserem lokalen Pfad verfügbar haben und sie nicht im Container gespeichert wird, worauf wir nicht zugreifen können sobald der Container beendet wurde. Der Container-interne Pfad wird durch unseren lokalen Pfad gemappt, siehe Parameter -v.-b-Parameter angegeben. Die Angabe der Koordinaten mit den Anführungszeichen und dem Leerzeichen in der Form ist wichtig, weil es sonst zu einem bekannten Fehler kommen kann.Man muss in diesem Docker-Kommando nicht map-machine mit angeben, weil es das Standardkommando beim Aufruf des Containers ist. Das ist so im Dockerfile definiert.
Mit dieser gewählten kleinen bbox und dem Zoom-Level 17 dauert die Generierung nur ein paar Sekunden (ca. 10 s auf einem i3-6100U mit SSD). Ein größeres Zoom-Level oder eine größere bbox verlängern den Prozess und die Größe der SVG-Kartendatei. Z.B. die Generierung einer Karte mit der gleichen bbox aber Zoom-Level 19 dauert in etwa doppelt so lange, wobei dank Nutzung des Caches keine neuen Daten von der OpenStreetMap API abgefragt werden müssen.
Wenn das Docker-Kommando fertig ist, haben wir im Pfad $HOME/data/mapmachine/maps/stralsund-hafen.svg unsere generierte Karte liegen.
Danke an Manfred für das Testen des Artikels und die Rückmeldungen. So haben wir zusammen den o.g. Bug gefunden.
Dieses Wochenende habe ich mir mal Pixelfed angesehen - eine Art Instagram-Klon. Dieser Blogeintrag dient dazu, die recherchierten Informationen mal alle zusammenzutragen, weil die Dokumentation zu wünschen übrig lässt.
Pixelfed ist ein mit Laravel in PHP erstelltes Projekt. Neben PHP hat es noch weitere Abhängigkeiten zu einer Datenbank: MySQL, PGSQL und sqlite werden wohl unterstützt, wobei MySQL im Moment also default vorgesehen ist. Außerdem kommt noch Redis dazu.
Das klingt super, um es in Docker Container zu packen. Erste Aktivitäten bzgl. Docker sind in dem Projekt auch schon gestartet. Leider nutzt der Initiator des Projekts, Daniel, nicht Docker. Daher ist alles rund um Docker etwas stiefmütterlich gepflegt. Das führt also zu diesem Blog und ein paar Änderungen für Docker, die auch schon in das Projekt eingeflossen sind.
Wie in der Installtionsdokumentation geschrieben, lädt man sich zunächst eine Kopie des Projekts und erstellt die Produktionsumgebung:
git clone -b dev https://github.com/pixelfed/pixelfed.git pixelfed
cd pixelfed
cp .env.example .env
Die Datei .env passt man entsprechend den eigenen Anforderungen an. Hierbei gibt es zu beachten, dass man den APP_KEY mit exakt 32 zufälligen Zeichen befüllt.
Der eigentliche Weg wäre gewesen, dieses Feld leer zu lassen und mit dem Befehl php artisan key:generate einen Key zu erstellen. Doch das befüllte bei mir dieses Feld mit einem base64 codierten Schlüssel, mit dem die Applikation nichts anfangen konnte. Also habe ich kurzerhand KeepassXC bemüht, mir 32 Zeichen Zufall zu geben und diese manuall eingetragen. Ich habe noch nicht herausgefunden, welchen Nebeneffekt das haben könnte.
Außerdem habe ich das mit key:generate noch mit der Version v0.10.6 getestet. Mittlerweile habe ich auf den heutigen Stand vom dev Branch gewechselt, wo ich nicht noch einmal ausprobiert habe, ob das Problem noch exisitiert.
Wenn die .env stimmig ist, kann man die Container starten und die Datenbank erstellen:
docker-compose up
docker-compose exec app php artisan migrate --force
Im Prinzip ist man damit fertig und man kann Pixelfed aufrufen, sich registrieren und es nutzen. Evtl. möchte man noch einen Adminnutzer bestimmen. Das geht mit docker-compose mit dem folgenden Kommando: docker-compose exec app php artisan user:admin ADMINUSER, wobei ADMINUSER durch den Nutzernamen ersetzt wird, der die Rolle zugeteilt bekommen soll.
Pixelfed unterstützt mobile Apps (noch nicht vollständig). Um die generelle Unterstützung für mobile Apps zu aktivieren, muss man laut Release Notes von v0.10.6 folgenden Schritte durchführen.
docker-compose exec app php artisan passport:keys
In die Datei .env wird die Zeile OAUTH_ENABLED=true hinzugefügt und anschließend die Änderung dieser Datei neu in den Cache geladen:
docker-compose exec app php artisan config:cache
Das hat bei mir aber nicht ausgereicht, sodass ich die Container mittels down und up neustarten musste. Ein restart hat nicht gereicht:
docker-compose down
docker-compose up
Welche App unterstützt wird, habe ich weiter unten aufgeschrieben.
Die neue sog. “ComposeUI v4 BETA” für das Hochladen von Bilder unterstützt seit Release v0.10.1, dass man den Ort, wo das Foto erstellt wurde, festlegen kann. Um die Unterstützung für dieses Feature zu aktivieren muss man einmalig folgendes Kommando ausführen während die Docker Container laufen:
docker-compose exec app php artisan import:cities
Damit kann man beim Beitrag erstellen den Ort festlegen. Die Suche nach Orten beachtet die Groß- und Kleinschreibung.
Da ich einen nginx als Proxy für den Docker Container nutze, muss der nginx so konfiguriert werden, dass der Standwert iHv. 1 MB erhöht wird. Man sollte den Wert so erhöhen, dass er größer gleich dem Wert für Uploads ist, der in der Datei .env eingestellt ist.
Da das Release v0.10.7 im Moment noch auf sich warten lässt, wurde verkündet, dass man den dev Branch, der bereits 145 Commits neuer als v0.10.6 ist, nutzen soll.
Um Nutzer anderer Pixelfed-Instanzen hinzuzufügen, muss man die komplette URL zu dem jeweiligen Profil in das Suchfenster in Pixelfed eingeben. Dann findet Pixelfed den Nutzer der anderen Instanz und man kann ihn hinzufügen.
Was im Moment noch nicht funktioniert, ist die Vorschau von einem Bild für verschiedene Filter. Diese Vorschau sieht man direkt nach dem Upload eines Bildes und sollte eigentlich das Originalbild anzeigen wie es mit verschiedenen Filtern aussieht. Diese Filterbilder können im Moment aber nicht angezeigt werden und die URL auf diese Bilder gibt vom Webserver ein 404 zurück.
Wenn man pgsql als Datenbank wählt, kommt man momentan nicht weit, da diese noch nicht richtig unterstützt wird.
Ich habe Fedilab und Fedilab Lite erfolglos getestet. Die Ansage ist aber, dass Fedilab Lite ab Version 2.23.0 Pixelfed untersützt. Nur doof, dass in F-Droid das Update immer noch nicht angekommen ist. Dort ist Version 2.22.2 noch die aktuellste. 😞
Wer bis hier gelesen hat und mich auf Pixelfed hinzufügen möchte, kann mich unter folgender Adresse finden: https://pixel.strubbl.de/strubbl