Archiv der Kategorie: Software

Alles was mit Software zu tun hat

Docker: Container-Zombies blockieren Netzwerk-Löschung

(Achtung, Rant-Character. Wer das nicht mag findet die Lösung in den letzten 3 Absätzen)

Heute also mal wieder Docker. Ein stetiger Quell an Problemen. Ursprünglich war meine Anforderung gar nicht so kompliziert: Per docker-compose soll eine Multi-Container-Applikation aus- und wieder eingeschaltet werden. Also: docker-compose down und warten. Leider scheiterte der Prozess bereits an dieser Stelle aufgrund eines Timeouts. Das Schreiben großer Caches beim Beenden benötigt eben seine Zeit. Sicher, es gäbe -t oder stop_grace_period, aber wie das oft so ist: Wer auch immer vorher damit gearbeitet hat, hat es natürlich nicht dokumentiert oder konfiguriert.

Nunja, der docker-daemon sollte die zugehörigen Container trotz des Timeouts im Frontend noch abarbeiten – entsprechend war nach kurzer Bedenkzeit in docker ps -a auch kein Container mehr zu sehen, der zur Applikation gehört.

Alles gut? Leider nein. Das folgende docker-compose up weigerte sich beharrlich die Container wieder zu starten. Es versuchte immer noch, die Überreste der alten Struktur, insbesondere die Netzwerke, zu löschen, und scheiterte:

ERROR: error while removing network: network application_network id XXX has active endpoints

Active? Interessant, denn in docker ps -a war ja definitiv nichts mehr aktiv. Auch ein manuelles docker network remove application_network behauptete weiterhin, dass es die ID noch gäbe.

Error response from daemon: error while removing network: network application_network id XXX has active endpoints.

Ein docker network inspect application_network verriet: Die nicht mehr gelisteten Container sind wohl doch noch da – zumindest so halb. Also gehen wir auf Zombie-Jagd.

Die Lösung: Erst trägt man mit docker network inspect application_network | grep Name die Namen der verbliebenen Containerreste zusammen. Im Anschluss kann man über docker network disconnect ein Entfernen erzwingen.

for i in application_db_1 application_es_1 application_redis_1 application_nginx_1 ;do docker network disconnect -f application_network $i ;done

Abschließend entfernt man mit docker network remove application_network das Netzwerk. Danach sollte einem erneuten Start nichts mehr im Wege stehen.

Absichtliche Latenz für Pulseaudio

Wieder einmal stoße ich an eigentlich einfache Dinge, die dank Closed-Source aber etwas komplizierter sind: Ich möchte Youtube-Videos von meinem Laptop auf dem Fernseher schauen. Hierzu nutze ich üblicherweise einen Chromecast, welcher sich per Chrom[e|ium] oder Smartphone bedienen lässt. Nun hatte ich jedoch den Wunsch nur Bild zu übertragen, den Ton aber am lokal angebundenen Bluetooth-Kopfhöhrer zu behalten. Das ist so leider nicht vorgesehen, also bleibt nur Improvisation.

Für das Bild ist das schnell erledigt: Ein ungenutzter HDMI-Port wird kurzerhand eingeschaltet und per Chrome geteilt, so wird verhindert, dass der Chromecast auf die interne App zurückfällt. Der Ton bleibt so ebenfalls lokal verfügbar, aber nicht Synchron. Durch die Übertragung ist das bild knapp eine Sekunde hinterher.

Also muss das Audiosignal des Browsers absichtlich verzögert werden. Pavucontrol bietet hierzu eine Latenzeinstellung, dessen Funktion ist jedoch von der verwendeten Soundhardware abhängig. In meinem Fall konnte ich unabhängig der Einstellung keine Latenz feststellen.

Abhilfe schafft die Konsole und ein Tipp von Thomas auf Stackexchange. Es wird ein Dummy-Gerät registriert, welches vom Browser als Ziel genutzt werden kann. Dieses wiederum wird als loopback wieder an das korrekte Ausgabegerät angehangen. Den passenden Namen der Ausgabe findet man mit pactl list cards. Da hier alles in Software emuliert wird, sind nun die Latenzangaben funktionsfähig.

pactl load-module module-null-sink sink_name=delay
pactl load-module module-loopback latency_msec=2000 source=delay.monitor sink=alsa_card.pci-0000_00_1f.3.analog-stereo

