To The Cloud! Maybe not the best solution.

"The Cloud" or "Cloud Computing" are some of the latest buzz words in the industry.  The definition of either of these terms is... well.. cloudy.  The basic idea is that your applications are virtualized across a global network of hypervisors.  Not too dis-similar from the VM Clusters run at the institution that I work at, just on a much larger scale.

Mounting xen disk images.

I run a Xen vm system which in turn hosts all of my linux servers. Recently, I had reason to mount the disk image from one of the vm's on the xen host.

I've found little documentation on this, so I thought i'd post what I ended up doing.

First, make sure the vm is down. Then you can mount it's disk image.

I used kpartx to mount the image as a loop.

RHEL 5.5 KVM Guest memory ballooning

We've started to look into memory ballooning on RHEL and KVM.  I thought I'd document some of my findings here.

The concept is simple.  You have your RHEL host, running KVM, that host runs a number of virtual machine guests.  The guests can be anything that runs on the chip archetecture that you're emulating.  In my case, x86_64 and i386.  We run some Windows guests, and mostly RHEL.  In my testing, i'm using a RHEL guest.  I'll test this on Windows at some point, and see what happens. 

Dismantling a desk drawer lock with a paper clip.

I found myself at work the other day, without my keys. Luckily our offices share the same key, so a co-worker was able to get me into my office. Not so my desk though. I don't keep anything terribly sensitive in my desk, because i've always felt the lock was a tad on the cheap side. Though i've attempted to pick it in the past with no success.

Today i really wanted to get at a sheet that I had in my desk drawer. So i thought I'd give it another shot. I'm no locksmith. Nor am I a pro at picking locks, but I've had luck in the past with this paper clip that i keep in my wallet, and a small pocket knife that i have in my pocket all the time. I take the screwdriver/file on the knife, and use it to put pressure on the tumbler, and then rake the pins in the lock, to try to get the tumbler to turn. This has worked on low grade locks in the past. I used to use this method to unlock the hdd write locks in college so i could install Netscape on the IE only computers in class. Today I set about picking the lock using my old method, and discovered a new method... I've seen locksmiths re-key locks in the past. They used a specialized tool, and just pulled the whole tumbler out, and replaced it with another one keyed differently but i never really knew how they got the old tumbler out. Well, today I found out. I, quite accidentally i might add, pulled out the entire tumbler in my desk lock using my paper clip. After I'd done this, i was determined to figure out HOW i did it. A spare key for my desk, which was IN the locked desk drawer, helped me shed light on this. It also gave me a very good look at how locks work in general. I'd already had a basic knowledge, but this allowed me to solidify it. Basically, there are 6 pins. Well when you put your key in, it contacts 5 of these, and moves them into just the right position that the tumbler is allowed to spin. The tumbler is then attached to some other mechanism which actually unlocks the drawers. The 6th pin, is there solely to hold the tumbler in! I was able to hit the 6th pin, and unlock the tumbler. At that point, the whole tumbler came out in my hand regardless of the presence, or lack thereof, of the key. I was then able to use my pocket knife to turn the mechanism which unlocked the drawers.

A friend called me MacGuyver for figuring this out, which prompted an earlier blog post. It does sound rather funny when you think about it, i defeated the "Security" on my desk with a straightened paper clip... Needless to say, I have even less faith in this desk lock now, and i'll be even less likely to put anything of value in it.

From the Deep

"Here we are again, on this rust-bucket of a boat." thought James, as he looked around at the poorly supplied vessel he found himself on. Hardly any ammunition, a single torpedo, practically defenceless. "It's a good thing I've got Wren to look out for me...". James, and two other mercenaries were contracted by a ships captain that they've worked with in the past, to investigate a distress call that was received from one of the oil rigs still in operation off of the gulf coast. They were en-route.

Knowledge isn't innate, it comes from a willingness to know.

Over the past 20 year or so of my life, I've been tinkering with these things called computers. I started out when i was young, in my parent's attic, on my Dad's Atari computer. He had a simple system, one 5.25" floppy drive, and a hand full of software for it. He used it for word processing, and a hand full of games. I can vaguely remember the first time we sat down, and he showed me how to load up a game off of one of these floppies. The procedure involved in turning the thing on, and when the disk had to be put in, when to push the power button all of that. I cant remember how old i was, but it had to be before i was 9. I could have been... 6, maybe 7? I'm not trying to get nostalgic, this is back story, It'll make sense in a minute.

Diaspora, on CentOS

