Re: GW-Struktur, war: Re: AW: Gateways Nürnberg, was ist da los?

Christian Dresel fff at chrisi01.de
Di Sep 22 00:40:20 CEST 2015


Guten Abend (oder gute Nacht...)

bevor ich jetzt unter jedem Punkt ein "ja seh ich auch so/so ähnlich" 
schreibe fass ich mich kurz und sag, schicke Ideen mit einer Ausname:
Zwei Serveradmins, wie stellst du dir das genau vor?
Mein RootPW bekommt bestimmt niemand (für das Ding hafte immerhin ich) 
und anders macht ein 2. Admin in meinen Augen keinen Sinn, gerne 
natürlich lass ich bei einem Treffen Leute auch mal auf den Server 
gucken wenn denn jemand will, dann sitzt ich aber daneben. Sorry da bin 
ich einfach ein wenig eigen.
Ich wäre für eine Art festes Webinterface:
- Ausgaben der wichtigsten Sachen (bisschen was hast du ja schon 
aufgezählt, dazu z.b. wieviele DHCP Clients aktuell drauf sind usw. ich 
hab da schon mal ganz ganz ganz bisschen angefangen und einfach vnstat 
ein ganz klein bisschen erweitert: http://37.120.189.175/vnstat)
- Fernsteuern von wichtigen Sachen für ausgesuchten Personenkreis 
(.htaccess Schutz o.ä.) wie z.b. dhcp abschalten (bei Probleme damit 
keine weiteren IPs verteilt werden) o.ä. ist ja mit php und system() 
kein Problem (bei ordentlichen .htaccess Schutz und wenn man nicht 
gerade system($_GET['asdf']) schreibt in meinen Augen auch kein Problem ;))
soviel PHP hab ich auch gerade noch drauf um sowas auf die Beine zu 
stellen wenn gewünscht (vielleicht nicht der schönste Profi Code aber er 
wird funktionieren und sicher sein ;)). Es müsste dann nur mal gemeinsam 
zusammen getragen werden was wir genau wollen.

Ansonsten ja, ich denke auch daran sollten wir Arbeiten vorrangig 
vielleicht wirklich erst mal eine sinnvolle Verteilung der Gateways 
(siehe heute, Nürnberg ist fast tot und Fürth langweilen sich die 
Server, das ist irgendwie ziemlich schief).

Gruß

Christian

Am 22.09.2015 um 00:11 schrieb Michael Fritscher:
> Hi,
>
> wir sollten uns glaube ich so langsam mal Gedanken um die GW-Struktur machen.
>
> Wir haben einige Server, die in allen Hoods mit drinhängen, sowie Hoods,
> wo 5 GWs herumwerkeln. Unter denen gibt es mittlerweile einen ziemlichen
> Verhau an GRE-Links.
>
> Das ist zwar alles schön und gut, produziert aber ziemlichen Overhead und
> auch unnötigen Traffic. Außerdem macht es die Konfigurationsdateien und
> die Fehlersuche nicht gerade übersichtlicher.
>
> Deswegen mein Vorschlag:
>    * Jeder Gateway sollte in max. 3 Hoods drin sein.
>    * Jede Hood sollte 3 GWs haben - was ein guter Kompromiss zwischen
> Ausfallsicherheit und Overhead sein sollte. Davon sollte(n) einer,
> besser 2 einen direkten (=nicht über olsrd) Uplink ins Internet haben.
>    * Jeder Gateway sollte 2-3 GREs zu GWs haben, die wenig bis keine
> gemeinsame Hoods haben (Hood-intern sind die GWs ja eh per fastd
> verflochten)
>    * Wenn wir mehr Server haben sollten wir die Hoods verkleinern.
>
> Weitere eher administrative Vorschläge:
>    * Jeder Gateway sollte min. 2 Admins haben - zum einen wegen der
> Erreichbarkeit, außerdem können so Neulinge besser eingearbeitet und
> betreut werden. Ganz ehrlich ist m.E. ein GW mit zu viel Verantwortung
> verbunden als dass ein (Linux & Netzwerk-) Neuling ein GW alleine
> betreiben sollte.
>    * Wenn bemerkt wird, dass ein GW beispielsweise einen fehlerhaften
> Uplink hat, diesen aber weiterhin announct, sollte er temporär per
> KeyExchange gekickt werden, um Schaden vom Netzwerk zu vermeiden.
>    * Traffic-Statistik für alle Interfaces sowie olsrd-Daten sollten
> Pflicht werden (ob jetzt vnstat oder mrtg ist egal) - darüber können
> schnell Probleme festgestellt werden.
>    * Man könnte sich überlegen, ob man einen Service baut, der anhand der
> gewünschten Hoods, GREs etc. automatisiert GW-Konfigurationstemplates
> erstellt - dann wären die einheitlich und es gäbe weniger Raum für
> Fehler.
>    * Alternativ könnte man sich überlegen, ob eine Ausgabe von ifconfig -a,
> ip route/rule show, ip route/rule show table sowie
> /etc/network/interfaces zwingend "irgendwo" hinterlegt und aktuell
> gehalten werden muss (Dinge wie öffentliche IPs maskieren sind erstmal
> Details ;) )
>    * Eine weitere Alternative wäre ein über ein Script bereitgestellte API,
> die jedes GW haben muss und worüber die aktuelle Konfiguration
> eingesammelt werden kann. Wäre eventuell was fürn keyxchange.
>
> Das sind einfach so meine Ideen zu diesem Themenkomplex, wo nichts in
> Stein gemeiselt ist ;-) Aber ich denke, dass wir so langsam eine Größe
> erreicht haben, wo man sich darüber zumindest mal Gedanken machen sollte.
>
> Viele Grüße,
> Michael
>




Mehr Informationen über die Mailingliste franken-dev