|
||
---|---|---|
doc | ||
nix | ||
openwrt | ||
salt | ||
salt-pillar | ||
.gitignore | ||
README.md | ||
cabling.md | ||
contact.md.asc | ||
flake.lock | ||
flake.nix | ||
security.md | ||
subnets.md |
README.md
Netzwerk im Zentralwerk
Begrüßung von Menschen im Haus, die für ihren Anschluss Zugang zum Netzwerk brauchen
Zweck
Das Zentralwerk ist ein Gebäude, das bestmöglich vernetzt sein soll. Das beginnt mit der Bereitstellung vom Zugang zum Internet, reicht über das isolierte Zusammenführen von einzelnen Anschlüssen und endet mit Angebot von zeitgemäßen Diensten für alle, die das Netz nutzen wollen.
Anstatt irgendwie rumzukonfigurieren, soll es eine Nachvollziehbarkeit (Reproduzierbarkeit) der gemachten Einstellungen geben. Mit der Transparenz soll es möglich sein, dass das Netzwerk möglichst einfach verwaltet werden kann. (Stichworte sind: Zusammenarbeit, Wiederherstellbarkeit, Teilhabe, Mitmachen, Nachahmen, …)
Öffentlichkeit
Warum ist das alles einsehbar? Für maximale Transparenz! Wir sind kein Unternehmen das Geheimnisse schützen muss. Stattdessen wollen wir freie Kommunikation für alle!
Wie werden die (wenigen) persönlichen Daten "öffentlich" verwaltet? Mit entsprechender Verschlüsselung! Wir, ein kleiner Kreis von Menschen die das Netzwerk im Zentralwerk betreuen, haben dafür einen Geheimschlüssel. Im Übrigen behandeln wir gleichermaßen sicher die "heiligen" Zugangsdaten für die Geräte (und andere für den Betrieb wichtigen Instanzen).
Informationen für Lebewesen, die das Netzwerk mit verwalten
Inhaltsverzeichnis
- Verkabelung Patchpanel Haus B
- TODO: tuerme, saal
- Planung der IP-Adressbereiche
- (verschlüsselte) Kontakte zu den Personen mit den einzelnen Anschlüssen
- Dokumentation
- WiFi-Provisionierung und Erstellung von Privatnetzen
flake.nix
und Unterverzeichnis nix/: Konfigurationsskripte
Nixification Roadmap
- Einlesen der Salt-Daten in Nix
- Containererstellung
- Migration der Container
- device-scripts auf Site Config umstellen
- Site Config dumpen, Salt-Daten löschen
Development Setup
Get Nix with Flakes first:
nix-shell -p nixFlakes
To test-drive a server, run in a checkout of this repository:
nix run .#server2-vm
Login as root
with an empty password. Use build-container $(ls -1 /etc/lxc/containers)
to build and start the required containers.
Gerätekonfigurationen
nix build .#all-device-scripts
./result/bin/...
Server Setup
ssh root@server2.cluster.zentralwerk.org
Ein Checkout dieses Repositorys liegt in ~/network
. Dorthin zeigt
auch /etc/nixos
so dass nixos-rebuild switch
problemlos
klappt. Ausserdem ist dieser lokale Checkout in der nix registry
eingetragen, was von bspw. von build-container
verwendet wird.
Der Flake-input zentralwerk-network-key
ist mit einem lokalen
Repository überschrieben, weshalb die flake.lock
dirty ist.
LXC-Containers auf Server
Ein Server erwartet die für ihn (location = hostName
) konfigurierten
Container. systemd versucht sie zu starten. Das wird erst nach
build-container
funktionieren, welches das Rootfs anlegt.
Management per systemd-Service lxc@.service
. Beispiel:
systemctl start lxc@pub-gw
lxc-attach -n pub-gw
Innerhalb eines Containers gibts erneut systemctl
, journalctl
,
networkctl
Nix Flake
Segfaulting nix? Until
resolved, export GC_DONT_GC=1
Site Config
Wir verwenden das Module-System von NixOS eigenständig in
nix/lib/config
weil:
- Checks gegen options
- Nutzbarkeit in Paketen (device-scripts) ausserhalb eines
nixos-rebuild
- Konfigurationsdaten über mehr als 1 Host
nixosConfigurations
Systemkonfigurationen für alle Hosts mit der role
"server"
oder
"container"
nixosModule
Alle NixOS-Einstellungen
Dinge die stets schieflaufen
pub-Netz läuft, aber kein DHCP+Internet darüber verfügbar
Eventuell hat uci
bei der ap-Konfiguration die Switch-Konfiguration
für dieses VLAN nicht in /etc/config/network
angelegt.
- Überprüfen:
swconfig dev switch0 show