What we want
- a stable development workflow for a net-bootable transactionally maintained system
- based on an arbitrary ALT live distro
- using standard Linux and ALT technology
- several different net-bootable systems on one server
- continuous development cycle
- rollback, cherry-pick
- decent performance
- running performance (moderate boot-up times, ...)
- ro-update performance
most often network is the bottleneck, so we want good compression ratio, that means zstd?
client: .rw/ -> .tar.zstd -> server, asynchronously return.
- server listens to directory update and bakes an overlay.
What we have
Alterator backend (alterator-netinst)
- with web interface
- selects an ALT-based ISO image to share
sets up /srv/public/netinst
- current propagator
- Mandrake remnant
- huge C program that:
- can be replaced
C -> shell (mostly)
aufs -> overlayfs (multiple filesystems?)
overlayfs only directly supports two layers
- overlays
hacked by FrBrGeorge some time ago, largely untouched as of now
- long-standing bugs
- lots of hardcode
- mostly undocumented
FrBrGeorge has a wiki page on that, but it mostly describes
- the benefits of netbooting in general
- tools are a bit difficult to correctly use
/srv/public/netinst/overlays-live/$date-$purpose.iso
- profile support
- different sets of overlays for different profiles
- tied deeply to a single iso image
overlays are mounted right over a squashfs in /srv/public/netinst/$ISO
- (AFAI understand)
If `current' changes -> broken!
- ISOs despite having little rationale to use them
- are hard to manipulate/patch
- no point in maintaining a DVD-compatible storage format that will NEVER get used on a DVD
FrBrGeorge: "I do not know of a viable alternative"
Ideas
- squashes instead of isos, multiple profiles
- "decompose" ISO image on net-bootable deployment
- extract kernel/initrd/squash
- reflect new scheme in alterator-netinst
- reflect new scheme in propagator (live initrd)
- "decompose" ISO image on net-bootable deployment
- overlays-tools
- rebranding (name collisions)
- FROMBIN: why???
- overlays-backend
- SSH transport security model
FrBrGeorge mentioned key dependency chains (openssh feature?)
- try squashes instead of isos
- alternative scheme
- SSH transport security model
- backup-to-disk
- an option to automatically back up the overlay chain to (specified) local storage
- if no storage available: continue
FrBrGeorge: "That belongs in an installer"
- counter-argument: you shouldn't have to run an installer 200 times on 200 machines on every system update.
- an option to automatically back up the overlay chain to (specified) local storage
See Also
../PleerFirmwarePlan (взгляд из прошлого года)