As usual, I have been bored (not that there’s a lack of things to do – but one requires stimulation – and not in the sexual kind of way, although I definitely wouldn’t say no), so I decided to look at Ruby on Rails.  Admittedly I’m probably a complete moron when it comes to looking things up, per se, but I battled to find decent beginner information on rails, and ruby and how everything fits together in the scheme of things. Sure, there are ruby tutorials, and rails tutorials, but I just couldn’t find anything that actually made sense to my warped frame of mind. I did quite a bit of googling, clicking on links from rubyonrails.org and ruby-lang.org, and reading of pages and such.  I even subscribed to some podcasts.

Eventually I figured out that Phusion Passenger was the correct way to run Rails applications on Apache, so I looked into installing that.  Unfortunately Phusion passenger requires apache2-mpm-worker which allows apache to use multiple threads. It completely replaces apache2-mpm-prefork, the default non-threaded model which the apache php5 module requires. And since everything on my web server is php based, this presented a problem. Fortunately it’s not a huge problem, as the workaround is to set up php5-cgi using FastCGI, which actually has more pros than cons. It’s definitely a better way to run php – the speed boost was definitely noticeable to me, and I didn’t pick up any issues with any of the sites.  Fortunately it didn’t take me too long to convert the sites to use FastCGI. Downtime was less than 5 minutes.

I then installed ruby, and rails from the stock repositories. Turns out this wasn’t a great idea, as by default it was ruby 1.8… and I’m obsessed with using the latest version of things. So I installed ruby 1.9. Then I discovered that it still wasn’t the latest, and it wasn’t in the repository.  So I upgraded my server OS to the latest release. And it had ruby 1.9.1. And even that patch level wasn’t even close to the latest version.

In the mean time, I found http://railstutorial.org. The newest tutorial deals with Rails 3.0, which is currently at version 3.00rc, and when you install that version of rails, it warns you that it may not function correctly with version 1.9.1 and to rather install 1.9.2 when it was released. Fan-bloody-tastic. I went ahead anyway, but had some issues getting the app to run properly. I kept getting odd errors, and there were messages about the app not finding certain gems that were, in fact, installed. It was painful.

So I figured, what the hell. I’d remove the OS-provided ruby and all the little bits and bobs, and I would compile ruby from scratch, and install it using checkinstall, so I could at least remove it.

I grabbed the most recent version (1.9.1p429 at the time) off ruby-lang.org, and tried to compile it, but received a compiler error. Googling told me I should try doing make optflags=-O3. That worked, but I got another error further along. Googling again told me that I should try running ./configure –enable-shared. So I did, and I ended up with a compiled ruby. I ran make install via checkinstall, and I was happy.

Actually, not. For some reason I checked the ruby-lang site, and discovered that the latest patch release was now 1.9.1.p430. What the…? It had been p429 just minutes ago, I swear!  I even thought that maybe I had actually downloaded p430, but the internal version number perhaps hadn’t changed… but I checked the downloaded archive, and it was definitely p429, the version.h said so.  So I downloaded the p430 archive, checked the version.h – it’s patch level 430. So I compile it. I run ./ruby -v. It returns 1.9.1-429.

Now I was incredibly confused. I grab the nightly snapshot. The version.h says it is version 1.9.3. Compile it, and run ./ruby -v. Also version 1.9.1-429.

I realised that it must be reading something from the installed version of ruby, so I remove it, and run ./ruby -v.  It returns an error about not finding libruby-1.9.1.so.

After a lot of thinking and considering, I decided that my best plan of action would be to grab a nightly build, and setup a package build via checkinstall. So I did just that. Although I think after this whole exercise, I’ve compiled ruby about 20 times now. But at least I now have a decent script that pretty much automates the getting, compiling and building of the package.

And I have a test site gurgling quite nicely under phusion passenger (modrails/modrack).

Of course, I’m leaving out a fair amount of detail about researching other frameworks and testing those out. The swearing about getting passenger to do what the docs say it should do (the OS-distro of it was old. Typical), and that kind of thing.  At least now I should hopefully be in a position to start actually learning how to use Rails via that tutorial I mentioned earlier.

Maybe.

So, just be warned, that if you get an email from some company – particularly from China – that "someone" is trying to register your "intellectual property" (as they tend to call it), just delete it. It's a scam to try get you to register domain names that you don't need at incredibly high prices.  Personally, I usually respond with a 'Fuck off', but that's just me.

sudo apt-get install dkms build-essential linux-headers-uname -r

I discovered that if you clone an ubuntu server based image, networking stops functioning in the clone.
The reason for this is that the new Machine assigns a new MAC address to the NIC. So the Udev rules think it's a new card, and assign it a new device id, like eth1, or eth2, etc.

To prevent this from happening, in your base image, edit /lib/udev/rules.d/75-persistent-net-generator.rules

