IPv4-NAT vom Firmware-Server repariert.
Interne IP hatte sich geändert -> iptables angepasst.
2 „Gefällt mir“
Dem Firmware-Server eine Native IPv4 spendiert da das NAT andauernd kapod is und die IP noch frei war…
2 „Gefällt mir“
Auf der neuen check MK VM Port 111 per iptables gedropt und iptables-persistent installiert weil das BSI Portmapper doof findet und Nervmails verschickt… rpcbind ist wohl eine Abhängigkeit von Check MK daher hab ich es nicht einfach deinstalliert.
2 „Gefällt mir“
Auf der check_mk-Kiste:
systemctl stop rpcbind
systemctl stop rpcbind.socket
systemctl disable rpcbind.socket
systemctl disable rpcbind
systemctl disable rpcbind.target
systemctl stop rpcbind.target
Ich hatte deinen Post vorher nicht gelesen. @corny456.
Doppelt hält besser 
3 „Gefällt mir“
Zertifikate für den CheckMK-Server status.tld konfiguriert.
1 „Gefällt mir“
Was lange währt, wird endlich gut: corny läuft mit dem Ansible-Zweig as-router-als-gateway mit ifupdown2 produktiv. 
eth0 kann auf Grund des folgenden Bugs noch nicht neu gestartet werden: https://github.com/CumulusNetworks/ifupdown2/issues/147
Dies kann manuell umgangen werden:
ip addr del 144.76.69.56 peer 144.76.69.37/32 dev eth0
1 „Gefällt mir“
Da mir aufgefallen war das diverse IPs aus zwielichtiger Herkunft ein starkes Interesse an unseren SSH Zugängen haben, hab ich mal eine kleine fail2ban rolle gebaut und auf alles was so da ist ausgerollt. Mit Ausnahme der debian 8 Maschinen. Da ist die Installation fehlgeschlagen und da wir die eh abreißen hab ich da keine mühe investiert.
IPs werden für 60 Minuten geblockt wenn sie mehr als 3 Fehlgeschlagene Logins binnen 10 Minuten hatten.
3 „Gefällt mir“
Wiki war nicht erreichbar. Updates gemacht und neu gestartet.
1 „Gefällt mir“
Reverse-User auf Parad0x neu angelegt und autossh auf dem Server an der BEZ repariert.
PS: + LAFP
1 „Gefällt mir“
Festplatte vom meshviewer war vollgelaufen.
Logrotate war kapod und somit hatten sich 15GB Syslog angehäuft.
Konkret mussten nur die Rechte von /var/log auf 755 gesetzt werden. Keine Ahnung warum das nicht so war…
Abschließend noch schnell n paar Updates gemacht und alles durchgebootet.
2 „Gefällt mir“
Stats Server upgedatet und neu gestartet.
2 „Gefällt mir“
rowe’s Hypervisor erhielt Updates und startete neu.
2 „Gefällt mir“
Blech unter TJ01 hat updates bekommen und einen Reboot gemacht.
würde demnächst ein upgrade von Ubuntu 18,xx auf 20.04 machen
oder auf ein neues Blech wechseln?
2 „Gefällt mir“
Confluence Lizenzen verlängert und alle Plugins aktualisiert.
3 „Gefällt mir“
Tunneldigger auf Obelix gestoppt.
1 „Gefällt mir“
Tunneldigger Dom02 auf Hulk gestoppt, da Mesh-VPN Quali teilweise nur bei 87%.
1 „Gefällt mir“
Tunneldigger Dom10 u. Dom39 auf Obelix gestoppt da sich Knoten verbunden haben und diese dann keine Verbindung ins Internetz mehr hatten.
1 „Gefällt mir“
Update-Marathon bei unserer Wolke gemacht…
Nextcloud von 17.* über 18.* auf 19.0.5 hoch gezogen.
Das hatte dann wegen eines Bugs ne defekte SQL Datenbank zur Folge.
Dafür durfte ich dann mariadb von 10.1 auf 10.3 Updaten um es wieder heile zu bekommen.
Und zu guter letzt möchte nextcloud ab einer kommenden Version kein php7.2 mehr…
Das hab ich dann auch noch gegen php7.4 getauscht…
2 „Gefällt mir“
fredbackend VM Upgedatet.
1 „Gefällt mir“
Blech unter TJ01 macht mal wieder Updates…
@Adminteam
Ich werde das Blech demnächst umziehen, da die Festplatte vollgelaufen ist und ich für ein zukünfiges Projekt mehr RAM brauche.
Log:
3.00 TJ01 Ist gerade nicht verfügbar. mir ist die platte vollgelaufen…
3.15 Mache mal ein update auf 20.04…
5.40 jetzt sollte wieder alles online sein…
nacht 
3 „Gefällt mir“