For months I've been following the Diaspora* project. On 9/15/2010, they opened up their git repository, so that eager IT people like me could go grab their code, and start poking at it. So, on 9/15, I watched their site eagerly waiting for the announcement. Sometime late evening (around 8-9PM EST) it finally popped up, the link to the git repo. I donwloaded it within minutes, and started tinkering on my laptop (Fedora 13), and had it up and running in about an hour. I thought I'd write a little blog entry about the setup, and my initial thoughts. First, i'll say that Diaspora* runs on top of some rather new software. Fedora is a testing bed, it's usually full of bleeding edge software, things that are being tested and vetted for eventual use in RHEL. I've had issues in the past where the versions of software in Fedora were so new, they were alpha, and i actually had to downgrade them in order to get things working. Not so with Diaspora*. Diaspora* is written in ruby, and its data is stored in a noSQL implementation called MongoDB. There are no packages for MongoDB for Fedora, and the version of Ruby packaged in Fedora is one sub-revision too old. None of this was a huge issue on Fedora however. I grabbed Fedora Rawhide rpm's for Ruby 1.8.7, and MongoDB is distributed in binary form, so i just grabbed the binaries and put them in place, which is actually detailed in Diaspora's README. This was all well and good, but i wanted to run this on a web server, not my laptop. I like Fedora for my workstations, but for a server.. I like things a little more conservative. So i run CentOS for all of my personal systems, and RHEL on all of the systems at work. Both distributions are similar, in fact, CentOS is based on RHEL, its just free, where RHEL requires a subscription. Generally, there are compatibility issues with bleeding edge software like Diaspora, and RHEL and its clones. This is because when a package reaches RHEL, its supposed to be completely stable. Bleeding edge is rarely completely stable. So I built myself a new VM, which will host Diaspora. At this stage, I don't fully trust the security of Diaspora, even the developers have come out and said that they know there are security issues with this release, but its pre-alpha! The VM makes it segregated, and means I can play with packages that I may not be willing to do on my production web server. If i hose it, just junk it and start over.
What I started with
CentOS 5.5 1GB of memory 1CPU 40GB Disk Hypervisor: xen
Extra repositories
EPEL RPMFusion (Free and non-free)
CentOS Install
Nothing special here, i installed the bare minimum, just the base packages, and networking.
Preparation
Once the OS was installed, I ran a yum upgrade, to get the latest packages for the base install, and rebooted. After the reboot, i installed the following from yum: screen openssl openssl-devel git vim-enhanced gcc libxslt libxslt-devel libxml2 libxml2-devel ImageMagick gcc gcc-c++ You'll notice that Ruby isnt in that list. Thats because ruby is at version 1.8.5 on CentOS, we need 1.8.7. So, i installed the following from Source: ruby-1.8.7-p302 rubygems-1.3.7 I ran into an issue when I built ruby that ruby-openssl didn't build. I think this was because I didnt intially have openssl-devel installed. I added it later, and then built ruby-openssl by running "ruby extconf.rb" in (ruby source dir)/ext/openssl. This built and I was on my way. If it doesn't build for you, you'll find out when you try to launch Diaspora for the first time. if it gives you an error about openssl being missing, make sure openssl-devel is installed, and then build it for ruby as I've mentioned. Now, we need Ruby's bundler gem, so install from gem: bundler (gem intall bundler)
Setting up MongoDB
This is noted in the Diaspora* README.md. Essentially, unpack the MongoDB binary package, and then copy everything in (mongo directory)/bin to /bin on your system. Then create /data/db with "mkdir -p /data/db". The Diaspora directions say to chmod -R 777 /data, but this seems insecure to me. mongod runs as root, so I gave some tighter perms a try. /data is owned by root:root, i set permissions to 700 recursively, mongo appears to start, and Diaspora functions. Starting mongo is as easy as running "mongod" as root. I send it to the background so that I can free up my terminal.
Setting up Disapora* itself
If you don't already have it, go get Disapora's source. You can get it at GitHub or via git on the command line with "git clone http://github.com/diaspora/diaspora.git". I put Diaspora in /var/diaspora. Once you have the package, run "bundler install" in diaspora's root directory. If you run into errors here, you'll need to track them down. Most commonly its caused by a missing package, or some other mis-configuration. Once that finishes, you;re just about ready to run diaspora!
Running diaspora
Diaspora runs via ruby's "thin" http server. To start diaspora run "bundle exec thin start". You'll see something like:
>> Using rack adapter
>> Thin web server (v1.2.7 codename No Hup)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:3000, CTRL+C to stop
This means that Diaspora is up and running! You can connect to it via http://yourserversip:3000 Some notes on running diaspora. To run on standard port 80, you'll need to add a -p 80 to your command line. "bundle exec thin start -p 80" Also, i like to run it via screen, so i can detach it, and re-attach it later. "screen bundle exec thin start -p 80" Then once its started, use ctrl-a, ctrl-d to detach from screen, then screen -list to find it again, and re-attach with screen -r (id from list).
Using Diaspora*
Now you should be to a point where you can actually login, and use Disapora. Pointing a browser to your install will get you to the login page, first you'll need to sign up. There's a link for that on the page. Once you've signed up, if you intend for this to be your own little playground, and not open to registration, you can disable new signups by following the entry in the Diaspora FAQ regarding disabling outside registrations.
Keeping Diaspora up to date
If you're running this pre-alpha code publicly, I'd highly recommend keeping it fresh with what's available on the git repo. You can download it manually, or if you downloaded it via git in the first place, you can use "git pull" to grab the latest via the command line. Once you've done so, you'll need to stop the server, and run "bundle install" again, and then "rake". You could run this via a scheduler. I intend to write a script which does all of this. I'll post it whenever i've done so. A quick and dirty updater script, as promised.
[root@pod ~]# cat bin/updatediaspora.sh 
#!/bin/bash
cd /var/diaspora
/usr/bin/git pull
/usr/local/bin/bundle install
/usr/local/bin/rake
/bin/kill `ps awx | /bin/grep 'thin start -p 80' | /bin/grep -v grep | /bin/grep -v SCREEN | $AWK '{print $1}'`
/usr/bin/screen -d -m /usr/local/bin/bundle exec thin start -p 80
Conclusion
I really like this project thus far. I'd like to learn more about how things are going to be linked later. Right now i'm unable to link to users on any other systems, I don't know yet if this is an issue with the state of the project (i.e. not yet implemented) or a config issue on my part. I have a few co-workers and friends using my install, its fun to toy with, I've not yet dug into any of the code. i don't know ruby, so I'll need to learn something about ruby before I'll be able to make much sense of the source. I like the idea of aspects for separating co-workers from friends, from whatever else. It does seem like this could get confusing until you get used to the idea however. The UI is nice, i like the styling and it doesn't feel overly clunky. Which is saying something this early on. All in all, I can't wait for this project to pick up more followers.

Pages