Deutlich komplexer als ein HDMI-Kabel, aber was tut man nicht Alles um nicht das passende Kabel suchen gehen zu müssen…

Qt5: LoadLibrary-Fehler mit RDP unter Windows (ATI, OpenGL, Nextcloud)

Das Qt-Framework wird von vielen Projekten genutzt um grafische Oberflächen auf allen Betriebssystemen einheitlich entwickeln zu können. Bekannte Softwarepakete, welche Qt nutzen, sind unter Anderem: Nextcloud-Client, Owncloud-Client, FileZilla, Quassel, Mumble, MiniTube, Bitcoin-Qt, Scribus, LuminanceHDR, Audacious, Clementine, LMMS, VLC, AviDemux-qt, Shotcut, OpenShot, LibreCAD, FreeCAD, OpenSCAD, QOwnNotes, Calibre, KeePassX, KeePassXC, Wireshark und BlueStacks.

Eigentlich eine praktische Sache, jedoch mit einem Haken: Mit Qt5 versuchte man viele grafische Operationen per Hardwarebeschleunigung zu erledigen. Dies sorgt für schnellere Programme und weniger Systemlast. Für die Ansteuerung der Grafikkarte nutzt man hierbei OpenGL, welches auf allen gängigen Betriebssystemen verfügbar ist. Leider tritt man sich hierbei auch einige Probleme ein, so ist z.B. Windows dafür bekannt qualitativ zweifelhafte Treiber zu verteilen, welche stark auf Gaming optimiert sind, aber bei anderen Operationen gerne ins Straucheln kommen.

Ein recht verbreitetes Problem tritt dann auf, wenn eine AMD-Grafikkarte wie z.B. Radeon oder im System steckt, man jedoch auf den Windows-Rechner per Remote Desktop (RDP) zugreift. Windows lädt – auch wenn RDP genutzt wird – die Grafikkartentreiber. Ein Fehler in den ATI-Treibern, welcher bereits seit Ende der 2010er-Jahre bekannt ist, führt jedoch dazu, dass in RDP-Sitzungen Grafikoperationen nicht in Software ausgeführt oder von der Grafikkarte berechnet und zurückgegeben werden, sondern sie versuchen diese Trotzdem komplett in der GPU zu verarbeiten und brechen die Anfrage letztendlich ab. In vielen Anwendungen äußert sich das in fehlenden Grafikelementen oder Fehlermeldungen. So lässt sich z.B. der Nextcloud-Client gar nicht starten und Quittiert den Versuch die GUI per RDP zu öffnen mit einem fatalen Fehler. Es ist somit nicht möglich die Software per RDP zu starten.

Fehlermeldung NextCloud-Client: „LoadLibrary failed with error 87: The parameter is incorrect.“

Glücklicherweise kann man sich hierbei einer Eigenheit von „Shared Libraries“ zu nutze machen, welche peeter123 auf GitHub vorschlägt: Jede App bevorzugt seine eigene Version, nur wenn sie selbst nichts mitliefert wird auf jene des Systems zurückgegriffen. Im Falle des OpenGL-Bugs kann man also einfach statt der Microsoft/ATI-Version eine weniger kaputte nutzen. Hierzu eignet sich z.B. die Variante des Mesa-Projektes, welche die OpenGL-Operationen nicht direkt an die Grafikkarte sendet. Um diese nun einzubinden lädt man auf der Releases-Seite die letzte Release-Version für mingw herunter (mesa3d-xx.yy.zz-release-mingw.7z), öffnet diese (z.B. mit 7Zip) und kopiert aus dem Ordner x64 (für 64-Bit-Systeme) die Datei „opengl32.dll“ in den Ordner des betroffenen Programms, also z.B. C:\Program Files\Nextcloud. Hierdurch greift die Änderung nur für diese eine App und beeinflusst nicht alle installieren Programme. Fortan sollten die Operationen der Software ohne GPU-Treiber laufen und die Applikation somit auch per RDP lauffähig sein.

Durch diese Änderung verliert man zur potentiell etwas Geschwindigkeit in der betroffenen App, dies sollte bei aktuellen Systemen aber nicht groß auffallen – insbesondere, wenn man diese ohnehin nicht häufig aktiv nutzt. Immerhin ist die Software so auch remote nutzbar. Mit fortschreitender Migration auf Qt6 sollte sich das Problem mit der Zeit auch ganz von selbst erledigen: Dies nutzt statt OpenGL die jeweiligen Funktionen des Betriebssystems, welche auch auf Windows nicht ganz so kaputt sind.

