Thanks for prodding me a bit. I’ve been meaning to reply for awhile but I keep going around in circles. This is still very much a work in progress. I had some stuff working in Fedora SB 30 and now on SB 31 some stuff works better and other stuff is broken. Anyway, have a look here,
My initial idea was to build two toolbox containers, control and $USER, and use ansible to provision them. After awhile I realized I really only need one container, so now everything runs from the $USER container. The control playbook makes a network connection on 127.0.0.1 and installs flatpaks on the host, while the user playbook makes an ansible local connection, installing packages with dnf in the $USER container.
There’s a few things that need to be done to get started. First there’s setup.sh. On SB 30 there wasn’t H.264 support for video so I had to install rpmfusion and compat-ffmpeg28 with rpm-ostree. On SB 31 this is no longer necessary and I’ve gotten things worked out so I don’t need to install any packages on the base image. So now setup.sh pretty much just configures sshd for remote connectivity on 127.0.0.1. This part worked just fine on SB 30, but for some reason I haven’t been able to get remote login working on SB 31. At this point, when I ssh to 127.0.0.1 I can’t authenticate, either with ssh key, or with a password. So I still have to sort that out again.
After setup.sh it’s time to run errata.sh. I ran into a problem on SB 30 where I was getting a “failed ot obtain transaction lock” error that’s described in this issue, https://github.com/containers/fuse-overlayfs/issues/108. I haven’t had time to look into it to see if this is still an issue on SB 31, so for now I’m still running errata.sh.
A couple of more steps and we’ll get to where things are “automatic”. So next up is build.sh, which is going to set up the $USER container and do the first ansible run. There’s also a wrapper for ansbile so you can re-run the playbooks by doing
ansible-run.sh $USER or
At this point I’m pretty much running all my desktop applications from the $USER container, but there are a few idiosyncrasies that come along with the system. I used $USER for the container name, rather than just using the default container, because I built this on my home computer, but now I’m also running it on my workstaion and laptop at work, so I like the name difference. But it’s a pain to always have to do
toolbox enter -c $USER, so in by .bashrc I have ‘alias enter="toolbox -c $USER’. I’ve also installed VSCode in the $USER container, but sometimes I want to run it from a regular shell session. I’ve got it so code will now start anywhere with this alias: alias code=‘toolbox run -c terrance bash -c ‘’‘code’’’’. The other thing I had problems with was vim. I like to alias vi to vim, but in this situation vim only lives in the container. It’s a bit of kludge but I ended up aliasing vi to v, and vim to vi, which works well enough that I’m happy.
Rather than bloating the playbook I like to write roles and call the role from the playbook, even for silly things like this. So the user role is in dotfiles-fedors-sb/ansible/roles/local/fedora_sb_user. The templates directory has my bashrc and some package repo definitions, and the tasks directory is where most everything happens. When it runs it installs some packages, sets up vim and vundle, installs vscode, keybase, chrome and some other stuff. It does a decent job for what it is, but I have to say I’m starting to have serious doubts about using toolbox at all. My quible comes at the point where toolbox presents a completely mutable containerized environment. I’d rather it were variably mutable, than completely mutable. With that in mind I’ve shifted focus and I’m working on using buildah to provision a container image from the ansible user playbook. It’s not working yet, but I’ve got the building a container in a container part mostly working now, so I’m hopeful it’ll be running before too long.