NOC Team/To-Dos

Tagebuch

Wichtiger Punkt: Dokumentation was bisher getan wurde. Was ergab sich aus der Freifunk-Diskussion heute, was aus Verm.+Pfalzkom+Politik, was machen wir mit dem Cisco-Stack hinsichtlich des Tschisko-Fuckups mit Self-Signed Certificates (ist zwar scheisse, macht aber jeder(tm), auch wir?) vor Januar 2020? Was habe ich vergessen?

Cisco siehe auch FN 70489.

•  0xb4dc0d3d  ^wtf? • 21:35, 27. Dez. 2019 (CET)

Und noch ein wichtiger Punkt: Entscheid Serverhardware, Anbringung des Kostenpunkts im Plenum Anfang Januar.

1. Tagebuch erstellt, git
2. Server-Hardware-Raussuchen festgehalten, git, in Progress

•  0xb4dc0d3d  ^wtf? • 22:58, 29. Dez. 2019 (CET)

Netzwerk

DNS rzl.so

Alle internen Dienste enden auf .rzl, was keine Domain ist, die uns gehört. Wäre cool, wenn das stattdessen .rzl.so wäre.

→ Split-DNS?

--Helix 14:35, 27. Dez. 2019 (CET)

SSL-Zertifikate

Für nur intern verfügbare Dienste wäre auch ein SSL-Zertifikat sinnvoll.

Letsencrypt *.rzl.so würde die internen Dienste dann nicht nach crt.sh | entrust.com/ct-search leaken, daher würde ich das vorschlagen.

Für extern verfügbare Dienste kann man dann ja je FQDN ein normales Cert holen. Eventuell auf Rate Limits aufpassen.

--Helix 14:35, 27. Dez. 2019 (CET)

Aufbauend darauf (Obacht: Rate Limits are a real thing): Automatisierung der Zertifikate. LE-Zerts halten nur 3 Monate, da ist Rumgammeln keine Option mehr. Und die Faustregel heißt: ist es rein interner Kram? Wirklich? Wenn nein --> Non-Wildcard und SAN. Wildcard-Zerts sind obsolete Tech, machen wir nur zur Obfuscation. Doku essentiell, SAN-Zusammenfassung und -Stepping!

Zur Disk. im NOC-Meeting. Bei weiteren Diskussionspunkten diese Zeile löschen und bitte die Diskussionsseite dieses Artikels nutzen. •  0xb4dc0d3d  ^wtf? • 20:38, 27. Dez. 2019 (CET)

Inventur Internetleitung

Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es?

Aktuelle Leitung:

Telekom Hybrid 50Mbit

16 Mbit DSL

Rest geht über im Router verbaute Sim Karte (Nur mit Telekom Router Kompatibel)

Geimeinsame Klärung mit der Spedition erstrebenswert.

Holzwerkstatt

Wurde geklärt es muss definitiv ein Patchpanel für die neue Werkstatt angeschafft werden, z.B.: Amazon-Link, deleyCON Patchpanel

Außerdem noch ein Switch da der momentane Ersatz ein relikt aus den 90ern ist. Beispiel: Mikrotik Routerboard CRS328 (24-Port) auf omg. Oder jemand repariert den Ubiquity der seit Monaten in der Werkstatt liegt.

(alles unsigniert von Lordeis)

Freifunk + IPv6

Zukunft ab 01.01.2020? Kübler Glasfaser?
Fürs erste wenn möglich über das /56 Netz, das am Telekom Router anliegt. - Lordeis
Update vom 27.12.19:
Laut @cheatha wird gerade die Freifunk Infrastruktur umgezogen was uns ein wenig zeit ins neue jahr gewähren sollte.
Lordeis (Diskussion) 18:00, 29. Dez. 2019 (CET)

Switches

Inventur aller Switche und Firmware Stand prüfen

Cisco-Stack E-Werkstatt

Update von Cisco verfügbar: 1.4.11.02

Diskussion, ob Update durchgeführt werden soll (unsignierter Beitrag von Lordeis)

Wichtig:

Prüfen ob die Switche von dem Cisco-Zertifikats-Fuckup betroffen sind.

Benutzer-DB

TLS-Renewal. Details nach Fertigstellung.

Router

Ubiquity

1. Auseinandersortieren der Netzwerkverbindungen.
2. Reverse Engineering und Dokumentieren der Konfiguration.
3. IPv6 Konfiguration.

Speedport (Telekom)

1. Reverse Engineering und Dokumentieren der Konfiguration.
2. IPv6 Konfiguration.

Kommentar Ranlvor: Sollte ziemlich Standard sein, nur eventuell ein paar Regeln drin, die versuchen sollen Telefonie-Traffic auf DSL zu zwingen (weil das weniger schlecht tut als via LTE).

WIFI Access Points

Ubiquity

1. Reverse Engineering und Dokumentieren der Konfiguration.
2. Auseinadersortieren der SSIDs:
   1. Prüfen ob alle SSIDs nötig sind.
   2. Diskutieren ob Band Steering Sinvoll Wäre.
   3. Prüfen ob Layer 3 Roaming Sinnig ist.
3. Prüfung ob ein zusätzlicher Unify AP für die Werkstatt sinn macht.
4. Auslagern des RZL IOT WLAN auf anderen AP.

