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. Möglichkeit: Belassen mit ungültigem FQDN oder mergen in rzl.so unter Berücksichtigung der Security-Through-Obscurity-Prinzipien.

→ Split-DNS? --> Verschoben auf Diskussionsseite, dafür ist sie da.

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-Stände 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. Auseinandersortieren 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)

WLAN

1. Kanäle auswürfeln und konfigurieren

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 undokumentierte 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. Also Basisrahmen, zur Diskussion 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. Konfiguration hier: Hardware Konfiguration Lordeis (Diskussion) 18:10, 29. Dez. 2019 (CET) --> Preis: 1848,39€
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)

DNS

Konzept:

1. IP, DNS und Reverse DNS für den angedachten Hostnamen asap registrieren, die MACs dürften sich auch nicht ändern
2. CNAME-Record für den neuen Host (volt?), name: cybervisor.rzl[.so]

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.

Raumtelefonie

Es geht! Allerdings haben wir eine irritierende Anzahl diverser Töne auf den Telefonen. Nun bietet es sich an, jedem Telefon einen individuellen Ton zu verpassen, der die Raumharmonie dennoch erhält. Hierzu haben die Götter dem Menschen das Werkzeug des Kanons dargereicht, daher bieten sich folgende Klassiker eines anerkannten Künstlers an:

• Der Klassiker, sechsstimmig: KV 231 (382c) von Wolfgang Amadeus Mozart
• Eine andere Variante, dreistimmig: KV 233 (382d) von W.A. Mozart

•  0xb4dc0d3d  ^wtf? • 19:51, 3. Mär. 2020 (CET)