We just started a project for a client that involves Cassandra.

If you’ve been living under a rock and don’t know what Cassandra is let me tell you :)

Cassandra is a “second-generation distributed database” that was built for web scale. Its is one of the many distributed nosql databases that appear everywhere lately like mushrooms after a heavy rain :).

What sets Cassandra apart is that it comes from a recognizable entity - Facebook.

But I digress. This is not meant to be a Cassandra introduction, there are enough of those on the net. I Just created a new nosql section on this blog where I’m going to post various tidbits of information about cassandra (and probably others) as I learn them while working on this new project.

Here is the first one:

Cassandra gem is just an installer

If you are on Mac OSX and interested in Cassandra you probably know that its just a gem installation away (almost):

gem install cassandra

First thing to note though is that this will not install Cassandra. It will install cassandra installer! I got bitten by this when I took my laptop with me to my doughter’s dancing class. You see, parents are not allowed “in the room” to not interfere with the process :), so I have 45 minutes to find myself something to do each time. I installed cassandra gem at home and intended to play with Cassandra while there. Not so fast. When I run cassandra_helper cassandra which is supposed to start a test cassandra instance it went to connect to a github repository to download and install the actual database. Duh!

and the 2nd one:

Use java preferences

When I got back and finally built Cassandra I got the following message when starting it for the first time:

~ > cassandra_helper cassandra
Set the CASSANDRA_INCLUDE environment variable to use a non-default cassandra.in.sh and friends.
(in /Library/Ruby/Gems/1.8/gems/cassandra-0.5.6.2)
You need to configure your environment for Java 1.6.
If you're on OS X, just export the following environment variables:
  JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home"
  PATH="/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin:$PATH"

First thing to note is that just typing JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home" in the terminal wont help. You need to export it:

export JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home"
PATH="/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin:$PATH"

No need to export PATH as its already exported.

But there is a better and simpler way!

Start “Java Preferences” (find it in /Applications/Utilities, or just use spotlight):

Then reorder the entries in the bottom “Java Applications” section so that Java 6 will be the 1st:

Now cassandra starts right away w/o any exports:

~ > cassandra_helper cassandra
Set the CASSANDRA_INCLUDE environment variable to use a non-default cassandra.in.sh and friends.
(in /Library/Ruby/Gems/1.8/gems/cassandra-0.5.6.2)
CASSANDRA_HOME: /Users/vitaly/cassandra/server
CASSANDRA_CONF: /Library/Ruby/Gems/1.8/gems/cassandra-0.5.6.2/conf
Listening for transport dt_socket at address: 8888
...

Cool, now go write your killer application!

I just did something pretty stupid. I edited /etc/sudoers file directly from within my non-root user account.

I did

sudo vim /etc/sudoers

and added the following to it:

Cmnd_Alias GEM_INSTALL = /usr/bin/gem install *
Cmnd_Alias GEM_UNINSTALL = /usr/bin/gem uninstall *
vitaly ALL=NOPASSWD GEM_INSTALL
vitaly ALL=NOPASSWD GEM_UNINSTALL

The intention was to grant myself permissions to install gems w/o entering password. I know its insecure, but this is security-vs-convinience kind of thing and I only intended to leave it there for a couple of hours while I do some heavy gem development.

Anyway, experienced unix users might have spotted the syntax error in my sudoers edits. I forgot the “:” just after the NOPASSWD. But the problem is even more basic then that. I shouldn’t have beed editing the file directly. I should have known better. And now I’m paying the price:

$ sudo
>>> sudoers file: syntax error, line 36 <<<
>>> sudoers file: syntax error, line 37 <<<
sudo: parse error in /private/etc/sudoers near line 36

$ sudo vim /etc/sudoers
>>> sudoers file: syntax error, line 36 <<<
>>> sudoers file: syntax error, line 37 <<<
sudo: parse error in /private/etc/sudoers near line 36

OOPS!

Now the sudoers file is broken and I can’t even fix it since I was using sudo to edit it! Never do that! :) Use the visudo command. it will check the file syntax before ‘commiting’ it.

Now what?

I looked at the net and the general consensus is that you need to boot into a single-user mode to fix it. I really really didn’t want to do it. I have 4G of RAM and so I’m usually running dozens of programs and its a pain to close and reopen them all after boot. I’m lazy :)

Then I thought there might be a better way.

First I checked the permissions on the sudoers file:

$ ls -l /etc/sudoers 
-r--r-----+ 1 root  wheel  1302 Sep 28 17:20 /etc/sudoers

and only ‘root’ is in the group wheel, so no luck here.

I also couldn’t ‘su root’ since my root user doesn’t have a password. duh!

But then it appeared to me that I might be able to circumvent this protection by leveraging my OS X ‘admin’ status. After all it ought to count for something :).

I opened “/etc” folder in finder (“Go” -> “Go to Folder…”), then opened sudoers file properties. Opening the lock there doesn’t require to be a root. Its enough to be an Admin and my Admin user does have a password! So I was easily able to grant myself permission to edit the file:

after that I just edited the file with vim again to comment the edits

vim /etc/sudoers

Then I did what I was supposed to do from the beginning, I used the ‘visudo’ at last:

sudo visudo

Last thing was to restore original permissions on the file in finder.

DONE

RRDtool is the OpenSource industry standard, high performance data logging and graphing system for time series data. Use it to write your custom monitoring shell scripts or create whole applications using its Perl, Python, Ruby, TCL or PHP bindings.

Let’s run it with Ruby on Leopard.

We recently moved our DNS to dnsmadeeasy.com from godaddy.com name servers.

After the transfer some internal CNAME records had a problem. So after fixing the problem and checking in the terminal that the changes propagated to the DNS server (host xxx.astrails.com) I tried to type the address in the browser, but it kept giving me the “can’t find host” error.

The solution was to flush OSX built in DNS cache (apparently the ‘host’ utility bypasses it, and browsers do not).

Fortunately it is very easy to do:

• On Leopard: dscacheutil -flushcache
• On Tiger (didn’t check it, no tigers here :): lookupd -flushcache