Archive for the ‘gentoo’ Category

“Gentoo is about choice.” We’ve said it so often that it seems like we just don’t bother to say it any more. However, with some of the recent conflicts on the lists (which I’ve contributed to) and indeed across the FOSS community at large, I think this is a message that is worth repeating… Read the rest of this entry »

I just added sys-process/systemd-cron to the Gentoo repository. Until now I’ve been running it from my overlay and getting it into the tree was overdue. I’ve found it to be an incredibly useful tool.

All it does is install a set of unit files and a crontab generator. The unit files (best used by starting/enabling cron.target) will run jobs from /etc/cron.* at the appropriate times. The generator can parse /etc/crontab and create timer units for every line dynamically.

Note that the default Gentoo install runs the /etc/cron.* jobs from /etc/crontab, so if you aren’t careful you might end up running them twice. The simplest solutions this are to either remove those lines from /etc/crontab, or install systemd-cron using USE=etc-crontab-systemd which will have the generator ignore /etc/crontab and instead look for /etc/crontab-systemd where you can install jobs you’d like to run using systemd.

The generator works like you’d expect it to – if you edit the crontab file the units will automatically be created/destroyed dynamically.

One warning about timer units compared to cron jobs is that the jobs are run as services, which means that when the main process dies all its children will be killed. If you have anything in /etc/cron.* which forks you’ll need to have the main script wait at the end.

On the topic of race conditions, each cron.* directory and each /etc/crontab line will create a separate unit. Those units will all run in parallel (to the extent that one is still running when the next starts), but within a cron.* directory the scripts will run in series. That may be a bit different from some cron implementations which may limit the number of simultaneous jobs globally.

All the usual timer unit logic applies. stdout goes to the journal, systemctl list-timers shows what is scheduled, etc.

I switched to using systemd-nspawn in place of chroot and wanted to give a quick guide to using it. The short version is that I’d strongly recommend that anybody running systemd that uses chroot switch over – there really are no downsides as long as your kernel is properly configured.

I’ve been doing online EC2 backups on my Gentoo box for a while, but switched to Duplicity a few months ago and have been very happy with the results. Setting this up took some trial and error, so I figured I’d share my config in case others find it useful. But first, here’s why I switched… Read the rest of this entry »

This is just a quick share-a-recipe post to introduce snapper to anybody who hasn’t heard of it, and explain how to use it.

Snapper is a utility that manages btrfs snapshots. One of the nice features of btrfs is that snapshots are cheap (virtually instant, and consume space only as changes accumulate), and easy to access. Snapper allows you to automatically create and manage them based on time, events, manual action, etc.

Once snapper is set up you can display a list of snapshots. I have 10 hourly snapshots, 10 daily snapshots, and snapshots from before/after each emerge. I can diff them, browse them, etc. Btrfs snapshots can be browsed right from the filesystem, so if I nuke /etc/passwd I can always do a cp /.snapshots/1875/snapshot/etc/passwd /etc/passwd to restore one from a few hours before (though I do also have /etc in a git repo).

Snapper is currently available in the sunrise overlay – I won’t spend time on how to set that up/etc. Also, I’ve had time-based snapshots running for a while now and my memory is hazy as to whether I had to do anything to get those working – it just requires sticking some scripts in /etc/cron.*/ and creating a config file containing your policies.

What I did want to post is a recipe for getting pre/post-emerge snapshots working. All you need to do is add some lines to /etc/portage/bashrc:

The recent concerns with the request to re-populate QA have re-opened a debate that is a few years old now. I’ve already made some specific recommendations on the lists, but I wanted to step back and explain why I feel the way I do.

Gentoo’s system of governance has some internal ironies – ones which occasionally even lead to calls to establish a benevolent dictator position. I think the mistake that Gentoo makes is that the problem is perceived as being democracy, when in reality the problem is with competing governance bodies with differing constituencies…

Well, all of MythTV 0.26 is now in portage, masked for testing for a few days.

If anyone is interested now is a good time to give it a try and report any issues you find. If all is quiet the masks will come off and we’ll be up-to-date (including all patches up to a few days ago).

Thanks to all who have contributed to the 0.26 bug. I can also happily report that I’m running Gentoo on my mythtv front-end, which should help me with maintaining things. MiniMyth is a great distro, but it has made it difficult to keep the front- and back-ends in sync.