From 0900268cfc8a4b1fda23bbc542d21973776c6cc9 Mon Sep 17 00:00:00 2001 From: XenGi Date: Wed, 9 Nov 2022 09:35:56 +0000 Subject: [PATCH] Update README.md Deleted BUILD.md --- BUILD.md | 22 ---------- README.md | 120 ++++++++++++++++++++++++++++++++---------------------- 2 files changed, 71 insertions(+), 71 deletions(-) delete mode 100644 BUILD.md diff --git a/BUILD.md b/BUILD.md deleted file mode 100644 index 09e0122..0000000 --- a/BUILD.md +++ /dev/null @@ -1,22 +0,0 @@ -Image building -============== - -## Notes - -- package source: arch linux - -## Process - -1. Setup minimal base rootfs -2. Install needed packages -3. Create `/config` directory -4. Setup git repository for config files -5. Initial ansible run with default config -6. Setup symlinks to `/config/*` -7. Run testsuite -8. Export rootfs as btrfs snapshot -9. Release snapshot as new DEVELOP version -10. Run testsuite -11. Once every month: If no issues with DEVELOP version, publish as RELEASE version - -_Security fixes get released asap_ diff --git a/README.md b/README.md index 4498b9b..2e3a1ed 100644 --- a/README.md +++ b/README.md @@ -4,12 +4,13 @@ Firewall Linux - A small and simple Linux based Firewall Distribution -It combines an optimized Linux Kernel, Busybox and a simple Webinterface and API to configure. It is not meant to be a replacement to far superiour Appliances but as an alternative solution for typical home use. +It combines a standard Linux distribution with modern network services, a simple web interface and API to configure it. It's not meant to be a replacement to far superiour Appliances like pfSense or OPNSense but as an alternative solution for typical home use. ## Target platforms - QEMU/KVM -- [PCEngines APU2](https://www.pcengines.ch/apu2.htm) +- [PCEngines APU2/3/4](https://www.pcengines.ch/apu2.htm) +- Generic [AliExpress](https://www.aliexpress.com/wholesale?catId=0&SearchText=router+pc) Router PCs ## Planned initial features @@ -19,71 +20,92 @@ It combines an optimized Linux Kernel, Busybox and a simple Webinterface and API - [ ] UPnP - [ ] DynDNS - VPN - - [ ] OpenVPN - - [ ] Wireguard -- [ ] NTP -- [ ] DHCP -- [ ] DNS + - [ ] [OpenVPN](https://openvpn.net/) + - [ ] [Wireguard](https://www.wireguard.com/) +- [ ] NTP ([chrony](https://chrony.tuxfamily.org/)) +- [ ] DHCP ([Kea](https://www.isc.org/kea/)) +- [ ] DNS ([Knot](https://www.knot-dns.cz/)) - [ ] Auto config backup -- [ ] Cron/Timers +- [ ] Cron/Timers ([Systemd-timers](https://www.freedesktop.org/software/systemd/man/systemd.timer.html)) + +## Installation + +TBD ## Design ### Partitioning -MBR/BIOS: +The partitioning schema is kept simple and will be setup like this: + +BIOS/MBR: ``` -/dev/disk: - /dev/disk1 ext4 /boot - /dev/disk2 swap [SWAP] - /dev/disk3 btrfs@home /home - /dev/disk3 btrfs@config /config - /dev/disk3 btrfs@root-2021-04-01 / - /dev/disk3 btrfs@root-2021-04-20 / +/dev/sda: + /dev/sda1 swap [SWAP] # SWAP + /dev/sda2 ext4 / # FWLNX ``` -- Every installed release has it's own subvolume for the rootfs -- The `config` subvolumes has a git repository which saves all configuration changes and the used version -- The user can choose which one to boot into +UEFI/GPT: -### Update flow +``` +/dev/sda: + /dev/sda1 vfat /boot # ESP + /dev/sda2 swap [SWAP] # SWAP + /dev/sda3 ext4 / # FWLNX +``` -State before the update: +### Operating system -- boot entry `last` is set to version 1 (last known working version) -- boot entry `current` is also set to version 1 -- on every boot the default boot entry is set to `last` automatically in early boot +As the base operatring system NixOS is used. -Update process: +### [Garmr](https://gitlab.com/fwlnx/garmr) -- a new version is downloaded as a btrfs snapshot and put into place as version 2 -- `current` boot entry is modified to boot the new version -- `current` is set as default boot entry +Backend daemon -- device reboots into new version 2 via `current` boot entry -- early boot sets `last` as default boot entry -- after successful boot: - - the user marks the system as functional which sets the `last` boot entry to the current version -- if something goes wrong: - - the system reboots, now with the `last` entry being the default booting into the last known working system - - the user gets displayed an error because `last` and `current` is not the pointing to the same version and `last` is booted indicating an error +### [Freyja](https://gitlab.com/fwlnx/freyja) -### Configuration changes +Web frontend -- User changes current config via HTTP API (Web interface) - - Background process puts changes into ansible variables in `/config` -- When user discards changes git repo under `/config` is reset to original state -- When change is ready and user triggers commit via HTTP API - - Changes form a git commit with name `[$VERSION] $username - $change summary` - - Timer is setup to revert to old config in 600s - - Changes get applied via ansible -- User confirms working state via HTTP API - - Timer get removed -- If new change is not confirmed and Timer gets triggered - - git commit is reverted - - Ansible runs again with old config - - User get an error message +# OLD concept + +### ~Update flow~ + +~State before the update:~ + +- ~boot entry `last` is set to version 1 (last known working version)~ +- ~boot entry `current` is also set to version 1~ +- ~on every boot the default boot entry is set to `last` automatically in early boot~ + +~Update process:~ + +- ~a new version is downloaded as a btrfs snapshot and put into place as version 2~ +- ~`current` boot entry is modified to boot the new version~ +- ~`current` is set as default boot entry~ + +- ~device reboots into new version 2 via `current` boot entry~ +- ~early boot sets `last` as default boot entry~ +- ~after successful boot:~ + - ~the user marks the system as functional which sets the `last` boot entry to the current version~ +- ~if something goes wrong:~ + - ~the system reboots, now with the `last` entry being the default booting into the last known working system~ + - ~the user gets displayed an error because `last` and `current` is not the pointing to the same version and `last` is booted indicating an error~ + +### ~Configuration changes~ + +- ~User changes current config via HTTP API (Web interface)~ + - ~Background process puts changes into ansible variables in `/config`~ +- ~When user discards changes git repo under `/config` is reset to original state~ +- ~When change is ready and user triggers commit via HTTP API~ + - ~Changes form a git commit with name `[$VERSION] $username - $change summary`~ + - ~Timer is setup to revert to old config in 600s~ + - ~Changes get applied via ansible~ +- ~User confirms working state via HTTP API~ + - ~Timer get removed~ +- ~If new change is not confirmed and Timer gets triggered~ + - ~git commit is reverted~ + - ~Ansible runs again with old config~ + - ~User get an error message~ ---