Raspian: AbhängigkeitsFehler bei Upgrade von Buster zu Bullseye (unreleased)

Normalerweise ist ein Upgrade von Debian zu einer neueren Version keine große Sache: System in aktuellen Release aktualisieren (apt dist-upgrade), Sources anpassen, full-upgrade, fertig. Leider scheint Raspian hier wieder eine Extrawurst zu benötigen. Nach Ändern der Sources von Buster (Debian 10) zu Bullseye (Debian 11) gab es beim full-upgrade einen Abhängigkeitsfehler:

Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6+rpi1 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

Manuell festgenagelte Pakete gab es meinerseits nicht, entsprechend hätte ich erwartet, dass die Abhängigkeiten automatisch aufgelöst werden können. Abhilfe schaffte letztendlich das Update von GCC vor dem full-upgrade mittels apt install gcc-8-base per Hand zu installieren. Hierdurch wurden die beteiligten Pakete vorab aktualisiert und das Abhängigkeitsproblem somit aufgelöst.

Vorsicht: Bullseye für Raspian ist auch 2 Monate nach dem Release von Debian 11 noch nicht offiziell freigegeben. Viele Systemteile, die Raspian gegenüber einem „echten“ Debian ändert, sind noch nicht lauffähig. So startet nach dem Update beispielsweise dhcpcd nicht mehr. Schaltet man die Raspian-Anpassungen ab (z.B. in dem man Systemd, Networkmanager o.Ä. nutzt) ist das System jedoch prinzipiell lauffähig.

Windows-Update – Fehler 0x800f0831 beheben

Hinweis: Die Screenshots sind von einem älteren System, die Meldungen, Pfade und Vorgehensweisen sollten sich jedoch auch auf aktuelle Versionen übertragen lassen.

Und wieder das übliche Bild: Auf einem Windows-System sind nicht alle Updates installiert. Keine gute Idee, insbesondere bei Systemen, die an einem Netzwerk betrieben werden. Also schnell in die Einstellungen und Updates installieren – in der Theorie. Leider passiert es nach meiner Beobachtung immer wieder, dass Updates quer sitzen und sich nicht installieren lassen. Auch im aktuellen Fall sah man bereits: „Failed“ war im letzten Installationsversuch zu erkennen.

8 offene Windows-Updates, letzter Installationsversuch fehlgeschlagen

Auch ein manueller Versuch über „Install updates“ brachte kein Erfolg. Der Assistent schien fehlerfrei zu laufen, nach dem im Anschluss angeforderten Reboot war jedoch das Bild wieder identisch: Die Updates standen erneut als offen drin. Also erster Blick: Welche waren überhaupt betroffen. In den Details fanden sich neben den meist wenig aussagekräftigen Bezeichnungen auch die KB-Nummern, welche bei Microsoft die zugehörigen Dokumentationen beschreiben.

Liste der offenen Updates mit KB-Nummern

Hier kam dann der Microsoft Catalog unter https://www.catalog.update.microsoft.com/ ins Spiel: Über diese Webseite lassen sich per KB-Nummer einzelne Updates suchen und per Hand herunterladen. Hierbei etwas aufpassen: Oft sind die Updates für verschiedene Betriebssystemversionen und CPU-Architekturen mit der selben KB-Nummer eingestellt, beim Download lohnt es sich also doppelt hin zu schauen.

Microsoft Update Katalog-Webseite mit einzelnen Updates

Die zum Download angebotenen MSU-Dateien sollten sich direkt per Doppelklick öffnen lassen und einen Setup-Assistenten zeigen. Leider brachte auch die händische Installation keine Besserung – am Ende des Assistenten vermeldete das Ergebnis ein wenig aussagekräftiges „The following updates were not installed„. Auch die Ereignisanzeige des Betriebssystems verriet nicht mehr als eben jene wenig hilfreiche Statusmeldung.

An dieser Stelle wird oft eine Reparatur mit DISM.exe /Online /Cleanup-image /Restorehealth bzw. Sfc /scannow oder gar eine Neuinstallation empfohlen. Ist jedoch klar, dass das System keine weiteren Probleme hat, ist eine gezielte Reparatur jedoch oft weniger Zeitintensiv als eine vollständige Neuinstallation, insbesondere wenn die betroffenen Systeme nicht über ein Konfigruationsmanagement/Orchestration zur automatischen Installation verfügen.

Glücklicherweise erstellt Windows Update an diversen Stellen erweiterte Protokolle, welche die Fehlersuche erleichtern. Bei Installationsfehlern sind die CBS-Logs meist die hilfreichste Anlaufstelle. Die Korrekte Datei findet sich unter %systemroot%\Logs\CBS\CBS.log. Eine Suche nach “ Error “ (mit ein paar Leerzeichen dahinter) sollte die relevante Stelle schnell sichtbar machen. In diesem Fall handelte es sich um eine Inkonsistenz im Updatespeicher, die zugehörige KB-Nummer ist in solchen Fällen in der Fehlermeldung erkennbar. Wer diese vergleicht wird feststellen, dass es sich hierbei nicht um eins der zur Installation vorgemerkten Updates handelte. Stattdessen betraf es ein älteres Update, welches für die aktuelle Installation benötigt wurde. Das genannte, ältere Update war laut System installiert, fehlte in Realität jedoch. Ein solcher Zustand ist oft zu finden, wenn bei einem vorherigen Update der Rechner abstürzte.

Ausschnitt CBS-Log. Vorausgesetzte KB-Nummer in der Fehlermeldung erkennbar

Also zurück zum Catalog, dort kann man das defekte Update manuell herunterladen und nochmals installieren. Ist dies Erfolgreich sind Updatespeicher und Realität an dieser Stelle wieder auf einem konsistenten Stand und die Installation der neueren Updates kann fehlerfrei erfolgen. Möglicherweise muss der Vorgang für mehrere ältere Updates wiederholt werden. Hier kann es helfen in der Updatehistorie zu prüfen, welche Updates mit dem Betroffenen zeitgleich installiert wurden und diese – sofern nicht ersetzt – präventiv ebenfalls neu zu installieren. Am Ende sollten sich alle Updates installieren und das System so auf einen aktuellen Stand bringen lassen.

Windows 10: Fehlende Audioausgabe nach April 2020-Updates (Realtek)

Nach installation der April 2020 Updates für Windows 10 19.09 kam es auf einigen von mir betriebenen Systemen zum Verschwinden der Audio-Treiber. Somit war eine Ton Ein- und Ausgabe nicht mehr möglich. In Zeiten von dauerhaften Videoschalten eher ungünstig. Selbes wurde von anderen Nutzern berichtet. Allen gemein: Es handelt sich um PCs und Laptops mit Realtek-Sound auf Basis von Intel HD Audio.

Treiber-Updates zeigen keine Änderung, das Booten eines vernünftigenanderen Betriebssystems bingt funktionierenden Ton mit sich. Interessant dabei: Die Audio-Devices tauchen nicht einmal mehr im Gerätemanager auf. In den ausgeblendeten Geräten wird das Gerät noch angezeigt, jedoch mit der Info „Dieses Hardwaregerät ist zurzeit nicht an den Computer angeschlossen. (Code 45)“.

Sucht man etwas weiter findet man unter „Systemgeräte“ einen Eintrag für „Intel(R) Smart Sound Technologie-OED“, welcher als „nicht gestartet“ (Code 10) markiert ist.

Auch an diesem kann man sich lange erfolglos abarbeiten. Ursache ist der vermeintlich fehlerfreie eintrag drüber: „Intel(R) Smart Sound Technologie-Audiocontroller“. Hier klickt man in den Details auf Treiber ? Treiber aktualisieren. Im Assistenten wählt mach „Auf dem Computer nach Treibersoftware suchen“ und dort „Aus einer Liste verfügbarer Treiber auf meinem Computer auswählen“.

Nun erhält man eine Liste aktueller und älterer Treiber. Statt der Smart-Sound-Technologie (SST) wählt man „High Definition Audio-Controller“ und installiert diesen. Im Anschluss erkennt Windows alle Geräte am Audio-bus neu und die Sound-Ausgabe sollte wieder wie gewohnt funktionieren.

PostgreSQL-Update im Docker-Stil

