Raligh update #3

It’s been a while since I’ve posted about the Raligh. I’ve been working on it but not as much as I’d like. You know how it is: school, work blah blah blah. Same old sob story, poor me. Anyways I’ve started in on the home stretch and it’s turned out to be a very long one.

The drive train on this thing is nasty. It’s the front and rear derailer, the chain rings, the cranks and the bottom bracket. That’s pretty much the hard stuff, specifically the derailers. These things have about 20 years of crap built up on them and it’s obvious that a few parts are bent. Here are the before pictures:

The front derailer:


The front chain wheels / rings:



Rear derailer:


And finally the cranks:

Those of you who’ve done this before will notice the cotter pin through the cranks. I’ll get to these in a in a bit but first the good news … the front chain rings and the kickstand cleaned up great!

So now the bad news: I got everything off the frame except for the cranks. Cleaning the 20 years worth of lubricant and dirt off the frame was a pain in the ass and there’s still more to be done but I can’t get to it all till the cranks are off. But these cranks do not want to come off. Stupid cotter pins. I’ve never seen cranks with cotter pins in them and I now know why.

I did some research and found that there are cotter pin presses out there but none are less than $50 + shipping so I rigged up my own boot-leg press. I took a 3 inch c-clamp I had laying about, cupped the out-going end of the cotter pin in a 10mm socket and used the clamp to press the cotter pin out. I left the nut on the threaded end, one turn out to keep it from completely bending over. It looked like this:

That was till the c-clamp broke. I should have seen it coming when I had to turn the clamp with a pair of 9 inch pliers. It wasn’t as dramatic as you think, I just ended up pushing the threaded bit through the plunger a bit. It sank right into the hollow part of the socket. The plunger wasn’t spinning much after that. You can see the plunger pushed through in the following pic, this thing was flat initially:

So one c-clamp down I looked for other options. I went with a solution recommended by the late great Sheldon “No Clunk” Brown. His site is the first google hit for “cottered cranks” and he has a laundry list of things he’s done to get cotter pins out of old-school European bike cranks. After soaking the cotter pin in WD-40 penetrating oil I tried his claw hammer & pipe method. I didn’t ding up the frame like I was afraid I would but I did some damage to the threaded end of the pin. It didn’t budge.

I figured this was a good time to take a break so I sat down with a whiskey and read some of Sheldon Brown’s journal entries and accounts of some of the rides and events that he attended. Really cool to read about a bike enthusiast riding around the north shore of Massachusetts just a few towns over from where I grew up. Some of the pictures made me nostalgic for New England, especially the one of his bike propped up against a beautiful New England field stone wall.

Sheldon put a wealth of information into the public domain through his website. He basically was blogging every day before a blog was a blog. He passed away but his site is still out there, complete with pictures of his kick-ass beard. His advice was a big help so, thanks man. I’m still working on way to get these pins out, hopefully it won’t come down to using the drill 🙂

dnsmasq and racoon VPN

I’ve always used the standard dhcp3 server on my local networks (non-routable IPs). Never really knew of any other options and I didn’t look for any. As the few networks I manage have gotten larger I’ve wanted my DHCP server to be able to feed information into local DNS so I don’t have to maintain hosts files or remember IP addresses. I’ve heard horror stories about configuring BIND so I figured hooking up DHCP and BIND would be way too much work for my purposes.

After some digging I ran across dnsmasq [1]. It’s a DHCP server and a DNS proxy rolled into one. As it doles out DHCP leases it populates the DNS proxy with host names, just what I need. There are a good lot of howto’s out there for setting up dnsmasq so I won’t pollute the web with another one that’s likely not as good as the others. Frankly, dnsmasq can pretty much be configured with the information contained in its well documented example config file (provided as part of the Debian package).

What I will add to the inter-tubes is how I got dnsmasq to resolve names for VPN users connected to the racoon VPN that I’ve documented in a previous post [2] without interfering with other DNS configurations on the client. This requires a few modifications to the racoon server config and the client side up/down scripts. It also takes some resolvconf magic to finish the job.

Serving DNS info to VPN Clients

The configuration required to get racoon to send DNS information to clients as part of the mode_cfg is pretty straight forward.

    dns4 10.XXX.XXX.XXX;
    default_domain "vpn.example";