Search for 'xen', and you'll see a block about ignoring the Xen virtual interfaces. Add the following below it:

# ignore VirtualBox virtual interfaces ATTR{address}=="08:00:27:*", GOTO="persistent_net_generator_end"

Save it, and then remove the file /etc/udev/rules.d/70-persistent-net.rules.

Do the same thing in any cloned images with broken networking, and reboot the VMs.

You've been messing about in your VM, installing and removing software, etc. Your disk space usage inside your machine says you've only used 3Gb of disk space, yet your actual image is much bigger. How do you fix it?

It's fairly simple to fix. First, you should probably remove all the unnecessary crap that you never use. There's a bunch of utilities out there that can help you with this.

Defrag your drive using your favourite defragger.

Now you will need one of two possible utilities (There may be more, but these are the ones I'm aware of):

• SDelete from http://www.sysinternals.com – this is a tiny 47kb executable.
• Precompact.iso – Obtained from Microsoft Virtual Server installation (May be available in other MS VM products)

Precompact.iso is MUCH easier to use. All you need to do is mount the ISO inside your VM, and it will prepare your disk for compaction.

SDelete is only marginally more difficult. Run it in a command prompt like so: SDelete -c C:
(or use whatever drive letter you want to compact). SDelete will write zeroes to the free space on your drive image. This allows compaction to take place properly.  Note – this is exactly what the Precompact.iso does, just without the fancy Windows GUI progress bar.

As soon as Precompact or SDelete is finished, shut down the VM.

Open command prompt on your host machine, and navigate to the folder where your hard disk images are located.

NOTE: It's probably MUCH easier to have the path to Virtual Box set in your PATH statement, otherwise you have to specify the full path to VBoxManage every time you use it.

In the command prompt, run:

Your disk image will now be compacted, and should end up quite a bit smaller than it was.
If you get an error about the disk image not being found blah blah, specify the FULL path to the image, like so:

Like a tool, and not thinking ahead, I created an XP Base dynamic image of max 10gb in size.  While this is usually enough space to mess around with things, I find it can be a pain in the backside when you want to install a sizeable program – say Visual Studio. While possible, you end up with very little disk space left over at the end of the day.

A possible solution to this dilemma would be to simply add a new disk to the machine, as needed. However, I like making things difficult for myself, so I rather wanted to resize the initial disk.  Unfortunately this is not possible with the provided VBoxManage utility. So, you need to jump through a few hoops, but it's really not that difficult.

You will need:

• Clonezilla – http://clonezilla.org
• GParted – http://sourceforge.net/projects/gparted/

Download the ISO versions – and for Clonezilla – DO NOT download the "Alternate" version, it will NOT work.

Using the Virtual Media Manager, create a new dynamic disk of your desired larger size. Call it whatever you like.
While you are there, add the CloneZilla and GParted iso's to the CD/DVD library.
Create a new VM, but do not attach any disks to it. Configure it as Linux, Debian. I called mine Clone Master.
Edit the VM settings, go to the Storage node, and add a new hard disk. Select your SOURCE disk (The disk  you want to enlarge). Add another hard disk, and select the DESTINATION disk (the big image you just created). Click the CD node, and select the clonezilla image. Boot the new VM.

The CloneZilla CD should now boot (If it doesn't, check the boot priority in your VM settings, and make sure CD is set to boot first).


Use the utility to do a local disk to disk clone. Using "beginner" mode is fine.  The "expert" mode has a setting to extend the partition to the size of the destination disk, but it didn't work for me at all – the cloned partition was the original size. Not sure if it's because of the NTFS partitions, or a bug in the version I was using. If it works for you then EXCELLENT – you won't need to do the GParted segment.
 

Once you have cloned the disk, power off the cloning VM, edit the settings, and detach the hard disks from it. Attach the newly cloned bigger image to your original VM, or create a new VM for it, and boot it. Check that the system works ok. If the partition hasn't grown to fill the new partition, you will need to continue to the next step.

Shut down the VM with the new large image.
Edit the settings of your cloning VM, set the CD to use the GParted iso, and attach the newly cloned image to the machine.
Boot the machine, and GParted should load. Just accept default settings, and eventually X-Windows will load with a copy of GParted. Click the extend button, and increase the partition to fill the disk. Apply the changes. It will only take a few seconds to completed. Exit the system, and shut down the VM. Edit the VM settings, and detach the disks (It's not strictly necessary – more of a safety measure).

Boot your previous VM to test the disk. All should be good.
 

1:36 PM Alexander: i know
i know
ok
1:37 PM so this thing works very well
now it's a question of playing with it
and test it with posterous
me: the more you play with it the harder it gets
Alexander: well, up to a point
WHAT?!
NO!!1
me: ROFL
1:39 PM Alexander: uncool

Damnit. What is it with these damn themes that keep fucking up the formatting?