Use mod_rails with Freebsd 7.0

Man, been a while but i forgot how much i hate FreeBSD. Reminds me of the old days where solaris refused to ship their OS with a compiler or a decent shell, or require you to update /etc/nsswitch.conf to use DNS. Oh wait they still they do that with Solaris 10.. Ok, sorry tangent.

So if you need to compile mod_rails (aka passenger) on FreeBSD 7 with apache 2 and you used the default port install then you need to recompile with

make USE_THREADS=yes

and you will avoid that very nasty "Bus Error (core dumped)"

The other option is to use the Worker MPM and you should be good as well. I still cant mod_proxy to work but thats another issues.

Fun times.

Run db:migrate in jruby from warfile

If you have production servers running jruby/rails applications packaged as war files and dont actually have the full jruby installed to run your migrations, you can follow these steps. This will allow you to run db:migrate without a jruby installation on your java application servers

Assuming you are deploying your app called 'myapp' into tomcat5, you would have a warfile located in $CATALINA_HOME/webapps/myapp.war. if your war is not unwar'd you can run "jar xvf myapp.war" to generate the unwar'd directory of your app (which you will need)

# cd $CATALINA_HOME/webapps/YOURAPP/WEB-INF
# export GEM_HOME=$CATALINA_HOME/webapps/YOURAPP/WEB-INF/gems
# cp $YOUR_REPISTORY/Rakefile .
# mkdir -p db/migrate
# cp $YOUR_REPISITORY/db/migrate/* db/migrate
# java -jar lib/jars/jruby-complete-1.3.1.jar -S rake db:migrate


Thats it.

GemFire RubyGem (activesupport-gemfirecache)

So i finally got around to building my first Ruby gem, activesupport-gemfirecache. Its with a very cool distributed memory fabric called Gemfire. Its a java based distributed cache application, which has a fairly easy to use Java API. Since we are using Jruby/Rails I thought it would be an interesting project to try to build a custom Rails Cache store that can be used natively from within Rails. This is one of the real nice things about JRuby, is being able to call native Java libraries.

So I finally got version 0.0.5 out and so far it seems to work !

>> Rails.cache.region.getName
=> "RubyGemFireCacheStore"
>> Rails.cache.write('test1','adam1')
=> true
>> Rails.cache.read('test1')
=> "adam1"

Check it out here http://github.com/denen99/activesupport-gemfirecache

UUID with ruby/jruby on solaris

So, it turns out the default behavior of the uuid gem for UUID generation on solaris relies on "ifconfig" to use the MAC address as part of the random UUID seeding. This is the default behavior of the uuid gem which includes the macaddr gem. The issue is that the command "ifconfig" by itself on solaris does not work. A few things I found en route to this.

Firstly the uuid gem has the following line inside the initialize block

@mac = Mac.addr.gsub(/:|-/, '').hex & 0x7FFFFFFFFFFF

This references the macaddr gem which has the following line in it.

cmds = '/sbin/ifconfig', '/bin/ifconfig', 'ifconfig', 'ipconfig /all'

Besides not even referencing 'ifconfig -a' which is the only command that works on solaris to get the info they are after, by default solaris doesnt show the mac address so you need to pull the IP out and then filter it from the ARP table, eek. I found this link off of the Joyent website that shows how to do this if you *really* want to override initialize and pull the MAC out (http://rubyforge.org/tracker/index.php?func=detail&aid=5220&group_id=914&atid=3591)

After some research it turns out there is a much simpler solution for solaris and ruby users. Install uuidtools instead of uuid. Then instead of the old UUID.new, etc just call UUID.random_create with the new gem. This prevents any gem overriding or hacking of gem libraries, or to be honest, even using the mac address at all.

One caveat, since both gems use the UUID constructor, you cant have both loaded or things go absolutely bonkers. So if you have both gems "required" anywhere, make sure you only require one in your app.