[BKR-1021] Archlinux support

[jantman]

This adds support for archlinux, which is present in beaker-puppet, originally introduced by pre-refactor beaker PR 1289 by @petems and I, but isn't supported for Docker.

This also introduces support for a docker_cap_add Array section of the config, which allows setting additional kernel capabilities for the SUT container (see Docker kernel capabilities, docker run --cap-add. This was needed for a module I'm testing; see below for more.

This should add the minimum needed to get Arch working as a docker-based SUT with the "standard" SUT setup (openssh/sshd). An example of this working can be seen in my puppet-archlinux-workstation module; host yaml and tests passing on TravisCI.

I'm not sure if this should be documented, or if so where, but the archlinux distro itself is only supported by beaker-puppet with PUPPET_INSTALL_TYPE=foss, probably because the PR above predates agent installs.

Note about added capabilities: The module that inspired this PR is my puppet-archlinux-workstation module module that I use to manage a base graphical install of ArchLinux on my desktop and laptops. It's not terribly popular but isn't unknown either (and would probably get more visibility if it were on the Forge, which I'm going to do soon, but it's a vintage module ;) ). It requires a full-blown systemd to do acceptance testing (the old Vagrant/VirtualBox tests stood up xorg and sddm, too, but that's too problematic in Docker), which requires the SYS_ADMIN capability.

[puppetlabs-jenkins]

Can one of the admins verify this patch?

[jantman]

Egads! No Travis on this repo!

Also, I just realized that this may fulfill BKR-1021 for Arch support, which @petems opened about a year ago.

There is one asterisk on my implementation here, which may be cause for concern...

1. To get ssh working in the container, I had to explicitly install openssh
2. and then systemctl enable sshd, which assumes the container is running a full-fledged init and systemd (which is the Arch default)
3. Which requires both a container with a "normal" (i.e. non-container-optimized) Arch install, and for that container to be running with --cap-add SYS_ADMIN and -v /sys/fs/cgroup:/sys/fs/cgroup:ro

Not sure if that should be documented or not, and if that's OK or not.

I assume that since many/most Puppet modules manage daemons, it's normal to be running in a Docker environment with the system standard init and process manager, but this is my first foray into beaker-docker for a module of my own.

[kevpl]

@jantman thanks for this submission! I'm surprised there are so many commits for this few changes, but I see they're pretty granular.

Would you please prefix your git commit messages w/the ticket reference (BKR-1021) like you've done with the title of this PR? Then everything here should match our contributing standards, and we can look to push this through our CI for merging.

[jantman]

@kevpl I rebased this down to one commit, appropriately prefixed.

Sorry for not referencing the issue in the original commits... I actually found the ticket after I opened the PR.

[petems]

@jantman Thanks for picking this up! I had honestly forgotten about this 😄

I'm sure @bastelfreak will be happy to see this, as our resident Arch + Linux person 👍

[bastelfreak]

\o/
Thanks for the work here! I already added a nodeset for arch on Vox Pupuli, this PR would allow us to finally use it.

[kevpl]

👍

[kevpl]

@puppetlabs-jenkins test this please

[jantman]

@bastelfreak @petems Sure! I'm finally getting around to cleaning up and modernizing some of my vintage-2013 Arch-centric modules, and just couldn't bear to use VirtualBox acceptance tests anymore (or leave acceptance tests out of the Travis run).

Glad to know there are still some other Arch folks around!