 Genau, ich wollte ein bisschen was darüber erzählen, wie wir bei uns im Studentenwohnheim hier in Karlsruhe das Netzwerk automatisiert haben bzw. die Netzwerkautomatisierung komplett umgestellt haben. Erst mal an, erst mal stelle ich mich und das Studentenwohnheim vor, dann erzähle ich was zu unserer Ausgangssituation mit der Software-Pidgen-Control, wie sie heißt, hieß wie auch immer, dann die Probleme die diese Software mit sich gebracht hat, dann unsere neue Software, die Flightplane heißt, den aktuellen Stand von dieser Migration und zu guter Letzt noch ein paar Lessons learned, dass ihr auch was zu mitnehmen habt, wenn es um Softwareprojekte oder ähnliches geht. Das fuhr im Ei, ich bin Adrian oder Promazu, ich mache im HDInet, also im HDIQEV, bin ich Administrator für Netzwerknahedienste und Automatisierungsgeschichten, also Infrastructure as Code als Beispiel für das Management von unseren Servern, mache sonst auch relativ vier ernehmtamtliche IT, vielleicht habt ihr vorhin das Q&A vom NOC gehört, wo ich auch dieses Jahr zum ersten Mal mitwirke, mache sonst bei Piratenpartei noch IT und auch bei anderen Veranstaltungen. In RealLife bin ich auszubildender Fachinformatiker und Netzwerkarchäologe mit, naja, so vier alten Krams, wie man halt so zu tun hat im Arbeitsalltag. Dann, was ist das HALIKO überhaupt? Das HALIKO ist das größte selbstverwertete Studentenwohnheim in Deutschland, wenn nicht vielleicht sogar in Europa oder weltweit, man weiß es nicht. Wir haben 1.102 Zimmer, beziehungsweise Bewohner, die teilen sich auf sechs Gebäude auf und die Abteilung im HDInet, eben im HDIQEV, das ist der Verein, über den die Selbstverwaltung dort läuft, betreibt eben das Internet quasi als Internetdiensteanbieter. Wir, unsere Infrastruktur, gehören für diese sechs Gebäude, 12 Switches, wir haben aktuell 246 Access Points und noch mal 76 Access Points, die aber mehr oder minder unwartbar sind und naja. Eines von diesen Exemplaren sieht man da links. Seid beruhigt aus Brandschutzgründen, wurde 2013 ist das Bild entstanden, man hat diese 16 Points und den POE-Splitter in dieser Form aus Brandschutzgründen, weil das ist ein IKEA-Schneidebrett aus Plastik, so nicht in die Küchen bei uns im Wohnheim hängen dürfen. Stattdessen sind das Gipsplatten geworden und die brennen nicht. Und auf der rechten Seite sieht man einen von unseren Verteilerräumen, beziehungsweise das ist jetzt vom Gebäude K4, der Switch-Schrank stand und war das Freitag, Samstag, irgendwie sowas, wo wir den gerade frisch umgebaut haben. Genau, das Network Management Pigeon-Kontroll. Der Name ist ganz klar inspiriert vom RFC 1149, Kenna Wissen in der IP over Avian Carrier, weil liegt ja ganz nahe, wenn man so ein Studentenwohnheim sieht. Das hat ja ganz gewisse Ähnlichkeiten mit so einem Taubenschlag. Wobei so ganz abwägig ist dieser Vergleich eigentlich nicht, zumindest dieses Software so zu nennen, weil so ein Taubenschlag, der brennt relativ gut, also ist eher so als B3 einzukategorisieren. Genau, so, wieso sage ich das so, naja, wieso sage ich das so? Genau, also, wie schon gesagt, Namensherkunft RFC 1149, die Entwicklungen haben, ich habe nachgeguckt bei uns in der Versionsverwaltung im April 2012 und die aktive Entwicklung dieser Software hat im September 2013 aufgehört, seitdem sind 15 Commits ungefähr dazugekommen in das Repository, hauptsächlich Anpassungen von Netzbereichen, die wir von der Uni zugewiesen bekommen haben. Was macht die Software? Die Provisioniert, die Switches, die wir bei uns haben, das sind HP ProCurve, 54.0 ZL, also ein Werder 54.06 bzw. 54.12 via SNMP und genau. Mit Pigeon Control hat man die Verwaltung der Netze für die Bewohner, also jeder Bewohner hat bei uns genau eine, also hat eine Netzwerkdose im Zimmer, die aufgelegt ist auf ein Port auf den Switch und die Software, dazu komme ich gleich noch, kümmert sich eben darum, dass der Port auf dem Switch zu diesem Zimmer entsprechend eingerichtet wird, je nach Vertragsstatus und so weiter und so fort. Wofür man sich damals entschieden hat, man hat gesagt, okay, jedes Zimmer bekommt seinen eigenen Port, sein eigenes V-Lan und wir setzen dann auf diesem V-Lan entsprechend die IP-Netzwerke, also IPv4-Netz, IPv6-Netz und macht das Ganze aber stateless. Das heißt, die Software weiß eigentlich gar nicht, was sie tut, die macht halt das, was ihr gesagt wird. Was dann dazukommt oder daraus folgt, wir haben überhaupt den Status unserer Infrastruktur zu sehen, hatten wir Aschenputte, hieß die Software, als Looking Glass auf unsere Infrastruktur, wo man eben die Switches sehen konnte, was auf welchem Port konfiguriert ist und das wurde einmal nachts in so einem Kron-Job, der so zwei Stunden läuft, ungefähr lief, aktualisiert. So eine Static-Page, die ewig lang zum Laden braucht und wenn sie einmal geladen hat, dann auch tatsächlich sinnvoll verwendbar irgendwie die Infos über die Infrastruktur anzeigen. Mal zur Architektur von der Software, also wir haben bei uns unsere Vertragsverwaltung, also unser AAA, MyHardinet, was den State oder wir hatten, was den State hält für das Netzwerk, also wie sieht der Netzwerkvertrag aus, IP-Adress-Bereich und so dann sofort, haben die Leute vielleicht eine Mail-Account bei uns, haben sie sonstige Dienste wie Telefonie oder Druckerdienste und allgemein die Verträge Vereins, da fehlt ein R, Verträge allgemein, zum Beispiel Vereinsmitgliedschaft oder eben Netzwerkvertrag oder zugehörig dann eben der Telefon und so weiter. Prinzipier, so als Mensch, der Support leistet, bei uns arbeitet man sowohl in MyHardinet als auch im A-Dub zwischen dem AAA, also zwischen MyHardinet und dem A-Dub bestehen eine entsprechende Synchronisation beziehungsweise MyHardinet schreibt teilweise je nachdem zu einem Vertrag oder ähnliches dann Attribut ins A-Dub, die wiederum von anderen Diensten abgerufen werden, zum Beispiel, zum Beispiel im Wiki oder so, wo dann je nachdem zu welchem Benutzergruppe man zugehörig ist, man Zugriff auf bestimmte Wiki-Instanzen hat oder halt nicht. Und es gibt Synchronisationsskripte zu unseren netzwecknahen Diensten, dem DNS, dem DHCP, unser Firewall, die einmal alle Minute im Fall vom DNS beziehungsweise in eine einmal alle Stunde im Fall von der Firewall eben einmal über das A-Dub iterieren und da die Informationen rausziehen und dann entsprechend das DNS, der CP und die Firewall entsprechend einrichten. Wie werden jetzt die Switches konfiguriert? Ganz einfach, MyHardinet geht hin, schreibt Synchron oder macht eine Synchronesignalisierung über eine Message Queue zu Pitch and Control, der auf einen separaten Noxhörer mit entsprechenden Management Foularn liegt und Pitch and Control geht hin und schreibt via SNMP auf die Switches. Ja, Synchronesignalisierung, das ist ein bisschen ungünstig, wenn MyHardinet irgendwie 16 Threads hat, irgendwas bei Pitch and Control hängt sich auf und dann bei so einem normalen oder bei einem Support mit mehr Support aufkommen ist dann irgendwie nach 10 Minuten Schluss und alles ist tot. Eben Synchronesignalisierung, wenn auf der Gegenseite nichts hört beziehungsweise irgendetwas länger dauert, dann wird gewartet auf ein Ergebnis und gewartet und gewartet und im Zweifel geht man dann die Message Queue, im Zweifel geht man dann Pitch and Control und eventuell wird dann auch das MyHardinet neu gestartet, damit man überhaupt wieder arbeiten kann. Dann auch sehr, sehr schön Race Conditions, man hat das sehr klug gebaut, man hat, genau, man ist hingegangen für die IP-Netzwerke und hat, wenn man einen Netzwerkvertrag angelegt hat, bekommen die Person IP-Netzwerke zugewiesen und da jetzt kann es passieren, dass gleichzeitig im Support zwei Leute ihren Netzwerkvertrag bekommen und dann plötzlich zwei Leute den gleichen IP-Adress Bereich ist ungünstig, macht Dinge kaputt und sorgt für sehr, sehr witzige Fehler und auch das zu fixen. Was auch sehr, sehr schön ist die Implementierung von dieser Message Queue kann die Person, ihr, danke. Die Implementierung von dieser Message Queue ist auch total großartig gewesen. Wir schreiben einfach Ergebnisse zurück in die Message Queue, wenn ich noch mal eine Frage zurückgehe, die Kommunikation ist in eine Richtung. Wir schreiben mal trotzdem in die Message Queue Ergebnisse oder sowas ähnliches zurück, holt die aber nicht ab. Eine Message Queue hat den Crams in Memory, irgendwann ist der Ram vor, Message Queue sagt nur, ich will nicht mehr und da geht auch nichts mehr. Danke für gar nichts. Genau. Und da geht auch nichts mehr, ist ungünstig. Die Bugging ist auch total spaßig, wenn du einfach quasi nichts an Locks hast und Wartbarkeit, ganz viel undokumentierter Code und ganz viel SNMP-Magie, von dem keiner irgendwie eine Ahnung hat, was das irgendwie tut. Ja, sieht man ja daran, dass 2013 quasi das letzte Mal daran entwickelt worden ist. Gut, kommen wir zu Flightplane. Der Name kommt aus Flightflug. Wir haben das Thema beibehalten und Controlplane. Wir haben irgendwann Mitte 2020 und mit mir mein ich Levi, der auch hier vorne sitzt und ich, haben uns Gedanken dazu gemacht, wie kriegen wir das Management sinnvoller hin. Außer dafür war die 54er von HP, die sind so langsam zehn, elf Jahre alt und sollten abgelöst werden. Wurzig entschieden für Aruba CX und dass die Switches wollen auch irgendwie ins Management rein. Und wenn man jetzt schon mal so eine große Umstellung macht, dann bietet es sich ja eigentlich an, das Management entsprechend umzuplanen. Gut, wir haben dann irgendwann im Dezember nach sehr, sehr ausführlicher Planung im Dezember 2020 dann angefangen zu implementieren und im Februar 2022, nein, das ist kein Schreibfehler, im Februar 2022 angefangen mit dem Royal Out zeitgleich zur Erneuerung der Switch-Infrastruktur im ersten Gebäude. Wir haben uns sehr, sehr viel Zeit gelassen damit, eben um Bugs auszumerzen beziehungsweise die Software entsprechend testen zu können. Und das hat soweit auch ganz gut funktioniert, wobei natürlich jeder macht Fehler und auch die Software war am Anfang nicht perfekt, ist aber inzwischen in einem sehr, sehr guten Zustand. Wir haben beim Software Design damals darauf geachtet, dass wir das möglichst allgemein halten, die Software. Also wir arbeiten über Interfaces, das heißt wir sind prinzipiell Hersteller unabhängig. Sprich, wenn irgendwie neue Hersteller dazukommt, dann lässt sich das eigentlich relativ einfach eben bewegstelligen. Man implementiert die Interfaces, die die Software zur Verfügung stellt und dann hat man letztlich die Möglichkeit dieses, die Software auch für die neue Switches irgendwie zu verwenden. Was wir auch gemacht haben, wir haben umgestellt vom Layer 3 Management auf Layer 2 Management, weil es ist aufgefallen, naja, wenn wir Layer 3 Management haben, wir gucken, was ist auf dem Foulan von diesem Zimmer drauf, welche IP-Netze, ach, die sind falsch, wir löschen die runter, wir setzen die neu, wunderbar funktioniert. Layer 2 Management, Hallo, Netzwerk Interface, du kriegst jetzt das Foulan, danke, spart vier Request oder sowas. Und wir haben gesagt, okay, wir machen das Ganze stateful. Das heißt, wir haben diesen kompletten Netzwerkstate von, wir werden noch, komme ich später dazu, diesen kompletten Netzwerkstate und alles, was damit zu tun hat, komplett aus dem LDAP und MyHerdiental rausziehen und an Flightplaying Phase übergeben fürs Management, dass da tatsächlich nur noch die ganzen Netzwerkthematiken drinstehen. Und wir haben da ein integriertes Looking Glass, wo man eben hingehen kann, okay, so ist der State-Inner-Datenbank hinterlegt, das für die Switches beziehungsweise, hey, Flightplaying zeigt mir mal, wie das aktuell auf dem Switch aussieht. Zu der Zehrarchitektur, wie schon eigentlich gesagt, da ist jetzt ein Benutzer dazu gekommen, gleich dazu, genau, State-Adder-Base, E-Mail-Verträge sind, ziehen wir oder lassen wir bei MyHerdiental und State-Adder-Base fürs Netzwerk und die Netzwerknahendienste ziehen wir rüber auf, ziehen wir rüber auf den Knock, also unseren, den Host sich um das Netzwerkmanagement kümmert, wo eben Flightplaying drauf läuft. Machen jetzt eine Asynchrone-Signalisierung, das heißt, MyHerdiental geht hin, sagt, jo, hier, mach mal, ich warte fünf Sekunden darauf, dass du mir irgendwas sagst oder sind inzwischen mehr. Jedenfalls, ich warte kurz darauf, dass du was sagst, wenn du mir nichts sagst, dann ist mir egal, ich sage irgendwann mit dem Bescheid, dass da vielleicht mal nachgucken sollte. Und natürlich muss es da irgendwie eine Rückroute geben, weil in MyHerdiental werden zum Beispiel die IP-Adress-Bereiche angezeigt für die Benutzer, deswegen Flightplaying stellt eine Rest-RP zur Verfügung, wo man eben die entsprechende Einstellung zu einem Benutzer abrufen kann. Synchronisation zwischen MyHerdiental bleibt, zumindest für alle Themen, die eben nicht Netzwerk nahe sind und die Dienste greifen auch weiterhin auf das ADAP zu. Neu hinzugekommen sind die Benutzer auf der linken Seite, weil wir prinzipiell für viele Sachen, wo vorher einer bei uns der Support macht, im ADAP arbeiten musste, ist eigentlich unschön, könnte man schöner hinkriegen, dass der Benutzer selber per eben in MyHerdiental Requesten kann, hey, ich möchte gerne einen statischen der CP-Eintrag haben oder ähnliches, was dazu kommt. Und das lässt sich dann im Zweifel auch sehr, sehr einfach dann implementieren. Neu sind auch die Admins, bekriegen Mayreports, wenn irgendwas schiefläufend, irgendwas nicht passt, einstellbar, genau. Provisionierung der Netzwerk nahen Dienste soll eben über Flightplaying erfolgen, was man damit zum Teil loswerden kann bzw. das sind Sachen, die noch zu, letztlich genauer zu planen sind, aber wir haben theoretisch die Möglichkeit quasi Instant und die ganzen, also die ganzen Syncript loszuwerden und Instant diese Daten halt rüber zu ziehen. Und das man nicht mehr so lange warten muss, wenn sich irgendwas am DnS oder der CP-Fillen Benutzer ändern sollte. Und wir gehen per, genau, per REST-RP auf die Aurobat CX-Witches. Was hat das jetzt für Vorteile, dass wir die Architektur so gewählt haben? Wir haben zum einen eine zentrale Datenhaltung, die an genau dem Ort ist, wo die Daten eben gebraucht werden. Wir haben eine Generalisierung und wir haben eine Erweiterbarkeit. Auch das Signalisierungssystem zwischen E-My Hardinet und Flightplane ist auch entsprechend ausgelegt, dass man darüber auch Signale realisieren kann, wie Benutzer hat für die IPv4-Adresse oder für die Mac-Adresse hätte er gerne mit dem Offset einen statischen DACP-Eintrag machen und das ist im Endeffekt sehr, sehr einfach umsetzbar. Dann Wartbarkeit, auch Teil der Software, da haben wir auch darauf geachtet, ist eine entsprechende Dokumentation. Der komplette Code ist dokumentiert. Es wird eine HTML-Doku rausgerendert, die im WebUI von Flightplane eben einsehbar ist, wo zum Teil auch Details zu den technischen Hintergründen, zu Entscheidungsfindungen auch hinterlegt sind. Das sind auch Infos, die einfach uns gefehlt haben beim Nachvollziehen von eben genau, was man hat, was man sich da vorher bei gedacht hat, wo er teilweise dann mit Admins, die seit Jahren nicht mehr im Wohnheim eben wohnen, mit dem mal gequatscht haben, hey, wisst ihr da irgendwas zu, wieso wurde das so gemacht, was hat der Hintergrund zu gewesen? Und was auch dazu kommt, Performance, eben wie schon angesprochen, na ja, statt fünf Requests, um den Netz zu setzen, nur noch ein, hat letztlich dafür gesorgt, dass, obwohl wir in der Zwischenzeit noch einen Haus dazu bekommen haben, wir von der Provisionierungszeit für die Switches, also einmal nächtlich über alle Switches drüber gehen und die entsprechenden V-Lands und so weiter und sofort setzen, sind wir von 30 bis 40 Minuten auf ungefähr 10 Minuten runter und dass, obwohl bisher zwei von den Switches, von diesen zwölf, von diesen ursprünglich LVP Switches erst ausgetauscht sind. Genau. Und wie auch schon gesagt, Hersteller Unabhängigkeit, eben durch das Adapter, das ist, genau, eben durch die Interfaces, ist es halt möglich, einfach zu implementieren, ihr neues Switch-Hersteller, da ich implementiere Interfaces, hat einen neuen Switch, den ich mal hinschauen kann mit der Software. Der aktuelle Stand sieht in etwa so aus. Der Großteil der Dienste ist weiterhin auf der linken Seite, wir schreiben immer noch Daten ins Adap dazu. Der Support arbeitet weiterhin Mahalienett und im Adap. Das Einzige, was eben rübergewandert ist, ist letztlich der State eben fürs Netzwerk, wo Flightplane eben führend ist und Mahalienett sich nächtlich die Netze abholt, aus Flightplane zu den einzelnen Benutzern und die dann ins Adap reinschreibt, damit die anderen Netzwerknahendienzen noch funktionieren. Und wir unterstützen weiterhin PSNMP, unsere HP Switches. Genau. Wir haben zusammengefasst, wir haben zum Teil eine doppelte Datenhaltung in der Flightplane-Datenbank und im Adap, wobei Flightplane ist an der Stelle führend. Wir provisionieren die Switches schon via Flightplane, aber die Umstellung vom DIN, die Umstellung vom DRCP ist aktuell in Arbeit, auch mit dann direkt aktueller Distribution und ein Wechsel von der DRCP-Software. Fürs DNS ist noch offen, Falle wo es auch offen, muss halt irgendjemand die Zeit finden, das zu implementieren und wir sind alles Ehrenamtler dementsprechend. Gut. Ein paar lessons learned, was uns so aufgefallen ist eben bei der, genau, was uns so aufgefallen ist bei der Implementierung. Es ist total geil, wenn du eine Konfig-Datei aufmachst und diese Konfig-Datei so 1070 Zeilen hat. Der Großteil dieser Datei ist ein Tuple, wo definiert ist, welches Zimmer auf welchem Switch hängt und welche bekommt. Kann man machen? Ja, ne? Neu-Technologie. Diese Probleme, die wir hatten mit zum Beispiel Message Queue, dass der Ram irgendwann voll war, weil man halt wahllos einfach Daten reingeworfen und okay, da ist irgendwann eine Ram voll, ist dann doof. Prinzipiell, es ist voll cool, wenn man irgendwie mit, wenn es sich überlegt, okay, ich spiele jetzt mit einer Technologie rum oder sowas oder ich will, ich nutze so ein Projekt, um was Neues zu lernen und das Geschichte, auch wir beide haben eben bei diesem Projekt Sachen oder haben Software verwendet, die wir vorher nicht kannten. Z.B. Bibliotheken verwenden, die wir vorhin nicht kannten, haben uns dann aber entsprechend eingehend damit beschäftigt, uns Vertraut damit gemacht und auch uns Rat gesucht bei Leuten, die die Software zum Beispiel länger eingesetzt haben. So vermeidet man dann eben Fehler, die wir tatsächlich auch hatten. So vermeidet man eben so Basic-Anfänger Fehler und sorgt eben dafür, dass man nicht so schnell auf die Schnauze fliegt. Logging ist key. Man kann eigentlich nicht genug Logging haben, eigentlich. Irgendwann wird es natürlich unübersichtlich, aber wenn man prinzipiell bei der Fehler suche, ist es absolut hilfreich, wenn man sagt okay, irgendwas ist komisch, ich stelle das Loglevel von der Software hoch, kriegt dann tatsächlich jeden einzelnen Schritt mit, den die Software macht. Eventuell sogar mit Timings. Oh, das dauert lange, wieso dauert das so lange? Ach, ja, okay, da ist irgendwie, wird Mist gebaut. Dann kann man das fixen und das Problem ist dann relativ schnell aus der Welt. Fehler machen ist menschlich. Jeder macht Fehler und auch bei einer Planung von der Software oder Ähnlichem macht man sehr, sehr gerne Fehler. Keine Software ist backfrei. Sich damit zu arrangieren, dass man eben Fehler macht und die dann auch bereit ist, diese Fehler zu fixen, ist sehr, sehr wichtig und ist eben nicht dabei zu belassen. Da verhält sich die Software aber komisch. Häh, irgendwie dauern die HTTP-Requests total lange zwischendurch mal. Oh, ja, okay, lag dann daran, kein Timeout definiert und irgendwann hat dann halt das Skript blockiert und hat dann halt gewartet, dass irgendwas passiert, ist aber nichts passiert, ist ungünstig. Datenreduanz reduzieren. Daten prinzipiell in einem Ort halten und schauen, dass man irgendwie und dazu eignen sich Relationale Datenbanken, zum Beispiel sehr, sehr gut, weil es ist eines der Grundkonzepte davon. Wir halten Daten in einem Ort, referenzieren irgendwie aufeinanderstellen Beziehungen her und sind darüber eben in der Lage, herzusagen, okay, hier, ich verweise darauf und habe ich einmal die IP-Adressen zum Beispiel oder einmal den Benutzer und sage, okay, die Einträge fürs DNS, die der CPA-Einträge oder Ähnliches sind dazugehörig und dann war es das. Man speichert die Daten nur einmal. Insbesondere wenn man dann meint, okay, wir gehen hin, haben eine Software, die uns anzeigt, was auf unseren Switches konfiguriert ist, ja, ist okay, aber wenn die dann irgendwann mal nicht gelaufen ist, was auch schon mal vorgekommen ist bzw. wo teilweise bei größeren Debugging-Aktionen man vorher dann hingegangen ist, gesagt, okay, ich generiere jetzt gerade die Statische Seite mit von Aschenputin noch mal neu, damit ich wirklich sicher bin, dass ich weiß, was überall konfiguriert ist, wenn ich nicht gerade Lust habe, irgendwie Konfig-Dateien zu lesen. Und Document Your Code, ich weiß, wir hassen alle Dokumentationen, wenn wir unsere Software schreiben, aber nur mit Dokumentationen weiß man auch im Nachhinein, was man irgendwie getan hat bzw. was dieses eine bisschen Code tut, weil es könnte irgendwann total unwichtig aussehen, war es aber am Zeit, finde ich. Ich habe mir mal den Spaß gemacht, weil ich habe ja gesagt, okay, es ist prinzipiell ja sehr, sehr einfach irgendwie das zu generalisieren bzw. neue Hersteller anzubinden. Ich habe mir den Spaß gemacht, habe mich gestern einmal hingesetzt, habe die Software installiert, habe also okay, wir haben hier auf der GPN, haben wir Switches von Arista, Arista ist nur per SNMP ansprechbar, gut gehst du halt hin, wir haben schon SNMP, also die, wir haben ja schon einen SNMP klein, letztlich mit den HP Switches, nimmst du den, passt den anderen die Besonderheiten, die Arista Switches haben und zumindest um das hier anzuzeigen, sie sagen okay, hier, das sollte nicht vom Mikrofon weggehen, sie sagen okay, wir haben hier jetzt gerade die 48 Ports, die eben User-Facing sind, da sind die Uplink-Ports zum Beispiel nicht drin, weil ich mich nicht näher genug oder nicht die Zeit hatte, mich näher genug zu beschäftigen, wo genau im SNMP-Tree diese Ports auftauchen, aber so funktioniert es prinzipiell super easy, ich kriege okay, ich habe die Portnummern, ich weiß die Beschreibung von den Ports, ich weiß welches Faulander drauf liegt, das ist in dem Fall 103 für unsere Wired Clients und ich kann mir sogar live anzeigen lassen, ob dieser Port ab ist, also das angesteckt ist oder nicht, welche Geschwindigkeit ausgehandelt worden ist und genau. In dem Fall sieht man zum Beispiel, das ist immer oben rechts, Request Time von vier Sekunden, von vier Sekunden habe ich halt live die Daten irgendwie vom Switch abgerufen per SNMP. Um, genau, ich bin, so, genau, um noch ein paar Worte zum Schluss zu sagen, die Software prinzipiell, falls irgendwie, ich wurde auch schon danach gefragt, die ist closed source, die ist nicht öffentlich, auch wenn manche Leute sich das gerne wünschen würden, dass wir die öffentlich machen. Ich weiß, vielleicht kommt das irgendwann in der Zukunft irgendwann mal, dass die Software veröffentlicht wird, aktuell ist sie eher nicht so in einem Zustand, dass man sie so verwenden kann, weil sie ist dann doch sehr wohnheimsbezogen und auf unsere Prozesse angepasst. Genau. Implementierung, auch wenn ich die Software gerade hier vorgestellt habe, ich habe fast keine Zeile Code geschrieben, so habe nicht wirklich viel, viel Code technisch daran gearbeitet, sondern in großer Zeit ist halt von Levi gewesen und so ein Copster, der leider nicht hier ist, aber der hat aufgrund von einer Diskussion über die Software eigentlich so die Idee gegeben, dafür einen Talk-Height jetzt heute hier zu halten. Das ging schneller als gedacht. Sind irgendwelche Fragen aus dem Publikum zu irgendeinem Thema? Womit habt ihr die Software geschrieben? Prinzipiell arbeiten, oder wir arbeiten im HDNet bei uns größtenteils in Python und das ist auch genau da der Fall. Also wir benutzen Python als Programmiersprache für die Software selber und das WebUI ist mit Flask geschrieben im Gegensatz zu eben alle anderen Software, die mit Django arbeitet bei uns. Aber genau, das ist zum Beispiel einer der Punkte, wo ich, wie ich eben meinte, mit neuer Technologie für uns auch mal ein bisschen spielen, wo wir auch am Anfang diverse Fehler mitgemacht haben, das Dinge wie nicht sinnvoll getan haben, aber inzwischen tut das Zeug sauber. Was genau macht ihr alles nachts, wo du erzählt hattest, dass der Job, der da so läuft, so lange dauert? Dass der Job existiert inzwischen nicht mehr. Das war eben das, quasi das Looking-Glas, also Aschenputtel, dass der Vorgänger von dem da quasi, der eben nachts einmal über alle Switches drübergegangen ist, sich die V-Lands geholt hat, die auf den Switches konfiguriert sind, sich die ganzen Ports geholt hat, die Beschreibung dazu, welche V-Lands wie geteckt sind, ob da irgendwelche IP-Adressen konfiguriert sind. Und das hat dann halt immer sehr, sehr lange, oder das dauert halt sehr, sehr lange, liegt in der Natur der Sache, wenn irgendwie per SNMP, was ja sehr langsam ist, prinzipiell, genau, super viele Daten im Abruf von den Switches. Aber klar, also unsere Krons, die wir generell haben, auch für beispielsweise Signalisierung, wenn jemand zum, also zum 31.3. zum Beispiel kündigt, das heißt ab dem 1.4. kein Internet hat. Also eben Vertragsübergang und Ähnliches, das wird auch nachts dann synchronisiert kurz nach Mitternacht, geht dann halt bei uns, man hat ihn halt eben hin und gleich dann beispielsweise die Dienste und Verträge mit dem Ad-Up ab, dass, oh, jemand hat seinen Druckervertrag gekündigt, okay, dann nehme ich ihm das Fleck im Ad-Up weg, Netzwerkvertrag gekündigt, Fleck im Ad-Up weg und so halt dann sofort. Das wird halt auch, ist auch nachts verlagert, weil es sehr zeitnah an dem tatsächlichen Vertragsende dann dran oder Vertragsbeginn. Erst mal vielen Dank für den interessanten Vortrag. Wie zuverlässig läuft die Software? Kurz, kurzer Disclaimer an der Stelle, der da macht sehr, sehr viel von unserem Support, der ist auch bei uns im Team drin und der meint gerade treuen zu müssen. Sie lief schon mal unzuverlässiger, insbesondere halt zu anfangen. Nee, an sich die Software läuft relativ zuverlässig, hat ab und an mal ein paar Hänger oder sowas. Das ist aber auch so mehr oder minder, so nach und nach, findet man da auch die Bugs, so kriegt die gefixt und genau. Kleine Frage, hatte dir jetzt einfach Bock da drauf, die, also die zwei Pfeilchen, da das SNMP und das Rest zu den, zu den Switches, hatte dir einfach Bock drauf, dass ein Partner jetzt zu implementieren oder habt ihr da zum Beispiel, ihr habt da 2020 damit angefangen, da ist immer so die Frage, warum zum Beispiel nicht Ansible, wo man das URI-Modul hat und SMPT-Modul und tatsächlich auch noch oder Rollen für die entsprechende Zielplattform. Also, warum die Entscheidung für Partner sozusagen? Wir haben, also wir haben prinzipiell machen wir sehr, also machen wir sehr, sehr viel eben von Systemen automatisiert. Klar, man könnte auch mit Ansible hingehen und entsprechend die ganzen Sachen quasi autark laufen lassen. Klar, könnte man tun. Wir haben uns aber auch gesagt, dass wir relativ viel Kontrolle irgendwie über den ganzen Prozess haben wollen, eben diese Erweiterbarkeit für, genau, eben diese Erweiterbarkeit und wir haben eben ja auch irgendwo den, ja, den Aspekt, dass wir zum Teil eben, zum Teil eben bei Vertragschluss, oder, genau, Vertragschluss auf, ich hätte gerne ab jetzt Internet irgendwie was gemacht werden muss, was eben anders ist als das, was zum Beispiel nachts passiert und so und genau, da war eben die Entscheidung dann, oder haben wir eben die Entscheidung getroffen, dass wir okay, wir bleiben dabei, dass wir einen separaten Dienst haben, der sich um diese ganzen Themen kümmert und auch zum Beispiel dann aber nacharbeiten kann, wenn beispielsweise Flightplan in dem Fall jetzt zum Beispiel aus ist. Die Sachen werden der Message-Qual gespeichert und sobald Flightplan dann wieder startet, werden die Sachen dann noch nachgeholt und so. Eine Frage zu den Faulands. Benutzt ihr die, um die Benutzer voneinander zu isolieren, dass halt keine IPs vom anderen benutzt oder ähnliches oder für irgendwelchen Zweck sind die? Genau, also wir haben einen im cgnut IP Bereich, haben wir von der Uni einen Netzbereich gekriegt und jeder Benutzer kriegt von uns einen schräger 27 Block an eben V4-Adressen und die sind eben hängen entsprechend auf den Faulands. Also die einzelnen Zimmer sind, laier 2 isoliert, wobei das Netz geroutet ist von außerhalb, also von hinter quasi unserem Gateway Server kommt man zum Beispiel nicht rein bei uns, außer der Benutzer hat explizit eine Firewall Freischaltung bei uns angefragt, intern übers Routing kommt man an, im Zweifel an die anderen Zimmer dran, das ist auch so gewollt. Das ist prinzipiell einfach zu logischen Trennung auch beispielsweise von Broadcast und Man oder Ähnlichem, dass wenn du dein Spotify bei dir in deinem Zimmer hast auf irgendeinem Kleint, dass du dann nicht von drei Häuser weiter irgendwie gesehen wirst, beziehungsweise Musik steuern kannst und zwar dann sofort. Weil das sind auch Geschichten, auch Sachen, die eben die Geschichte gezeigt hat mit, naja du hast dann irgendwie ein Layer 2, also quasi ein Fauland, wo dann alles nur logisch getrennt ist, nach Benutzer richten sich ihre IP-Adressen einmal ähnliches. Wenn da irgendwie Windows oder Mac mit ihren Update-Prozessen kommen, die dann teilweise irgendwie ins Netz zurückstrahlen oder auch sehr beliebt irgendwelche Fritzboxen, die Dinge tun, ins Netz zurückstrahlen, dann hast du sehr, sehr schnell die komplette Netzwerkbandbreite, die von Broadcast ausgelastet ist und das ist dann halt eher ungünstig, nennen wir es mal so. Du hast ja jetzt sehr stark hier auf die Ethernet-Ports von den Zwitschern gezeigt. Hattest du aber anfangs auch von WLAN Access Points gesprochen? Wie fern sind denn da auch die WLAN Access Points, die jetzt noch integriert? Tatsächlich in dem Part, in der Software sind die tatsächlich gar nicht integriert, abgesehen davon, dass du naja siehst, wo, naja abgesehen davon, dass du eben siehst, auf welchem Port irgendwie ein Access Point hängt. Sieht man es, naja sieht man nicht. Genau. Was aber ein Punkt ist, wir machen damit ja nicht nur die nächtliche Synchronisation von den Zwitsches, sondern auch das Initialistaging, wo wir eben dann festlegen für jeden Zwitsch, okay, die und die Ports, in denen wir den Zimmern zugehörig, die und die Ports nehmen wir für WLAN und genau nehmen wir für WLAN und so weiter und so fort. Das WLAN am Anfang habe ich primär nur deswegen angeführt, dass man so grob Überblick bekommt mit welchen Zahlen, mit welchen Zahlen an Geräten wir arbeiten. Naja, also die Access Points hängt schon auf den Zwitsches mit drauf. Klar. Aber achso, achso, du meinst WLAN-TV-Lan. Ja, nee, WLAN-TV-Lan existiert bei uns nicht. Also der Benutzer ist nicht übers WLAN bei sich in seinem VLAN drin, hat diverse Hintergründe und ist das Ursprungs von Entscheidungen, die vor quasi unserer aktiven Administrationszeit getätigt worden sind, mal getroffen worden sind, dementsprechend. Das ist nicht implementiert und das wird auch in der näheren Zukunft nicht implementiert werden können, rein technisch. Ich möchte nur ein bisschen protestieren und zwar werden SNP langsam es dann liegt wahrscheinlich daran, dass Bulk Requests und Asynchronität nicht richtig genutzt wurden. Also in dem alten Design war das glaube ich so, wenn ich es richtig verstanden habe. Ja, das kann sehr gut sein, dass Sachen nicht richtig implementiert worden sind. Also ich weiß es nicht, ich kann es auch nicht sauber nachvollziehen, dafür müsste ich mich zu sehr mit dieser Software beschäftigen und da habe ich jetzt inzwischen auch keinen Grund mehr zu. Ich weiß halt, die war langsam. Wie viel Freiheiten haben eigentlich die Nutzerinnen oder Nutzer, wenn sie so was haben wollen, wie zum Beispiel Port Forwarding oder doch mit anderen Leuten sprechen wollen, mit dem Netzwerk? Also intern bei uns, das hat ja primär nichts mehr mit meinem Talk zu tun, aber auch in die Richtung, wenn irgendwie Leute interessiert sind an Strändenwohnheim oder bei einem Netzen, wie wir Sachen machen, auch gerne Fragen, auch wenn das mit dem Thema jetzt nichts zu tun hat. Prinzipiell, wenn nicht irgendwie irgendwas sehr hart Fischi aussieht oder jemand irgendein Domainnamen haben will, der offensichtlich irreführend ist oder Ähnliches, dann sind wir da doch sehr frei, was die Umsetzung von solchen Wünschen angeht. Kurze Frage, wie genau macht ihr den Access Control? Geht es auch über die VOLans? Also meine Frage ist eigentlich die, wenn sich jemand anschließt, müsst ihr letztendlich eine 1 zu 1 Zuordnung machen können, wenn denn mal wirklich Spaß passieren sollte, was in gewisser Weise illegale Sensor zum Beispiel, damit ihr da eben auch entsprechend dann das einem Nutzer zuordnen könnt. Wie geht das Thema an? Wir haben, ich kann ja mal das Bild trüben aufmachen und ein bisschen größer machen. Man sieht es nicht wirklich, aber doch, sieht man, ein bisschen verschwommen, da steht zum Beispiel I411 drauf. Wir können, oder genau, da steht zum Beispiel I411 drauf, jeder Switchport ist einem Benutzer zugewiesen, weil, naja, wir haben, wir haben unsere Patch-Panels da unten, genau, Patch-Panel, Einkabel geht hoch ins Zimmer und die sind entsprechend aufgelegt und das weiß eben, oder das Netz ist, bis zum Switch ist das Netz komplett statisch und wir wissen eben, welche Person, wo drauf hängt. Was Access Control zum Beispiel in Küchen angeht, weil wir auch den Leuten die Möglichkeit geben wollen, in ihren Küchen zum Beispiel, bis sie an Zahn anzuschließen für einen Fernseher, für eine Konsole oder ähnliches. Auch da gibt es aktuellen Freigabeprozess über per Mail, also per Ticket bei uns, wo dann entsprechend vermerkt wird in der Konfiguration vom Küchenrouter, also in jeder Küche hängt aktuell einer von dem unwahrtbaren Plastik-Schrott. Genau, da wird halt eben im Konfig-Management davon hinterlegt, welche Megadresse, welchem Ticket zugehörig ist, dass man darüber im Zweifel was rausfinden könnte. Bei Prinzipiell, wir haben halt auch die Vorgabe, dass wir eigentlich jeden Traffic, der bei uns durchs Netz geht, irgendeinen Benutzer zuordnen können müssen und das wird eben genau darüber realisiert. Gibt es noch Fragen? Sind euch die Switchs schon mal ausgefallen? Sprich, ob wir die ganze Verkabelung noch mal ändern müssen, anpassen müssen, auswechseln oder so, oder laufen die wunderbar 24 x 7 durch? Die Switches, die laufen 1a, also die Switches laufen 1a. Was wir ab und an mit den alten Switches eben auch aufgrund des Alters machen mussten, sind ein Austausch von den Modulen. Also die Switches vorher, das waren bahnmodularer Switches, das waren Chassis, wo eben 6 bzw. 12 da auch der Name Module reinkommen und da ist zum Teil eben das PoE oder also Power over Ethernet dann ausgefallen und die mussten wir dann zum Hersteller schicken und dann haben wir am nächsten Tag oder zwei Tage später dann ein neues Modul bekommen. Wir kriegen erst das neue Modul schicken, dann das alte Modul weg, aber genau, also das passiert manchmal aber mit den neuen Switches, keine Probleme und auch die Geräte sind ja prinzipiell darauf ausgelegt, dass die 24 x 7 laufen, die Räume sind eigentlich gut klimatisiert, größtenteils und deswegen kommt es da auch eigentlich zu keinem Problem. Ja, danke für den Vortrag, also ich habe selber so was bei uns im Wohnheim vor 20 Jahren mal gemacht, auch mit SNMP und anderen Sachen. Mich würde interessieren, gibt es hier so Fragestellungen wie Accounting, Traffic Shaping, wenn einzelne Nutzerinnen das ganze übertreiben und da riesige Datenmengen ziehen oder schieben, gibt es Quality of Service, gibt es zum Beispiel Voice over IP, Telefonie? Das wurde größt jetzt abgeschafft, noch bevor wir angefangen haben. Also es gab früher mal Nutzer basiert, eine Quotierung vom Internet-Traffic eine automatisierten Mail eben an die Netzwerkadmins und den Benutzern mit hey, du hast gerade in den letzten zwei Stunden irgendwie 400 Gigabyte an Datens Internet rausgepustet, sag mal, ist das mit Absicht oder ist da irgendwas, ist da irgendwas schief gelaufen? Hast du dir irgendwie ein Model oder ähnliches eingefangen? Beziehungsweise dann sind, wenn das häufiger vorgekommen sind, die Leute mussten sich eben, oh, wurde das Internet abgedreht und die Leute mussten sich erklären, wieso das jetzt so der Fall ist. Wir haben dafür nicht wirklich eine Nutzen, wir haben nach außen ins Internet eine Anbindung mit zwei Gigabit symmetrisch und obwohl wir 1.100 Menschen sind, wir kommen in Piechstunden so abends, so gegen 22.00 Uhr, 23.00 Uhr, kommen wir da ab und an mal ran, aber da ist super viel Luft nach oben noch, deswegen werden die Sachen nicht gebraucht. Genau, und auch bezüglich Telefonie. Auch bezüglich, zum Beispiel Frage nach Quality of Service Telefonie, brauchen wir nicht, weil es funktioniert auch ohne. Also eigentlich zwei kleine Einwürfe, keine Fragen, um genau zu sein, aber zu der eine Frage, dass die Switches 24.07 laufen, ja, die sind dafür ausgelegt. Ich kann da auch ein sehr gutes Beispiel dazu geben. Wir hatten einen von diesen alten Bro-Curves-Switchen, der war 12 Jahre alt, der war Schnee draufgelegt, der war bei 45 Grad, im Sommer ist er gelaufen, außerhalb von seinen Specs, also der hat es ausgehalten. Und die andere Anmerkung, was ich ein bisschen verwunderlich find, dass ihr mit so vielen Bewohnern nur so wenig Traffic macht, weil ich bin im gleichen Boot letztendlich in Fuhrtwang beim GAB und da machen wir mit weitaus weniger Bewohnern auch schon an die 2 Gigabits. Problem ist voll. Ja, ich weiß nicht, was eure Benutzer anders machen als unsere, keine Ahnung, weiß ich nicht. Es sind halt bei uns die Daten, die das Monitor so ausspuckt. Ich weiß, also wahrscheinlich habt ihr ähnliche Kurven wie wir. Also bei uns, so gegen 19, 20 Uhr, Spaß oder wird Spaß-Cyber immer Porn-Hour genannt, steigt so gegen 18, 19 Uhr, dann der Traffic dann eben stei an und ist dann bis 24 Uhr, 1 Uhr oder so relativ hoch und fällt dann rapider ab und ist dann auf so einen Grundrauschen von irgendwie 200, 300 Megawit und dann, ja, so. Aber tatsächlich ist da noch sehr, sehr gut Luft nach oben. Hallo. Ich glaube schon. Okay, wenn ihr so Projekte angeht oder Infrastruktur, berücksichtigt ihr Komplexität dabei, so dass Leute, also spätere Admins, die nach euch einziehen, das nach nachvollziehen können, weil ich wohne jetzt auch in einem von den Wohnheimen, hier in Karlsruhe von den Viertelverwalten, macht da das Netzwerk und wir haben das Problem, dass wir niemals übertreiben sollten, weil die nächsten, die dann einziehen, wenn ich zum Beispiel weg bin. Die Probleme haben sich da einzulesen. Habt ihr da außer gute Dokumentation irgendwelche Grundsätze? Also, ich kenne das Problem. Die komplette Riege hier vorne lacht. Also, es hat ja so einen Punkt, was du ja prinzipiell bei Ehrenamtsarbeit hast. Jeder macht eigentlich nur das, worauf er Lust hat, woran er Spaß hat. Außer du hast irgendwie einen von wenigen Menschen, der sagt, okay, mir alle scheiß egal, ich mach das halt, was gemacht werden muss. Ich lese mich da auch ein, hab sehr, sehr viel Zeit bzw. ich hab eigentlich keine Lust aufs Studium. Gibt es, die dann entsprechend sich auch tief in so Geschichten einlernen können. Das Ziel ist natürlich irgendwo, eine wartbare Infrastruktur zu haben, auch zu Neupersonen, die neu ins Team kommen, irgendwie eine Übergabe stattfinden zu lassen. Das sind halt Themen, die aus verschiedensten Gründen in den letzten paar Iterationen in diesen Teams, also klar, das rotiert laufend durch, aber es gibt mehr oder minder absteckbare Generationen irgendwo, weil du hast immer die zwei, drei, vier Leute, die irgendwie rausstechen, weil die halt sehr, sehr viel Zeit investieren oder sehr, sehr große Änderungen gemacht haben, die auch größtenteils eigentlich alle sinnvoll sind. Die so zu machen, auch aus deren Sicht sinnvoll sind. Beispielsweise, du hast plötzlich quasi kein Team mehr um dich rum, was aktiv sich um Server kümmern kann. Okay, dann gehen wir bald hin und implementieren Puppet als Management für unsere Server und probieren, dass unsere komplette Infrastruktur quasi aus einem Git repository kommt. Also Infrastructure ist Code. Die Einführung deswegen war mehr oder minder, weil, naja, war halt kein Admin da. Und so Geschichten eben sinnvoll dokumentiert und in sinnvoll definierter State sind natürlich sehr, sehr wichtig und sehr, sehr gut, wenn du auch eine Übergabe machen willst. Beim Zweifel, du lernst halt einen Tooling und kannst im Zweifel genau lesen, was auf welchem System gerade läuft, ohne auch dieses Software kennenzulösen. Aber trotzdem, Einstieg zu Themen sind halt schwer und wenn irgendjemand einen geheimen Rezept, einen Patent hat dafür, dass man sinnvoll irgendwie Leute in den IT-Team reinkommt, auch wenn die Person zum Beispiel keine Erfahrung haben oder was auch sehr häufig in der Fall ist, ich habe Angst, was falsch zu machen, ich habe Angst, was kaputt zu machen. Wenn da irgendjemand was weiß, gerne Bescheid sagen. Ich glaube, das ist ein Problem, mit dem wir alle irgendwie zu tun haben, wenn wir irgendwie ehrenamtlich an irgendwelchen Themen arbeiten. Ich würde noch interessieren, ob IPv6 für euch in irgendeiner Weise relevant war. Das ist keine Schatzfrage, ganz ehrlich gemeint. 80% unseres Traffics in IPv6. Bum! Ne, also tatsächlich... Ich habe schon fast damit gerechnet, dass diese Frage kommt. Ne, tatsächlich sind zwischen 60% und 80% unseres Traffics auch tatsächlich u-zeitabhängig, weil diverse Internetseiten oder Ähnliches keine IPv6 anbieten. Aber u-zeitabhängig schwanken wir so zwischen 60% und 80%, was IPv6-Auslastung angeht oder Verwendung angeht. Was da zum Beispiel als link irgendwie empfehlenswert wäre, grafana.hardicopunkt.de, das sind unsere Public-Dashboards, wo man eben so Traffics-Statisten oder Ähnliches zum Beispiel sehen kann. Genau. Gibt es noch Fragen? Wir haben noch knapp 10 Minuten. Möchtet niemand mehr Fragen stellen? Auf zu anderen Themen, bezüglich Infrastruktur im Wohnheim, wie wir irgendwelche Sachen machen und so. Also ich weiß, es gibt einen anderen Austauschkreis für eigentlich so eine Thematik, also Ständenwohnheimsnetze, klar, aber wenn wir hier schon mal die Möglichkeit haben, uns irgendwie dieses Bezug auszutauschen. Auch weil ich zum Beispiel weiß, es gibt einen anderen Austauschkreis seit vielen Jahren eigentlich nicht mehr irgendwie aktiv drin sind aus diversen Kunden, was sich vielleicht zukünftig ändern wird. Aber wenn da irgendwie Fragen sind, gern fragen, auch wenn ihr jetzt nicht direkt mit dem Talk zu tun haben. Ansonsten vielen Dank für deinen Vortrag und vielleicht hört man ein Update von euch irgendwie beim nächsten Mal. Wer weiß, wird sich die Zeit zeigen, denke ich mal. Vielen Dank. Und gerne irgendwie unter Daten erreichen, wenn ihr wollt. Wenn euch noch irgendwas einfällt, Feedback, gut Feedback geht auch über das Pretex. Und sonst kann man sich gern mal irgendwie zum Weiterquatschen oder so mal auf einen Chunk oder sowas treffen. Vielen Dank.