Posts by Lukasz

Mein Problem ist in erster Linie die Auto Registrierung in Verbindung mit meinem Workflow zur Bereitstellung der Systeme. Dadurch, dass der Agent ohne host.conf das erste mal startet, bevor die IP Config durch DHCP fertig ist, läuft die Registrierung gegen die Wand.

Aug 27 10:58:10 [ERROR] $VAR1 = { 
         'offset' => 0, 
         'server_time' => '1756285090676', 
         'status' => 'err-610', 
         'maintenance' => 'disabled', 
         'total' => 2, 
         'who_am_i' => 'bloonix.home', 
         'size' => 2, 
         'version' => 143, 
         'data' => { 
                     'failed' => [ 
                                   'ipaddr' 
                                 ], 
                     'message' => 'Please fill in the red marked fields correctly!' 
                   } 
       };

Mein Playbook, das am Bloonix Server den neuen Host aktiviert, greift dann ins leere. Wenn der Agent einmal registriert ist, ist das kein Problem mehr, richtig.

Ich habe jetzt auch gelernt, dass die Lösung simpler sein kann. Anstatt das interface mit allow-hotplug zu deklarieren, nimmt man einfach auto. Dann starten die Dienste auch mit dhcpcd nachdem die IP Config fertig ist.

Macht Sinn - ich habe mein pressed initial für Debian 9 geschrieben und es hat nur bedingt Spaß gemacht. Danach wurde es aber nur kopiert und auf die Version angepasst. Meine Systeme sind in der Basisinstallation recht statisch.

Kurzes Update zu dem Problem bei der Registrierung durch die verzögerte dhcp Client config.

Debian 13 hat per Default vom isc-dhcp-client auf dhcpcd gewechselt. Das Zusammenspiel von ifupdown und dhcpcd ist noch nicht ganz rund, da dhcpcd wohl im Hintergrund forked und sich um die Adresse beiläufig kümmert. Sobald die Schnittstelle carrier hat und gerade mal einen link-lokal v6 da ist, ist ifup durch und es werden bereits weitere Services gestartet. Die IP-Adresse von dhcpv4 kommt erst einige Sekunden später und braucht noch weitere ~5 Sekunden bevor diese angewandt wird, wenn man ARP Probing aktiviert lässt.

Ich habe es mit mal mit ifupdown-wait-online.service versucht, was auch etwas extra config und ein zuverlässiges ping Ziel benötigt, um die Dienste nach der IP Vergabe zu starten . Finde ich nur bedingt gut. Die IP Konfiguration in die Hände von systemd zu geben und dann systemd-networkd-wait-online.service mit -o routable zu verwenden wollte ich auch nicht.

Schlussendlich habe ich erst einmal während der Basisinstallation isc-dhcp-client wieder rein gedreht. Damit funktioniert es sauber und die Dienste starten erst nach der IP Konfiguration. Ich befürchte, dass der Bloonix-Agent nicht der einzige Dienst sein wird, der Probleme macht, wenn dieser vor der finalen IP Konfiguration startet.

Quote from Jonny

Die Probleme mit der IP lassen sich umgehen, in dem der Wert fest übergeben wird. Oder du ermittelst die IP selbst und schreibst sie in die Registrierungsdatei.

Das wäre auch eine Idee. Müsste der Eintrag in der register.conf dann ipaddr <ip> lauten? Das könnte ich mit einem Platzhalter in der config-Datei und einem sed oneliner im preseed file noch abwickeln. Die IP bekomme ich mit ip -br a | grep 'ens.*UP' | awk '{split($3, ip, "/"); print ip[1]}' einfach zu greifen.

ich würde aber noch mal schauen wieso Debian13 sich hier anders verhält als seine Vorgänger.

Quote from Jonny

Mein Tipp: net.ifnames=0

Damit hast du überall eth0 als erstes Interface, was man für die IF-Checks sauberer einbinden kann, ohne vorher ermitteln zu müssen, wie denn nun der Name des Interfaces ist.

Das habe ich bereits etwas anders gelöst. Im preseed wird ein register.conf Template mit dem Eintrag variables NIC=@@NIC@@ kopiert und dann entsprechend angepasst.

in-target sed -i "s/@@NIC@@/$(ip a | grep 'ens.*UP' | cut -d ":" -f 2  | sed 's/^[ \t]*//')/g" /etc/bloonix/agent/register.conf;

Die IF-Checks in den Templates nutzten dann nur noch die %NIC% Variable.

Aug 25 16:22:10 debianvm49 systemd[1]: Reached target network-online.target - Network is Online. 
Aug 25 16:22:10 debianvm49 systemd[1]: Starting bloonix-agent.service - Bloonix Agent...

[...]

Aug 25 16:22:11 debianvm49 ifup[819]: ens33: soliciting a DHCP lease 
Aug 25 16:22:11 debianvm49 dhcpcd[819]: ens33: soliciting a DHCP lease 
Aug 25 16:22:11 debianvm49 ifup[819]: ens33: offered 172.16.40.36 from 172.16.6.3 
Aug 25 16:22:11 debianvm49 dhcpcd[819]: ens33: offered 172.16.40.36 from 172.16.6.3 
Aug 25 16:22:11 debianvm49 dhcpcd[819]: ens33: ignoring offer of 172.16.40.36 from 172.16.6.4 
Aug 25 16:22:11 debianvm49 ifup[819]: ens33: ignoring offer of 172.16.40.36 from 172.16.6.4 
Aug 25 16:22:11 debianvm49 ifup[819]: ens33: probing address 172.16.40.36/24 
Aug 25 16:22:11 debianvm49 dhcpcd[819]: ens33: probing address 172.16.40.36/24 
Aug 25 16:22:13 debianvm49 ifup[819]: ens33: soliciting an IPv6 router 
Aug 25 16:22:13 debianvm49 dhcpcd[819]: ens33: soliciting an IPv6 router

