Workflows¶
fastd-keys¶
Damit die Nodes eine VPN-Verbindung aufbauen können, muss der öffentliche fastd Schlüssel auf die Gateways gelangen.
Wir verwalten diese Keys in Git-Repositories:
Mainz: peers-ffmz.git
Wiesbaden: peers-ffwi.git
Bei dem ersten Start der Gluon Node wird ein fastd Schlüsselpaar erzeugt.
Im Beschreibungstext steht, man solle den erzeugten öffentlichen Schlüssel per Mail an unsere Listen schicken. Alternativ lässt sich auch ein Link klicken, der das Email-Programm öffnet und eine neue Mail ausfüllt.
Mainz:
keys (at) freifunk-mainz.de
Wiesbaden:
keys (at) freifunk-wiesbaden.de
Die Empfänger dieser Liste sind am Besten auch Mitglieder des fastd-keys GitHub Teams - Mitglieder dieser Gruppe haben Schreibrechte auf die peers Repositories.
Die neuen Keys von der Liste werden wie unten gezeigt lokal eingetragen, die Änderungen wie gewohnt gepusht.
Bemerkung
Damit der Nodebesitzer und die anderen Empfänger der Keys-Listen bescheid wissen, muss nach dem Eintragen der Keys die Mail beantwortet werden. Den Nodebesitzer ins To:-Feld, keys@freifunk-...
ins CC: (Oder einfach auf Reply-All klicken..).
Alle 15 Minuten kommt ein Script vorbei und synchronisiert die neuen Keys von GitHub auf die Gateways.
Siehe auch
fastd-keys Format¶
Ein fastd-key ist ein 64-Zeichen langer HEX-String:
0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
Damit der fastd-daemon den Schlüssel lesen kann, muss noch etwas Syntax drum rum:
key "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef";
Bei Start oder Neuladen des fastd-daemons wird das Config-File neu eingelesen.
In diesem steht, fastd möge zusätzlich noch alle Dateien aus dem peers
-Ordner mit einlesen (== peers-… .git Repository).
fastd nimmt den Dateinamen des keys als peer name. Hat die Node z.B. den Namen Wurstsalat ist die Struktur denkbar einfach:
Dateiname:
Wurstsalat
:key "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef";
Einige Dateinamen werden zur einfachen Zuordnung mit einem Prefix markiert. In Benutzung/Angedacht sind:
- gw
Für Gateways (
gw_Lotuswurzel
,gw_Spinat
).- srv
Für Dienste-Server (
srv_Aubergine
).- chaos
Für Nodes im cccmz (
chaos_Haggis
).- peng
Für Nodes im pengland.
exitVPN Accounts¶
Anfragen aus dem Freifunknetz in das Internet tunneln wir durch das exitVPN, um die Störerhaftung zu umgehen.
Dies hat den Vorteil, dass Anfragen in das Internet anonymisiert werden, Anbieter sehen nur dass die Anfrage aus dem Freifunk-Netz kommt.
Hierbei handelt es sich um OpenVPN-Angebote, meist in Schweden oder Niederlande.
Diese werden im Vorraus gezahlt, und müssen von Hand aufgeladen werden.
Problem - Dies wird all zu gerne verpeilt!
Im gateway-configs.git findet sich eine exitvpn.yaml
Dort wird pro Gateway hinterlegt, welcher VPN-Account hinterlegt ist, und bis zu welchem Datum dieser bezahlt ist.
Einmal tägtlich kommt ein Script vorbei, und schreibt bei nähern des Datums Mails auf die admin@
-Listen, ansonsten wird ein mal pro Woche eine Übersicht verschickt.
Siehe auch
Firmware updates¶
Firmware updates müssen nach dem kompilieren noch signiert werden. So stellt Gluon die Integrität der Firmware Dateien sicher. Dazu wird die manifest datei, die Teil jedes kompilierten Gluon releases ist mittels ecdsasign signiert. Je nach Einstellungen in der site.conf und je nach build (experimental, beta, stable) sind eine verschiedene Anzahl von signaturen nötig.
Ecdsa utils intallieren & Key generieren¶
Siehe hier: http://wiki.freifunk-flensburg.de/wiki/ECDSA_Util
Der öffentliche Schlüssel muss dann noch in die site.conf im imagebuilder eingetragen werden.
Firmware signieren¶
Man braucht den Inhalt aus der manifest Datei, vom Anfang bis zum Ende Der Dateinamen der Router (also bis zum —–). Diesen speichert man ab und generiert die Signatur mit:
ecdsasign manifest < $private_keyfile
Die erhaltene Signatur fügt man jetzt unten an die manifest Datei an (unter dem —–) an.