Schroot cheatsheet

I don’t always install software whose idea of installation instructions is curl ... | sudo, but when I do, I jail it. In this case, I’m setting up a chroot for Nodejs:

sudo apt install schroot deboostrap
sudo mkdir /srv/npm-chroot
sudo debootstrap stable /srv/npm-chroot
sudo mkdir -p /srv/npm-chroot/home/joe/projects
sudo chown -R joe:joe /srv/npm-chroot/home/joe/

In these examples, “joe” is my username.

The “s” in “schroot” stands for “securely,” but it might as well be “simple” because “schroot” handles fiddly bookkeeping tasks for setting up your environment, based on its config file.

Edit /etc/schroot/schroot.conf:

[npm]
description=npm projects
type=directory
directory=/srv/npm-chroot
root-users=joe
setup.fstab=joe-projects/fstab

Normally, schroot mounts /home from the host as /home in the chroot. I don’t want programs in jail to muck about with my home on the host though, so I edit the setup.fstab option. Its default lives in /etc/schroot/default/fstab.

For my purposes, the schroot’s default configuration is a good start, so:

sudo mkdir /etc/schroot/joe-projects
sudo cp /etc/schroot/default/fstab /etc/schroot/joe-projects/

Edit /etc/schroot/joe-projects/fstab, removing the /home line and adding instead:

/home/joe/projects /home/joe/projects none rw,bind 0 0

Finally, enter the chroot, as root.

schroot -c npm -u root

I like to install sudo so it feels like a normal Ubuntu:

# now in the schroot
apt update
apt install sudo
exit

Then log in as my normal user:

# in the host
schroot -c npm

From here I can install npm in relative isolation; this is not sufficient for isolating malicious software, but it’s a nice way to avoid inconsiderate programs from pooping all over your system.

Does anyone know how to configure xkb?

I usually prefer to leave my keyboard layout and shortcuts in default configuration. Partly, this makes switching between machines easier and partly it helps me learn what the defaults are, so I can avoid breaking them in programs I write.

Some customizations, however, are just too valuable to forgo: super+arrow to move windows between monitors and shift+space to type an underscore. Kde has global shortcut configuration for the first, but what about the second?

I’ve used xmodmap before, but had problems where it wouldn’t stick throughout a session, apparently forgetting my configuration from time to time. So I end up using dumb tricks like a shell script with an infinite loop. Nowadays, though, the Internet says that xkb is the new and shinier replacement.

So, xkb it is. The best documentation I can find is An Unreliable Guide to Xkb Configuration. I learn that configuration lives in /usr/share/X11/xkb. There’s also something about /etc/X11/xorg.conf.d. Bad start… where does user-configuration go? I have no idea. I think the concept is probably that I should define a custom layout for me specifically, maybe naming it something like kingdom_of_joe, then pick that as my keyboard layout somewhere else in my window manager or login script. Screw it. I’ll just edit the files in /usr/share and if some barbarian who maps shift+space to backspace shares my computer, we’ll have to go to war.

Now, to look at the configuration. There are 275 config files. It’s slightly less than obvious where I should start.

Lampson attributes the aphorism that started our exploration (all problems in computer science can be solved by another level of indirection) to David Wheeler, the inventor of the subroutine. Significantly, Wheeler completed his quote with another phrase: “But that usually will create another problem.”

From Beautiful Code

Back to xkb. What do these six directories represent?

First layer of indirection is translating a scancode (some bytes the keyboard firmware generates) to a mysterious all-caps alphanumeric identifier that looks like FROB or AE01. This symbol is supposedly a mnemonic for the key’s physical position, except when it isn’t. The mapping happens via files in the “keycodes” directory and I think I can ignore it.

I can also ignore the “geometry” directory; it apparently contains specs for how to draw keyboards.

Thus, I eliminate 50 config files from consideration. Only 225 to go.

The “rules” directory seems like a promising place to look. This is hopeless. The files look like an almost-but-not-quite scripting language that refer to other parts of the configuration. Maybe the docs will enlighten me.

The main advantage of rules over formerly used keymaps is a possibility to simply parameterize (once) fixed patterns of configurations… A sample rules file looks like this:

! model = keycodes
 macintosh_old = macintosh
 ...
 * = xorg

! model = symbols
 hp = +inet(%m)
 microsoftpro = +inet(%m)
 geniuscomfy = +inet(%m)

! model layout[1] = symbols
 macintosh us = macintosh/us%(v[1])
 * * = pc/pc(%m)+pc/%l[1]%(v[1])

! model layout[2] = symbols
 macintosh us = +macintosh/us[2]%(v[2]):2
 * * = +pc/%l[2]%(v[2]):2

