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 Ubuntu category. Clear

Ubuntu To Switch to Systemd As Default Following Debian Decision

by Ben

Ubuntu To Switch to Systemd As Default Following Debian Decision | OMG! Ubuntu!.

In news few of us would have dared to predicted: Ubuntu is to switch to the ‘Systemd’ init system after years of using home-grown rival ‘Upstart’.

You know Ubuntu as an operating system. Mandela knew it as his life’s mission.

by Ben

You know Ubuntu as an operating system. Mandela knew it as his life’s mission.

Yet the system’s name didn’t spring from nowhere. It’s inspired by a notion that’s even less tangible than a bunch of ones and zeroes; it describes, Obama said, the extent of Mandela’s compassion.

There is a word in South Africa — Ubuntu, a word that captures Mandela’s greatest gift: His recognition that we are all bound together in ways that are invisible to the eye; that there is a oneness to humanity; that we achieve ourselves by sharing ourselves with others, and caring for those around us. … He not only embodied Ubuntu, he taught millions to find that truth within themselves.

Maid v0.3.0 release!

by Ben

I released Maid v0.3.0 yesterday, after using Maid v0.3.0 Beta 1 for over a week myself. It was also downloaded 36 times, without any known bugs reported by beta test team.

From the change log:

I did have to make some expected changes from move to rename, however, but the warning messages for that show the new usage pretty clearly:

skipping move because foo is not a directory (use 'mkdir' to create first, or use 'rename')

Otherwise, work is progressing on the next version of Maid also. Hopefully there will be another beta soon.

But in the meantime, Maid v0.3.0 has already been downloaded 62 times. If you haven’t already given it a try, maybe Maid can help you with your spring cleaning… :)

Enjoy!

Is an iPad Mini or a Nexus 7 Better for a Geek?

by Ben

Some people have recently asked me about switching from an iPad to a Nexus 7. Did I have to give anything up? Am I still happy with the choice?

My conclusion: Nexus 7 is the better choice for geeks over an iPad. Of course, I think it’s a good choice for non-geeks too. :)

I like my Nexus 7 a lot. In most ways, it seems comparable to an iPad Mini (I had an iPad 2). There are some gotchas, especially if you’ve already invested in the iOS ecosystem. In my case, I felt the difference in price ($429 for a 32GB iPad Mini vs $249 for a 32GB Nexus 7) and features I wanted made up for that. Having used both, I would definitely still choose the Nexus 7 over an iPad. Whether it makes sense for you will depend on your use case. I’ve also read that Android devices are quickly becoming the better choice for anyone under 35 or so. I don’t know if that’s true, but my argument fits in with that pattern.

The Nexus 7 isn’t perfect. Most of the reviews (e.g., CNET’s) are pretty spot on, but these are some observations I’ve had that you might not hear elsewhere. They’re coming from a geek’s perspective with about 2 months worth of Android usage. I’ve been using iOS since 2008.

Pros

Cons

I hope this list helps out another geek who’s considering making the switch, especially if you’re the kind of person who cares about the types of things I noted. Like I said, I’ve been happy with my choice so far.

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)

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.