0xStubs

System Administration, Programming and Reconfigurable Computing

Figuring out the used space_cache version of a btrfs file system

Btrfs contains different implementations of a free space cache. The default currently is space_cache=v1. A newer tree-based cache can be activated by the mount option space_cache=v2. As soon as the new version has been used once, it will automatically be used for any future mount. But how do you figure out which version your file system is actually using?

There are multiple ways to determine the used space cache version. The easiest one is to just mount the file system and look into the kernel log. If the default space cache v1 is used, it will say something like

BTRFS info (device yourdevice): disk space caching is enabled

However, if it already has been configured to use the new space cache v2, it will say something like

BTRFS info (device yourdevice): using free space tree

One can also determine the used space cache version without mounting the file system by peeking into the superblock:

btrfs inspect-internal dump-super /dev/yourdev

If the file system already uses space_cache=v2, the compat_ro_flags will contain the flag FREE_SPACE_TREE.

For completeness: When playing with space_cache=v2, be aware of the risks (see the remarks on the space_cache mount option in btrfs(5)).

Modifying environment variables in the Atom editor

If you are using the Atom editor, you may at some point need to set or modify certain environment variables within your editor, e.g., to allow packages to locate binaries that are not located within your normal $PATH. A solution you often find on the internet is to add a small snippet to your init.coffee script:

process.env.PATH = [
  '/my/special/path/for/atom'
  process.env.PATH
].join(':')

However, this does not always work. Even worse: If it works or not may change each time you launch Atom. So, what is the problem here?

During launch, Atom runs a routine called updateProcessEnv() that configures the environment. However, to not delay startup unnecessarily, this is an asynchronous function. During launch, it is called, then the user’s init.coffee script is run, and only after that the completion of updateProcessEnv is awaited. So if you modify the environment within init.coffee, there is a good chance that Atom’s startup procedure will overwrite it again a couple of milliseconds later.

So, how can we deal with this and reliably modify the environment? Luckily, Atom emits an event as soon as the environment has been setup. So we can use a construct like the following in init.coffee:

modEnv = ->
  return unless atom.shellEnvironmentLoaded
  process.env.PATH = [
    '/my/special/path/for/atom'
    process.env.PATH
  ].join(':')
modEnv()
atom.emitter.on 'loaded-shell-environment', modEnv

Prevent autostart of Android File Transfer on macOS

Android File Transfer (let’s call it AFT) is a handy tool to transfer files from and to an Android device when using a Mac. This software has an annoying habit though: It automatically starts when an Android device is plugged in. Since on most modern Android devices, the user has to give permission to access files after connecting it to a PC, it opens up just to confront the user with an error message.

Read More

Debugging a flaky cpu steal time counter on a paravirtualized Xen guest

I recently noticed a strange phenomenon on a Debian Stretch server running as a paravirtualized guest on a Xen host: top showed the CPU either be 100% idle or 100% stolen. User, system, nice and waiting times were stuck at 0%. I cross-checked with vmstat and it showed 0% for all cpu time counters. Both tools are getting their information from /proc/stat which looked like the following:

cpu 5322 0 4376 12720669 37879 0 59 1198368772563 0 0
cpu0 5322 0 4376 12720669 37879 0 59 1198368772563 0 0
...

The third to last value is the steal time, denoting “stolen time, which is the time spent in other operating systems when running in a virtualized environment” [procfs(5)]. This value looked way too high and, in particular, it was counting backwards. So, if I wanted to put this system into production, some debugging was required before…

Read More

Pitfalls when running a mail server

When running a mail server, some basic rules have to be followed, e.g. ensuring that the server does not operate as an open relay. These rules are nowadays well known and the default configuration provided with MTA software typically avoids these “big no-nos”. Still, there are many pitfalls when configuring a mail server. In this post I want to share some of those pitfalls that I stumbled across in the last years myself.

Read More

Migrating from ownCloud 9.1.6 to Nextcloud 10

If you are stuck with PHP 5.4 (e.g. because you are still running Debian Wheezy) and want to migrate from ownCloud to Nextcloud, you are probably facing a minor issue. Nextcloud 11 and newer require PHP 5.6 so you have to stick to version 10 instead. Nextcloud 10 reached its end-of-life with version 10.0.5, which internally corresponds to ownCloud version 9.1.5. The most recent version of ownCloud 9 is version 9.1.6 though, so when trying to migrate to Nextcloud you will face the following error:

Downgrading is not supported and is likely to cause unpredictable issues (from 9.1.6.2 to 9.1.5.2)

Looking at the git commits between ownCloud 9.1.5 and 9.1.6 shows that there were no changes to the database layout. So, as a workaround, you can just edit your config/config.php and set version to 9.1.5.1 or lower. Afterwards, you should be able to run the normal upgrade procedure.

Fixing Roundcube’s command execution vulnerability in Debian Wheezy

Recently a quite serious vulnerability (CVE-2016-9920) in Roundcube was reported. Until now (7th Dec) this vulnerability is unfixed in Debian’s roundcube packages (see the corresponding entry in the Debian Security Tracker).

The upstream patch is not directly applicable to version 0.7 which is used in Debian Wheezy but with a little modification it is. Following you find a corresponding patch*.
Read More