alvin -- Arch Linux Virtual INstaller

A vaguely opinionated, Arch Way-enabled method to quickly deploy Arch Linux virtual machines independent of virtualization substrate.

... or ...

Do you want to build systems like you do packages? I do.

... or ...

NixOS is great and all-- no, really-- but I don't want to have to learn another scripting language and I believe in the FHS.

... or ...

Usage

Caution

It's pretty early days, and it has a lot of sharp-edges. BASH-awareness is mandatory. Don't use on a system you aren't willing to melt.

Also, it is strongly encouraged to use an arch package cache like pacoloco if you intend to use this project extensively.

alvin

alvin builds a virtual machine and generates a configuration file for immediate use. Base Xen and KVM-backed libvirtd are currently supported. It reads alvin.conf to get configuration information, with some overrides available via the command. Only a hostname is required.

alvin command options:

usage: alvin -n [hostname] [...]

Options:
   -n [hostname]  REQUIRED: set hostname for new VM
   -d             installs development packages
   -u             leaves new VM mounted
   --srv [size]   create a /srv partition of set size

Options that override defaults in /etc/alvin.conf
   -m [size]   size of ram in new VM
   -c [int]    number of new vCPUS in VM
   -r [size]   size of root partition
   -s [size]   size of swap partition
   -q          create a QCOW2 file in current directory 
   --zstd      if building a qcow file, compress with zstd

Documentation options:
   -h        prints help
   --modules prints a summary of all alvin configuration modules
   --nocolor do not use color output

makesys

makesys is the alvin counterpart to makepkg. It reads a SYSBUILD file in the current working directory and builds a system image in that directory. It is mainly for use in normalizing system deployment. If you think of it as SYSBUILD == PKGBUILD for systems, you're not far off.

makesys command options:

usage: makepkg [...]
[ ! == unimplemented as of yet ]

Options:
   -n [hostname]       override hostname in SYSBUILD
   -p [filename]       use alternative from SYSBUILD file
   -u                  leave new virtual machine mounted
  ! -S                  create a source-only, exportable tarball
  ! -f                  force build, overwrite existing system
   -D [dir]            change to directory before processing SYSBUILD
   --nocolor           execute without color
   --unchroot [mntpnt] unmount chroot mounts after a failure


Documentation options:
   -h (prints this help)
   -v (prints alvin version)
   --modules (show available modules)

Modules

Both commands are based off of modular components that manage volumes and partitioning, filesystem types, and some basic and obvious systems. Both commands have a --modules argument that will summarize available modules.

In lieu of documents, the --modules command will be your guide to using alvin.

A Short FAQ, based on discussions with my friends

Q: What's in the future?

A: Immutable systems are a big future goal. Probably a SquashFS with a custom kernel and initrd to load up OverlayFS for configuration directories. Otherwise, the TODO list below has a better idea of what will be worked on.

Q: Reproducible builds are impossible since Arch Linux is a rolling release distribution!

A: Not a question, but yes, reproducible builds are not a goal. Instead the goal is a way to quickly iterate over system builds, with the ability to painlessly switch from a deployed to a developer-local substrate to test any changes as packages update and change.

Q: Is the goal to promote alvin to an official Arch Linux tool?

A: The goal is to make it possible. I have strong doubts about this projects suitability to the Arch ecosystem, but I want it to look like it fits in.

Q: Really, NixOS does all of this that is superior in every way.

A: I know, and that's fine. Also, still not a question.

To Do

Global

• DOCUMENTATION
• fix whatever is broken with /etc/locale.conf
• gettext i18n support
• meaningful exit codes
• trap and say something worthwhile about cleaning up after yourself
• see if there's any way at all to run this as a user
• move package out of repo, likely into SAUR
• consider adding argument support to modules by extending the string that calls the module
  • as in: MACROS[install]="xenxl opt1 opt2 opt3"
• user directories for custom modules
• maybe rename MACROS to something more reflective as the source of truth
• clean up the shell enviornment for "security" (read: not accidentially fouling the mechanism) purposes
• consider an /etc/makesys.conf that manages options for modules that need them
• compare last package versions used to packages installed [ akin to .SRCINFO ]

filesystem management

• make filesystem struct readonly on additions
• figure out a good sanity check for extra filesystem mountpoints
• force root to /, probably force boot to /boot
• if filesystem isn't special, check mountpoint

system config

• support for multiple kernels?
• globally regenerate initrd rather than after bootloader?

postprocessing

• check for compressed filename before compression
• add a toggle for pre- or post- umounting, move zero_fs to postprocessing

chrooting

• systemd-run support?