Adding CodeHighlighter to Typo

Recently, I ran across CodeHighlighter by Dan Webb. This looked like a pretty cool javascript, and I thought a better way than to do it on the server side.

Adding it to typo is fairly straightforward, baring a small patch.

Get the code

Get it from Dan’s site via subversion: http://svn.danwebb.net/external/CodeHighlighter/trunk

svn co http://svn.danwebb.net/external/CodeHighlighter/trunk

Adding CodeHightlighter to your template

Add to your template (themes/[YOUR THEME]/layouts/default.rhtml)

<%= javascript_include_tag "code_highlighter" %>
<%= javascript_include_tag "javascript" %>
<%= javascript_include_tag "css" %>
<%= javascript_include_tag "html" %>
<%= javascript_include_tag "ruby" %>

The code as provided by Dan has a small incompatibility with prototype used by Ruby on Rails. The following line

for (var i in this.styleSets) highlightCode(this.styleSets[i]);

behaves quite strangely and will pretty much kill your browser (Firefox runs out of memory and displays a bunch of “undefined” after several minutes) because it ends up calling hightlightCode way too many time because of all the methods added to all objects.

To make codehighlighter.js play nicely with prototype.js, replace that last line with:

if (this.styleSets.each) {
  this.styleSets.each(highlightCode)
} else {
    for (var i in this.styleSets) {
      highlightCode(this.styleSets[i]);
    }
}

Essentially, if prototype is present, we can use each to iterate on the styles, otherwise it is safe to used the old code.

Using Codehightlighter

Now, addng styling is easy. Using Textile, you can just put your code around a <pre> and a <code> block. If you have a javascript snippet, use a class of “javascript”.

For example:


<pre><code class="javascript">
if (this.styleSets.each) {
  this.styleSets.each(highlightCode)
} else {
    for (var i in this.styleSets) {
      highlightCode(this.styleSets[i]);
    }
</code></pre>

The other available styles are “html”, “css” and “ruby”.

For example, here’s how ruby would look like:

  def display_article(article = nil)
    begin
      @article      = block_given? ? yield : article
      @comment      = Comment.new
      @page_title   = @article.title
      auto_discovery_feed :type => 'article', :id => @article.id
      render :action => 'read'
    rescue ActiveRecord::RecordNotFound, NoMethodError => e
      error("Post not found...")
    end
  end

And it looks easy to create other styles. See the stylesetguide.html file for details.

Update: Turns out Dan already had a fix, so if you grab the trunk, you will be fine.

Here’s his version of the patch:

    for (var i=0; i < this.styleSets.length; i++) {
        highlightCode(this.styleSets[i]);
    }

Dreamhost router upgraded

DreamHost just completed the replacement of their main router and everything seems to be back to normal, hopefully for good.

If you’ve experienced some bumpy turbulences on this site over the past 4 days, please accept my apologies. This should not happen anymore.

Thank you DreamHost for keeping things mostly afloat while waiting for the new hardware and keeping us informed along the way. That helped!

in News | 65 Words

Install your own ruby on a shared host

Since I upgraded to Typo 4.0, and in the process rails 1.1.6 I have had a few occurrences where nanoRAILS would hang, several bloated processes would be sitting there and not respond, and the only option at that point was to kill all ruby processes once I realized what was happening, which could be several hours. Suffice it to say, this is not a good option.

So after struggling during last rails upgrade to 1.1 on my host, the next logical step is to also use my own version of ruby so I can have better control on its environment, and even apply patches if necessary.

The following steps apply on a lot of systems. More specifically, my host is DreamHost (aff), and as best I can tell, I’m on a host with Debian Sarge.

Build your own Ruby

Download ruby from http://www.ruby-lang.org. The latest version is currently ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.4.tar.gz

Create the makefile using

 ./configure prefix=[YOUR_OWN_RUBY_PREFIX]

Since you most likely don’t have root access, you need to override where ruby think it resides, and the way to do that is to set the prefix to somewhere into your home directory. Something like /home/USERNAME/ruby for example. From that point on, libraries, other builtin ruby files, gems will automatically install into your own ruby repository so you never have to worry about getting in trouble with an unforeseen upgrade.

Optionally, you can apply the patch used by Railsbench, with hardcoded default values because I haven’t figured how to set the environment variables for the dispatch.fcgi process (since apache in my case determines that). Download my version of rubygc.patch .

 patch gc.c rubygc.patch

Build and install ruby

 make
 make install

Additionally, so that the command line uses the same version of ruby, add this to your .bashrc or equivalent for your shel.

export PATH=[YOUR_OWN_RUBY_PREFIX]/bin:$PATH

Install your own gems

Now you are ready to install your own gems. Here’s the bare minimum you need.

First, install rubygems

 wget http://rubyforge.org/frs/download.php/11289/rubygems-0.9.0.tgz
 tar xzvf rubygems-0.9.0.tgz
 cd rubygems-0.9.0
 ruby setup.rb

Then install the minimum set of gems:

 gem install mysql
 gem install fcgi
 gem install rails --include-dependencies

Now, the only thing you need is to change the path to ruby in your dispatch file (dispatch.rb for mod_cgi, dispatch.cgi for regular cgi, and dispatch.fcgi for FastCGI/fcgid)

Typically, replace

#!/usr/bin/env ruby

by

#![YOUR_OWN_RUBY_PREFIX]/bin/ruby

Replace [YOUR_OWN_RUBY_PREFIX] by your own value you used earlier.

Upgraded to Typo 4.0

Well, the upgrade to Typo 4.0 didn’t go so well. No data loss though, so everything’s cool.

At least most pages seem to be functional, so this is not so bad. Combined with having custom sidebar plugins that no longer work, the fact that the merge between the new code and my old one did not quite go as planned, it was not a too pleasant (most of it my own fault I guess).

Anyway, it is getting really late and I’ll finish the rest of the migration tomorrow.

If you tried to access the site while this was going on and you were inconvenienced, pleas accept my most sincere apologies!

If you notice anything weird, please send me a mail at psq _at_ nanorails _dot_ com.

Update, about 20h later, some sleep…: It seems that everything is back up, I migrated my custom plugins to typo 4.0 (about removing 1 file, removing half of the code linked to configuration and adding a few lines) and it seems that everything has been working smoothly :)

And the best of all of that: no more trackback spam! Well, not that it went away, it caught about 25 since last night, but they don’t get published anymore. Just for that, it was all worth it. Thank you everyone in the typo team!

Update 2: Well rails 1.1.5 came out, and it was not enough, so rails 1.1.6 came out and seems to be strong enough to fill in the security issues

And in the process, I also upgraded to Typo 4.0.2

That last upgrade went very smoothly!

However, I’ve had a few annoying cases of nanoRAILS hanging and not responding for hours on hand till I killed the processes. I don’t know yet at this point whether it is due to the new version of rails, the new version of typo, or pehaps some settings that changes on dreamhost. In any case, I’ve installed my own version of ruby and the full set of gems, so we’ll see if that helps!

Rails Documentation Drive

Court3nay from ~:caboose has started a fundraising to be able to pay professional tech writers to beef up the Rails documentation. It is true that it is not advancing quite at the same pace that rails is and Court3nay’s initiative is a worthy one.

He’s aiming to raise $5,000 and after just a few hours he has reached half his goal.

If you enjoy Rails, please consider making a small donation, $10, $20, or whatever you can spare. That’s an investments that is sure to provide a return! So please help.

Fund the Rails Documentation Drive.

Update: the total is now $13,310, from 94 contributors, in less than 24 hours. Thank you everyone that contributed! This is going to help improve the doc a great deal!

RadRails is switching to Ruby-debug

According to Kyle, one of the tireless developer of Rad Rails, he is working on incorporating ruby-debug.

For more details about ruby-debug, see my write up about it.

The command line is great, and there are times when you are working on a remote server where nothing else will do. But having the ability to set breakpoints at the click of the mouse, see your variables in a separate pane, see a lot more of your source code is something quite convenient.