Die Dienste laufen schon alle an, bevor der dhcp client sich ausgetobt hat. Das ist in erster Linie ein Problem mit Debian 13 .. nicht unbedingt des bloonix-agents. Der Agent scheint allerdings die IP-Adresse nur einmalig beim Start zu ermitteln. Aller weiteren Versuchen basierend auf dem Wert aus dem initialen Start.

Ich installiere den Agent schon während der OS-Installation - in meiner preseed Datei definiert mit ( d-i pkgsel/include bloonix-agent und weitere Pakete für meine Standardinstallation ) .

d-i preseed/late_command wird nach der OS Installation samt Zusatzpaketen ausgeführt, hier ist die bloonix Gruppe mit der ID 1000 schon vorhanden.

d-i preseed/early_command ist too early, weil noch kein OS Installiert ist.

Ich könnte sicher etwas drum herum bauen wie z.B. die Agent Installation aus dem preseed herausnehmen und später mit Ansible samt Fix der Gruppen ID drüber bügeln - daran soll es nicht scheitern. Ich bin der Meinung, dass bereits bei der Installation der Software die notwendige Gruppe als System-Gruppe (ID < 1000) vom Paket her deklariert werden sollte.

Ich habe das Thema mit der Gruppen ID zwar für die Legacy Variante angesprochen, allerdings betrifft es auch die neue Bloonix Version - hier sieht der preinst Teil identisch aus. Cool wäre es wenn du das für Bloonix v2 anpassen könntest.

Quote from Jonny

Es wäre ratsam sich so langsam von der alten Bloonix Version zu verabschieden.

Ich weiß, nur muss ich die Zeit finden mich mit der neuen Version zu beschäftigen und meinen Zoo an Custom Plugins von perl auf python zu portieren. Ich finde es schon super, dass du Bloonix v2 bis runter zu Stretch paketiert hast - hiervon habe ich noch paar Maschinen am laufen

Edit: Mein größeres Problem ist gerade, dass bei Trixie nach dem ersten Boot die IP-Adresse vom Agent nicht ermittelt werden kann und die Registrierung auf die Nase fällt.

Danke dir - ich habe zwischenzeitig das Paket für Bookworm getestet und es funktioniert weitestgehend. Ich passe allerdings noch das systemd file etwas an, da systemd hier etwas zu meckern hat. Das ist aber nicht weitere tragisch.

/usr/lib/systemd/system/bloonix-agent.service:17: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. 
Aug 25 08:10:08 debianvm48.home.dc systemd[1]: /usr/lib/systemd/system/bloonix-agent.service:18: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether.

Zusätzlich habe ich einen restart eingebaut, sollte der Agent aus irgend einem Grund mal auf die Nase fallen.

[Unit]
Description=Bloonix Agent
After=network.target
StartLimitInterval=30
StartLimitBurst=5
[Service]
Type=forking
PIDFile=/run/bloonix/bloonix-agent.pid
ExecStartPre=/usr/lib/bloonix/bin/bloonix-pre-start /var/lib/bloonix /var/lib/bloonix/agent /var/log/bloonix /run/bloonix
ExecStart=/usr/bin/bloonix-agent --pid-file /run/bloonix/bloonix-agent.pid --config-file /etc/bloonix/agent/main.conf --sock-file /run/bloonix/bloonix-agent.sock
ExecReload=/bin/kill -1 $MAINPID
ExecStop=/bin/kill -15 $MAINPID
PrivateTmp=false
TimeoutStartSec=15
TimeoutStopSec=30
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Cool wäre es wenn man im preinst Teil des core paketes die bloonix gruppe mit groupadd -r bloonix anlegt, damit die id < 1000 ausfällt. Beim User passiert das. Da ich mein Server mit einem preseed betanke und während der Installation schon der Agent drauf kommt, schnappt dieser sich für die Gruppe immer die id 1000.

uid=988(bloonix) gid=1000(bloonix) groups=1000(bloonix)

In meinem ersten Anlauf ist die automatische Registrierung nicht gelaufen, weil ich IP Adresse nach dem Neustart ermittelt werden konnte. DNS Einträge passen jedoch. Nach einem Neustart des Agent hat dieser die IP dann auch gefunden. Ich teste das mal mit den neuen Paketen auch wenn ich auf den ersten Blick keine speziellen Anpassungen für Trixie gesehen habe

Hi Jonny,

besteht die Chance noch einen Agent Paket für Debian 13 Trixie zu bekommen, der kompatibel mit der Perl Version ist?

Mein Bloonix Server möchte noch sein 10 Jähriges feiern

Filesystem created:       Sun May  1 11:32:02 2016

Grüße

Lukasz

Ich gehe davon aus es handelt sich bei den Servern um VMs und diese werden Nachts gesichert, wofür ein Snapshot erforderlich ist. Die Stun-Time für die Löschung des Snapshots nach dem Backup lässt die Zeit auf dem System driften. Sollten es Agent-basierende Backups sein, kann die erhöhte Last zu Live-Migration führen, was ebenfalls eine Stun-Time auf den Systemen erzeugt bzw. einen Time Sync über die Guest Tools triggert.

Abhängig von deiner NTP Client Konfiguration kann eine erneute Zeit Synchronisation stattfinden, nachdem Bloonix Alarm schlägt. Entweder passt du die Intervalle an ,in welcher die Zeit auf dem System geprüft wird oder du lässt den NTP Client regelmäßiger syncen.