Phly, boy, phly
the weblog and site of Matthew Weier O'Phinney

We're working on migrating Zend Framework to Git. One issue we're trying to deal with is enforcing that commits come from CLA signees.

One possibility presented to us was the possibility of utilizing GPG signing of commit messages. Unfortunately, I was able to find little to no information on the 'net about how this might be done, so I started to experiment with some solutions.

The approach I chose utilizes git hooks, specifically the commit-msg hook client-side, and the pre-receive hook server-side.

I've been using NetworkManager for some time now, and appreciate how easy it makes both connecting to wifi as well as VPNs. That said, I've had an issue with it that I only resolved today.

When working from home, I prefer to use a VPN split tunnel setup -- I'm behind a firewall all the time, and it's useful to be able to run virtual machines while still connected to my VPN (e.g., when doing training or webinar sessions). However, I noticed some months ago that this wasn't working. I assumed at first it was a change in our network setup, but others reported that the split tunnel was working fine. It's been particularly problematic when on IRC -- if the VPN drops, I lose my IRC connection, meaning I have to re-connect and re-claim my nick.

So, I did some searching, and found an interesting setting. In NetworkManager, "Configure..." then "Edit" your VPN connection, and navigate to the "IPv4 Settings" tab. Once there, click the button that says "Routes..." and select the checkbox next to "Use this connection only for resources on its network". Press Ok to close the dialog, then "Apply" to exit out of the VPN configuration. Re-connect to the VPN, and you should be all set.

Note: this will only work if your VPN server is configured to allow split tunnels. Additionally, only do so if you are behind a firewall. Practice safe networking.

I use Linux on the desktop (currently Ubuntu), but occasionally need to use Windows for things like webinars, OS-specific testing, etc. I started using VirtualBox for virtualization around six months ago, and have been reasonably satisfied; Windows boots quickly, and everything "just works." That is, until yesterday.

I was given a linux VM image running a web server and some applications I needed to review. On top of that, I needed to do so over WebEx, so that I could share my screen with somebody else. This meant I needed the following to work:

1. Internet access for my Windows VM
2. Access to my linux VM from my Windows VM
3. Ideally, access to both guest VMs from my linux host
4. Ideally, internet access for my linux host

My good friend, Rob, hosts my site for me, in return for helping with server maintenance. After being on Gentoo for the past three years, though, we decided it was time to switch to something a little easier to maintain, so last night we wiped the system partitions and installed Ubuntu server.

I'll say this: the setup is much faster! However, we had a few gotchas that surprised us -- it didn't setup our RAID array out-of-the-box, which led to a good hour of frustration as we tried to verify that the install wouldn't wipe it, and then to verify that we could re-assemble it. (We succeeded.) Additionally, we second-guessed a few things we shouldn't have, which led to needing to back out and reconfigure. But what was over a 12 hour install with Gentoo we accomplished in a matter of a few hours with Ubuntu server -- so it was a huge success that way.

Unfortunately, our mysqldump of all databases... wasn't, a fact we discovered only after importing it into the new system. I ended up losing my blog database and PEAR channel database. Fortunately, the PEAR channel has not changed at all in the past year, so we had an old backup that worked, and I had a snapshot of my blog database from three weeks ago I was able to use. As a result, there are a few missing entries, but for the most part, all works. If you commented on one of those missing entries, my apologies.

Now that the install is done, I'm also finalizing some design changes to my blog -- it's time to leave the black and white for more colorful grounds. Look for a revamp in the coming weeks!

In an effort to debug issues on a cluster, I was trying to determine which machine on the cluster was causing the issue. My idea was that I could insert a header token identifying the server.

My first idea was to add the directive 'Header add X-Server-Ip "%{SERVER_ADDR}e" in my httpd.conf. However, due to the nature of our load balancer, Apache was somehow resolving this to the load balancer IP address on all machines of the cluster -- which was really, really not useful.

I finally stumbled on a good solution, however: you can set environment variables in apachectl, and then pass them into the Apache environment using the PassEnv directive from mod_env; once that's done, you can use the environment variable anywhere.

In my apachectl, I added the line "export HOSTNAME=`hostname`". Then, in my httpd.conf, I added first the line "PassEnv HOSTNAME", followed by the directive 'Header add X-Server-Name "%{HOSTNAME}e"'. Voila! I now had the hostname in the header, which gave me the information I needed for debugging.

Early in the week, I decided to avoid the release rush and go ahead and update my laptop to Ubuntu's Gutsy Gibbon release. Overall, it's quite good, with one caveat I'll elaborate on later.

A little over a year ago, I stopped using Linux as my primary desktop due to the fact that a number of programs we were using were Windows dependent. Despite getting coLinux running, I've never been completely satisfied with the setup. I missed being able to paste with my middle-mouse button, and I was constantly having character encoding issues pasting back and forth between PuTTY and windows apps, couldn't access mail easily between my coLinux and Windows partitions, and overall felt that I was losing out on some productivity by not having a native linux environment as my primary OS.

Last week, we had an infrastructure change at work, and I basically realized that my Windows + coLinux setup was going to get in the way of productivity -- and that, at this point, there were now Windows applications tying me to that OS. So, I decided it was time to go back to Linux.

As I've written previously, I use coLinux in order to have a Linux virtual machine running on my Windows XP install. It runs Debian unstable (SID), which gives me all apt-geet love I could want.

Except when an apt-get based install goes bad, that is, like it did Saturday evening. This is the tale of how I got it back up and running.

I wrote earlier of my experiences using Windows XP, a move I've considered somewhat unfortunate but necessary. I've added a couple more tools to my toolbox since that have made the environment even better.

I've been cobbling together a system at work for the last couple months to allow a single place for changing all network passwords. This includes a variety of database sources, as well as passwd files and smbpasswd files. I've been making use of PEAR's File_Passwd and File_SMBPasswd, and they've greatly simplified the task of updating passwords for those types of systems. However, I've encountered some issues that I never would have expected.

I have the web user in a group called 'samba', and I have the smbpasswd file owned by root:samba. I then set the smbpasswd file to be group +rw. Simple, right? The web user should then be able to update the smbpasswd file without a problem, right? Wrong.

I kept getting errors, and on investigation continually found that the smbpasswd file permissions had reverted to 0600 -- i.e., only the root user could access it. I tried using 'chattr -i' on the off-chance that the file had been made immutable (which didn't make sense, as I was able to see the permissions change). No luck.

Based on observations of when the permissions reverted, it appears that the various SMB processes will reset the permissions! An example is when someone attempts to mount a resource from the server; this accesses the smbpasswd file to perform authentication -- and at this point the file permissions change. I can find no documentation to support this; these are simply my observations.

So, to get around the behaviour, I created a script that will set the file permissions to what I want them, and then gave sudo privileges to the samba group for that script. This script is then called via system() in the update script just before processing.

It's a hack, and could be made more secure, but it works.