And with the added speed of ruby-debug, this should make debugging in Rad Rails something you can’t afford not to use.

This is very welcome news and I look forward to use it!

A better Rails debugger: ruby-debug

Just a few days ago, Kent Sibilev quietly released an amazing little plugin with far reaching consequences: ruby-debug. This is a marked improvement over Ruby’s own rdebug. The major difference is that he removed the major slow down that impacted rdebug usability with Ruby on Rails so it is blazing fast.

Instead of using the Kernel#set_trace_func API, which makes it possible to implement a debugger in Ruby, but has a negative effect on the speed on your program execution, he uses a native extension with a new hook using the Ruby C API

For each trace call Ruby interpreter creates a Binding object, even though it is not being used most of the time. ruby-debug library moves most of the functionality of debug.rb to a native extension, this way significantly improving the execution of your program.

This means that watchpoints and the standard tracing facility are not supported, but I’m gladly giving that up for the comfort and speed. And if you are wondering how the speed is, that is really the difference between utter frustration each time you debug something to bliss!

Previously I covered some options for Debugging in Rails. This is going to become my preferred option by far, and I’m willing to bet this will become yours too. Why? Because you can see the source code of where you are, you can execute step while watching some or your variables, you can inspect of your variables (this you could do with breakpointer), you can use conditional breakpoints, you can get a list of expressions to be displayed every time you step. The downside compared to breakpointer? You can’t do it remotely, which in most instances, as best as I can tell, is not going to be a problem at all.

Installation

Ruby-debug comes as a gem so to install, just run:

sudo gem install ruby-debug

Make sure you chose the proper windows or ruby version depending on your platform.

Using ruby-debug

To use in your rails application, assuming you want this to only be available in development mode (this is not such a great idea to leave in in production mode, just in case you forget to remove the breakpoints, and also for performance reasons as I’ll explain in a bit)

In environement.rb add the following:

SCRIPT_LINES__ = {} if ENV['RAILS_ENV'] == 'development'

