Menu du jour: Vivaneau vert sur lit de légumes au beurre et suprêmes de pamplemousse

Vivaneau vert…

Called “Aprion virescens” in Latin, “Uku” in Micronesia, and “green jobfish” in English, “vivaneau vert” is a tasty table fish. It’s also called “blue-green snapper,” and thus shares its name and color with the other Snapper that is very familiar to the SUSE communities.

Snapper is a utility for improving usability of snapshots for filesystem subvolumes, and those snapshots are again (read-only) subvolumes. Snapper is integrated with SUSE’s ZYpp stack for package and patch management, and triggered by our friend YaST, Snapper takes snapshots on every administrative activity automatically, if you run with btrfs as your filesystem for the Operating System. All preparation and integration work has been taken care about by the YaST Installer before.

In openSUSE 12.3 and the upcoming SUSE Linux Enterprise 11 SP3, you see significant enhancements to Snapper, empowering you to hunt the job(fish) down, when managing a system as an administrator or managing your data as a non-privileged user.

The latter feature is the most visible enhancement: Snapper now provides a framework to allow users without administrator rights to create snapshots for btrfs subvolumes.

This change required our engineering team to extend the architecture and implementation of Snapper: instead of a pure command-line program, the Snapper framework now includes a daemon, which serves three primary purposes:

1. Authentication: the Snapper configs located at /etc/snapper/configs/ contain information about USERS and GROUPS allowed to take snapshots in the realm of this Snapper configuration.
2. Access to Snapper functionality via D-Bus for easy integration into an event-based world
3. Kick off asynchronous tasks, e.g. cleanup processes.

Thus, the administrator has to grant permissions to one or more USERS or GROUPS before those users can work on the subvolume. Let’s have a quick view on the steps necessary to achieve this:

# The user $USER should not yet exist in the system
# Create a subvolume for the USER:
btrfs subvol create /home/$USER
# Create Snapper config for USER
snapper -c home_$USER create-config /home/$USER
# Add the user to the list of empowered USERS in the Snapper configuration
sed -i -e "s/ALLOW_USERS=\"\"/ALLOW_USERS=\"${USER}\"/g" \
/etc/snapper/configs/home_$USER
# Create the user
yast users add username=$USER home=/home/$USER password=[passwd]
# Important:
# 1. Change the ownership of home directory to USER
chown $USER.users /home/$USER
# 2. Make snapshots accessible to USER 
chmod 755 /home/$USER/.snapshots

For upcoming versions of openSUSE and for SUSE Linux Enterprise 12, we are working on an integration of btrfs with the user creation (via YaST or useradd), thus these manual steps won’t be necessary anymore.

… au beurre

As you know, Snapper implements the full range of snapshot capabilities based on btrfs. I learned that we should pronounce it “butter-f-s,” because btrfs gets its power from the built-in Copy-on-Write functionality, and “Copy-on-Write”, is abbreviated as “CoW”. Butter comes from (milk, milk comes from the) cow. Butter in French, by the way, is “beurre.”

And indeed the second major enhancement in openSUSE 12.3 and the upcoming SUSE Linux Enterprise 11 SP3 – improved performance for snapshot comparisons – depends on development in btrfs itself:

The differences, in short, are:

• Initially, Snapper had to implement all snapshot comparisons (“snapper status …”, “snapper diff …”) in userland, an obviously expensive and thus slow way.
• Meanwhile btrfs implements “send/receive”, i.e. exporting and importing filesystem snapshots on the filesystem level. For this to work efficiently, the filesystem kernel code contains routines to track differences on the block and file level. Based on the existing “send” code (i.e. exporting), our engineers developed sort of a “dry-run export”, i.e. show what an export would do, but do not send any data. And voilà, this list is exactly the information Snapper needs to build its list of snapshot differences. Certainly all this code is mainline in btrfs within the recent Linux kernels.

Regarding mainline and upstream: Snapper is fully open source, and as it is designed to work on any recent Linux distribution, we are even providing packages for different Linux distributions in SUSE’s Open Build Service.

Snapper is also part of our SUSE Linux Enterprise strategy of providing a seamless integration of btrfs with the administrative experience. Thus, a number of enhancement requests come from the Enterprise business, and the implementation is funded by it, to the mutual benefit of both openSUSE and SUSE Linux Enterprise.

So, even though Snapper also can work upon other storage technologies meanwhile for snapshotting, e.g. the device mapper layer, you will understand why we prefer to serve the tasty Snapper upon a bed of buttered greens – sur lit de légumes au beurre.

Desert: suprêmes de PAMpelmousse

Using btrfs myself – as a root filesystem for two years now, and for my /home/mge filesystem since last summer – I realized that for /home/mge I do not want the time-based snapshots that Snapper offers by default, but rather a way to monitor, track, (and potentially roll-back) my work environment based on activity; so I considered implementing snapshots based on login and logout.

Login and logout, summarized as a session in Linux, are controlled by the “Pluggable Authentication Modules,” known as PAM.

While the first implementation was a simple shell script just initiating a snapshot by calling the snapper command-line tool, I developed a C-based implementation during SUSE’s hackweek#9 in April 2013. This version talks to the snapperd Daemon via Snapper’s new D-Bus interface and offers the administrator more options and control.

With pam_snapper in place and configured, a login/logout pair delivers:

$ snapper -c home_mge list | tail -2
pre  | 34 |    | Fri 26 Apr 2013 09:24:23 PM CEST | mge || pam_snapper | ruser=root, service=su-l, tty=pts/5
post | 35 | 34 | Fri 26 Apr 2013 09:24:48 PM CEST | mge || pam_snapper | ruser=root, service=su-l, tty=pts/5

We also easily see what files might have been changed:

$ snapper -c home_mge status 34..35
c... /home/mge/.bash_history
c... /home/mge/.inputrc

Assuming, you already have a Snapper configuration for your /home/$USER directory, and it is called “home_$USER“, as suggested above, the configuration is as easy as these three steps:

1. Download the PAM module from the Open Build Service – it’s available as part of the upstream Snapper project there.
2. Install the module to your system
3. Add the following line to /etc/pam.d/common-session:

   session optional pam_snapper.so

   See man pam_snapper for more information and configuration options.

Even if you don’t have the Snapper configuration for your user(s) yet, don’t worry: pam_snapper contains some scripts to help you bootstrapping your environment, such as /usr/lib/pam_snapper/pam_snapper_useradd.sh

Digestif

While you sip on your digestive, let’s have a look of potential future improvements of btrfs and its friends:

• Snapshot cleanup based on disk space.
• Deeper integration of btrfs and the systems management stack – this might require btrfs as the default filesystem.
• Integration of btrfs snapshots in the bootloader, to boot off a specific system status directly.

Send Your Ideas!

I hope you enjoyed today’s menu: “Green Snapper on a bed of buttered greens and finest grapefruit segments.” Or for the German-speaking community: “Grüner Schnapper auf einem Bett von gebuttertem Gemüse mit Grapefruit Filets.”