Home Esplora Aiuto
Accedi
ffdo
/
wiki
2
0
Forka 0
File Problemi 0 Pull Requests 0 Wiki
Albero (Tree): cb22634642
Rami (Branch) Tag
wiki
/
Technik
/
Netzinfrastruktur
/
Supernodes
/
todo.page

todo.page 4.5 KB
Cronologia Originale

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081 
  1. ---
    2. 

  2. format: markdown
    3. 

  3. categories: Netz-Infrastruktur, Backbone, Supernodes
    4. 

  4. title: To-Do
    5. 

  5. ...
    6. 

  6. 

  7. 

  8. # Zukünftige Entwicklung / TODOs
    9. 

  9. 

  10. ## Kurzfristig
    11. 

  11. 

  12. ### Bereitzustellende Dienste
    13. 

  13. 

  14. NTP: Es können auch externe NTP-Server im DHCP angegeben werden, aber selbst auf den Supernodes NTPDs zu betreiben dürfte am günstigsten sein.
    15. 

  15. **done**
    16. 

  16. 

  17. 

  18. ### Härtung
    19. 

  19. 

  20. Es sind überflüssige/ungenutzte Pakete und Komponenten auf den Supernodes installiert. Diese sollten überprüft und entfernt werden. 
    21. 

  21. 

  22. U.a. habe ich bei kurzer Durchsicht gefunden:
    23. 

  23. 

  24. * Exim, auf Loopback gebunden
    25. 

  25. * Nginx, ohne Funktion
    26. 

  26. * RPCBIND etc. sind aktiv, obwohl kein NFS genutzt wird.
    27. 

  27. 

  28. ### Mittelfristig & Langfristig
    29. 

  29. 

  30. > Wir können komplette Supernode-Cluster z.B. über GRE-Tunnel und BGP an unsere produktiven Supernodes anbinden und ihnen somit Zugang zum Freifunk-Netz geben. Damit können wir z.B. Neuentwicklungen als Sandbox aufsetzen und sie technisch wie eine Domäne als "Subdomäne" betreiben. Es muss also nicht in der Produktivumgebung experimentiert werden. Auch können einzelne Supernodes, die am batman-adv teilehmen aber keinen eigenen Uplink ins Backbone haben problemlos angeschlossen werden. Diese dürfen aber in batman-adv nicht als Gateway konfiguriert werden.
    31. 

  31. 

  32. > *Anmerkung:* Hier habe ich (Markus) meine subjektive Meinung notiert, bitte beliebig ergänzen / wiedersprechen / diskutieren, es ist sicher nicht vollständig...
    33. 

  33. 

  34. 

  35. ### Neuaufbau / Formalisierung
    36. 

  36. 

  37. Ein Neuaufbau auf Debian 8 und mit Ansible formalisiert ist geplant.
    38. 

  38. 

  39. ### Überprüfung / Tausch von genutzten Komponenten
    40. 

  40. 

  41. > Bitte immer auf das Prinzip Datensparsamkeit achten. `dnsmasq` ist z.B. so konfiguriert, dass es von DHCP-Clients mitgesendete Client-Namen nicht loggt.
    42. 

  42. 

  43. * DNS und DHCP für die Supernodes werden über `dnsmasq` bereitgestellt.
    44. 

  44.     * Nutzung von [Unbound](https://www.unbound.net/), [PowerDNS](https://www.powerdns.com/) o.ä. als Cachender DNS-Resolver
    45. 

  45.     * DHCP durch ISC-DHCPD? Weiterhin dnsmasq?
    46. 

  46.     * **done** es wird Unbound benutzt. 
    47. 

  47. * Einige Dienste und Netzwerk-Konfiguratonsschritte werden durch Scripte von Fastd getriggert gestartet. Dies ist weitgehend nicht mehr notwendig
    48. 

  48.     * Überführung der Netzwerkkonfiguration (sofern möglich) zu `systemd-networkd` 
    49. 

  49.     * Abbildung der gesamten Abhängigkeitsstruktur zwischen Diensten, Interfaces und dynamisch getriggerten Konfigurationsschritten durch Systemd-Units anstatt an verschiedenen Stellen z.B. durch Fastd getriggerte Scripte.
    50. 

  50. * Bereinigung von `/etc/sysctl.conf`, Freifunk-spezifische Settings nach `/etc/sysctl.d/`
    51. 

  51.     * Einige Sysctl-Settings werden durch Scripte gesetzt, diese ebenfalls beachten.
    52. 

  52. 

  53. # Research-Themen
    54. 

  54. 

  55. ## Skalierung von Fastd
    56. 

  56. 

  57. Fastd kann nur auf einer CPU rechnen. Dies ist der limitierende Faktor bei der Skalierung von Supernodes. Momentan wird skaliert, indem mehr (virtuelle) Supernodes auf der selben Hardware betrieben werden. Es könnte aber auch versucht werden, mehrere Fastd-Prozesse (Anzahl der Kerne) auf unterschiedlichen Ports eingesetzt werden und in die Clients konfiguriert werden um vorhandene Ressourcen besser zu nutzen. 
    58. 

  58. 

  59. **done** Auf Port 10000 und 10001 läuft jeweils eine Fastd-Instanz für die Clients
    60. 

  60. 

  61. ## Technologie für Transfernetz zwischen den Supernodes
    62. 

  62. 

  63. Alle Supernodes der Community untereinander benötigen ein geteiltes L2-Netz. Um dieses über die Server-Standorte zu realisieren wird momentan die Fastd-Instanz `backbone` ohne Verschlüsselung genutzt, die ein M:N-Netz zwischen unseren Supernodes darstellt. 
    64. 

  64. 

  65. Ggf. kann man hier zukünftig auf `vxlan` setzen. Dabei wird kein statischer Peer oder Mulitcast-Gruppe angegeben, sondern die Peers explizit mit [`bridge fdb add`](http://man7.org/linux/man-pages/man8/bridge.8.html) in die Forwarding-DB des virtuellen Switches eingetragen. Es muss die IP-Adresse sowie MAC-Adresse jedes Peers bekannt sein.
    66. 

  66. 

  67. # Umbenennung der Nodes
    68. 

  68. 

  69. Momentan haben die Supernodes DNS-Einträge unter `do.node.freifunk.ruhr`.
    70. 

  70. Das dort vergebene Hostnamen-Schema ist historisch so gewachsen, hat aber keine technische Relevanz mehr. 
    71. 

  71. Wir können auch nach Belieben ein anderes Schema einführen. 
    72. 

  72. 

  73. > *Vorschlag:* Um das Schema zu vereinfachen die Nodes flach durchnummerieren und unter `ffdo.de` ansiedeln. Beispiel für mögliche Benennung: `sn1.nodes.ffdo.de`, `sn2.nodes.ffdo.de` etc. 
    74. 

  74. 

  75. alter Name                  neuer Name   
    76. 

  76. --------------------------  -------------
    77. 

  77. node01-1.do.freifunk.ruhr   *t.b.d.*     
    78. 

  78. node02-1.do.freifunk.ruhr   *t.b.d.*     
    79. 

  79. node01-2.do.freifunk.ruhr   *t.b.d.*     
    80. 

  80. node02-1.do.freifunk.ruhr   *t.b.d.*     
    81. 

  81. map.do.freifunk.ruhr        map.ffdo.de  
    82.