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/…

Capturing and Replaying Connection-less Protocols (eg. IPFIX into Logstash)

It can be useful to be able to capture AppFlow (IPFIX) data, which in our environment at least is UDP, and replay that on some other machine where you are playing with Logstash (or some other tool that might read in such data from the network). In this page, I show you how you can capture packets using tcpdump, rewrite them post-capture, and replay them as if they were sent to your own machine. We'll also set up a standalone Logstash instance that reads in IPFIX records and just emits them to stdout in a debugging format.

Step 1: Capture some traffic This is easy; just remember to use a useful filter (not everything will rewrite easily, and capture the entire packet.

Notes: I'm running this capture on production, so I limited the number of packets, using '-c 10000', that could be captured (to prevent disk blowout) I want the application data, so I'm capturing the entire packet with '-s0' Because I only want IPFIX data, and can only realistically rewrite con…

Installer or command that hangs? Use /dev/urandom instead of /dev/random, but constrained to a particular process

Okay, so I'm working on making an Ansible role for deploying an Oracle 10g Webgate, and I want it working on RHEL 6 and RHEL 7. I managed to do that (yay; took a bit of persuading), but quickly noticed that if you don't do something to prevent it, the installer (InstallShield on Linux... yuck, and not just because it wraps Java 6), your entropy pool drains very very quickly and the installer just sits there, hanging.

You can verify that its blocking because of entropy by using a command such as:

watch cat /proc/sys/kernel/random/entropy_avail

and if it isn't hovering between 2000 and 3000, then you have a potential issue; if its staying under 1024 or so, then you very likely will be experiencing hanging behaviour, depending on which application is draining the pool (commonly by trying to read a bunch of data from /dev/random)

I should note that this is in a VMWare environment, so no hardware random number generation for me. Instead, what I typically do is to push out a sysc…

[Humbledown highlights] VLAN tag stripping in Virtualbox (actually, Intel NICs et al.)

This is historical material from my old site, but as I have just bumped into a page that linked to it, I thought I would republish it. I have not verified that this material is still accurate. Feel free to post an update as a comment and I'll publish it. VLAN tag stripping in Virtualbox (actually, Intel NICs et al.) Mon Jan 17 21:41:46 NZDT 2011 VirtualBox, VLAN, Networking, Linux, Mac OS X, Teaching, Study Short version: When using VirtualBox “Internal Network” adaptors for VLAN environments, don't use the ”Intel PRO/1000” family of adaptors, which are the default for some operating system types. Instead, use the either the Paravirtualised adaptor (which would require your guest to have Xen’s virtio drivers, or “AMD PCNet” family of adaptors.
This is because the “Intel PRO/1000” family of adaptors strip the VLAN tags: this is not a problem specific to Virtualbox: it occurs also in other virtualisation products and also on native systems; although you hear about it more often in…

Memcached logging (and others) under Systemd on RHEL7

I've been getting into RHEL7 lately (yay, a valid reason to get into at work!) and this means learning about systemd. This post is not about systemd... at least its not another systemd tutorial. This post is about how I got memcached to emit its logging to syslog while running under systemd, and how to configure memcache to sanely log to a file that I can expose via a file share.

Its 2:21am, so this is gonna be quick. I wrote this because I needed memcached, and in response to some bad advice on Stack Overflow.

Use IPTables NOTRACK to implement stateless rules and reduce packet loss.

I recently struck a performance problem with a high-volume Linux DNS server and found a very satisfying way to overcome it. This post is not about DNS specifically, but useful also to services with a high rate of connections/sessions (UDP or TCP), but it is especially useful for UDP-based traffic, as the stateful firewall doesn't really buy you much with UDP. It is also applicable to services such as HTTP/HTTPS or anything where you have a lot of connections...

We observed times when DNS would not respond, but retrying very soon after would generally work. For TCP, you may find that you get a a connection timeout (or possibly a connection reset? I haven't checked that recently).

Observing logs, you might the following in kernel logs:
kernel: nf_conntrack: table full, dropping packet. You might be inclined to increase net.netfilter.nf_conntrack_max and net.nf_conntrack_max, but a better response might be found by looking at what is actually taking up those entries in your conne…