This line is important if you want to be able to see your source code. SCRIPT_LINES__ is an obscure feature of the ruby interpreter. If it is defined, it will store all loaded ruby file in a hash, which debug-ruby will use to display where you are in your source code. The only problem is that it can have some impact on performance, and worst of all, use up quite a bit of memory, which is not so good in production (hence the “if ENV[‘RAILS_ENV’] == ‘development'”). SCRIPT_LINES__ needs to be initialized as early as possible so it can capture all loaded ruby files.

To add a breakpoint, you will need to use:

require 'ruby-debug'
...
def your_method
  ...
  debugger if ENV['RAILS_ENV] == 'development'
  ...
end

Then start your app using webrick (it does not work with lighttpd and I have not investigated why just yet):

script/server webrick

When the code hits the breakpoint, you are in a console like mode (not unlike irb or script/console).

Ruby-debug commands

  • b[reak]
    list breakpoints
  • b[reak] [file|class:]LINE|METHOD [if expr]
  • b[reak] [class.]LINE|METHOD [if expr]
    set breakpoint to some position, optionally if expr == true
  • cat[ch]
    show catchpoint
  • cat[ch] EXCEPTION
    set catchpoint to an exception
  • disp[lay] EXPRESSION
    add expression into display expression list
  • undisp[lay][ nnn]
    delete one particular or all display expressions if no expression number given
  • del[ete][ nnn]
    delete some or all breakpoints (get the number using “break”)
  • c[ont]
    run until program ends or hit breakpoint
  • r[un]
    alias for cont
  • s[tep][ nnn]
    step (into methods) one line or till line nnn
  • n[ext][ nnn]
    go over one line or till line nnn
  • w[here]
    displays stack
  • f[rame]
    alias for where
  • l[ist][ (-|nn-mm)]
    list program, – list backwards, nn-mm list given lines. No arguments keeps listing
  • up[ nn]
    move to higher frame
  • down[ nn]
    move to lower frame
  • fin[ish]
    return to outer frame
  • q[uit]
    exit from debugger
  • v[ar] g[lobal]
    show global variables
  • v[ar] l[ocal]
    show local variables
  • v[ar] i[nstance] OBJECT
    show instance variables of object
  • v[ar] c[onst] OBJECT
    show constants of object
  • m[ethod] i[nstance] OBJECT
    show methods of object
  • m[ethod] CLASS|MODULE
    show instance methods of class or module
  • th[read] l[ist]
    list all threads
  • th[read] c[ur[rent]]
    show current thread
  • th[read] [sw[itch]] nnn
    switch thread context to nnn
  • th[read] stop nnn
    stop thread nnn
  • th[read] resume nnn
    resume thread nnn
  • p EXPRESSION
    evaluate expression and print its value
  • pp EXPRESSSION
    evaluate expression and print its value
  • h[elp]
    print this help
  • RETURN KEY
    redo previous command. Convenient when using list, step, next, up, down,
  • EVERYHTING ELSE
    evaluate

Happy debugging!

Installing Rails on Mac OS X Tiger

2/23/07 update: some things have changed since I wrote this page, either in MacOS itself, or the components referenced. So before you start, be sure to also check a recent update for 10.4.8 and the comments of both pages that contain some valuable information.
If something still does not work, please leave a comment and someone will help you.

I recently Switched back to a Mac, while other long time Mac users are switching to Linux. And I love every minute of it! Once I got the basic stuff going, it was time to install a fitting Ruby on Rails environment on my new iMac.

There are a number of approaches you can use (see the reference section at the bottom). I was after installing an environment as close as one you can use in production, but right here on my desk.

If you are only looking for the basics, Locomotive is probably what you need, if you want a grown-up rails setup on Mac OS Tiger, read on.

Choosing an install method

There are 3 approaches to installing Ruby on Rails on Mac OS Tiger.

You can use the one click approach, and Locomotive is probably the simplest. My main issue is that it is a bit too opaque and if you want to patch anything, upgrade one one the component, you might be out of luck.

You can use the “compile everything from source approach”, and Hivelogic covers this well. This is an approach you might prefer except that you may run into Mac specific issues not covered by typical Unix/Linux code

A third option is to rely on Darwin ports as covered by Evan with “a better way of building ruby, rails, lighttpd, mysql, and postgres on OS X tiger

This third method gets my vote: less opaque, but a large number of smart and dedicated people have already worked out all the problems.

So with that covered, let’s get on with that “grow-up setup” (thanks Coda!). Hmm OK, just one last word of warning before you begin. I’ve installed more than the bare minimum. If you follow these directions, you’ll be all set for standalone lighttpd , standalone mongrel, apache, rails with mongrel and a few more combinations. I haven’t got to using pound just yet, so we’ll keep this for some other time.

Installation on Tiger

If you have not installed Darwin port, now is the time.
Then update port itself

sudo port -d selfupdate

Fix the root path and set the PATH variable in /etc/profile. You may not need this is you are not going to run things as root. Although this will simplify a few things for you.

mate /etc/profile    #fill free to use vi or any other editor you&#8217;d like
PATH=&#8221;/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin&#8221;

Install Apache 2

sudo port install apache2

Create a default configuration for apache

cd /opt/local/apache2/conf
cp httpd.conf.sample httpd.conf

Start Apache

sudo launchctl load -w /Library/LaunchDaemons/org.darwinports.apache2.plist

Rebooting would do the trick too. At this point you should have a “It works!” if you point a browser to http://localhost

Install fcgi (not really going to use it, so it is a just in case so I can benchmark it at some point)

sudo port install fcgi

Install lighttpd

sudo port install lighttpd +ssl

Install mysql 5

sudo port install mysql5 +server

start mysql 5 (you can also reboot)

sudo launchctl load -w /Library/LaunchDaemons/org.darwinports.mysql5.plist

Change the mysql root password (on localhost AND on your network card)

/opt/local/lib/mysql5/bin/mysqladmin -u root password &#8216;new-password&#8217;
/opt/local/lib/mysql5/bin/mysqladmin -u root -h [HOSTNAME] password &#8216;new-password&#8217;

Check it works (empty password if you have not set it)

mysql5 -u root -p

Install subversion

sudo port install subversion +mod_dav_svn +tools

Install ruby and a few goodies

#ruby
sudo port install ruby
sudo port install rb-rubygems
sudo port install rb-termios
sudo port install rb-fcgi
sudo port install rb-mysql5
sudo port install imagemagick

Install Apache mod_fcgi module

sudo port install mod_fastcgi

add the following line to /opt/local/apache2/conf/httpd.conf

LoadModule fastcgi_module modules/mod_fastcgi.so&#8221;

Install gems you can’t live without

sudo gem install -y rake
sudo gem install -y rails
sudo gem install -y capistrano
sudo gem install daemons gem_plugin mongrel mongrel_cluster &#8211;include-dependencies
sudo gem install rmagick

One good gem to have would be sendfile to avoid copying data between apache and mongrel for example, but the Tiger kernel does not support it despite having the function defined in the C header files. So since it is not really a production machine, we can live without it.

At this point, you’ve got more that the basic setup for Ruby on Rails. That was no too bad, wasn’t it? Although arguably, this could be easier!

Deploying a rails application: Mephisto

For good measure, just to check that our setup is all good, let’s install Mephisto. The latest Rails blog engine.

Create the databases

mysqladmin5 -u root create mephisto_development
mysqladmin5 -u root create mephisto_test
mysqladmin5 -u root create mephisto_production

Checkout everything

svn co http://svn.techno-weenie.net/projects/mephisto/trunk mephisto

Configure the database (should be the right default)

cd mephisto/config
cp database.example.yml database.yml
mate database.example #to check that the database name are what we created

Populate the database

rake RAILS_ENV=production db:bootstrap

And start. Since lighttpd is installed, that’s what it is using

script/server

Point your browser to http://localhost:3000 and yes! It works :D
Or you can go to http://localhost:3000/admin (using admin/test for user/password)

Now let’s finish our “grown up setup” and configure mongrel cluster

mongrel_rails cluster::configure -e production -p 8000 -a 127.0.0.1 -N3 -c [RAILS_ROOT of mephisto]

a few note on Capistrano

My initial Capistano Cheat Sheet should be enough with one exception. SSH is not enabled by default on Tiger. To enable, use the “Sharing” panel under System Preferences and enable “Remote Login”.

And second, if you have trouble when running via ssh, you may need to fix ssh PATH. To do that, create a file under ~/.ssh/environment with:

PATH=/opt/local/bin:/opt/local/sbin:/opt/local/apache2/bin:/bin:/sbin:/usr/bin:/usr/sbin

Run Mongrel Cluster as a service

Now let’s configure Mongrel Cluster to start at boot time

sudo mkdir /etc/mongrel_cluster
ln -s [YOUR RAILS_ROOT]/config/mongrel_cluster.yml /etc/mongrel_cluster/[your application].yml

Create a file ~/Library/LaunchAgents/mongrel_cluster.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Debug</key>
        <true/>
        <key>Label</key>
        <string>org.rails.mongrel.cluster</string>
        <key>OnDemand</key>
        <false/>
        <key>Program</key>
        <string>/opt/local/bin/daemondo</string>
        <key>ProgramArguments</key>
        <array>
                <string>&#8211;label=mongrel_cluster</string>
                <string>&#8211;start-cmd</string>
                <string>/opt/local/bin/mongrel_cluster_ctl</string>
                <string>start</string>
                <string>-v</string>
                <string>-c</string>
                <string>/etc/mongrel_cluster/</string>
                <string>;</string>
                <string>&#8211;stop-cmd</string>
                <string>/opt/local/bin/mongrel_cluster_ctl</string>
                <string>stop</string>
                <string>-v</string>
                <string>-c</string>
                <string>/etc/mongrel_cluster/</string>
                <string>;</string>
                <string>&#8211;restart-cmd</string>
                <string>/opt/local/bin/mongrel_cluster_ctl</string>
                <string>restart</string>
                <string>-v</string>
                <string>-c</string>
                <string>/etc/mongrel_cluster/</string>
                <string>;</string>
                <string>&#8211;pid=none</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>StandardErrorPath</key>
        <string>/tmp/mongrel.log</string>
        <key>StandardOutPath</key>
        <string>/tmp/mongrel.log</string>
</dict>
</plist>

Additionally, if you did not want to modify /etc/profile, you can add:

    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key><string>/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin</string>
    </dict>

And finally, you can start mongrel cluster. or logging in will work:

sudo launchctl load -w ~/Library/LaunchAgents/mongrel_cluster.plist

To have it work at boot time, you will need to put mongrel_cluster.plist under /Library/LaunchDaemons instead.

References

lighttpd

http://duncandavidson.com/essay/2005/12/railsonlighty
http://duncandavidson.com/essay/2006/01/railsvhostingonlighty

Rails installation

rails with postgres on tiger using Darwin Ports
Lighttpd with rails on tiger
Time For A Grown-Up Server: Rails, Mongrel, Apache, Capistrano and You
Rails installation from single script
Locomotive, one click rails installer for Mac OS X

pound

pound + lighttpd + mongrel

10/17/06 update: I’ve reinstalled on a brand new system with Mac OS 10.4.8. See my notes on what has changed.

Remote Ubuntu Dapper Drake Install

Don’t try this at home!

Well, actually, there are 2 ways you can look at it. Only attempt a remote install if it is absolutely necessary and there are no other practical ways of doing the OS install. It may be fun, and you’ll be impressed with yourself if you succeed, but the downside is that it takes a lot more time to do it remotely, it can be pretty tough on your nerves while you wait for the machine to come back up, eventually, and that’s it ever does. I can imagine a lot of things going wrong…

On the other hand, that’s exactly what you want to do. Do it from home instead of driving to the office, or better yet, to some hosting facility way out somewhere.

Anyway, now you’ve been warned and if you are still reading, here’s the challenge I was facing.

I had a machine (not the fastest, but a machine) with an old version of Linux. So old the distribution is no longer updated, and I’m not really that familiar with it anyway. So I had been itching to reinstall either a version of Debian or a version of Ubuntu Dapper as my choice of late. Plan B is having to drive to the data center, extract the machine, take it back, do the install, drive back to the data center, reinstall the machine, … and Plan B was not something I was looking forward to.

So I did some research, and using Google, it is fairly obvious that the article by Erik Jacobson that you should read first if you want to attempt any remote install of debian is the authority on the subject. Read the HOW-TO.

I could not find anything on Ubuntu, however. And I even found a few reports of people upgrading from debian to Ubuntu having troubles, but mostly from XWindows stuff, but for a server, that’s not something I was interested in. And worst case, I’d be on my driving to that data center…

So I read the HOW-TO carefully, a few times to let it sink in, and got started on my Ubuntu Dapper Drake (6.06) remote install.

Here’s what I did.

I first followed the procedure in the HOW-TO to install debian. At some points, there are a few differences that I’ll highlight. Here are some notes I took while doing the install.

I used the rpm from [http://azhrarn.underhanded.org/debootstrap-0.2.23-1.i386.rpm]()

I used the swap partition as a new boot partition for debian.

The old distribution did not support journaling, so I only used (this is only the boot partition anyway, so journaling is not as important, and that one will be temporary anyway):

mke2fs /dev/hda6

NOTE: identify your volume names at the beginning, create a table to help you translate between what the HOWTO uses, what I use and your setup otherwise you might be in for some serious trouble.

debootstrap does not support sarge, so using woody was fine. The only thing we’ll be using the bootstrap is to get apt working.

Follow the steps till you reach the part where you get apt working. Then no need to bother with netselect (didn’t work for me), now is the time to do a bit of tinkering.

Edit /etc/apt/sources.list and replace it with:

vi /etc/apt/sources.list
deb http://us.archive.ubuntu.com/ubuntu/  dapper main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/  dapper main restricted

deb http://us.archive.ubuntu.com/ubuntu  dapper universe
deb-src http://us.archive.ubuntu.com/ubuntu  dapper universe

#deb http://mirrors.kernel.org/debian/ stable main non-free contrib
#deb-src http://mirrors.kernel.org/debian/ stable main non-free contrib
#
#deb http://debian.yorku.ca/debian/ stable main non-free contrib
#deb-src http://debian.yorku.ca/debian/ stable main non-free contrib
#deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free
#deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free
#
## deb http://security.debian.org/ stable/updates main contrib non-free
#deb http://security.debian.org stable/updates main contrib non-free

Next, proceed with the update and dist-upgrade, then install a kernel.

apt-get update
apt-get dist-upgrade
apt-cache search kernel-image

Find a 2.6 kernel for your system (unless you insist on using 2.4).

Then proceed back with the rest of the script, starting with the install of ssh.

To make sure ssh was configured properly, I configured it on a different port so I could try it before the first reboot. Having everything working, but not ssh would be real bad, so spending some extra time here is worth it.

And one thing you want to take the time to do is to setup a cron job that will reboot the new system after some time (say every 2 hours), as an extra insurance, in case something wrong happens. Here’s a possible line to add to your crontab to reboot every 2 hours:

00  */2 * * * /sbin/shutdown -r now

I did mess up once, and I was really glad to see the machine come back after a very long 2 hours or so (I had almost given up on it and was getting ready to plan B). The second insurance you can take is to setup the reboot on the new kernel as a temporary reboot (as explained in the HOW-TO), you might be glad you did.

Once your reboot is successful, it is a matter of replacing the main partition with ubuntu, do the second reboot, and voila! Phewww! Not something I’d like to do everyday, but I’m glad I did it once.

Now you have a very barebone version of Ubuntu Dapper and you can customize it any which you need.

Good luck on your remote install!

Installing Ubuntu Dapper on Parallels running on Tiger

After my success with installing Windows XP on my shiny new iMac, I tried to install Ubuntu Dapper (a.k.a. Dapper Drake). Why would I want to install Linux on a Mac? Because that’s what I’m running on my server, so I need a sandbox where I won’t risk breaking real stuff.

Anyway, I created a new VM, chose Linux as the Guest OS Type, and Debian Linux as the Guest OS Version (since Ubuntu is derived from Debian and was most likely the closest).

Next, I put a CD of the latest Ubuntu install (Server Version: 6.06). Using mostly the defaults all along, the installation went smoothly. The only part were I went fancy was to use LVM (Logical Volume Manager). Everything went smoothly till it was time to reboot the machine…

The reboot went fine till after it was done uncompressing the kernel. Then it froze! Ouch.

From there, it was a lot of testing of various options, versions of Linux, even redid a full install without LVM. Nothing made any difference! So, I went ahead and tried to install Sarge (Ubuntu 3.1). This went like a breeze and worked the first time around (after all, Parallels officially supports Debian). So I was feeling a bit better…

… and went on to do some more research. And read that some people had had some luck with the Live CD (I had used the server CD since I wanted a permanent installation). So after a little while the download was over, and I booted the LiveCD, and it worked! Hurray! Bring on the champaign… Hold on, we are not quite there, but keep it in a nice cool place… Just in case…

And after playing for a while, just starring at me on the desktop was an “install” icon, so I figured, just one more try would not hurt. I went through the installation, and was bracing myself for the freeze right after the kernel gets uncompressed, but lo and behold! It did not freeze. Wow! Home free at last.

Ok, yes, you can bring on the champaign now.

Not sure what’s different about the 2 installers, but I don’t think I’ll try to figure it out. If anyone knows, would you let me know, please?

Note: this is my first post done using TextMate Blogging Bundle, so this may have a few hiccups…
In case you were wondering what the xmlrpc URL is for typo, it is /backend/xmlrpc (Thank you Damien)