IOT Accesspoint

1. Extra AP verwenden da Performance Probleme.
2. Ich habe noch einen Lancom Rumliegen den ich Spenden würde - Lordeis

Verkabelung

1. Die zwei Tische an der E/Ä-Ecke sind vorbildlich verkabelt, wenn man sie als autonome Hackrepublik innerhalb des RZL betrachtet. --> Uplink-Kabel setzen.
   1. Update: Hab' mal Kabel geordert, Kanäle haben wir noch da. Könnte auch beim Umbau 2020 hilfreich sein. •  0xb4dc0d3d  ^wtf? • 18:34, 28. Dez. 2019 (CET)

Hypervisor

RAM

Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. AUf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen, wenn wir in den Server reingeschaut haben wissen wir aber ob noch mehr als die dann 16GiB gehen.

Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - 0xb4dc0d3d

Update: Macht das noch Sinn? Siehe Punkt Server-Hardware weiter unten in diesem Kapitel. •  0xb4dc0d3d  ^wtf? • 22:10, 27. Dez. 2019 (CET)

Rechtekonzept

User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an UserDB.

Person mit Hut: 0xb4dc0d3d

Hypervisor-Software

1. HV bleibt KVM. Helix erwähnte heute Cockpit, das scheint also auch ohne das ganze oVirt-Debakel zu gehen, und wäre dann prima. Geht als Frontend dann mit dem Rechtekonzept Hand in Hand. Alternative: Proxmox als Aufsatz, nicht(!!!) als Basis.

1. OS sollte CentOS sein: der Hypervisor hat dumm zu sein (CA-Verwaltung, Automatisierung etc. darf da nicht laufen), also genügt CentOS, und wir gewinnen den Benefit SELinux. (Alternative wäre Arch, aber Rolling Release in bedingt gewarteter aber produktiver Umgebung? Meh. Willstenich.)

Gesamtes Kapitel zur Diskussion, habe ich ad hoc so niedergeschrieben •  0xb4dc0d3d  ^wtf? • 21:13, 27. Dez. 2019 (CET)

VM-Inventur

Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.

VM-Struktur

Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: cashdesk.rzl (leider auch gutes Beispiel für undoumentierte VM).

Kommentar Ranlvor: cashdesk ist ein schlechtes Beispiel, da das eigentlich mal eine MemberVM war und neben cashdesk auch den Infoscreen hosted.

Serverhardware

Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS.

1. Ob wir 2 Nodes brauchen oder 1 reicht, sollten wir in NOC-Meeting und Plenum diskutieren.
2. Basis: Nunja, 32 oder 64GiB RAM, mind. 64 GiB Platte und schauen wo die 3-4 TiB VM-Store hinkommen. Alos Basisrahmen, zur Diksussion und Anpassung hier. •  0xb4dc0d3d  ^wtf? • 18:31, 27. Dez. 2019 (CET)

Erneuerung unumgänglich, RAM-Erweiterung ist nur Lebenserhaltungsmaßnahme bei einer designierten Leiche.

Optionen:

1. Eigenkonfiguration auf Basis eines Supermicro Boards und einer AMD Epyc CPU. Koniguration hier: Hardware Konfiguration Lordeis (Diskussion) 18:10, 29. Dez. 2019 (CET)
2. Thomas-Krenn-Storage-Cluster: 240GB SSD OS, 3TB Nested Mirror, SuperMicro, 32GiB DDR4 ECC, max. 185W/Server, 13.100 Euro für zwei Server
3. Kite kann eventuell einen PowerEdge R510 startklarmachen. Er gibt noch bescheid, Basis-Specsheet hier.

Übersicht --> NOC Team/To-Dos/Serverhardware Q1 2020

Installationsstandards

Keine Nummer für den HV alleine, aber hier passt's am Ehesten rein: es gibt VMs ohne Swap, und alle VMs haben nur ein root-FS. Das lässt sich genauso simpel automatisieren und strukturieren wie das was wir schon haben. Resultat siehe meine User-VM. Z.B. den apt-cacher in eine root-Partition zu kloppen und generell nur eine root-Partition vorzuhalten, ist grober Unfug, oder Windows 95, oder wie auch immer man das nennen möchte.

Wir sollten einen Standard hinsichtlich Partitionen, Basissoftware etc. verabschieden. Aufbauend auf dem trivial gehaltenen Status Quo. •  0xb4dc0d3d  ^wtf? • 18:20, 29. Dez. 2019 (CET)

Services

Mailserver

Spamfilter

Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. Erst Spamfilter, dann Unterpunkt Blocklisten ;-)

Mailman

lists.raumzeitlabor.de benutzt Mailman v2.1.18 vom 6.5.2014.

Eine Migration von 2.1 auf 3.x ist möglich.

--Helix (Diskussion) 14:07, 28. Dez. 2019 (CET)

Gitlab

1. Root-Passwort unbekannt, Version zu alt und damit insecure.
2. AutoDevops und CI-Runner sind aktiviert ohne Instanz, nerven also bei jedem neuen Projekt wieder. Das anzuschalten ohne es zu konfigurieren ist nicht gerade clever. Sollte man beseitigen oder nachfragen warum das überhaupt angedacht wurde.