toolbox-it / toolbox-netzwerk

Ansible Playbook um das Toolbox Netzwerk zu deployen
MIT License
0 stars 3 forks source link

TO DO LISTE - bevor etwas gemacht werden kann! #37

Open DO1JLR opened 5 years ago

DO1JLR commented 5 years ago

Hier mal eine Übersicht, was man so mehr oder wniger dringend machen muss, bevor man neue Projekte (Beispiel Openstack) sinvoll realisieren kann:

rtt-mmk commented 5 years ago

Hier mal eine Übersicht, was man so mehr oder wniger dringend machen muss, bevor man neue Projekte (wie Openstack) realisieren kann:

  • Setup auf "alte" APU2 deployen - mit Debian 10
  • IPv6 macht massiv Probleme und will überhaupt nicht performat. Muss man echt mal ausfürlicher debuggen.
  • DNS spricht noch nicht mit dem DHCP Server und löst so keine Hostnamen auf
  • Alles ist ein großes Layer 2 Netz - Es braucht hier dringenst eine Segmentierung
  • WLAN Controller ist veraltet und sollte dringenst mal repariert werden - auf einen neuen Server!
  • Clients beschweren sich über RANDOm WLAN Probleme

    • legacy WLAN bauen - mit 8021.b
    • modernes WLAN bauen - mit 8021.ac und verschlüsselten Management traffic
  • Kabelführung im Serverraum (EG) unter aller Sau - Dringend neu machen
  • STROM im Serverraum (EG) sehr bedenklich. Man sollte zumindest mal alles halbwegs ordentlich verkabeln (und beschriften)
  • ferm (wrapper um iptables) macht probleme und sollte repariert oder besser durch native iptables regeln ersetzt werden!
  • Secoundary DNS eventuell lokal hosten mit etwas mehr caching, so dass das auch offline funktionieren könnte
  • SWITCHE sind nicht alle erreichbar:

    • ~Switche im Keller haben Probleme, aber keiner weiß was. Personen die sich das anschauen sind immer so eingeschüctert, dass sie nichts dazu sagen.~
    • Verkabelung der Switche im Keller kompolett ziehen und sagen, muss man neu machen
    • Schild dran: Switche sind NICHT redundant. Wecher IDIOT denkt so was? WTF!
    • Zweite Fiber in den Keller: Switche redundant anbinden: #wontfix
    • Switch im besprechungsraum seit Alex Loop Attake offline/port down -> reparieren und beschrften
    • Switche haben weder Spanning Tree am laufen noch weiß man ob sie etwas gegen loops machen
  • KEIN MONITORING

    • Switche sollten ins Monitoring - Inklusive Port monitoring
    • Router sollte ins Monitoring
    • WLAN APs sollten das auch
    • Dedizierte Services auch
  • Strichliste Zertifikat abgelaufen - hat aber noch neimand bemerkt
  • Strichliste hat kein backup - das ist kacke!
  • Openstack funktioniert noch nicht

    • sollte man mal aufsetzen, nachdem wesentliche Teile der Liste abgearbeitet sind

also im Fall von openstack geht es bei der doppelten Anbindung um die Netzwerkarten in den Server und, dass openstack grundsätzlich 2 Netze hat (management-verwaltung und das compute-netz...). ich möchte auch noch drauf kommen, wenn eine netzwerkkarte mal bricht...über welchen router und wie, egal. aber ich möchte nicht, einer der openstack-kisten hart ausschalten müssen, nur wenn eine netzwerkkarte nicht mehr tut, erst recht nicht, wenn sie mit ceph laufen!

rtt-mmk commented 5 years ago

bevor man neue Projekte (wie Openstack) realisieren kann

dieses Erpressungs-artige vorgehen wird in einem Verein leider nicht funktionieren - sehr schlechte Sache. Die allermeisten werde über diese Tour halt gar nichts machen!

DO1JLR commented 5 years ago

[...]

also im Fall von openstack geht es bei der doppelten Anbindung um die Netzwerkarten in den Server und, dass openstack grundsätzlich 2 Netze hat (management-verwaltung und das compute-netz...). ich möchte auch noch drauf kommen, wenn eine netzwerkkarte mal bricht...über welchen router und wie, egal. aber ich möchte nicht, einer der openstack-kisten hart ausschalten müssen, nur wenn eine netzwerkkarte nicht mehr tut, erst recht nicht, wenn sie mit ceph laufen!

Guter hinweis.

Redundante Anbindung ist in die Liste mit aufgenommen.

Dazu gehört dann auch die Netzwerktopologie umbauen (auch aufgenommen)

Und die Netzwerktopologie sichtbarer zu dokumentieren (gleich auch aufgenommen)

-> Zur Übersicht habe ich deinen Kommentar versteckt damit das issue lesbar bleibt.

DO1JLR commented 5 years ago

bevor man neue Projekte (wie Openstack) realisieren kann

dieses Erpressungs-artige vorgehen wird in einem Verein leider nicht funktionieren - sehr schlechte Sache. Die allermeisten werde über diese Tour halt gar nichts machen!

Das ist nicht als Erpressung gemeint sondern die nackte Tatsache das du hier einerseits redundante Netzwerkhardware forderst (woher auch immer wir das nehmen sollen) so wie redundante Netzwerk verkabelung (da müsste mal jemand Fiber legen) und redundante Router (hat jemand eine APU als Fallback Router übrig?)

Das alles - so wie bereits die frühzeitige Ankündigung einer segmentierung des Netzes - wird einen wandel im Netz mit sich bringen.

Und davon werden auch IP Adressen betroffen sein die sich - wie ich gehört habe - nicht im nachhinen anpassen lassen.

Daher die warnung: Erst die umstellung - dann das aufsetzen.

Es sei denn du weißt es besser und kannst das mit dem Netz und IPs ändern problemlos verkraften.

rtt-mmk commented 5 years ago

ok. so hört sich das sinnvoller an. prinzipiell verkraftet Openstack eine Änderung der IPs/Netze solange halbwegs gut, solange die VMs darin noch nicht große was bereitstellen, was hart auf diese IPs/Netze zeigt...so ein leeres/frisch installiertes openstack nur mit den Standard-Diensten (nova:compute, neutron:netzwerk, cinder:speicher, glance:images) dürfte umstellbar sein - das dürfte ich verkraften. also können wir damit ruhig anfangen. Sollten wir aber mehr darauf aufbauen, dann wir eine Neztumstellung später schwierig - unmöglich.

Ich bin übrigens gleich für vlans! unterstützen das die Router in der Toolbox? dann sollten wir das mal angehen, und openstack dann in zwei eigene deployen. Redudanter Router war so eine Wunschvorstellung bzw. lässt sich mit zweien halt besser was fixen -man probiert eine Lösung zuerst auf einem aus und hat noch einen Fallback mit der bisher funktionierenden config...muss das unbedingt eine APU sein? (Hardware haben wir ja genug, man müsste sie nur anstöpseln wieder an den Strom stecken;)

DO1JLR commented 5 years ago

Ja, VLANs sind bereits in Verwendung und werden genutzt. Siehe auch doc/VLANS.md

Die switche haben aktuell standardmäßig VLAN1 an jedem Port und leiten das auch standardmäßig ungetagged aus - es sei denn es ist etwas anderes Konfiguriert.

Die APs sind beispielsweise an einem Port wo die anderen VLANs getagged kommen. Denn auch Freifunk hat hier ein eigenes VLAN.

Der Router kann auch VLANs wen man sie ihm konfiguriert.

Alles eine Frage der Konfiguration...