I’ve recently started learning and using tmux as an alternative to screen since its import into the OpenBSD. Upon seeing the simplicity of the man page and commands over screen (nice default status line too), I became a fan and subsequently installed it on all of our servers.  It motivated me to re-subscribe to OpenBSD’s source-changes mailing list and learn that Nicholas Marriott (tmux author according to Undeadly) is a maniac when it comes to commits and also writes good commit logs.  Think we’ll be seeing more of him in the near future.

There are about 7 screens open on Juicebox, and 1 tmux.   Hence this post.

In other news, I’ve been reading a lot about DHCP and Option 82 lately upon finding some new types of information in our dhcpd.leases file.  I’m graduating soon, but if we could make it work and log as this article indicates (the logging part), it’d be pretty cool.

Spring break was quiet at ResTek.  I haven’t been into the office much.  I guess because I like to work from home more, where I have my own computer and access to as much coffee as I would like.

I had to buy a new french press (accidentally broke the last one that I got for Christmas, ouch) so I bought the Bodum Kenya model because it wasn’t as expensive as the Chambord (original — $40!).

On Wednesday I took a train down to Seattle to help my dad with some things at his business and ran into Symons across the street from the store.

Work has been uneventful, but I managed to finish the Perl script that I use to add new accounts.  It’s a lot more user-friendly now (view groups before selecting one, allow you to enter name or number, deal with non-ResTek accounts, etc.)  In addition to that, I extended our password-reset application.  It now supports changing more of your LDAP information such as phone numbers, email addresses, name, and login shell which means people don’t have to use phpldapadmin (they still can).  I broke away from using our current Staff class which encompasses employee information in doing so, but since Zend_Ldap is going to be extended soon (I hope!) I have plans to convert all of our PHP LDAP code to a consistent interface in the near future anyway.

Debian with VirtualBox (+Vista)

A while back I was talking to a friend and our discussion convinced me to install Linux (or something else) on my desktop.  I decided to give Debian another go, and I’ve been really happy with it.  I’ve had it on my laptop for quite a while, and now it’s on my desktop too.  The same discussion led to me installing VirtualBox, and I added 2GB more ram (making 4GB total) to my desktop to give my virtual machine(s) more memory.

When the time comes to buy a new laptop, I’ll probably use the same setup.

The end of another quarter is approaching which means finals are coming up. I’ve got 2 on Monday (Business and Its Environment, and Business Database Development) and another on Thursday (Telecommunications). The week before finals, known as “dead week”, turned out to be just an extension of finals week. I had a final for the lab portion of my database class, and another in MIS 495 — my capstone course — on Thursday, and a project due Friday. It’s been a busy quarter. It does look like I’m set to graduate this summer though.

I’m registered for next quarter:

• Computer-mediated communications
• Network Administration
• Humanities of Islamic Civilization
• Gender and Society

Pretty diverse schedule now that I have most of my major out of the way.

The world of ResTek has been quiet. One of the two new developers is leaving WWU at the end of this quarter, leaving only one (Symons and Ben are gone after this quarter). The servers are pretty easy to maintain and with zero budget to work with, I don’t have much to work with in the hardware upgrade realm.

I’d like to repartition the servers over break, since the current space allocation isn’t ideal. The database server, for example, needs more space for /var.

I haven’t broken anything too terribly in a while, but I did render our logserver useless for a while:


OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009


I used the first 4.5 snapshots to do so. When I upgraded the kernel and rebooted, I lost access. When I finally made it down to Bond Hall on Monday, the problem became clear. None of the network interfaces had been created because ifconfig(8) was out of sync with the new kernel due to some of the changes in 4.5. I extracted the new ifconfig(8) from base45.tgz of my snapshot and that fixed the problem. I later learned that a page for upgrade45.html exists even though 4.5 is not yet released — I’ll be following a process more similar to the one mentioned therein from now on when using snapshots.

Snapshots can be more interesting than supported upgrades between releases and that’s why I like them. They’re also relatively painless for the most part when you read about the changes made between releases (current.html, plus45.html).

I’m excited to see what kind of impact the pfsync improvements will have on our firewalls.

Our LDAP clients previously connected to a single IP address (ldap.restek.wwu.edu) which was a virtual address (using CARP) shared by two LDAP servers in a master/slave setup with replication. The slave of this pair was rarely used because the master rarely went down. CARP, therefore, created host-level redundancy for our LDAP directory but not service-level. The other host would have to lose network connectivity entirely for the slave to be used.

The load on the server wasn’t enough to justify load-balancing, but the setup had obvious problems. For simplicity, the two shared the same SSL certificate/keys with just one CN (ldap.restek.wwu.edu) and no subjectAltNames to make connecting to other hostnames (i.e., directly to the slave) over SSL impossible. Another problem was that when you needed to restart the OpenLDAP daemon for an upgrade on the master, it would be unable to look things up. This required workarounds like adjusting CARP settings temporarily during upgrades. Anyway, the setup was problematic and clearly not effective long-term.

Our certificates expired a day or two ago, and I decided to use the opportunity to fix the setup.

1. New DNS names

