Im abgeschotteten Intranet manchmal ein zeitsparender Faktor bei der Entwicklung, sollte man sich trotzdem genau überlegen, ob man Verbindungen von Systemen außer localhost zulassen möchte.

Auf einem Debian 10-System muß zuerst die Datei “50-server.cnf” im Verzeichnis “/etc/mysql/mariadb.conf.d/” angepasst werden:

$ cd /etc/mysql/mariadb.conf.d/
$ sudo vi 50-server.cnf

In der Datei dann die Zeile beginnend mit “bind-address” suchen und wie folgt ändern:

bind-address = 0.0.0.0

Diese Änderung bewirkt, daß der Server ab sofort über alle verfügbaren Netzwerkinterfaces erreichbar ist. Anschließend wird der Dienst neu gestartet:

$ sudo systemctl restart mariadb

Als nächster (und letzter) Schritt muß noch ein Benutzer für den externen Zugriff angelegt werden:

$ sudo mysql -u root
MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'remote'@'%' IDENTIFIED BY 'remotepassword';
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> EXIT
Bye

Anschließend kann von beliebigen Quelladressen mit dem Benutzer “remote” auf alle Datenbanken zugegriffen werden. Sinnvollerweise sollte man die Berechtigungen nicht so weitreichend vergeben, sondern auf einzelne Datenbanken (“Datenbank.*”) und Rechner (‘remote’@‘1.2.3.4’) beschränken.

Technik kann frustrierend sein, vor allem, wenn die mehr oder minder geplante Obsoleszenz zuschlägt. Ein gutes Beispiel dafür ist VoLTE, eine neue Technik, deren Vorteil in einem schnelleren Gesprächsaufbau sowie dem Wegfallen des Netzwechsels auf 2G / 3G beim Telefonieren liegt.

Das Google Pixel der ersten Generation ist seit Android 7.1.1 VoLTE-fähig, Congstar hat VoLTE im Laufe des Jahres 2020 freigeschaltet, trotzdem fehlt im Einstellungsdialog die benötigte Option:

Weiterlesen

Manche Funktionsbezeichnungen lassen Interpretationsspielraum, wo besser keiner sein sollte. Die WordPress-Funktion “is_admin()” ist so ein Fall, denn wie die WordPress Code Refernce erklärt

Does not check if the user is an administrator

“is_admin()” prüft lediglich, ob der Aufruf innerhalb der Administrations-Oberfläche erfolgte. Wer sich für die tatsächlichen Berechtigungen des angemeldeten Benutzers interessiert, sollte “current_user_can()” verwenden.

Es gibt verschiedene Strategien, wie die Änderung einer Datei gespeichert werden kann. Die beiden i.d.R. eingesetzten Verfahren sind entweder die vorhandene Datei mit dem neuen Inhalt zu überschreiben oder aber den geänderten Inhalt in eine neue Datei zu speichern und dann die Dateien auszutauschen.

Unter Sicherheitsaspekten ist der Dateiaustausch klar vorzuziehen, denn erst wenn der neue Inhalt erfolgreich in die neue Datei gespeichert wurde, wird die bisherige Datei gelöscht. Beim direkten Überschreiben kann entweder beim Zugriff durch andere Programme eine halbfertige Datei geliefert werden oder es kommt durch Hardware- / Software-Fehler zu einer Situation, in welcher der alte Inhalt bereits zerstört, der neue Inhalt aber nicht erfolgreich geschrieben werden kann.

Dies hat Auswirkungen auf die Möglichkeiten, mittels inotifywait auf Dateiänderungen zu reagieren. Während beim direkten Überschreiben inotifywait ordnungsgemäß eine Änderung der Datei registriert, bricht inotifywait beim Dateiaustausch ab - die z.B. im Beitrag “Sass ohne Ruby” geschilderte Vorgehensweise scheitert dann, da die ursprünglich überwachte Datei ja nicht mehr existiert.

$ while inotifywait -e close_write style.scss; do sassc --style compact style.scss style.css ; done

Eine Möglichkeit, dies zum umgehen, ist das Überwachen des kompletten Verzeichnisses mit Abfrage der geänderten Datei

inotifywait -e close_write,moved_to,create -m . |
while read -r directory events filename; do
	if [ "$filename" = "style.scss" ]; then
		sassc --style compact style.scss .style.css
	fi
done

was aber - je nach Anzahl der im Verzeichnis vorhandenen Dateien und deren Änderungshäufigkeit - zu einer erhöhten Systemlast führen kann.

Soll das Skript, welches die WSUS-Updates genehmigt (oder ablehnt) nicht auf dem WSUS-Server selbst sondern auf einem anderen Server ausgeführt werden, scheitert dies zunächst mit der Fehlermeldung

Der Typ [Microsoft.UpdateServices.Administration.AdminProxy] wurde nicht gefunden.

Grund ist das Fehlen der benötigten Powershell-Cmdlets, welche zur Ausführung installiert werden müssen. Eine Suche im Internet führt meist in die falsche Richtung, nämlich zu Installationsanleitungen für die WSUS 3.0 SP2 Administration Console, welche aber für den unter Server 2019 verwendeten WSUS schon ein paar Tage zu alt ist.

Die benötigten Module lassen sich über den “Assistent zum Hinzufügen von Rollen und Features” installieren, hier ist unter “Features” der Punkt “Remoteserver-Verwaltungstools” / “Rollenverwaltungstools” / “Windows Server Upgrade Service-Tools” / “API- und PowerShell-Cmdlets” zu wählen.

Als letztes muß in dem Skript nur noch eine Zeile zum Zugriff auf den Remote-Server angepasst werden:

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($serverName, $useSecureConnection, $portNumber)

Der Aufruf der Funktion “getUpdateServer” wird um die drei selbsterklärenden Parameter “$serverName”, “$useSecureConnection” sowie “$portNumber” erweitert.