! option = types
 caps:internal = +caps(internal)
 caps:internal_nocancel = +caps(internal_nocancel)

I think the writer has a different idea of “simple” than I. Having given up on rules files, I move on to “compat”, “symbols” and “types”.

The docs make it sound like these configurations all do just about the same thing:

  • Types “…describe how the produced key is changed by active modifiers…”
  • Compat “…defines internal behaviour of modifiers…”
  • Symbols “…defines what values (=symbols) are assigned to what keycodes [depending] on a key type and on modifiers state…”

I cross my fingers and hope I won’t need compat, so I look at types. The files are full of incantations like this:

type "TWO_LEVEL" {
    modifiers = Shift;
    map[Shift] = Level2;
    level_name[Level1] = "Base";
    level_name[Level2] = "Shift";
};

It appears that xkb abstracts the concept of a modifier key to something called a “level.” Level one means no modifiers, level two is with shift pressed, level three is alt or ctrl or super or something, and so on. I guess, maybe, if I wanted space to behave as shift, I might do that in the types (or compat?) folder, but since those files don’t appear to mention specific keys like space, they probably are not what I want today.

On to symbols…

There are a mere 183 config files in symbols. They have names that look mostly like country codes, but some are a little odd. I’ve never heard of a country called “capslock”, for example. How do I know which symbols file applies to me? I have no clue; guessing it is.

I discovered in keycodes that the four-letter word for space in xkb-language is SPCE, so I break out grep to find where it appears in symbols… it is all over, but I sense a pattern. Also, I notice an oddly-named country called “pc”.

$ grep SPCE symbols/pc
key <SPCE> { [ space ] };

In other countries other than the republic of pc, it looks a bit different:

$ grep SPCE symbols/fr 
    key  { [ space, nobreakspace, underscore, U202F ] };
    // ␣ (espace insécable) _ (espace insécable fin)
    ...

The French seem to get four mappings for space. Combined with my knowledge of levels, I finally put this together. It seems that the symbols files are tables of what character to produce, given an key and a particular modifier, if the modifier is level two (shift), you use column two, and so forth. I think.

So, I edit the pc symbols:

$ sudo vim /usr/share/X11/xkb/symbols/pc 
...
    key <SPCE> { [ space, underscore ] };

I log off, and back on again and I finally can type shift+space=__wtf__ in comfort.

Quad-monitor Linux

The last time I ran multiheaded Linux, I was on Kubuntu 12. Since that time I’ve built about a half dozen machines with same or similar hardware: a couple dual-dvi Nvidia cards. They mostly ran Windows, but it’s 2016 and time to kick Windows out again.

Upon initial install, three of the monitors are basically functional and Kde display settings detect the fourth, but won’t let me enable it. A little research and I remember that I used to use Xinerama.

In 2012, Nvidia supported multi-head configurations on Linux with its proprietary X extension, Xinerama. It was a bit quirky, but worked well enough so long as you had a set configuration you didn’t want to change often.

So I install the binary blob Nvidia drivers, enable Xinerama and get only black screen plus a cursor shaped like the letter x.

It seems that Nvidia abandoned Xinerama and they now say to use something called Base Mosaic. After reading many instructions and questions about this setup and tweaking xorg.conf every way I can imagine, I conclude that Base Mosaic can only span multiple video cards when they are connected via sli, and even if I had cards with that capability, it’s not clear whether I could expect it to work for more than three monitors.

Essentially, I have the wrong hardware. So I abandon the hostile Nvidia and instead order two Radeon cards.

Ati used to ship binary driver blobs, but also made specs available that enabled development of more reliable open source drivers. In the last few years, Ubuntu dropped support for the binary blob “fglrx” drivers, reasoning that the open source drivers are adequate, so the the fglrx packages no longer appear in official repositories for Kubuntu 16.

Two Radeon cards go in and all four monitors come to life. It looks like progress. Unfortunately, though active, they are barely usable: my mouse suffers terrible jerkiness and screens briefly freeze from time to time. I spend the rest of the day trying different combinations of Linux and window managers: i3 on Ubuntu, Kde on Centos, Gnome 3 on Centos, Cinnamon on Mint. All suffer similar problems and the fglrx drivers from ElRepo just crash.

I observe that the the problems go away so long as I use only one card at a time. So, I reason that I still don’t have the right hardware. I order a quad-head card, the VisionTek Radeon 5570. Finally, five video cards, later, I start Kubuntu and everything just works.

Short story: for multi-head Linux in 2016, use a single video card and avoid Nvidia.