Rather than having only one name, I decided to create two more aliases for the LDAP servers: ldap1, and ldap2. These were simply CNAMEs for our master and slave LDAP server, respectively. This follows the convention that I used for nameserver naming: ns1, ns2, ns3, etc.

2. New certificates

I also created new and unique self-signed certificates for each LDAP server. I created certificates with information like the following:


Subject:
C=US, ST=Washington, L=Bellingham, O=Western Washington University, OU=ResTek,
CN=vali.restek.wwu.edu/emailAddress=admin@restek.wwu.edu


X509v3 Subject Alternative Name:
DNS:vali.restek.wwu.edu, DNS:ldap1.restek.wwu.edu, DNS:ldap.restek.wwu.edu


The Subject Alternative Name (subjectAltName) piece, described in RFC 3280, is to ensure that people can securely connect to any of those three names without warnings or errors about the names not matching. I believe it is possible to also use wildcard certificates, but I prefer this. Wildcards are ambiguous I added the primary hostname to subjectAltName because some reading indicated that a client might prefer alternative names over subject CN. It may also be possible to leave CN blank in the case where you use subjectAltName, but I’m not sure how older clients handle this.

I installed these certificates on the clients (all FreeBSD servers) into /etc/ssl/certs with descriptive filenames.


vali-restek-wwu-edu-ldap-20081223163515.crt
vidar-restek-wwu-edu-ldap-20081223173447.crt


These “2008″ numbers are simply the issue dates of the certificates. I wasn’t sure whether I wanted to use issue date, expiration date, neither, or what. But I ended up sticking with issue date for now. The main reason behind this was to allow a new administrator to install new certificates without renaming the old ones.

If you’re at all familiar with SSL configuration, you may know that most applications allow you to specify a path to a directory of certificates rather than a filename. This is most often used for CA certificates which you trust. How are these located when you need them? It seems that OpenSSL expects them to be located according to their hash. Rather than rename them, I created links to the actual certificates using commands like the following:


$ openssl x509 -hash -noout -in vali-restek-wwu-edu-ldap-20081223163515.crt
51afeb96
$ ln -s vali-restek-wwu-edu-ldap-20081223163515.crt 51afeb96.0


The extra digit (i.e. 0) appended to the end of the symbolic link name is used in case of multiple certificates with the same hash value.

3. pam_ldap, nss_ldap configuration

I won’t go over the entire configurations I have – just what I changed. First, I changed the URI to include both hosts:


uri ldap://ldap1.restek.wwu.edu/ ldap://ldap2.restek.wwu.edu/


The second will be tried if the first fails, according to the documentation and my tests. Obviously this is much better than a single CARP’ed IP address.

I also changed the certificate location from a single file to a directory:


tls_cacertdir /etc/ssl/certs


This is where the symlinks come into play. Notice I did not have to specify the actual filenames — just the directory where certificates are located.

4. Postfix

The manual page ldap_table(5) was extremely helpful (it described the necessity of the hash symlinks shown above in addition to exactly what Postfix needed). Relevant parts of my Postfix LDAP configuration file (ldap.cf):


server_host = ldap://ldap1.restek.wwu.edu ldap://ldap2.restek.wwu.edu
start_tls = yes
tls_ca_cert_dir = /etc/ssl/certs/
tls_require_cert = yes


5. Dovecot

Dovecot documentation wasn’t as clear. I ended up looking at the source and discovered that it does support options similar to Postfix, but they aren’t in the wiki to my knowledge. They are, however, documented in the example LDAP configuration included with the distribution.


uris = ldap://ldap1.restek.wwu.edu ldap://ldap2.restek.wwu.edu
tls = yes
tls_ca_cert_dir = /etc/ssl/certs
tls_require_cert = demand


6. Apache (mod_authnz_ldap)

Not much needed to change in the Apache configuration, but one thing did require testing. The syntax to specify multiple hosts is as follows:


AuthLDAPURL "ldap://ldap1.restek.wwu.edu ldap2.restek.wwu.edu/ou=People,dc=restek,dc=wwu,dc=edu?uid?" TLS


I’m still trying to figure out how to configure Apache to trust certain certificates.

In order to make this easy to maintain in the future, I may end up setting up a local CA or using a free provider. This way, the clients won’t need to be reconfigured when the certificates change.

I upgraded the WordPress installations over at ResTek to 2.7 this morning and the new design made me want to start up my own blog again. A while back I deleted my account over at Dreamhost because I got tired of paying for it so I decided to use this free service instead.

With me being set to graduate in a 2-3 quarters (finally…), we’re looking for a new Server Administrator for ResTek. We found one to do the Housing stuff a while back. The pay isn’t anything to write home about and you’re limited to 19 hours per week (40 during breaks) but it’s an opportunity to learn an incredible amount, whether it be through experimentation or your peers. Things run really smoothly lately as far as the servers are concerned, but they won’t forever, and whoever is around will have an opportunity (like I did) to make improvments.

A while back I ended up picking up a new monitor finally. Next on my list is a set of speakers, but I’m too broke to pay for those just yet and Christmas is coming up meaning I’ll be spending my money on gifts for people. Estimates show the new monitor has increased my productivity about 35.7%. It’s nothing amazing but it’s nice to be able to watch movies or TV shows (The X-Files) from the comfort of your bed.