From 0 to an OpenBSD install, with no hands and a custom disk layout

No one likes to do repetitive OS installs. You know the kind, where you are just clicking through a bunch of prompts for username, password, and partitioning scheme as fast as you can to quickly get to the point where you can get some work done. This scenario happens to me every time OpenBSD releases a new errata. As my OS of choice for firewalls/routers, I use a fresh OS install as the baseline for building a -stable branch of install set files.

While OpenBSD had automated away most of those manual-installation tasks with autoinstall(8), as of a week ago you still could not customize your disk layout. But thanks to commits by OpenBSD developers henning@ and rpe@, you can now specify your own disk layout programmatically to be used during an automated install.

While building a new set of install files is not part of this post, continue reading to see how I got one step  closer by completely automating the base OS install with my custom disk layout.

Continue reading “From 0 to an OpenBSD install, with no hands and a custom disk layout”

All the bits, from anywhere.

Problem Statement: While OpenVPN has served me well over the past few years both for site-to-site and road-warrior style VPN connections, it always bugged me that I had to hack a config file, juggle certificates, and use a custom client that isn’t part of the base OS to bring up the links. My Android phone has a built-in L2TP/IPSec VPN client. My Macbook Pro OS X 10.9 laptop has both an IPSec and L2TP VPN client GUI wrapped around racoon. I run OpenBSD as my firewall/router gateway at home. There must be a solution here.

Goal: To allow all remote clients (both site-to-site and road-warrior) to connect and route all their traffic securely over the Internet through my OpenBSD machine at home.

Continue reading “All the bits, from anywhere.”

Family Tech Support: Vacation Edition

This was an epic visit home, tech-wise. Just so I don’t forget, and can hold it over my folks’ head for a while:

  • Upgraded two five-year-old Linksys E2000 AP’s to Netgear r6250’s. Those old ones were just not reaching the entire length of the house anymore.
  • Upgraded the firewall/router from OpenBSD 5.5-stable to OpenBSD 5.6-stable. It just so happens I’m home every six months to stay relatively close to the most-recent errata.
  • Converted my father’s Gmail account over from one-factor to two-factor authentication thanks to some nasty spyware/adware and potential identity-theft issues he’s had recently. I wasn’t willing to do this conversion remotely given the horror of Application Specific Passwords and how many devices I would have to do it on (desktops, laptops, one iPhone, and one iPad)
  • Reinstalled one Late 2009 21.5″ iMac via Internet Recovery to OSX 10.10 due to aforementioned nasty adware infestation.
  • Upgraded that same iMac from 4GB RAM to 16 GB RAM.

All I can say is that it’s nice having all Mac’s in the house now, after finally kicking out the last Windows-based PC on my last visit.

Third time’s a charm? Gitolite, Git, Nagios, and a bunch of hooks

I was hoping with my past posts on this topic, I would have enough examples to just copy-and-paste along to configure my Gitolite+Nagios monitoring setup. Not so true. It looked like there were semi-colon’s missing in my past examples. After looking at the huge number of changes in Gitolite, I had to re-do everything. Not to mention I always wanted a better way to manage the hooks as opposed to editing them directly on the host. In short, my goal is still simple: be able to manage and verify Nagios configuration remotely via Git. Below is how I did it. For the third time.

Continue reading “Third time’s a charm? Gitolite, Git, Nagios, and a bunch of hooks”

Stack it up: KVM, VLANs, Network Bridges, Linux/OpenBSD

I’ve had some free time and a desire to break stuff on my network at home. I wanted to fix my home network’s topology to more correctly split up my wired (DHCP), wireless (DHCP) and server (statically-configured) subnets. At a high level, I had to create a server subnet, create vlan’s on my layer-3 switch for each of those pervious subnets, then I had to move the network interfaces on my VM host around to only connect to the networks I wanted it to (wired and server).

First, I moved the secondary interface of my VM host at home from the wifi network to the new server network. The server network would have its own subnet ( and its own VLAN, Vlan 12. (we all have Layer3 managed-switches at home, right?).

The fw/router on my network runs OpenBSD.  Interface ’em3′ will be providing connectivity to  vlan 12.

Depending on if I want to throw more VLAN’s on em3, I can just create more hostname.vlan{number} files with appropriate network configuration.

The switch managing my network’s traffic is an HP 2910al-24G (J9145). The relevant configuration to handle tagged packets on vlan-12 on two ports (4, 12) is:

I’ve also added a management IP on this server subnet VLAN as well. On my VM host, this took me the most time to get right. The hardware network interface for the server network is eth1. I wanted to create a bridge on this interface so that multiple VM’s could use this interface to bind to. This bridged interface on vlan-12 is br-vlan12. This host also has an IP address on the network itself so that I can access the VM host itself over the server subnet.

One of the pieces that had me fumbling for so long is getting the bridge_ports and vlan_raw_interfaces specification on the bridge. It turns out when the former is specified in a certain way, the latter is not needed.

From interfaces(5):

I am still having some fun issues with routing on my network, where I can ping from my wifi network to the wired-network interface on my LAN, but not wifi -> server. I think this has to do with reverse path forwarding (RPF) checking on the server, given its default route is over the ‘wired’ network and not the server network interface. An invaluable tool to debugging these types of issues has been the sysctl setting below, logging martians. It logs instances where packets come into an interface which it does not expect, and therefore by-default rejects.

The fun and breakage continues.

Helpful links found during my foray into this topic: