The OpenBSD routing table can be carved into multiple virtual routing tables allowing complete logical separation of attached networks. This article gives a brief overview of rtables and explains how to successfully leak traffic between virtual routing domains.

I just upgraded a couple of machines to OpenBSD 4.9 and noticed the hrSystemProcesses OID was not being returned by Net-SNMP 5.6.1 (from the 4.9 ports/packages collection) . joel@theta:~% snmpwalk -v2c -c public theta .1.3.6.1.2.1.25.1.6.0 SNMPv2-SMI::mib-2.25.1.6.0 = No Such Instance currently exists at this OID I know for sure this worked on OpenBSD 4.8/Net-SNMP 5.4.2.1. Turns out there is a bug in Net-SNMP 5.6.1 (bug 3166568) that's causing this. It's been fixed in their SVN tree.

I've updated my SNMP MIBs to support OpenBSD 4.9.

I used to have a machine sitting around that I would power up whenever I needed to build a new OpenBSD kernel or rebuild the source tree due to a patch or a new version of the OS being released. Eventually I moved that machine into a VirtualBox virtual machine running on my desktop. Recently I moved that VM into VMWare's free ESXi hypervisor running on some pretty decent hardware. It got me wondering how much I could lower compile times by adjusting how many vCPUs were allocated to the VM.

As a follow-on to my previous post about disabling plugins, this script will enable plugins from the shell.

Lately I've been working with a separate instance of my WordPress site for development and testing of plugins, my theme, etc. I have a helper script that orchestrates the pulling of files and copying of the database from the production server into the dev server. I found that it would be nice to disable certain plugins that I don't want running in the dev instance (ie, plugins that notify search indexes when new posts are made) from within this script.

I recently had an issue with an OpenBSD firewall where the number of state table entries was hitting the default limit of 10,000. When this limit is reached, no new state entries can be created. If you're using "keep state", "modulate state" or "synproxy state" on your rules or if you're running OpenBSD 4.1 or newer (where "keep state" is the default on all rules) this could mean that:

• You cannot make new connections through the firewall
• You cannot make new connections to the firewall
• You cannot make new connections from the firewall

So.... if you hit the state table limit it's kinda bad, mmmkay?