Administratives Tagebuch

Das VPS auf dem stats.ffrn.de (Wiki) läuft wurde auf den aktuellen Tarif umgestellt. Das machte eine Neuinstallation des Servers nötig, da ein Umzug des existierenden Servers extra gekostet hätte. Doch durch die Vorarbeiten von @JevermeisteR (Grafana läuft seitdem in einem docker-compose Setup) und durch die Hilfe von Saltstack, war der neue Server zum Glück sehr schnell eingerichtet. So schnell, das ich für die Zeit des Umzuges Grafana in einer VM auf itter.ffrn.de (Wiki) laufen lassen konnte und es dadurch zu keinem allzu langen Ausfall kam.

Nun läuft stats.ffrn.de aber wieder auf dem externen Server und das Monitoring funktioniert dadurch wieder unabhängig von den 3 Hetzner Servern.

Unabhängig davon war ich aber doch etwas verwundert, das bei dem Anbieter IPv6 im Jahre 2020 nicht standardmäßig aktiviert ist. Das Leute IPv6 abschalten, ja mag vorkommen, auch wenn das wohl der falsche Weg ist. Aber das man es erst aktivieren muss, definitiv interessant.

Naja, wir beim FFRN überlegen jedenfalls eifrig, ob wir nicht die ersten sein wollen, die IPv4+ einführen. :crazy_face:

4 Like

Ich habe gerade mal in der nginx Konfiguration von fw.gluon.ffrn.de ein geo Konstrukt hinterlegt.
Damit ist es möglich eine Variable basierend auf der IP Adresse des anfragenden Clients zu setzten. Dadurch ist es nun möglich die IPv6 Addressen von Freifunk Routern auf eine Liste zu setzen und diese auf eine andere Firmware Seite umzuleiten.

Dies ermöglicht es nun Knoten welche länger nicht am Netz waren und welche daher die Firmware Signatur von uns neuen Admins nicht hinterlegt haben trotzdem auf die aktuelle Firmware zu updaten. Diese bekommen dann erst die 1.2.3-20191229 (welche von @NurticVibe signiert worden ist) und dann die aktuelle.

Wenigstens ist das der Plan.

Edit: Scheint zu funktionieren.

3 Like

Mhm, welcher Provider da wohl Probleme hatte?

2 Like

Da ich gerade das icvpn-meta Repository gefunden habe, habe ich gerade mal einen Pull Request erstellt um die Rhein-Neckar Daten zu updaten: https://github.com/freifunk/icvpn-meta/pull/603

Wir haben da aktuell zwar keine Verbindung, aber falls das doch noch mal wieder verbunden werden soll ist es sicherlich besser, wenn die Daten halbwegs aktuell sind.

2 Like

Ich habe stats.ffrn.de auf Grafana 7 aktualisiert.

2 Like

Der sync zwischen den authoritativen Nameservern (ns1.ffrn.de, ns2.ffrn.de und ns3.ffrn.de) wird nun per TSIG authentifiziert.

Seit heute Nacht setzen wir nun knot-resolver auf resolver1.ffrn.de und resolver2.ffrn.de ein. (Ein Resolver wird auch gerne allgemein „DNS Server“ genannt).

Bisher war es so, das der per DHCP verteilte „v4-resolver“ ein bind auf jedem der Gateways war. Die per Router Advertisement (IPv6) verteilen Resolver waren auch vorher schon resolver{1…2}.ffrn.de.

Da IPv6 sowieso bevorzugt wird sollte das eigentlich, bis auf die ganz paar Geräte die kein IPv6 können (wobei man mit denen vermutlich eh nicht in einem öffentlichen WLAN unterwegs sein sollte (da veraltet)), keinen Unterschied machen.

Die hauptsächliche Neuerung ist das wir nun DNSSEC überall strikt prüfen. Das bedeutet, das wenn der Eintrag nicht passt die resolver keine IP zurückliefern. Das ist aber nur relevant, wenn es einen DNSSEC Eintrag für die Domain gibt.

Beobachten kann man das ganz aktuell (wie @JevermeisteR festgestellt hat) auf cve.mitre.org. (Edit: Der Fehler wurde nun wohl behoben,)

1 Like

Nachdem chat.ffrn.de nicht mehr funktionierte stellte sich heraus, dass das mit der Umstellung auf direkte nftables Regeln (Debian 10 schreibt in der Standardeinstellung alle iptables Regeln zu nftables Regeln um) auf dem Host tools-itter.ffrn.de zu tun hatte. Beim Starten des RocketChat Docker Containers mittels docker-compose up -d bekam man einen wie folgend aussehenden Fehler:

ERROR: for rocketchat  Cannot start service rocketchat: driver failed programming external connectivity on endpoint rocketchat_rocketchat_1 (xxxxxxxxxxxxxxxxxxxxxxxxxxxxx):  (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 127.0.0.1 --dport 3002 -j DNAT --to-destination 172.18.0.2:3000 ! -i br-4905ae49b518: iptables v1.8.2 (nf_tables): Chain 'DOCKER' does not exist

Es stellte sich heraus, das ein systemctl restart docker hier Abhilfe schaffen konnte.

1 Like

Früher wurde collectd im Zusammenhang mit Graphite genutzt um ein paar Metriken zu sammeln. Doch da der Graphite Server nicht mehr verfügbar war führte das dazu das die Server beispielsweise bei Reboots erst in einen 90 Sekunden Timeout laufen mussten.

Nachdem ich auf den VM Hosts und den Gateways den Service neulich bereits deaktiviert und gestoppt hatte, habe ich nun gestern festgestellt gehabt, das auf v6upstream.ffrn.de dieser noch lief und sämtlichen RAM gefressen hatte.

Daher habe ich mittels salt '*' service.status collectd.service geprüft ob der sonst noch irgendwo läuft. Und wie sich herrausstellte lief er auch noch auf map.ffrn.de. Dort wurde er also in beiden VMs deaktiviert und gestoppt.

Leider ist v6upstream bisher nicht im Monitoring was Server Ressourcen angeht. Das werde ich nachholen. So kann ich leider nicht sagen wie lange da bereits aller RAM belegt war. Mein Eindruck war, das es keine grundsätzlichen Probleme mit IPv6 gegeben haben dürfte. Aber das ist nicht belegbar und es hat keine entsprechenden Tests gegeben.

Salt States

Inzwischen habe ich unsere Salt States mal veröffentlicht. Was da nicht enthalten ist, sind die Pillars. Das ist ein privates Repository in welchem die Konfigurationsdaten gespeichert sind. Dort stehen dann zum Beispiel die Passwörter drin. Oder aber auch die jeweiligen Werte für einzelne Konfigurationsoptionen auf den unterschiedlichen Systemen.

Das ist aber noch stark in Arbeit. Nicht enthalten sind da also zum Beispiel die Gateway Konfigurationen.

map.ffrn.de

Ich habe hier die neueste Version des Meshviewers ausgerollt (über Salt)

Firmware

Ich habe eine neue nightly auf Basis von Gluon 2020.1.3 hochgeladen.
Bei stable sind wir aktuell ja noch bei 2019.1.2. Das wird sich auch nicht unmittelbar ändern, da der aktuelle Plan nicht vorsieht Tiny Geräte (also hauptsächlich Geräte mit 4 MB RAM und 32 MB Flash - beispielsweise die „beliebten“ TP-Link 841) auf Gluon 2020 zu updaten, da sie damit nicht gut laufen. Das wird sich aufgrund der Hardware Limitierungen wohl auch nicht ändern.

Daher ist der aktuelle „Plan“ Multidomain unter Gluon 2019 einzuführen und dann die „ordentlichen“ :wink: Geräte auf Gluon 2020 zu updaten.

Gluon 2019 wird wohl auch noch etwas Pflege (Updats) erhalten, da vor der Problematik mit den tiny Geräten einige stehen.

Der Unterschied zwischen Gluon 2019 und 2020 ist übrigens hauptsächlich die neuere OpenWrt Version bei 2020.

Ich würde also definitiv davon abraten neue Tiny Geräte zu kaufen und sich mal darüber Gedanken zu machen, wenn man noch ein solches Gerät einsetzt), eventuell auf ein „zeitgemäßes“ Modell zu updaten.

3 Like

Es gab hier im Forum ein Problem das E-Mails nicht verschickt wurden und Push Benachrichtigungen gingen auch nicht raus. Sollte nun behoben sein. Hatte mit Änderungen in der Firewall zu tun. Da war Forwarding nicht richtig erlaubt.

1 Like

Weiterhin gibt es ab heute für unseren Blog unter https://blog.ffrn.de eine Kommentarfunktion. Es werden automatisch Themen im Forum für jeden Blogeintrag erstellt. Das gilt auch für ältere Blogposts.

3 Like

Ich habe gerade alle FFRN Systeme rebootet. Gab für Debian Kernel Updates.

Auf stats.ffrn.de kann man ganz schön sehen wie die Nodes dabei von Gateway zu Gateway wechseln mussten:

image

2 Like

Ich plane übrigens aktuell die Abschaltung von chat.ffrn.de. Sobald es soweit ist wird es aber nochmal eine größere Nachricht geben. Wirklich genutzt wird das meines Wissens aber eh nicht.

Wir Admins nutzen aktuell Matrix für unsere Kommunikation. Und es wurden auch schon mal öffentliche Räume eingerichtet:

Wie das alles ganz genau aussehen soll ist auch noch nicht klar. Und auch ob Matrix wirklich die Antwort auf die Frage ist wie wir leichtgewichtigere Kommunikation innerhalb der Community ermöglichen können ist nicht geklärt.

Dazu gehört auch ob wir öffentliche Accounts bereitstellen wollenn, können, … Da gibt es noch viele ungeklärte Fragen.

Aber wer einen Matrix Account hat kann ja mal joinen.

Noch ein Kommentar zu Matrix Accounts:

Ich persönlich würde eher von matrix.org abraten. Einerseits aus ideologischer Sicht, da es sich nun mal um eine sehr zentrale Instanz handelt, andererseits aber auch, da es (wenigstens in letzter Zeit) nicht ganz so stabil zu funktionieren scheint. Aber eine direkte Empfehlung (außer selber hosten), habe ich aktuell leider auch nicht. Ich habe nur beim kurzen Googlen gerade diese Liste mit öffentlichen Matrix Servern gefunden. Aber ob da wirklich eine ordentliche Alternative dabei ist weiß ich auch nicht.

Über die in der security.txt hinterlegte E-Mail Addresse hat sich Gaurav Popalghat (LinkedIn Profil) bei uns gemeldet und darauf hingewiesen, das wir bisher sehr großzügig mit einigen Versionsinformationen der verwendeten Software waren.
Während ich nicht viel von „Security through Obscouruty“ halte, so mag es eben vielleicht doch helfen, da bei einer neu bekanntgewordenen Sicherheitslücke ein Angreifer (bei beschränkten Ressourcen) sich vielleicht erst auf die Ziele konzentriert welche in Versionsdatenbanken mit der betroffenen Version gelistet sind. Das ist aber natürlich (falls überhaupt) nur ein minimaler zeitlicher Vorteil.
Da uns jedocch aktuell keine Nachteile bekannt sind (also zum Beispiel Software welche die Versionsinformation dafür braucht um zu entscheiden ob ein Workarround angewendet werden muss oder nicht), habe ich die Infos für ssh, knot (autoritativer nameserver) und nginx (Webserver) mal etwas eingeschränkt.

Heute in der Früh (03:00 - 03:45) habe ich altneckar.ffrn.de (Wiki) auf Debian 10 geupdatet (von Debian 9). Es war eine sehr kurzfristige Entscheidung, daher gab es keine Ankündigung.
Die Auswirkungen sollten sich um die Uhrzeit aber auch in Grenzen gehalten haben. Dieses Forum, die Karte, resolver1, gw05, gw06 und gw08 waren währenddessen nicht erreichbar. Das Netz als solches sollte aber nicht wirklich beeinträchtigt gewesen sein.

2 Like

Nun ist der letzte verbleibende Host dran. Dadurch wird es zu Einschränkungen bei IPv6 kommen.

Okay, auch auf elsenz.ffrn.de (Wiki) läuft nun Debian 10.

2 Like

Heute Nachmittag um 17:06 ist die Netzwerkverbindung auf altneckar.ffrn.de abgebrochen und das Teil war nicht mehr erreichbar. Um 18:02 habe ich einen manuellen Reset des Servers bei Hetzner beauftragt (manuell damit ein Techniker mal vor dem Neustart schaut ob da was auffälliges steht). Um 18:32 wurde der Reset dann durchgeführt und ich habe dann um 19:00 die VMs die dort laufen gestartet.