That’s it. The client side up script receives these config parameters in two new environment variables: INTERNAL_DNS4_LIST and DEFAULT_DOMAIN. The INTERNAL_DNS4_LIST reflects the fact that we can include the address of more than one DNS server. In this example we’ve only got one but we write our script such that it can handle the list.

In the up script we’ve got the DNS information now but what do we do with it? I’m no expert at building a resolv.conf files by hand and I really don’t want to be. We need a way to manage multiple DNS configurations at the same time such that when we need to resolve names for hosts on the VPN network they get routed to the DNS server configuration received from racoon. Other names we want resolved by whatever DNS configuration was in place when we brought up the VPN connection. The resolvconf program (yeah bad/confusing choice of names) almost does what we need.

Client Configuration with resolvconf

The man page for resolvconf is pretty straight forward but it leaves out one specific detail. By my reading of the man page I would think to call resolvconf as follows:

  echo -e "domain ${DEFAULT_DOMAIN}nnameserver ${DNS_IP}" | resolvconf -a ${INTERFACE}

Where INTERFACE would be the name of the interface we’re talking to the VPN through.

This doesn’t actually work though. After an hour of trying multiple configurations to see what I was doing wrong I thought to look at the script that the resolvconf package installed in my /etc/network/if-up.d directory. This script takes whatever DNS info was associated with the interface either statically in the interfaces file or dynamically over DHCP and feeds it into the resolvconf program. It does something funny though. The interface name used isn’t actually that of the interface. The script appends the address family to the interface name passed into resolvconf.

I tried using this convention for the VPN configuration scripts. I appended ‘.vpn’ to the interface name (very original I know) and this time the DNS info obtained over the VPN doesn’t stomp all over the existing DNS info (the configuration my laptop got from DHCP on the local network). The small addition to the racoon up script is as follows:

RESOLVCONF=$(which resolvconf)
INTERFACE=$(ip route get ${REMOTE_ADDR} 
    | grep --only-match 'dev[[:space:]][0-9a-zA-Z]*' | awk '{print $2}')
if [ -x ${RESOLVCONF} ]; then
    INPUT=""
    for DNS in ${INTERNAL_DNS4_LIST}
    do
        INPUT=${INPUT}$(echo "nameserver ${DNS}")
    done
    echo -n -e "domain ${DEFAULT_DOMAIN}n${INPUT}" 
        | resolvconf -a "${INTERFACE}.vpn" | logger -t "phaseone-up"
fi

This is a step in the right direction but it still doesn’t work exactly as we want.

The resolv.conf file generated by resolvconf after bringing up the VPN looks like this:

nameserver 192.XXX.XXX.XXX
nameserver 10.XXX.XXX.XXX
search home.example vpn.example

Here the 192.XXX.XXX.XXX DNS server was obtained by our network interface when it was brought up using DHCP. This is the DNS server on my home network. It knows the names of devices that have registered using DHCP and when searching for a hostname that’s not qualified the suffix appended is ‘home.example’. I leave off the top level suffix to prevent the proxy from forwarding bad search requests. The 10.XXX.XXX.XXX DNS server is the one that will resolve hosts on the VPN network. Again it knows the names of devices that have registered on the VPN network using DHCP and provides the search suffix of ‘vpn.example’.

Why This Doesn’t Work

Because the home DNS server is listed before the VPN DNS server it will be queried first. When asked for a host that exists on the VPN domain the query will first be sent to the DNS server on the home.example netowrk and the query will fail. The query will fall through to the next nameserver only in the case of a timeout or an error so the VPN DNS server will not be queried in this case and we can’t resolve names on the VPN network. If we switch their order manually we’ll be able to resolve names on the vpn.example network but attempts to resolve names on the home.example network will fail.

This situation is represented graphically here:

To make this more concrete, say we want to resolve the name for ‘bob’ (like if I were to run ‘ping bob’), a system on the home.example network. We’d expect the resolver to be smart enough to search through the two available DNS servers knowing their search domains. It could ask the vpn.example DNS server for ‘bob.vpn.example’ and if I didn’t find bob there it could then ask the DNS server on home.example for ‘bob.home.example’. If only the resolver functions in libc were this smart.
NOTE: we’d be in trouble if each network has a host named ‘bob’ but how to handle that situation is out of scope for this discussion.

For configurations that are relatively advanced we have to fall back on a DNS proxy like dnsmasq. Yes we’re already running dnsmasq as a DNS proxy on these two networks but the problem we’re running into is that the resolver on the client isn’t smart enough. The smarts we need are built into dnsmasq.

dnsmasq as a Client-side DNS Proxy

Installing dnsmasq on the client is painless. It’s already tied into the resolvconf system so its notified of changes to the reslover information but it preserves the behavior of the standard libc resolver described above. We can however statically configure dnsmasq to consult a particular DNS servers for a specific domain with one configuration line:

server=/domain/ip

For the network layout described we could add two lines to the dnsmasq.conf file to get the behavior we want:

server=/home.example/192.XXX.XXX.XXX
server=/vpn.example/10.XXX.XXX.XXX

Static configurations stink though (too easy) and with a little more work we can get the same effect with a short script:

#!/bin/sh                                                                       
# ip address from string to int                              
function inet_aton () {
    local count=3
    local int=0
    for num in $(echo $1 | sed -e 's/./ /g'); do
        let "int+=$num*256**$count"
        let "count-=1"
    done
    echo $int
}
pushd "/etc/resolvconf/run/interface/" > /dev/null
FILES=$(/lib/resolvconf/list-records | sed -e '/^lo.dnsmasq$/d')
for file in $FILES; do
    ns=$(cat $file | sed -n -e 's/^[[:space:]]*nameserver[[:space:]]+//p')
    PARAMS+="uint32:$(inet_aton $ns) "
    domain=$(cat $file | sed -n -e 's/^[[:space:]]*domain[[:space:]]+//p')
    PARAMS+="string:$domain "
done
dbus-send --system  --dest='uk.org.thekelleys.dnsmasq' 
    /uk/org/thekelleys/dnsmasq uk.org.thekelleys.SetServers $PARAMS
popd > /dev/null

For this script to make sense it’s important to know that when the resolvconf system is passed DNS information for a particular interface it makes a file with the name of the interface in /etc/resolvconf/run/interface/. This last script is placed in the directory /etc/resolvconf/update.d/. Each script in this directory is run every time the resolvconf information is changed. In the script we extract the nameserver and domain information from each file and send it to dnsmasq through the dnsmasq dbus interface (which must be enabled in dnsmasq.conf).

That’s it. Now each time we make a connection to the VPN the racoon client scripts send the VPN DNS info into resolvconf. resolvconf then runs its update.d scripts and the new script that we’ve provided takes this DNS information and sends it through to dnsmasq through a dbus interface. That was a lot of work, but now my VPN works the way I want it to. Well worth the effort IMHO.

I’m no dbus expert but I don’t really like the dnsmasq dbus interface. All functionality for manipulating the servers is packed into one function. As you can see from the above script it’s just “SetServers”. The interface would be much more effective and much easier to use if this one function were broken up into several, like an “AddServer”, “RemoveServer” etc. The full documentation for the dnsmasq dbus interface can be found here [3]. Proposing a few patches to fix this up would be a fun summer project 🙂

Mandatory Access Control SEED Lab

As part of the graduation requirements for my Masters degree, SU requires that we either complete a “masters project” or a thesis. Working full time while working towards my degree has really limited my ability to interact with the faculty and get involved with their research. This has mad the thesis option difficult since most of my research interests haven’t lined up with the interests of any professors I’ve been able to interact with. So the project seemed like the way to go especially since I’m really looking forward to graduating soon 🙂

The project that I’ve settled on is a lab that hopefully will be used by my advisor, Dr. Wenliang (Kevin) Du as part of his SEED project. He’s been using these labs in his computer security class and I noticed that, though Dr. Du teaches mandatory access control (MAC) he didn’t have a lab to make the topic concrete. I’ve been working with SELinux for a while now so making this lab it seemed a good fit for me.

It turns out that others have attempted this task in the past but have run into difficulties. I haven’t had a chance to see the previous attempts but Dr. Du couldn’t use their labs because they were very long and very complicated. After hearing this my brain starts to file it away under requirements. The lab has to be “short”: something that a graduate student in computer science / computer engineering can accomplish in a two week period (that’s actually a pretty long lab IMHO).

This initial post is just a quick introduction to the topic and to a new tag on my blog. If you’re interested in following this work, subscribe to my MACSEEDLab tag. I’ll be updating this with some brain storming soon.