Skip to main content

Benjamin Oakes

Photo of Ben Oakes

Hi, I'm Ben Oakes and this is my geek blog. Currently, I'm a Ruby/JavaScript Developer at Liaison. Previously, I was a Developer at Continuity and Hedgeye, a Research Assistant in the Early Social Cognition Lab at Yale University and a student at the University of Iowa. I also organize TechCorridor.io, ICRuby, OpenHack Iowa City, and previously organized NewHaven.rb. I have an amazing wife named Danielle Oakes.

Filtering for the month October, 2012. Clear

We’re certain it’s a nice town…

by Ben

I’m certain that was meant to sound nice…

…but honestly, the way that’s worded rubs me in the wrong way. It’s a little odd that they say this same message for any given location.

We're certain it's a nice town, but at the moment there are no Microsoft Stores near you.

We’re certain it’s a nice town, but at the moment there are no Microsoft Stores near you.

database configuration does not specify adapter

by Ben

From an answer I wrote for StackOverflow:

Another possible cause:

In Rails 3.2.x, establish_connection has a default argument set from the environment:

From connection_specification.rb:

def self.establish_connection(spec = ENV["DATABASE_URL"])
  resolver = ConnectionSpecification::Resolver.new spec, configurations
  spec = resolver.spec

The way ConnectionSpecification::Resolver works depends on ENV['DATABASE_URL'] giving a nil if not set. (Normally, it would be something like postgres://...).

So, if you happen to have misconfigured DATABASE_URL such that ENV['DATABASE_URL'] == '', that will give you database configuration does not specify adapter.

Maid presentation

by Ben

Since I wasn’t able to make it to the newhaven.rb meetup, I ended up presenting about Maid at ICRuby today. I was happy there was quite a bit of interest.

I thought I’d share my (quick and dirty) slides and example scripts I created for the presentation. There’s no audio (besides the Ruby5 story), but you should be able to get a good sense of what I presented.

There were lots of good questions (which I wish I had written down), including how to use it with iTunes, how to use it as a replacement for logrotate, how I was using Vagrant for testing, how to automate more than set of rules, etc.

View the slides (or get the source markdown)

Thou Shalt Not Park Here

by Ben

Seen behind the Trinity Episcopal Church, downtown Iowa City.

20121021-192829.jpg

Keep Calm and Vote Early

by Ben

Seen downtown today.

Obama Keep Calm and Vote Early

Debugging rsyslog and logrotate

by Ben

Takeaway: Debugging rsyslog and logrotate is easier when using Vagrant and logrotate‘s debug switch (-d).

I’ve been getting my hands greasy with more involvement in Ubuntu server maintenance lately, so I thought I’d share some of my experiences with debugging rsyslog and logrotate.

We’re using an EC2 instance running Ubuntu 12.04 (Precise Pangolin) to receive syslog packets from Heroku and elsewhere. They’re received with rsyslog, and we’re using logrotate to rotate and compress the log files. We’re being a little lazy right now and just letting everything go into /var/log/syslog. So far, that’s been a good choice as the machine only handles log aggregation. Most of the setup is similar to what Heroku recommends.

My first bump in the road was that which Ubuntu 12.04 doesn’t give rsyslog port 514 (the standard syslog port), unlike Ubuntu 10.04. This is because 514 requires root privileges. As a result, the port has to be above 1024, so I chose 1514 to make it easier to remember and know its purpose. It’s not completely clear why Ubuntu changed rsyslog to run under its own user (I would guess security reasons), but there is a bug report which helped me figure this out.

Following that I ran into an issue with getting logrotate to rotate the log files in the way we wanted. We decided that storing 30 days worth of logs, marking the rotation with the date, and compressing older logs would be best for our needs. It sounded easy enough to configure after looking at man logrotate and /etc/logrotate.conf. But it didn’t work! No matter what I tried, only 7 days of logs were retained, although compressing and adding a date extension worked fine.

It turned out to be a simple problem, but it’s more important to know how to debug these problems, I think. Below is what I did.

You probably don’t want to debug configuration problems directly on your production instance, or even on a staging instance. To develop the changes locally, I found that the easiest solution was to use Vagrant. They provide a precise64 box which was perfect for my needs:

vagrant box add precise64 http://files.vagrantup.com/precise64.box

From there, you can test logrotate with the -d switch. Point it to your configuration file and then see what it says it will do:

logrotate -d /etc/logrotate.conf

The problem behavior was clearly visible in the output; /var/log/syslog was only being kept for 7 days. Changes to /etc/logrotate.conf did not make a difference for the rotation count (but I could change to doing dateext). Around that time, started poking around in /etc/logrotate.d/, where I found /etc/logrotate.d/rsyslog.

This is the original configuration for /var/log/syslog:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

After that point, it was simple to try my changes and retest using logrotate as above:

/var/log/syslog
{
        rotate 30
        daily
        # NOTE: `dateext` means you can rotate at **most** once a day.  Be cafeful setting it globally.
        dateext
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

The debug output then showed it would retain the logs for 30 days. Great! It was then a simple matter of installing the same configuration in production.

While the result is important, I think the bigger takeaway is a process I can use in the future. With Vagrant and logrotate -d /path/to/conf in hand, future configuration changes are easier to develop, test, and deploy.

Sharing is Caring

by Ben

I’m what you might call an “Iowa City enthusiast”. As residents, we are extremely fortunate to be surrounded by an incredible number of people who work every day to make this a better place to live.

Even so, Iowa City has its blemishes. When I first relocated to study at the University of Iowa, I was taken aback by how hard it is to use a car here. Where I used to live, I was used to driving everywhere and not having to worry much about parking. Iowa City has a famously pedestrian downtown and it can sometimes be at odds with car ownership in general.

But we all have places to be, don’t we? Cars give an amazing sense of freedom and independence, but as many have found, they also can be amazingly expensive and often inconvenient.

I’m a big fan of sharing and pooling resources. Not only is it a great way to save money, but it’s also a great way to reduce the number of things you have to worry about, and even to meet amazing people. I ride our buses; I borrow from our amazing city and university libraries; I enjoy our parks, trails, and recreation; I shop at a community-owned grocery store; I work out of a coworking space; I work with community-maintained software; and I am an open source software developer who gives back to that community. I’m also fortunate enough to be married to an amazing woman with whom I’m incredibly happy to share my life.

I just moved back to Iowa City, after living in New Haven, CT because of a job at the Yale School of Medicine. While I was there, I was happy to find a great car-sharing service called Zipcar that included a Yale-subsidized membership. I even lived there for a year without owning my own car. When we decided to move back, I was happy to learn that Zipcar was coming to Iowa City soon after we arrived. If only it had been here when I was a student!

I still work for a company based out of New Haven, CT (they’ve been gracious enough to let me work remotely from Iowa), and I often travel for work and open source conferences. It’s great to know that I have a car waiting for me downtown Iowa City if I need it, in New Haven two blocks from my office, in Philadelphia and New York if I get stuck, and in many cities where I might visit. That’s not bad for a small yearly membership fee and then $8/hr. That price includes gas, maintenance, and auto insurance too.

(Sound interesting? I have a promo code for $25 in free driving when you join Zipcar.)

We do still own a car, but with Zipcar and everything else Iowa City has to offer, we’ve been able to delay the purchase of another. That helps reduce traffic congestion in Iowa City, saves us money, reduces our environmental footprint, and reduces the number of car related headaches we have. To me, that’s a great example of a win-win scenario.

Creative Commons License
Sharing is Caring by Benjamin Oakes is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

How the Internet will (one day) transform government

by Ben

I’ve seen some of the experimenting that people have done with bringing legal code (i.e., laws) to GitHub. As an open source developer, I think Clay has it right when he says that transparency is only one side of openness and that citizen created bills are (hopefully) inevitable. After all, our government is too important to leave exclusively to politicians.

Or, you know, the Internet will just be a place we go to see funny pictures of cats. It’s what we make of it.

Update: Just as an experiment, I made a repository for the laws of Iowa because I couldn’t find an existing one. I’m experimenting to see if any others are interesed as well, based on star count or contributions.

Video: Clay Shirky: How the Internet will (one day) transform government