Protokolle/Techniktreffen 2013-12-12: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Spky (Diskussion | Beiträge) K |
Jan (Diskussion | Beiträge) K (etwas präzisiert) |
||
| Zeile 10: | Zeile 10: | ||
* Gates sind DHCP (dhcpd) | * Gates sind DHCP (dhcpd) | ||
| − | ** DHCP verteilt Leases bis Threshold | + | ** DHCP verteilt neue Leases bis zum Erreichen eines Threshold (empirisch ermitteln) |
| − | ** DHCP ermittelt Last anhand | + | ** DHCP ermittelt/berechnet seine Last anhand der Anzahl der verteilten Leases und Bandbreitenauslastung |
| − | ** DHCP verteilt wenn Last zu hoch keine neuen Leases aber beantwortet/bestätigt die vorhandenen Leases weiterhin | + | ** DHCP verteilt, wenn Last zu hoch, also über dem Threshold, keine neuen Leases mehr, wohl aber beantwortet/bestätigt er die vorhandenen Leases weiterhin |
| − | ** DHCP verteilt Leases mit TTL | + | ** DHCP verteilt Leases mit TTL 5 Min. |
| − | ** Jedes Gate hat eigene Adressrange | + | ** Jedes Gate hat seine eigene Adressrange, disjunkt von denen anderer Gates. |
* Nodes verbinden sich per Tinc zu Gates | * Nodes verbinden sich per Tinc zu Gates | ||
| − | * Nodes bekommen Pool von 20 | + | * Nodes bekommen einen Pool von 20 Tinc-Servern hinterlegt (im Voraus angelegte Schlüsselpaare) als Wachstumspfad |
| − | * Nodes bekommen DNS Namen der Gates eingetragen | + | * Nodes bekommen DNS-Namen der Gates eingetragen |
* Nodes entscheiden bei Boot: | * Nodes entscheiden bei Boot: | ||
** welche Tinc-Server erreichbar sind (Ping check) | ** welche Tinc-Server erreichbar sind (Ping check) | ||
** Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner | ** Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner | ||
| − | ** jedes Gate hat | + | ** jedes Gate hat eigenes Priv/Pub-Schlüsselpärchen |
* tinc verschlüsseln ja/nein? | * tinc verschlüsseln ja/nein? | ||
| − | ** tinc | + | ** tinc-Compression aus, da gescheite Protokolle sowieso komprimiert sind und der Rest ist nicht komprimierbar ist (JPGs, MPGs) |
| − | ** tinc | + | ** tinc-Verschlüsselung an |
** node publickeys werden per GIT verteilt | ** node publickeys werden per GIT verteilt | ||
| − | ** node publickeys werden von der | + | ** node publickeys werden von der Technikgruppe eingetragen |
** es werden 20 tinc schlüssel für die Gates vorab generiert und im node-image hinterlegt | ** es werden 20 tinc schlüssel für die Gates vorab generiert und im node-image hinterlegt | ||
** verschlüsselungs-algo wird von sebastian getestet und der für MIPS schnellste ausgewählt (weil starke crypto nicht gebraucht) | ** verschlüsselungs-algo wird von sebastian getestet und der für MIPS schnellste ausgewählt (weil starke crypto nicht gebraucht) | ||
| Zeile 37: | Zeile 37: | ||
* tinc namensschema: | * tinc namensschema: | ||
** soll einheitlich vorgegeben werden | ** soll einheitlich vorgegeben werden | ||
| − | ** evtl. hash aus vorgegebener datei | + | ** (evtl. hash aus vorgegebener datei) |
| + | *** besser gut menschenlesbar | ||
** evtl. prefix gleich und zweiter teil private und selbst bestimmbar | ** evtl. prefix gleich und zweiter teil private und selbst bestimmbar | ||
** brauchen wir tincnamen? | ** brauchen wir tincnamen? | ||
* batman | * batman | ||
| − | ** originator | + | ** originator Interval auf 10 Sek. |
| − | ** network mode und andere | + | ** network mode und andere Optionen anschauen/testen |
| − | |||
* wenn tinc-uplink weg dann freifunk SSID aus/verstecken? | * wenn tinc-uplink weg dann freifunk SSID aus/verstecken? | ||
* mesh verstecken? | * mesh verstecken? | ||
Version vom 14. Dezember 2013, 19:22 Uhr
Gedankenfesthaltungsprotokoll vom Techniktreffen am 12.12.2013 zur Grundinfrastruktur
- Gates vereinen Entry(Tinc)* und Exit(Schweden)-Level in einer Maschine (keine geteilte Entry-/Exit-Node Strategie)
- Gates verbinden nach Schweden per VPN
- Gates routen+NATen zwischen Freifunk-Wolke und Schweden/Internetz
- Gates sind DHCP (dhcpd)
- DHCP verteilt neue Leases bis zum Erreichen eines Threshold (empirisch ermitteln)
- DHCP ermittelt/berechnet seine Last anhand der Anzahl der verteilten Leases und Bandbreitenauslastung
- DHCP verteilt, wenn Last zu hoch, also über dem Threshold, keine neuen Leases mehr, wohl aber beantwortet/bestätigt er die vorhandenen Leases weiterhin
- DHCP verteilt Leases mit TTL 5 Min.
- Jedes Gate hat seine eigene Adressrange, disjunkt von denen anderer Gates.
- Nodes verbinden sich per Tinc zu Gates
- Nodes bekommen einen Pool von 20 Tinc-Servern hinterlegt (im Voraus angelegte Schlüsselpaare) als Wachstumspfad
- Nodes bekommen DNS-Namen der Gates eingetragen
- Nodes entscheiden bei Boot:
- welche Tinc-Server erreichbar sind (Ping check)
- Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner
- jedes Gate hat eigenes Priv/Pub-Schlüsselpärchen
- tinc verschlüsseln ja/nein?
- tinc-Compression aus, da gescheite Protokolle sowieso komprimiert sind und der Rest ist nicht komprimierbar ist (JPGs, MPGs)
- tinc-Verschlüsselung an
- node publickeys werden per GIT verteilt
- node publickeys werden von der Technikgruppe eingetragen
- es werden 20 tinc schlüssel für die Gates vorab generiert und im node-image hinterlegt
- verschlüsselungs-algo wird von sebastian getestet und der für MIPS schnellste ausgewählt (weil starke crypto nicht gebraucht)
- tinc namensschema:
- soll einheitlich vorgegeben werden
- (evtl. hash aus vorgegebener datei)
- besser gut menschenlesbar
- evtl. prefix gleich und zweiter teil private und selbst bestimmbar
- brauchen wir tincnamen?
- batman
- originator Interval auf 10 Sek.
- network mode und andere Optionen anschauen/testen
- wenn tinc-uplink weg dann freifunk SSID aus/verstecken?
- mesh verstecken?