Hi,
für die, die Interesse haben sich in der Entwicklung zu beteiligen. Es
wird im Mainframe (der Oldenburger Hackerspace) ein Vortrag zur
Einführung in git geben. Git ist ein versions-verwaltungs-programm was
ein essentielles Entwicklungstool bei uns ist.
vg
Tarek
-------- Forwarded Message --------
Subject: [Diskussion-KtT] Vortrag: Einführung in git
Date: Sun, 3 Jan 2016 20:48:55 +0100
From: Sebastian Reichel <sre(a)kreativitaet-trifft-technik.de>
Reply-To: Allgemeine Diskussion Kreativität trifft Technik e.V.
<diskussion(a)kreativitaet-trifft-technik.de>
To: KtT Diskussion <diskussion(a)kreativitaet-trifft-technik.de>
Hi,
Der nächste Vortrag findet am folgenden Samstag, den 09.01.2016 um
19:00 statt. Thema ist dieses mal eine Einführung in Git. Diese
soll zunächst in Vortragsform erfolgen, um dann an den Notebooks der
Teilnehmer git zu installieren und mit diesem zu arbeiten.
Termin 09.01.2016 19:00
Thema: Einführung in Git
Referent: sre
https://www.kreativitaet-trifft-technik.de/talk/git.html
-- Sebastian
Hallo,
tl;dr: wer ahnung von puppet hat, möge sich mal das schaubild unter
https://wiki.nordwest.freifunk.net/Puppet ansehen und beurteilen bzw.
ggf. verbessern/alternativen vorschlagen. Alle anderen dürfen natürlich
gerne aus Interesse mitlesen oder es ignorieren, ich wollte nur mal die
aktuellen Überlegungen kommunizieren.
wie ihr ja wisst, sind wir nun seit einigen Wochen dabei, die Verwaltung
der Server durch Puppet übernehmen zu lassen. Grundsätzlich bietet
Puppet dafür auch tolle Möglichkeiten, jedoch bin ich nun auch an
einigen Stellen an Puppets, bzw. genauer gesagt Hieras Grenzen gestoßen.
In Kürze ist Hiera eine art Datenbank, die auf *.yaml-Dateien basiert
und die Konfigurationsdaten für die sogn. Puppet-Module enthält, welche
wiederum jeweils eine Funktionseinheit eines Servers darstellen (zB
apt-Paket und dessen Konfiguration). Die Puppet-Module enthalten also
entsprechende Templates für die Konfigurationsdateien, die genauen,
teils universellen (zB MTU, ssh-keys oder interface-namen), teils
serverspezifischen Werte (zB Adressbereiche oder fastd-private-key).
Gemäß einer definierbaren Reihenfolge (einer HIERArchie) läd hiera bei
einem puppet-Durchlauf nun die korrekten werte aus der datenbank. So
schaut hier zunächst, ob es node-spezifische Werte (in den
srvXX.ffnw.de.yaml-Dateien) gibt. Falls nein, geht es in der Hierarchie
eine ebene abwärts und es werden die allgemeingültigen Werte (aus der
Datei common.yaml) geliefert. Wie gesagt, grundsätzlich klingt das sehr
fein, der Teufel steckt aber in den Details:
Es gibt im Grunde 3 verschiedene Lookup-Typen in hiera: hiera(),
hiera_merge() und hiera_hash(). Verwendet wird meist der erste, welcher
genau einen Treffer zu dem gesuchten key liefert, nämlich den, der in
der Hierarchie am weitesten oben steht. Dummerweise gibt es Situationen,
da reicht das nicht bzw. führt zu redundanzen und doppelt eingetragenen
werten, die natürlich, was die Wartung angeht, scheiße sind.
Beispiel:
Für die Konfiguration von dhcp über dnsmasq muss in Hiera ein Datensatz
liegen, der im yaml-Format etwa so aussieht:
dnsmasq:
dhcp_range_start: 192.168.0.10
dhcp_range_end: 192.168.0.100
lease_time: 15m
Hierbei sind die Grenzen des Ranges natürlich serverspezifisch, die
lease_time aber tendenziell auf allen Servern gleich und würde in der
serverspezifischen hiera-datei diese nur künstlich aufblasen. Mit
hiera_hash() kann man nun folgendes tun: man definiert in common.yaml:
dnsmasq:
lease_time: 15m
und in srvXX.ffnw.de.yaml:
dnsmasq:
dhcp_range_start: 192.168.0.10
dhcp_range_end: 192.168.0.100
Ruft man nun in einem Modul hiera_hash('dnsmasq') auf, erhält man ein
Objekt, was den obigen vollständigen Datensatz enthält. Dabei entsteht
in den einzelnen serverspezifischen *.yaml keine Redundanz/potenzielle
Fehlermöglichkeit.
Leider ist die hiera_hash()-Funktion sowie eine zusätzliche Einstellung
des 'deeper merging', die hierfür in bestimmten Fällen benötigt wird,
noch recht neu und wird in vorhandenen Puppet-Modulen aus der
Puppet-Forge auch nur selten verwendet. Ein aktuell von uns verwendeter
"workaround" ist nun, die dnsmasq-Konfiguration vollständig in
common.yaml unterzubringen und zwar in dieser Form:
dnsmasq:
dhcp_range_start: "%{hiera('range_start')}"
dhcp_range_end: "%{hiera('range_end')}"
lease_time: 15m
und in der srvXX.ffnw.de folgendes zu speichern:
range_start: 192.168.0.10
range_end: 192.168.0.100
Damit hat man die lease_time nicht mehr in den serverspezifischen werten
und die start- und endadresse wird mit einem verschachtelten lookup eben
aus dieser datei geholt. (Das Beispiel hier ist kein gutes, weil gerade
dnsmasq über genau diese funktion verfügt, aber es ist hier ja nur für
das verständnis). Aber auch dieser Ansatz hat seine grenzen: Diese
verschachtelte hiera()-Funktion kann nur Strings, d.h. keine Nummern,
keine Booleans oder gar Objekte liefern, ebenso ist das Verhalten, wenn
die verschachtelte Abfrage keinen Treffer findet, so, dass die
übergeordnete Abfrage sehr wohl Erfolg hat und dann mit einem leeren
String arbeitet, was manchmal sehr problematisch sein kann.
Neben dieser - ich nenn sie mal -
hiera-eingeschränkter-lookup-problematik gibt es noch eine zweite, die
unangenehm sein kann: Man definiert in der Datei
<environment_name>/manifests/sites.pp, welcher server, welche
Puppet-Module bekommen soll, mit sogn. include-anweisungen der Form:
include dnsmasq
include ntp
include ...
Das gilt dann entweder nur für einen Server oder für alle oder für
diejenigen, deren fqdns ein bestimmten Regex matchen. Anschließend
müssen dann auch für alle die genannten module valide daten in hiera
hinterlegt werden, sonst schlägt der durchlauf fehl. Dort nun Gruppen
für Supernodes und andere Aufgaben anzulegen ist - was ich bisher weiß -
nur auf Umwegen möglich, es gibt hier aber die Methode, den Befehl
hiera_include statt der obigen, klassichen Include-direktiven zu
verwenden, das sieht dann so aus:
hiera_include('classes')
Und nun kann man wiede per hiera in common.yaml oder anderen Dateien der
Hierarchie Klassen angeben, also zb:
classes:
- ntp
- dnsmasq
Das schöne hierbei ist, dass diese Klassen tatsächlich gemerged werden,
d.h. sowohl die Klassen, die in common.yaml angegeben sind als auch die,
die in srvXX.ffnw.de angelegt sind, werden "in einen topf" geschmissen
und dann alle eingebunden. Wodurch man nun recht bequem einzelnen
servern nur bestimmte Module zuweisen kann. Was nun noch fehlt, ist ein
Mechanismus, um Servern bestimmte Rollen zu geben, zB "webserver" oder
"supernode" oder "webserver und supernode", ohne hier wiederum die
gemeinsamen hiera-werte in die serverspezifischen yaml-dateien knallen
zu müssen, sondern sie in einer gemeinsamen webserver.yaml oder
supernodes.yaml zusammenzuhalten. Hierfür habe ich mir das auf der
Wiki-Seite dargestellte Rollen-Konstrukt überlegt, das ähnlich wie bei
der Nginx-Config mit "available" und "enabled" ordnern arbeitet und zum
aktivieren einer Rolle aus "available" nach "enabled" symlinkt.
Desweiteren möchte ich zukünftig dann klar zwischen Modulen aus der
Forge und selbstentwickelten trennen, wobei die selbstentwickelten
künftig nicht mehr das in den hiera-dateien eingebettete
"%{hiera(KEY)}", sondern hiera_hash()-basierte Abfragen nutzen sollen,
wann immer Daten aus unterschiedlichen Ebenen gemischt werden müssen, da
diese bisherige methode die genannten großen Probleme mit sich bringt.
Die Forge-Module werden dann auch nicht mehr in
$codedir/environments/{dev,prod}/modules, sonder in $codedir/modules
liegen - damit ist dann leichter unterscheidbar, was selbstgebaut ist
und was nicht und es kommt nicht zu etwaigen problemen, wenn zB in dev
ein Forge-Modul geupdatet wird, aber selbiges in prod vergessen wird,
sondern alles greift immer auf exakt dasselbe Modul zu.
Soviel dazu, wie gesagt, wenn es Möglichkeiten gibt, die genannten
Probleme zum umschiffen, ohne hier mit etwas gewöhnungsbedürftigen
Symlink-Konstrukten herunmzubasteln, gerne her damit, ich hänge da nicht
dran, sehe derzeit nur keine gleichwertige Alternative.
Viele Grüße,
Eike
Hi,
das nächste gluon release wird weit bis vorraus sichtlich Anfang Februar
verschoben. Daher werde ich die hood Änderungen auf gluon v2015.1.x
portieren.
vg
Tarek
Hallo zusammen,
für das Hood-Setup sind zunächst 4 Hoods vorgesehen, eine fünfte soll
folgen.
Jede Hood soll mit zwei georedundanten Gateways ausgestattet werden.
Mindestens einer von beiden Gateways sollte ein Dedicated Server sein.
Um eine hochwertige und ausfallsichere Internetanbindung zu
gewährleisten, soll jedes Gateway nach Möglichkeit alle zur Verfügung
stehenden Internet-Exits nutzen können. Dafür stehen uns im Wesentlichen
zwei Partner zur Verfügung: Freifunk Rheinland e. V. mit 6 Routern auf 3
Standorte verteilt und einer Gesamtbandbreite von 26 GBit/s sowie der
Freie Netze e. V. in Berlin. AirVPN sollte nicht weiter genutzt werden,
um weitere IP-Konflikte mit dem InterCity-VPN zu vermeiden.
Mit IPv4 steht uns das private 10.18.0.0/16 Netz zur Verfügung.
Osnabrück hat ein weiteres Netz 10.33.0.0/16 reserviert, das derzeit als
Event-Netz in Osnabrück benutzt wird. Genutzt werden soll das Erstere.
Jedem Gateway soll ein /22 (1024 Adressen) zugewiesen werden. Damit sind
theoretisch 64 Gateways möglich, abzüglich Netzen für Dienste etc.
Über Freifunk Rheinland erhalten wir das öffentlich geroutete Netz
2a03:2260:1001::/48. Jedem Gateway soll ein /54 zugewiesen werden. Jedem
Client (als „Endkunden“) stünde dann theoretisch ein /64 zur Verfügung.
Auch hier wären 64 Gateways abzüglich Netze für Dienste möglich, wie
auch 1024 /64 Netze pro Gateway. Die eindeutige IPv6 Adresse kann
weiterhin über SLAAC vom Client selbst gewählt werden. Hier wird die 48
Bit MAC-Adresse in den bis zu 64 Bit IPv6 Netz verarbeitet. Mit den
übrigen 16 Bit des /64 kann der Client Spaß haben... who cares.
Die Vergabe der ULA fd74:fdaa:9dc4::/48 kann aufgrund gleicher Netzgröße
analog erfolgen.
Derzeit stehen 7 Server als Gateway zur Verfügung. Um die 4 Hoods voll
zu machen, brauchen wir noch einen Dedicated Server. Gibt es Vorschläge
/ Kontakte / Möglichkeiten? (Bedingung: Nicht Nürnberg, also nicht bei
netcup.)
Die Zuordnung sieht momentan wie folgt aus. Es wurde darauf geachtet
Gateway-fähige Server in Privatbesitz am Standort des Eigners zu lassen.
ffol:
- srv03 (bytemine fra)
- srv12 (myLoc dus)
ffwtm:
- srv10 (bytemine fra)
- srv04 (netcup nürnberg)
ffos:
- srv06 (myLoc dus)
- srv11 (bytemine fra)
default:
- srvXX ()
- srv08 (netcup nürnberg)
Gibt es begründete andere Vorschläge?
--
Viele Grüße,
Simon
On 12/18/15 11:06, Clemens John wrote:
> Am Donnerstag, 17. Dezember 2015, 00:29:34 schrieb Simon Kurka:
>> Gibt es begründete andere Vorschläge?
>
> Ich habe die Folgebeiträge auch etwas überflogen und meine Anmerkung dazu ist:
> bitte geht Schritt für Schritt vor und verliert euch nicht.
>
> Das Format zum Austausch der Hood-Daten muss natürlich alle Eventualitäten
> vorsehen. Aber bei der konkreten Umsetzung sollte im ersten Schritt
> ausschließlich die Umstellung des derzeitigen Systems auf das Hood-System
> erfolgen. Also dass sich die Router aus einer bestimmten Region nicht mehr zu
> einer zufälligen Supernode verbinden, sondern zu der ihrer Region
> zugewiesenen. Es reicht 1 Hood mit einer Supernode, einem Exit-Gateway und 200
> Routern.
Das bestehende Netz wird schritt für schritt in hoods aufgeteilt. Der
Anfang wird wahrscheinlich in Wittmund/Whv gemacht. Aktuell bin ich
gerade dabei ein Programm zu schreiben was die Supernode Zuteilung auf
den Routern macht.
> Wenn das auch nur annähernd Problemlos klappt (ich erinnere nochmal an die
> Probleme mit dem Batman Update im Sommer), dann können wir alle anderen Punkte
> wie Redundanz, Ausfallsicherheit, Peerings, Transitnetz etc. ganz in Ruhe
> nachziehen.
Hier mussten auf ein schlag alle Router auf eine Version updaten.
vg
Tarek
moin,
ich habe grade durch die puppet module geschaut, das schaut schon mal
super aus!
fehlen noch module?
vnstat
munin
munin-node
vim
mc
nginx
vermisse ich noch
gibt es eine liste?
--
Gruß
pic
@ME https://wiki.nordwest.freifunk.net/picard
Hi,
aktueller stand ist das Eike heute Abend noch mal das OpenVPN Modul
überarbeiten möchte. Simon hat sich in den letzten tagen in bir
eingelesen und würde wohl gerne ein puppet modul für die Rheinland
Anbindung realisieren wollen. Ich würde beginnen die Firmware soweit
fertig zu stellen so das wir spätestens zum Kongress die ersten hoods
aufbauen können. Ich würde vorschlagen das wir Morgen wenn es Eike und
Simon zeitlich passt gegen 18Uhr eine Telko machen um gemeinsam weiter
zu abernten und fragen zu klären.
@Eike Simon: würde euch das passen?
vg
Tarek
Hi,
die dns Konfiguration ist nun auf allen Superneodes fertig.
es sollte jetzt überall aus dem Netz folgende domains aufrufbar sein:
netmon.ffnw
autoupdate.ffnw
hood.ffnw
und gesondert als speedtest:
wget -O - speedtest.ffnw
nun beginne ich mit der Implementierung des Gateway selectirungs Scripts
für die einzelnen hoods.
Sobald das ok für die IP configuration in puppet da ist wird morgen
srv08 über puppet eingerichtet und die erste test hood in betrieb
genommen. (vorausgesetzt es entstehen keine unerwarteten Fehler).
Es sind jetzt noch ~14 Tage bis zur Deadline (10 Tage bis Congress
beginn). Meinem Gefühl nach liegen wir gut im Zeitplan.
vg
Tarek
