Hi,
 Moin zusammen,

 da ja das Hoodsystem relativ weit fortgeschritten ist, sollten wir uns
 hierzu noch die ein oder anderen Gedanken zu machen;:

 - Releasebeitrag im Blog, schreibe ich gerne sofern ihr mir hier ein
 paar Anhaltspunkte noch geben könnten. Klar ist, dass die Router sich
 nach Ihren Koordinaten in eine entsprechende Hood verbinden
Okay, ich glaube aber für den Endnutzer der Webseite reichen erstmal die
Punkte, dass wir die Serververwaltung per Puppet automatisieren und
unser nordwest-gebiet unterteilen in kleinerer hoods, um die grundlast
(die deutlich mehr als linear zur netzgröße wächst) deutlich zu
reduzieren. vielleicht noch der Hinweis, dass wir übergangsweise die
hoods voneinander isoliert, d.h. ohne routing dazwischen betreiben
werden, weil wir erstmal die hoods für sich laufen haben wollten und das
andere zeitlich nicht soooo drängt.

 - Zugriffsrechte: Wir sollten überlegen, ob es nicht sinnvoller wäre,
 die Hood erst zu releasen wenn auch alle Admins Zugang dazu haben.
Zu den Servern werden die admins - denke ich - direkt wieder zugang
bekommen, allerdings ganz klar unter der auflage bei problemen sehr sehr
besonnen und systematisch bei etwaigen fehlern die Suche zu betreiben.
Da die config weitestgehend über puppet läuft, wäre eine manuelle
änderung auf einem server in einem bereich, den Puppet nicht verwaltet
wieder eine richtig unangenehme fehlerquelle. Und Puppet sollte sich
normalerweise darum kümmern, dass das system dauerhaft in dem
definierten funktionsfähigen zustand läuft. Insbesondere, da
der
Puppetagent regelmäßig (ala cron Dienste und configs checkt und ggf.
startet und wiederherstellt.

Was den Puppetmaster anbetrifft, würde ich den Zugang *zunächst* streng
handeln, bis wir eine art mini-schulung mit denjenigen, die Zugang haben
wollen, durchgeführt und eine vernünftige versionsverwaltung für die
konfigurations-dateien auf dem server aufgebaut haben. Puppet
grundsätzlich ist nicht sonderlich schwer, aber es hat hier und da - wie
jedes system - ein paar fallstricke.

In einem ersten Schritt würde ich vorschlagen, dass diejenigen
interessierten zugang zum Git-repo bekommen, in dem momentan die config
entwickelt wird. dieses enthält zur zeit auch vertrauliche daten wie zB
die fastd-private keys der server und openvpn-cert-dateien, weshalb es
derzeit nicht öffentlich ist. wie das dann zukünftig gehandelt wird,
müssten wir dann mal überdenken (vllt. mit privaten git submodules
für
die sensiblen daten?)

 - Einteilung der Hoods, damit man den Nutzern hierdrüber auch Details
 nennen kann.

Unter hood.ffnw findet sich der hoodgen (hood-generator) den ich
entwickelt habe und mit welchem man die grenzen, bssid, pubkeys und
server der hoods festlegen kann. Tarek hatte bisher wimni ganz grob
erstmal 3 waagerechte streifen angedacht, einen um Oldenburg, einen um
Wittmund und einen um Osnabrück. Für den start ganz sinnvoll, denke ich,
ggf. muss das später nochmal geändert werden.

 Vielleicht fällt jemandem ja noch mehr ein
 -- 
 vg
 Stefan

 Dev mailing list
 Dev@lists.ffnw.de
 https://lists.ffnw.de/mailman/listinfo/dev