fwlnx/web
Watch
1
0
Fork
You've already forked web
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update README.md

Browse source 
Deleted BUILD.md
This commit is contained in:
XenGi 2022-11-09 09:35:56 +00:00
commit 0900268cfc
2 changed files with 79 additions and 79 deletions
Download patch file Download diff file Expand all files Collapse all files

22
BUILD.md
View file

@ -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_

120
README.md
View file

@ -4,12 +4,13 @@
Firewall Linux - A small and simple Linux based Firewall Distribution 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 ## Target platforms
- QEMU/KVM - 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 ## Planned initial features
@ -19,71 +20,92 @@ It combines an optimized Linux Kernel, Busybox and a simple Webinterface and API
- [ ] UPnP - [ ] UPnP
- [ ] DynDNS - [ ] DynDNS
- VPN - VPN
- [ ] OpenVPN - [ ] [OpenVPN](https://openvpn.net/)
- [ ] Wireguard - [ ] [Wireguard](https://www.wireguard.com/)
- [ ] NTP - [ ] NTP ([chrony](https://chrony.tuxfamily.org/))
- [ ] DHCP - [ ] DHCP ([Kea](https://www.isc.org/kea/))
- [ ] DNS - [ ] DNS ([Knot](https://www.knot-dns.cz/))
- [ ] Auto config backup - [ ] Auto config backup
- [ ] Cron/Timers - [ ] Cron/Timers ([Systemd-timers](https://www.freedesktop.org/software/systemd/man/systemd.timer.html))
## Installation
TBD
## Design ## Design
### Partitioning ### Partitioning
MBR/BIOS: The partitioning schema is kept simple and will be setup like this:
BIOS/MBR:
``` ```
/dev/disk: /dev/sda:
/dev/disk1 ext4 /boot /dev/sda1 swap [SWAP] # SWAP
/dev/disk2 swap [SWAP] /dev/sda2 ext4 / # FWLNX
/dev/disk3 btrfs@home /home
/dev/disk3 btrfs@config /config
/dev/disk3 btrfs@root-2021-04-01 /
/dev/disk3 btrfs@root-2021-04-20 /
``` ```
- Every installed release has it's own subvolume for the rootfs UEFI/GPT:
- 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
### 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) As the base operatring system NixOS is used.
- 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: ### [Garmr](https://gitlab.com/fwlnx/garmr)
- a new version is downloaded as a btrfs snapshot and put into place as version 2 Backend daemon
- `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 ### [Freyja](https://gitlab.com/fwlnx/freyja)
- 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 Web frontend
- User changes current config via HTTP API (Web interface) # OLD concept
- Background process puts changes into ansible variables in `/config`
- When user discards changes git repo under `/config` is reset to original state ### ~Update flow~
- When change is ready and user triggers commit via HTTP API
- Changes form a git commit with name `[$VERSION] $username - $change summary` ~State before the update:~
- Timer is setup to revert to old config in 600s
- Changes get applied via ansible - ~boot entry `last` is set to version 1 (last known working version)~
- User confirms working state via HTTP API - ~boot entry `current` is also set to version 1~
- Timer get removed - ~on every boot the default boot entry is set to `last` automatically in early boot~
- If new change is not confirmed and Timer gets triggered
- git commit is reverted ~Update process:~
- Ansible runs again with old config
- User get an error message - ~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~
--- ---