Docker. Eigentlich ja ganz praktisch, wenn man „mal schnell“ ein Softwarepaket trotz überschaubarer Wartbarkeit mit überschaubarem Aufwand ausrollen möchte, ab und an aber auch ein zuverlässiger Quell für Facepalm-Momente. So auch Heute: Nach dem Update einer mit docker-compose zusammengesetzten Anwendung ging nichts mehr. Der Maintainer hatte dort von postgres:10 auf postgres:11 aktualisiert. Kleines Update sollte man meinen, die PostgreSQL-Images für Docker sind jedoch technisch nicht in der Lage Daten älterer Installationen zu migrieren. Folglich zeigte sich im Log vor dem Absturz folgende Meldung:

postgres_1 | FATAL: database files are incompatible with server
postgres_1 | DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 11.6.

Was auf „normalen“ Servern mit pg_upgrade schnell geregelt und bei einigen Distributionen gar automatisiert ist, wird mit Docker ein paar Nummern komplizierter. Der Offizielle Weg: Backup machen, neu aufsetzen, importieren. Eigentlich wollte ich durch Docker Arbeit sparen, nicht mir weitere aufhalsen.

Glück im Unglück: Tianon Gravi hat auf GitHub und Docker Hub ein passendes System bereitgestellt, mit welchem man die Daten schnell zwischen verschiedenen PostgreSQL-Versionen migrieren kann.

Im Folgenden gehe ich davon aus, dass ein Named Volume „postgres-data“ existiert und alle darauf zugreifenden Container gestoppt sind.

Achtung, Fallstrick: Nutzt man docker-compose, so ändern sich die Volume-Namen. Ein Named Volume „postgres-data“ der Applikation „foobar“ heißt in Wahrheit „foobar_postgres-data„. Im Zweifel nochmal mit „docker volume ls“ prüfen.

  1. Fangen wir mit dem üblichen an: Backups. Bei Bind-Mounts kopiert man einfach den Quellordner passend zurecht, bei Named Volumes kann man diese üblicherweise unter /var/lib/docker/volumes/ finden oder mit docker-clone-volume duplizieren. Ich hatte postgres-data hierzu auf postgres-data-src und postgres-data-bck dupliziert.
  2. Weiter geht es mit dem Umwandeln der Datenbank. Hierzu nimmt man das Image mit den passenden Versionsnummern für Quell- und Zielversion.
    docker run --rm -v postgres-data-src:/var/lib/postgresql/10/data -v postgres-data-dst:/var/lib/postgresql/11/data tianon/postgres-upgrade:10-to-11
    Hiermit wird ein neues, mit PostgreSQL 11 kompatibles, Volume erzeugt, welches alle bisherigen Daten enthalten sollte.
  3. Leider gibt es in der aktuellen Version einen bekannten Bug, welche die Zugriffe in pg_hba.conf abweichend von den Dateien der offiziellen Images konfiguriert. Dies führt mit vielen Images zu Zugriffsfehlern. Um die Datei per hand zu editieren startet man entweder einen passenden Container oder greift über das Dateisystem des Hosts auf diese zu. In meinem Fall nutzte ich letztere Methode über die Datei /var/lib/docker/volumes/postgres-data-dst/_data/pg_hba.conf. An das Ende dieser wird folgende Zeile angefügt:
    host all all all md5
  4. Am Ende ändert man entweder den Volume-Eintrag seiner docker-compose.yml oder kopiert das neue Image passend zurück. In meinem Fall klang letzteres sinnvoller. Einen Befehl zum Umbenennen von Volumes ist Docker bis Heute nicht bekannt, daher bleibt hier nur das ursprüngliche Volume mit docker volume rm postgres-data zu löschen und postgres-data-dst – wie zuvor – mit docker-clone-volume oder im Dateisystem zum korrekten Volume-Namen zu klonen.

Warum man das nicht automatisiert erschließt sich mir nicht so ganz. Vermutlich beschränkt sich der Benutzerkreis hauptsächlich auf Entwickler, die ohnehin immer von 0 starten, und Enterprise-Häuser, die gemäß Fire-and-forget Systeme ohne Update bis zur Explosion betreiben.

Nginx: allow mit dynamic DNS

