untoreh / pine

Alpine Linux on OSTree, minimalistic os updated through atomic upgrades, for servers

Pine

Alpine Linux on OSTree.

Install

flash pulls the latest image from github and dumps it on the on specified device.

wget https://cdn.jsdelivr.net/gh/untoreh/pine/flash.sh -qO - | sh -s -- /dev/vda

Environment variables can be used:

• IFACE,ADDRESS,GATEWAY,NETMASK for network configuration
• PARTS comma separated list of partition sizes, eg 2G,256M

if partitions are specified no filesystems are created on them, otherwise a default configuration of 5G,128M

Server

serve re-sets up a tz2 ostree repo from built image and starts the server to allow ostree clients to update to the latest version.

Usage

run rebuilds the tree committing it to the previos gh image.

Github Releases

A rolling image containing the latest 3 months builds, and a static-delta artifact to be applied on top of the commit of the previous image, which means deltas have to be applied in order if a deployment lags behind, generated by build-update.

Utils

build and delta scripts in the init folder were previously wrongly used to setup github releases but don't contemplate continuitity. They are still useful for creating from-scratch images and one-shot deltas.

TODO

• Switch from xfs as base FS to either f2fs or just ext4. The choice should toward the more stable filesystem such that a newer image can be mounted on older kernels (this is not the case for XFS).
• Remove the 24M swap partition since it is useless, enable zswap by default once alpine includes it in the default kernel config.
• uproot vars and make them configurable
• make the packed extras optional

pine's Issues

friggin monitor builds

got to monitor builds so that rolling versions don't fall off

• doing catchups of many versions is not really nice because we use a fixed image size, which means a big diff usually requires too much space in the ostree repo which than would not fit into the allotted partition, and we want to keep things small. For ovz it should be fine though but better keep monitoring anyway

add overlay for ovz release

admin unlock uses overlay in /var for normal deployments, ovz should have an equivalent, best available afaik is union-fuse
Should an helper script sit on top of ostree like with runc? not unless further differences emerge

split the supfile

the Supfile got big and should be split into sub files for each job.
Or possible consider porting the jobs to another tools like henchman which currently depends on python so for that at least the shell module should be ported to go.

ovz ploop setups not recognized as ostree booted

some requirements are not getting satisfied with ovz ploop based setup and the system is not detected as ostree booted.
Needs investigation

use a proper build system

or at least a dockerfile

consider switching containerpilot with monexec

• more pet oriented
• consul + service registration

switch docker

The kvm images use docker, cri-o can be an alternative