Ursache dürfte vermutlich ein Treiber/Firmware Problem mit der Netzwerkkarte zu sein. :slightly_frowning_face:

Mal schauen ob und wie man das beheben kann.

Jun 17 15:56:25 altneckar kernel: [130799.804952] e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jun 17 15:56:25 altneckar kernel: [130799.804952]   TDH                  <ad>
Jun 17 15:56:25 altneckar kernel: [130799.804952]   TDT                  <9b>
Jun 17 15:56:25 altneckar kernel: [130799.804952]   next_to_use          <9b>
Jun 17 15:56:25 altneckar kernel: [130799.804952]   next_to_clean        <ad>
Jun 17 15:56:25 altneckar kernel: [130799.804952] buffer_info[next_to_clean]:
Jun 17 15:56:25 altneckar kernel: [130799.804952]   time_stamp           <101f1cc3d>
Jun 17 15:56:25 altneckar kernel: [130799.804952]   next_to_watch        <ae>
Jun 17 15:56:25 altneckar kernel: [130799.804952]   jiffies              <101f1d030>
Jun 17 15:56:25 altneckar kernel: [130799.804952]   next_to_watch.status <0>
Jun 17 15:56:25 altneckar kernel: [130799.804952] MAC Status             <80083>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY Status             <796d>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY 1000BASE-T Status  <7800>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY Extended Status    <3000>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PCI Status             <10>
Jun 17 15:56:26 altneckar kernel: [130800.892485] e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
Jun 17 15:56:26 altneckar kernel: [130800.893533] br-mesh: port 1(eth0.4042) entered disabled state
Jun 17 15:56:30 altneckar kernel: [130804.255231] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

Entsprechende Einträge im Log habe ich auch auf elsenz.ffrn.de gefunden. „Normalerweise“ scheint sich das wieder zu fangen, aber ich vermute das hat dann heute Nachmittag nicht geklappt.

1 Like

altneckar.ffrn.de ist schon wieder ab etwa 07:19 nicht mehr erreichbar gewesen.

Ich hatte gestern, kurz nach den letzten Post, mal testweise einen neueren Kernel installiert, aber das hat dann wohl nichts gebracht. Schade

root@altneckar ~ # uname -a
Linux altneckar 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
root@altneckar ~ # apt install linux-image-5.5.0-0.bpo.2-amd64 linux-headers-5.5.0-0.bpo.2-amd64
root@altneckar ~ # reboot now
W: molly-guard: SSH session detected!
Please type in hostname of the machine to reboot: altneckar
root@altneckar ~ # uname -a
Linux altneckar 5.5.0-0.bpo.2-amd64 #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23) x86_64 GNU/Linux
2 Like

So sieht es übrigens aus wenn Updates für die Server verfügbar sind:

root@master ~ # salt '*' pkg.list_upgrades
gw02.ffrn.de:                
    ----------         
    libruby2.5:              
        2.5.5-3+deb10u2  
    ruby2.5:               
        2.5.5-3+deb10u2  
resolver2.ffrn.de:                        
    ----------         
    libruby2.5:              
        2.5.5-3+deb10u2
    ruby2.5:                 
        2.5.5-3+deb10u2
tools-itter.ffrn.de:         
    ----------  
    libruby2.5:              
        2.5.5-3+deb10u2
    ruby2.5:                 
        2.5.5-3+deb10u2
gw04.ffrn.de:                
    ----------
    libruby2.5:              
        2.5.5-3+deb10u2
    ruby2.5:                 
        2.5.5-3+deb10u2  
meet.ffrn.de:              
    ----------           
    libruby2.5:              
        2.5.5-3+deb10u2  
    ruby2.5:                 
        2.5.5-3+deb10u2  
git.ffrn.de:
    ----------
itter.ffrn.de:
    ----------
    libavcodec58:
        7:4.1.6-1~deb10u1
    libavfilter7:
        7:4.1.6-1~deb10u1
    libavformat58:
        7:4.1.6-1~deb10u1
    libavutil56:
        7:4.1.6-1~deb10u1
    libpostproc55:
        7:4.1.6-1~deb10u1
    libruby2.5:
        2.5.5-3+deb10u2
    libswresample3:
        7:4.1.6-1~deb10u1
    libswscale5:
        7:4.1.6-1~deb10u1
    ruby2.5:
        2.5.5-3+deb10u2
stats.ffrn.de:
    ----------
forum.ffrn.de:
    ----------
v6upstream.ffrn.de:
    ----------
gw03.ffrn.de:
    ----------
    libruby2.5:
        2.5.5-3+deb10u2
    ruby2.5:
        2.5.5-3+deb10u2
gw09.ffrn.de:
    ----------
    libruby2.5:
        2.5.5-3+deb10u2
    ruby2.5:
        2.5.5-3+deb10u2
tools-elsenz.ffrn.de:
    ----------
altneckar.ffrn.de:
    ----------
    libavcodec58:
        7:4.1.6-1~deb10u1
    libavfilter7:
        7:4.1.6-1~deb10u1
    libavformat58:
        7:4.1.6-1~deb10u1
    libavutil56:
        7:4.1.6-1~deb10u1
    libpostproc55:
        7:4.1.6-1~deb10u1
    libruby2.5:
        2.5.5-3+deb10u2
    libswresample3:
        7:4.1.6-1~deb10u1
    libswscale5:
        7:4.1.6-1~deb10u1
    ruby2.5:
        2.5.5-3+deb10u2
elsenz.ffrn.de:
    ----------
    libavcodec58:
        7:4.1.6-1~deb10u1
    libavfilter7:
        7:4.1.6-1~deb10u1
    libavformat58:
        7:4.1.6-1~deb10u1
    libavutil56:
    libavutil56:
        7:4.1.6-1~deb10u1
    libpostproc55:
        7:4.1.6-1~deb10u1
    libruby2.5:
        2.5.5-3+deb10u2
    libswresample3:
        7:4.1.6-1~deb10u1
    libswscale5:
        7:4.1.6-1~deb10u1
    ruby2.5:
        2.5.5-3+deb10u2
unifi.ffrn.de:
    ----------
tickets.ffrn.de:
    ----------
gw06.ffrn.de:
    ----------
    libruby2.5:
        2.5.5-3+deb10u2
    ruby2.5:
        2.5.5-3+deb10u2
gw05.ffrn.de:
    ----------
    libruby2.5:
        2.5.5-3+deb10u2
    ruby2.5:
        2.5.5-3+deb10u2
resolver1.ffrn.de:
    ----------
    libruby2.5:
        2.5.5-3+deb10u2
    ruby2.5:
        2.5.5-3+deb10u2
map.ffrn.de:
    ----------
    libruby2.5:
        2.5.5-3+deb10u2
    ruby2.5:
        2.5.5-3+deb10u2
gw08.ffrn.de:
    ----------
    libruby2.5:
        2.5.5-3+deb10u2
    ruby2.5:
        2.5.5-3+deb10u2

Und man kann die dann so einspielen:

root@master ~ # salt '*' pkg.upgrade
stats.ffrn.de:
    ----------
v6upstream.ffrn.de:
    ----------
gw02.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
forum.ffrn.de:
    ----------
git.ffrn.de:
    ----------
tickets.ffrn.de:
    ----------
tools-itter.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
resolver2.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
tools-elsenz.ffrn.de:
    ----------
gw04.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
meet.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
unifi.ffrn.de:
    ----------
itter.ffrn.de:
    ----------
    libavcodec58:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavfilter7:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavformat58:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavutil56:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libpostproc55:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    libswresample3:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libswscale5:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
gw03.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
gw09.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
elsenz.ffrn.de:
    ----------
    libavcodec58:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavfilter7:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavformat58:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavutil56:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libpostproc55:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    libswresample3:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libswscale5:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
gw05.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
map.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
gw06.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
resolver1.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
gw08.ffrn.de:
    ----------
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
altneckar.ffrn.de:
    ----------
    libavcodec58:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavfilter7:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavformat58:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libavutil56:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libpostproc55:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1
    libswresample3:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    libswscale5:
        ----------
        new:
            7:4.1.6-1~deb10u1
        old:
            7:4.1.4-1~deb10u1
    ruby2.5:
        ----------
        new:
            2.5.5-3+deb10u2
        old:
            2.5.5-3+deb10u1