Ways of working

Infrastruktur
1

Fortsetzung der Diskussion von Neuer Firmwarebuild (experimental: 0.7.4~68) steht bereit:

Nope, Limit bei Antwort-per-Mail. Da soll eigentlich auch noch ein angepinnter Post hin, a) was und b) wie da vorzugsweise rein soll. 10-Finger-Adler-Such-System hat halt keinen unendlichen Durchsatz, und der Textpool ist auch leer bei der Wärme :wink:

Im Dashboard selber gibt es noch die milf und möglicherweise weitere veraltete Systeme?

Yepp. milf & angua müssen raus, inflexible und thunderflare rein, die Widgets neu organisiert (zu viele Systeme in GT).

gw03 müßte man mal neu aufsetzen (crasht ja den Host ;(), Konnektivitätsproblem mon<>bgp3 untersucht (bgp3 läuft, AFAIK).

Bezüglich Monitoring vs Humanoide: Gibt es denn die Möglichkeit zur Alarmierung? Mail, SMS, Messenger? Dann sollte man doch mal die uid 0 Inhaber damit belästigen.

Aktuell geht’s an die technik-Mailbox, auf die mehrerere per IMAP Zugriff haben. Allerdings lösche ich mittlerweile auch mehrmals täglich nach Sichtung die Meldungen; dabei ist dann mindestens mir die dhcprelay-Meldung durchgerutscht.

Ich kann das gerne umstellen, auf das die uid-0-Inhaber diese Mails bekommen. An sich war geplant, heute eine neue Batterie in willikins zu verlieren, aber der Tausch geht nicht online, da müssen die mittleren Lüfter raus und dann vorne die Pufferbatteriehalterung rausgepfriemelt … Neuer Plan ist jetzt, willikins leer zu ziehen und dann den Umbau machen zu lassen; Hintergrund ist der Einsatz von ovs auf den älteren Systemen und potentielle Probleme beim Reboot (statische vs. dynamische Portvergabe oder sowas). Neuere Systeme laufen z. Zt. wieder nur mit der Standard-Bridge, da ovs bislang uns nichts bringt, außer mehr Komplexität. (Außer Ralf, wer von den UID-0ern spricht flüssig ovs-vsctl? ;))

Langer Vorrede Hintergrund: derzeit gibt es mehrfach täglich FLAPPING-Mails von Icinga2, da der RAID-Test mit der Meldung des SmartArray-Tools nichts anfangen kann. Solange willikins also keine neue Pufferbatterie bekommt, bleibt das so (oder man deaktiviert den Test komplett und verpaßt ggf. defekte Platten).

2

Ziel sollte ja sein, das die uid-0 Besitzer nicht in Meldungen ersaufen, vielleicht sollte man es mit einer Positivliste versuchen. Nicht laufende Prozesse auf den Servern sollten da schonmal ein stabiles Kriterium sein. Andererseits sollte man die ja auch per systemd-Magie oder monit-Holzhammer wieder an den Start bringen können?

3

Ziel sollte ja sein, das die uid-0 Besitzer nicht in Meldungen ersaufen, vielleicht sollte man es mit einer Positivliste versuchen.

Wenn man dazu cut&paste-bare Kommandos für Icinga2s Konfigurationsfiles hat, also, mindestens ich würde mich bereiterklären, die einzuhacken.

Nicht laufende Prozesse auf den Servern sollten da schonmal ein stabiles Kriterium sein. Andererseits sollte man die ja auch per systemd-Magie oder monit-Holzhammer wieder an den Start bringen können?

Puh, ja, irgendwie hatte ich mal verstanden, daß systemd der Ersatz für sonderbare djb-Lösungen sein sollte.

Gut, konkrete Erschwernis: apt-get upgrade installiert neuere Pakete, die halt den Patch nicht haben (den Upstream keiner wollte?; nein, nicht meiner, müße https://github.com/marschap/debian-isc-dhcp/pull/1/files?diff=split gewesen sein), sodaß die Kommandozeilenoption, die wir brauchen, nicht mehr da ist, somit startet dhcrelay nicht. Täte es starten, würde es dennoch nicht funktionieren, insofern fast die bessere Lösung. »apt-mark hold isc-dhcp-client isc-dhcp-common isc-dhcp-relay« tut jedenfalls die Pakete nicht vor Upgrades schützen. Ich habe auf gw01 erst einmal apt-get entsorgt: »mv /usr/bin/apt-get /usr/bin/apt-get.real«, um das Problem nicht mehr zu haben. Präzision einer ICBM, ok, ging aber schnell und ist nachhaltig (hoffe ich). Dafür wird der apt-Test von gw01 nun seine Farbe ändern …

Schnelle Lösung: man baut eben neue Pakete. Hält bis zum nächsten Update.

Realistische Lösung: man hat immer aktuelle Pakete mit dem Patch in eigenem Repo. Wer das skripten kann: seine Dienerschaft Jenkins steht Gewehr bei Fuß, der Patch liegt auf s3.4830.org:/usr/src/dhcrelay-remote-id.patch … Hält zumindest, bis der fuzz zu groß wird.

Saubere Lösung: ISC/»Upstream« baut die Option ein. Dauert wohl solange, wie es hielte: ewig.

Kurzum: es gibt für »man« viel zu tun :wink:

4

Ich hab’ mal angefangen mit einem »Tagebuch«, neben wiederholten Tätigkeiten und wichtigen Änderungen werde zumindest ich da auch die »Altlasten« verlieren, sprich Dinge, die z. B. nach einem Reboot nicht automatisch behoben werden. Dinge, die andererseits wg. Langzeitstabilität der VMs aber auch nicht so nervig sind, daß sofort daran was gemacht werden müßte.

Kann »man« z. B. nehmen, um sich bei Langeweile an der FF-Infrastruktur auszutoben :wink: