Skip to main content


Laptop with small screen + Hyper-V + Install CentOS

So I've got a nice new Lenovo ThinkPad laptop for work. Its got lots of memory and disk, awesome battery life, and it's nice and portable; just the thing for a systems engineer -- it even has a wired ethernet connection (I was previously using a Mac Air). It doesn't have a very large resolution though, just 1366 x 768.

Normally I would use VirtualBox, but on this laptop I'm trying out Hyper-V (because that's what Docker for Windows requires on Windows 10).

I went to install CentOS 7 (7.4), but the resolution of the default framebuffer is larger than can fit on my host's screen. This biggest annoyance about this is that Hyper-V wasn't showing me scroll-bars, and it also only allows to zoom in (for Hi-DPI screens), and not to zoom out. Being able to zoom out was very useful feature in VirtualBox, but the biggest problem was that it cut off the bottom of the screen, so I couldn't proceed with the install. Even text-mode installation was impractical because…
Recent posts

Provisioning Limited Access via Squid Proxy to Docker Containers

You have a Docker environment in your network; you limit outgoing traffic from your servers using a whitelisted proxy configuration (Squid) which can then be used for auditing. You wish to allow some containers access to some sites; perhaps even allow some containers access to any site.

How then, can you grant access based on the container? You need to add an extra level of authentication.

You could set up user-credentials for each container that needs access, but that is an administrative burden, and further a lot of software doesn't work well with a proxy that needs user authentication, which is a support concern.

Or we could use ident lookups to determine the 'user', which can then be used to evaluate ACL conditions. To do that, we would need to set up some specialised 'identd' type service on our docker host(s) that was able to return the container name associated with a given source-dest TCP port pair.

This turns out to be entirely feasible, and has the added …

Using Ansible to Fix CFEngine (after a trust failure as a result of re-addressing policy hub)

One of the things I have been given (cursed with) in my life in IT is maintenance of CFEngine. CFEngine is one of the oldest, typically left on the wayside, systems for configuration management on Linux and other Unix (and I think also Windows these days).... I'd love to drastically refactor and clean it up, because its grown pretty organically.

Anyway, its on some old equipment and I need to migrate it to a new IP to keep management happy from a risk perspective. How bad could that get? Turns out that CFEngine is sensitive to this, and I get another deluge of email:
!! Not authorized to trust the's public key (trustkey=false)  !! Authentication dialogue with failed  ... ad nuseum
So.... I think I just broke all the CFEngine agents, which won't be able to grab policy updates. Let's fix this using Ansible.

VirtualBox 5.1.27 + RHEL 7.4 (and others) + kernel update = suggest double reboot

For a long time now, every damn time I go to apply a kernel update, I have to rebuild the VirtualBox Guest Additions. If I have any vboxsf mounts set to mount at boot in /etc/fstab, I can look forward to a rescue-mode prompt. This is not specific to RHEL7, or to RHEL (I see plenty of reports of Ubuntu 11.04 with the same issue).

The 'dkms' (Dynamic Kernel Module Support) is meant to prevent this issue by triggering a rebuild when a kernel package is updated. It's installed,....  so why isn't it working. Time to get my hands dirty and learn a bit about dkms.

VirtualBox 5.1.26 + RHEL 7.4 = GA 5.1.27 needed

Well, its that time of the month again when life gets difficult. That's right, it patching time. So naturally, on the Monday after patch week, I decided to apply the updates that VirtualBox was notifying me about.

This time, its an update from 5.1.24 to 5.1.26.... it did not go as smoothly as I would have hoped. But the breaking change seems to be in the upgrade from RHEL 7.3 to 7.4, which changed the version of to 1.19, which Guest Additions 5.1.26 doesn't seem to support.

The symptom was that the graphic driver didn't seem to work (so tiny resolution). Other functionality such as shared clipboard still worked, thankfully.

VirtualBox 5.1.22 Guest Additions (un)install fail and fix

Patch time again, say goodbye to half a day with urgent Windows updates and routine VirtualBox / Linux etc. updates for my workstation.

Anyway, it seems 5.1.22 fixed by earlier problem in 5.1.20 to do with Shared Folders, but I really wish they would test things a bit more, as this patching didn't go very smoothly and my VM failed to boot to completion (VBoxAdditions missing).

Attempting to run the installer gives you this message:

VirtualBox Guest Additions installer You appear to have a version of the VirtualBox Guest Additions on your system which was installed from a different source or using a different type of installer. If you installed it from a package from your Linux distribution or if it is a default part of the system then we strongly recommend that you cancel this installation and remove it properly before installing this version. If this is simply an older or a damaged installation you may safely proceed. Do you wish to continue anyway? [yes or no]
Okay.... haven&…

VirtualBox 5.1.20 bug with Shared Folders (RHEL 7 guest)

Upgraded VirtualBox (as is my wont to do) and found the following problem after reinstalling the newer Guest Additions.
I've submitted a bug report 16697 for this.

# mount host_home mount: wrong fs type, bad option, bad superblock on host_home, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. dmesg tells me the following (I had already tried rebuilding the GA with rcvboxadd setup -- the systemd equivalent of /etc/init.d/vboxadd setup)
# dmesg | tail ... [ 334.616717] vboxsf: Successfully loaded version 5.1.20 (interface 0x00010004) [ 343.413650] sf_read_super_aux err=-22 A similar report from an earlier version suggested a installation bug with library locations, so looking around ...
# updatedb # locate mount.vbox /opt/VBoxGuestAdditions-5.1.20/lib/VBoxGuestAdditions/mount.vboxsf /usr/sbin/mount.vboxsf # ls -l /usr/sbin/mount.vboxsf lrwxrwxrwx. 1 root root 49 Apr 26 10:04 /usr/sbin/…