Update README.md

Deleted BUILD.md

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~
 
 ---