Wenn man Webseiten mit Backend betreibt ist es oft eine gute Idee die Verwaltungsbereiche nur von bestimmten IPs oder Netzen zuzulassen. Unter nginx gibt es hierzu den allow-Befehl, mit welchem man IPs und Netze angeben kann. Ich verwende dies z.B. häufig um nur interne IP-Bereiche oder per VPN angebundene Clients zuzulassen. Für ein aktuelles Projekt sollte jedoch auf ein VPN verzichtet werden. Theoretisch kein Problem – externe IP rein und fertig, aber leider ist es auch 2019 noch in Deutschland für viele Anschlussarten üblich bei Trennung und erneutem Verbinden eine andere IP-Adresse zuzuweisen. Für eingehende Verbindungen lässt sich dies mittels dynamischen DNS-Einträgen schnell in den Griff bekommen, jedoch ist das für das hiesige Konstrukt keine Option, da nginx mit solchen Einträgen nicht sinnvoll umgehen kann. Im Netz finden sich einige Helper-Scripte, welche den DNS regelmäßig Prüfen, die Konfiguration anpassen und den Webserver passend umkonfigurieren. Leider sind diese oft eher alt und nur auf das schon seit Jahrzehnten veraltete IPv4 ausgelegt. Als Abhilfe habe ich meine Anforderungen in ein kleines Python-Script gegossen. Für IPv6 wird von der aufgefundenen IP auf ein /48er Netz geschlossen und dieses freigegeben, sollte euer Provider nur ein /56er oder gar /64er rausrücken muss dass ggf. angepasst werden.

Vorbedingung ist, dass nginx die neue Konfiguration findet. Um es einfach zu halten stehen die dynamischen Einträge in einer separaten Textdatei, welche an passender Stelle per include eingebunden wird. Statische Einträge können, sofern vorhanden, an der üblichen Stelle bleiben.

