Update README.md
Deleted BUILD.md
This commit is contained in:
XenGi
parent
90b43c186f
commit
0900268cfc
2 changed files with 79 additions and 79 deletions
22
BUILD.md
22
BUILD.md
|
|
@ -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
120
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~
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue