Wir sollten einfach die root-Passwörter löschen. Schlüssellogin ist denke ich sicher.
Ich habe heute Des2 konfiguriert und dort die Domäne 16 draufgelegt. Hat Anschluss an Des1, dort kommt jetzt die Burse rein.
Grüße
Matthias
Wenn du das root-Passwort löscht und irgendwie das Netwerk zerstörst, kommst du nicht mehr drauf, auch nicht per Konsole. Besser ssh-Auth per Passwort verbieten.
3 „Gefällt mir“
Nein,
Wenn kein root pw gesetzt ist, kann man sich dennoch einloggen. Einfach enter drücken und man ist drin (wie bei gluon). Man muss halt nur “lokal” (also via vnc oder libvirt viewer) sein. Ich setzte aus diesem grund trotzdem ein passwort, kann ja mal passieren, dass man versehentlich den vnc port nach außen exposed.
Daher würde ich einfach im sshd den passwort auth verbieten. Im ansible-hypervisor sind in der common rolle entsprechende tasks bereits definiert.
2 „Gefällt mir“
Ahh, es gibt Löschen und Löschen. Ich hatte jetzt daran gedacht, denn Passwort-Hash auf “x” zu setzen, um dadurch den root-Login per Passwort unmöglich zu machen. Ein leerer Passwort-Hash wäre natürlich noch unsicherer als als ein wenigen Leuten bekanntes, sicheres Passwort.
Ich habe das Wordpress-Plugin “WP Statistics” von 10.0.5 auf 10.1 aktualisiert. Es scheint nichts defektiert worden zu sein.
3 „Gefällt mir“
Auf c1024 was die conntrack Tabelle voll. Habe die conntrack-tool installiert und die Tabelle gelöscht. Läuft wieder…
dpkg -l conntrack
1 „Gefällt mir“
@Fungur und ich haben heute angefangen die bird-Rollen zusammen zu führen: Ansible-Konfiguration weiterentwickeln
Dabei haben wir auch iBGP angelegt, aber noch nicht getestet.
Es gibt ein neues Routingkonzept für Greyworm mit VMware: Internes Routing für Greyworm
Da seit der Doppelbenennung von Des2 die intere DNS-Auflösung in der Testdomäne kaputt war, habe ich firmware.ffms jetzt auf Des2-Alt lokal gesetzt, damit die letzten vier Knoten aus der Testdomäne umziehen können.
Danach wird die dicht gemacht.
Grüße
Matthias
Und weg damit: Die Testdomäne ist Geschichte
Server ist aus.
1 „Gefällt mir“
nf_conntrack_count Anpassungen mittels Ansible ebenfalls auf alle Gateways ausgerollt (im gleichen Zuge ebenfalls tunearpcache ausgerollt) und Erfassung der nf_conntrack Statistiken ebenfalls für Gateways aktiviert.
1 „Gefällt mir“
ip_conntrack Tabelle auf Backbone c1024 geflusht. Dort waren wieder über 200k Einträge. Derzeit wächst die Tabelle auf c1024 täglich um ca. > 50k Einträge, während sie auf des1 (um die 50k Einträge) konstant bleibt. Genaue Ursache noch nicht gefunden.
(Durch das Flushen werden wohl alle (tcp) Verbindungen (ipv4) über c1024 kurz abgerissen worden sein.)
Auf des2 manuell networking stop; networking start ausgeführt, weil bat12 nicht aktiv war. Es war schon korrekt angelegt, aber irgendwie nicht gestartet worden.
Ansible auf Service-VM ausgerollt.
Die Domänen zwölf und 13 liegen auf Des2 und Remü-08.
barristan.kgbvax.net auf Wunsch von @mpw wieder eingeschaltet.
(Cloud Modell, man bezahl “on time” daher war das Ding aus)
Technische Daten die ich genannte habe waren falsch,
korrekt:
8 Core (C2750) 2.4 Ghz, heisst eher übersichtliche Compute Performance
16 G RAM
500 MBit connect
1 „Gefällt mir“
Reicht zum routen, wir wollen kein Fastd damit machen. Danke für’s Einschalten. Ich frage Tunnel beim FFRL für die Kiste an.
Mehr geht netto bei Hetzner auch nicht durch. Ist die Frage, was hier netto durchgeht, müssen wir einfach mal testen.
Des2 war kaputt. Nach dem Neustart des Netzwerkes gestern waren die Schnittstellen nicht mehr im Batman drin. Ich war zu faul die bei dreien alle einzeln einzuhängen und habe reboot getippt.
Das scheint mir noch ein Fehler in der Multidomänen-Konstruktion zu sein. Ich erstelle dazu mal einen Bug, damit wir das nicht vergessen: #31
Grüße
Matthias
Ein Netzwerk-Restart löscht auch die Bridges und baut sie neu wieder auf. Danach nicht dann natürlich die L2TP-Interfaces nicht in den Bridges und wir können die auch nicht einfach wieder hinzufügen, da nicht erkenntlich ist, welches L2TP-Interface in welche Bridge gehört. Für mich bleibt damit nur ein Restart des Tunneldiggers nach jedem Netzwerk-Restart als Lösung.
Ein automatischer Restart des Tunneldiggers durch den Netzwerk-Restart ist meiner Meinung nach nicht sauber möglich. Es würde ins post-up einer Bridge passen, aber da wir mehrere Bridges haben, würde dann der Tunneldigger mehrfach kurz hintereinander restartet werden, was wahrscheinlich zu Problemen führen wird.
Also bleibt für mich eigentlich nur: Immer wenn manuell Netzwerk-Restart ausgeführt wurde, auch manuell Tunneldigger restarten (und auch isc-dhcp-server restarten - der hat ggf. sonst auch Probleme). In den Ansible-Rollen ist das schon eingebaut gewesen.
Der Legacy-Gateway-Server parad0x wurde heute abgeschaltet und neu installiert.
Michael und ich haben anschließend das neue Ansible Playbook backway.yml auf parad0x ausgerollt um diesen als Gateway inkl. FFRL-Anbindung zu konfigurieren.
Dabei wurden einige kleinere Fehler im Ansible behoben. Einen größeren Fehler in bird haben wir nicht mehr behoben und das Problem vertagt. Sobald bird läuft (ipv4) ist der Server nicht mehr erreichbar. Wir vermuten ein Config-Fehler mit falscher Default-Route. Damit der Server auch nach Reboot noch erreichbar ist haben wir den bird-Dienst disabled.
P.S.: (sn-)parad0x-01 aus Dom5 wurde nicht verändert
Möglicherweise liegt es daran, dass der Server seine IP Adresse mittels DHCP erhält. Also ich meine nicht, dass das der Fehler ist, sondern dass der Fehler vermutlich mit diesem Umstand zusammenhängt. Es ist der erste Server, den wir mit Ansible konfigurierten der so konfiguriert ist.
@Parad0x, @Fungur und ich haben heute Nachmittag das Problem mit birdv4 gelöst. Das Protokoll direct fehlte. Außerdem haben wir noch die IPV6 für die FFRL-Tunnel auf dem Gateway Parad0x korrigiert.
Die Tunnel stehen jetzt, das Routing sieht gut aus. Als nächstes wird das Backway ans restliche Backbone-Netz angeschlossen.
@MPW und ich haben die neuen Backway-Rollen weiter gerade gezogen, so dass sie auch für normale Gateways funktionieren. Entsprechend wurde backways.yml in gateways.yml umbenannt und auf den L2TP-Domänen-Gateways ausgerollt.
Parad0x wurde als zusätzlicher Server für die Domänen 12, 13 und 16 konfiguriert, um die Backway-Funktionalität weiter zu testen.
1 „Gefällt mir“
Wir haben gestern @Fanlin s Gateway Backbone wieder in Betrieb genommen. Der Durchsatz an Greyworm sollte jetzt wieder auf dem Niveau von vor einigen Wochen liegen. An einer Erweiterung der Serverkapazitäten wird gearbeitet. Wir warten derzeit auf einen neuen Tunnel aus dem Rheinland.
3 „Gefällt mir“