Update-Notify/Public
Notwendigkeit eines Update-Monitoring
Unabhängig vom konkreten Clientmanagement-System (OPSI, ACMP, Baramundi, SCCM/Intune, Matrix42 etc) ist es zwingend notwendig, über das Erscheinen von Updates/Security-Fixes informiert zu werden. Durch die SW-Hersteller erfolgt dies auf die verschiedenste Art und Weise:
- Ankündigungen auf derem Website bzw. Forum,
- eintragen in deren Mailinglisten,
- Abonnieren von RSS-Feeds,
- Benachrichtigung bei Starten der Applikation auf dem Client
- usw. ...
Meines Erachtens ist diese Art Monitoring nur für eine kleine Anzahl von SW-Produkten (<30?) händisch möglich.
Nur wenige Applikationen updaten sich selbst über eigene Services, z.B. Google-Chrome, Firefox, Thunderbird sowie die meisten Applikationen aus dem MS-Store.
Aus der Summe der vorliegenden (statistischen) Daten seit 05/2015 kann man ableiten, dass ca. pro zwei SW-Produkten durchschnittlich ein monatliches Update anfällt.
Bei beispielsweise 60 SW-Anwendungen des gemanagten Clientpools sind also MONATLICH ca. 30 Updates bereitzustellen und auszurollen.
Lebenszyklus SW-Paket im Clientmanagementsystems
Allgemein kann man den Lebenszyklus eines Software-Produktes innerhalb eines Clientmanagement-Systems wie folgt darstellen:
Beschreibung des freien Services 'o4i-DFN-Notifier'
Um den mühseligen Teil der Beobachtung diverser Herstellerseiten zu reduzieren, informieren wir automatisiert über SW-Produkte mit häufigen Updates. Der Update-Notifier ist ein o4i-Service des Leibniz-Institut für Bildungsmedien | Georg-Eckert-Institutes (GEI). Es werden ca. 270 Applikationen (Stand September 2025) gemonitort.
Zeit-gesteuerte Scripte parsen die jeweilige Hersteller-Website des Produktes, extrahieren die dortige aktuelle Versionsnummer und Download-Link, vergleichen diese Informationen mit der letzten bekannten Version. Gegebenenfalls wird das Hersteller-Setup-File gedownloadet und analysiert. Das Erkennen einer neue Produktversion generiert eine eMail und trägt es gleichzeitig in die Log-Dateien des Webservice ein.
Die Benachrichtiung erfolgt über eine DFN-Mailingliste "o4i-notify"(read-onlny) und seit Frühjahr 2025 zusätzlich über einen Webservice "https://o4inotify.gei.de".
Die versionierte SW-Entwicklung der Scripte erfolgt über unser o4i-GIT: https://git.o4i.org/o4i-infra/notify-server (bitte Fehler als Issue melden...)
Mailing-Liste "o4i-notify"
Listenanmeldung per Mail: --> anonyme Listen-Anmeldung per eMail
(Mail an LISTSERV@LISTSERV.DFN.DE mit Body "SUBSCRIBE O4I-NOTIFY Name ODER Anonymous ", später Confirm-Mail bestätigen...).
Listenanmeldung per Web: https://www.listserv.dfn.de/sympa/info/o4i-notify (Website der Liste)
Listenarchiv: https://www.listserv.dfn.de/sympa/arc/o4i-notify/2025-09/ (monatsweise), Das Mailinglisten-Archiv mit dem Datenbestand ab Mitte 12/2015 läßt sich durchsuchen.
Das monatliche Mailaufkommen ist anwachsend und beträgt zur Zeit ca.140 Benachrichtigungen, gegebenenfalls sollte man sich die Mailingliste als "Digest/Zusammenfassung" konfigurieren.
Die dann bei einem vorliegendem Update versandten Benachrichtigungs-eMails haben folgende feste Struktur:
FROM: "Opsi DFN Notify" (via o4i-notify Mailing List) <o4i-notify@listserv.dfn.de>
SUBJECT: [opsipackage]-{$PAKETNAME} Update gefunden! [alteVersion]->[neueVersion]
MAILBODY: Sie finden ein Update der Software {$PAKETNAME} Version [$DOWNLOAD_VERSION] unter $DOWNLOAD_LINK.
und sind damit "filter- / SIEVE-" freundlich.
Bemerkung:
Update-Benachrichtigungen mit der AltVersion '[0000] bzw. [0.0.0]' o.ä. kennzeichnen den Monitoring-Start eines neuen SW-Produktes.
Hinweis:
manch ungewöhnliche Änderung auf der SW-Herstellerseite kann zu einer Falschmeldung führen, das scheint nicht zu vermeiden zu sein - die Fehlerquote ist aber gering.
Der Notify-Service ist auch in das zentrale Monitoring eingebunden, damit werden die meisten Fehler (Download-Error, Version#-Error u.ä.) signalisiert:
Webservice "o4inotify.gei.de"
Seit Frühjahr 2025 werden die ermittelten Daten auch über einen einfachen Webservice https://o4inotify.gei.de/ bereitgestellt:
Diese Auflistung ist über den Spaltenkopf einfach sortierbar ... alphabetisch, Datum, Größe
Es gibt zwei spezielle Log-Dateien:
notify_allcurrent.log --> Liste über alle Produkte mit dem jeweils letzten Versionsstand (pro Produkt eine Zeile) notify-allhistory.log --> Liste über alle Versions-Checks des laufenden Jahres (lang ... aktuell ganz unten!)
Eine produktspzifische Log-Datei ist eine strukturierte Text-Datei, in der die letzte Zeile den aktuellsten Versions-Informationen enthält.
(Beispiel: https://o4inotify.gei.de/notify_vscode.log)
Hinweis:
in den produktspezifischen Log-Dateien sind die Notify-Meldungen von 2015 bis Frühjahr 2025 noch nicht eingepflegt!
Ansatz als Startauslöser für CI/CD (Continuous Integration/Continuous Delivery)
Für den automatisierten Versionsabgleich bietet sich der Aufruf des produktspezifischen Logfiles und die Auswertung der letzen Zeile an (Beispiel "vscode"):
wget -qq -O - https://o4inotify.gei.de/notify_vscode.log | tail -1 | cut -d';' -f7
Ähnlich ist die Auswertung der Gesamtliste "notify_allcurrent.log" mit einer einzelnen Produktzeile:
wget -qq -O - https://o4inotify.gei.de/notify_allcurrent.log | grep ';vscode' | cut -d';' -f7
Eine einfache Liste mit den Produktnamen der gemonitorten Produkte generiert man z.B. mit:
wget -qq -O - https://o4inotify.gei.de/notify_allcurrent.log | cut -d';' -f6 | sort > o4inotify_all-products_$(date +%F).lst
Log-Datei Datenstruktur (Versionsstand 2.0):
1758856046;2025-09-26;05:07;CEST;2.0;vscode;1.104.2;https://code.visualstudio.com/sha/download?build=stable&os=win32-x64 # | | | | | | | | # Unix-Timecode | | | | | | | # | | | | | | | # Date | | | | | | # Time | | | | | # TimeZone | | | | # intDataStruc | | | # Product | | # ProductVersion | # Download-URL
Vortrag "Neues vom Notify-Service" (o4i-Communitytreffen 11.Juni 2025)
Auf dem o4i-Communitytreffen wurde im Rahmen der Koordinatorengruppe darüber in einem Vortrag informiert.
Dieser ist hier als PDF abrufbar Medium:O4i-community3_NeuesVomNotify_FINALmini.pdf.