[…]
location /admin {
        allow 192.168.0.0/24;
        include /etc/nginx/dyndns.conf;
        deny all;
        […]

Das eigentliche Script nutzt nach meinem Wissen keine externen Module und sollte somit auf jedem System mit Python 3 laufen. Es werden alle IPv4- und IPv6-Adressen abgerufen. Der angegebene Port (80) ist irrelevant, da nur die IPs genutzt werden. Die Konfiguration wird mittels MD5 auf Änderungen geprüft, liegt eine solche vor wird per Systemd eine reload ausgelöst. Ich habe die Datei mit in den nginx-Konfigurationsordner als /etc/nginx/dyndns.py gepackt – nicht schön, aber passte besser in die bereits vorhandene Struktur und Verwaltung.

#!/usr/bin/python3
import socket
import subprocess
import hashlib
import ipaddress


def md5(fname):
    hash_md5 = hashlib.md5()
    with open(fname, "rb") as f:
        for chunk in iter(lambda: f.read(4096), b""):
            hash_md5.update(chunk)
    return hash_md5.hexdigest()



before = md5("/etc/nginx/dyndns.conf")
cfg = open("/etc/nginx/dyndns.conf", "w")
addrs = socket.getaddrinfo("DEIN.DYNAMISCHER.DNS", 80, type=socket.SOCK_STREAM)
for addr in addrs:
    out = ""
    ip = ipaddress.ip_address(addr[4][0])
    if ip.version == 6:
        ip = ipaddress.ip_network(str(addr[4][0]) + "/48", False)
        out = (str(ip.network_address) + "/" + str(ip.prefixlen))
    else:
        out = addr[4][0]
    cfg.write("allow\t\t" + out + ";\t#Dynamic DNS\n")

cfg.close()

after = md5("/etc/nginx/dyndns.conf")

if before != after:
    #DNS has changed
    #print("RELOAD")
    subprocess.call('/usr/bin/systemctl reload nginx', shell=True)

Das Script muss regelmäßig gestartet werden um Änderungen zu prüfen. Wenn der zugehörige DNS-Dienst auf dem selben System läuft kann man möglicherweise auf Hooks zurückgreifen, andernfalls muss es zeitbasiert über Cron oder Timer laufen. Für letzteres mit einem Intervall von 5 Minuten legt man die Datei /etc/systemd/system/nginx-dyndns.timer an und füllt sie wie folgt:

[Unit]
Description=Nginx DNS updater

[Timer]
OnBootSec=0min
OnUnitInactiveSec=5m

[Install]
WantedBy=timers.target

Dazu benötigt man noch einen passenden Service, welcher unter /etc/systemd/system/nginx-dyndns.service definiert wird:

[Unit]
Description=Nginx DNS updater

[Service]
Type=oneshot
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/usr/bin/python3 /etc/nginx/dyndns.py

Last but not least wird der Timer eingeschaltet:

systemctl enable --now nginx-dyndns.timer

OSTicket: Ticketerstellung über Python

OSTicket ist ein freies Ticketsystem, also System zur Sammlung und Dokumentation von Aufgaben. Ab und an kann es praktisch sein solche Aufgaben auch per Software zu generieren, z.B. für wiederkehrende Aufgaben oder wenn Systeme Störungen automatisiert erkennen. Da die Doku bisher eher dünn ist anbei ein kleines Python-Script, welches über die API Tickets erstellen kann. Hierzu muss erst im Admin-Bereich ein passender API-Zugang angelegt werden. Zu beachten ist, dass ein solcher API-Zugang auf eine IP limitiert ist.

import requests
import json

headers = {'X-API-Key': '12345ENTERHERE12345'}
subject = "12345"

ostdata = {
    "alert": True,
    "autorespond": False,
    "source": "API",
    "name": "GenervterUser",
    "email": "genervter@us.er",
    "phone": "",
    "subject": str(subject),
    "ip": "::1",
    "message": "data:text/plain,Ich bin ein Ticket",
}

json_data = json.dumps(ostdata)

r =
requests.post("https://helpdesk.meinefirma.local/api/tickets.json", data=json_data, verify = '/usr/local/share/ca-certificates/meineca.crt', headers=headers)
print(r)

Hinweise:

  • Der verify-Parameter ist nur nötig, wenn man HTTPS mit einer im System unbekannten CA nutzt
  • Die Telefonnummer wird bei source=API wohl nicht angezeigt
  • Der Name wird bei erster Nutzung mit der E-Mail-Adresse verknüpft, wenn man weitere Tickets mit der selben E-Mail anlegt scheinen diese alle den zuerst genutzten Namen anzuzeigen

Weitere Doku

[NextCloud/EN] No login possible after Update to 13.0.4 due to encryption app

I ran into some trouble while Updating to NC 13.0.4 regarding encryption. As long as Encryption was installed and enabled no login was possible – WebDAV and Clients received HTTP/503, WebUI didn’t show the login form but only „Bad Signature“. Also occ failed with the same error – „bad signature“. The previously working version was afair 13.0.1, since downgrading isn’t supported I can’t say much for .2 and .3. Inside the log (see below) I could see the error being caused by the encryption module. There might be the odd encrypted folder still present in old accounts, but since it never worked for me reliably it’s disabled for everything currently in use. External solutions are IMO the way to go.

{"reqId":"xyz","level":4,"time":"2018-07-20T17:53:17+00:00","remoteAddr":"xyz","user":"--","app":"webdav","method":"PROPFIND","url":"\/remote.php\/dav\/files\/xyz\/","message":"Exception: {\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\ServiceUnavailable\",\"Message\":\"OCP\\\\Encryption\\\\Exceptions\\\\GenericEncryptionException: Bad Signature\",\"Code\":0,\"Trace\":\"#0 [internal function]: {closure}(*** sensitive parameters replaced ***)\\n#1 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Object(Closure), Array)\\n#2 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(466): Sabre\\\\Event\\\\EventEmitter-&gt;emit('beforeMethod', Array)\\n#3 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server-&gt;invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/html\\\/remote.php(72): Sabre\\\\DAV\\\\Server-&gt;exec()\\n#5 \\\/var\\\/www\\\/html\\\/remote.php(167): handleException(Object(OCP\\\\Encryption\\\\Exceptions\\\\GenericEncryptionException))\\n#6 {main}\",\"File\":\"\\\/var\\\/www\\\/html\\\/remote.php\",\"Line\":70}","userAgent":"Mozilla\/5.0 (Windows) mirall\/2.3.2 (build 1) (Nextcloud)","version":"13.0.4.0"}

The usual literature suggests to disable the encryption module using occ – not quite helpful in my case. Deleting the encryption app on FS-level did revive occ and Web but the App now failed due to missing encryption. My solution was to disable encryption using SQL instead of just deleting it:

UPDATE `oc_appconfig`
SET `configvalue` = 'no'
WHERE `oc_appconfig`.`appid` = 'core'
AND `oc_appconfig`.`configkey` = 'encryption_enabled';