Jared

In my last post I suggested that I might find time to post the configurations I used for the test run. Well, I hope to be able to do that this time. I’ll go over the kernel settings I used, the settings for the DHCP server, how the initrd was setup, the settings for PXELinux, and the packages I had installed for the root filesystem.

For the kernel, I used the 2.6.15.7 kernel. I needed to patch it with SquashFS and UnionFS. I turned off support for modules as I was only going to compile the drivers needed for the system. So my network driver and the filesystem drivers were all compiled into the kernel. I also needed to enable DHCP support in the kernel. The actual config file I used is in the ZIP file available at the end of this post.

For the DHCP server, I simply needed to define a subnet to hand addresses out for and then configure options in DHCP. This was simple to accomplish. For the DHCP server, I used dhcpd but almost any DHCP server will do. For my setup, I used the subnet of 192.168.201.0/24. I then set two options in the subnet configuration that tells the PXE client what to download and where to download from. These options are “filename” and “server-name”. The DHCP server config is also in the ZIP file.

I have limited experience with initrds. I did a couple things for the one I used for this one. First was that I needed a way to download the rootfs from the TFTP server. I decided to use curl but didn’t want to have to worry about the libraries for it, so I compiled curl with static linking. I created my own linuxrc that would be run on boot. The linuxrc handles downloading the rootfs, setting up the root with unionfs and then initiating the init process on the newly mounted rootfs. It could probably be more robust, but it works for my purposes. I’ve attached the entire initrd I used.

For PXELinux to be usable, I needed to install a TFTP server. I used the tfpd-hpa server and left it will default settings. I downloaded PXELinux and copied the file pxelinux.0 to the TFTP server root location. Also note, that the kernel, initrd and rootfs need to be copied here as well. I created a default config file for PXELinux and placed it in the TFTP root location in a directory called pxelinux.cfg.

The last thing to finish up is to create the root filesystem. I used a stripped down version of Ubuntu for my filesystem. I started by using debootstrap. I then customized it to reduce the size. Once I had that completed, I used mksquashfs to then create my “image” for the rootfs. I’ve placed a list of packages in the ZIP file for those interested.

Here is the ZIP file I promised. Have fun.

Okay. So it’s been a while since I’ve written about my idea of how to manage and LVS cluster, but with good reason. That pesky thing called school came around and detracted from the project. Now that I’m graduated, I’m starting back into my old projects. While not a whole lot has progressed with this project from when I last wrote, I did have to go and relearn what I had learned before. With that in mind, I decided that I should write some of the details so that I don’t have to do it all over again. (more…)

In my previous post I talked about how the idea of using Asterisk and its features to allow moving a home or office bound call to a cell phone. As I thought more about this idea, I thought it was be much cooler to not have to put the other person on hold while the transfer was made. It would be much cooler if the person on the other side never knew that I had changed phones. So, that is what I set out to accomplish. (more…)

I’ve been a bit of an Asterisk enthusiast for a while now. There are a number of great things that can be done with it and many free services to do this with. One thing that I haven’t seen yet is using the Parked Calls feature of Asterisk to make it possible to move a call from your home phone (which is connected to an Asterisk PBX) to your cell phone.

IPKall offers a free phone number in Washington state which is forwarded to any SIP address. If one were to setup an extension on their Asterisk PBX for the IPKall number to ring to which then authenticates the caller. After authentication, the user can then pick up a parked call. So, the scenario.

You are talking to someone at home. You need to run to the store for some hot chocolate (it is cold now after all ), but want to continue your conversation. Simply park the call on your Asterisk PBX. Get your cell phone and call your IPKall number. Enter your authentication and pick up the parked call. Presto! You are now on the go without having to disconnect. If you really don’t want to waste much time between, you can even begin calling from your cell phone before you park the call and wait to the last second to park the call.

This isn’t something I could see as just useful for home users but also perhaps for a business where employees are often on the run.

As an early Christmas present, my wife got me the a Philips DVP5960 DVD/DivX player. This player also has a USB port on the front allowing for USB mass storage devices to be attached allowing for playing of music, displaying of pictures and also for playing of DivX movies.

From my experience of a week, I’m quite impressed. The player is DivX Ultra certified which means it can use the new DivX container allowing for menus, alternate audio streams and subtitles. Through the disc it has played my video selections without problem and with great quality. Playing movies from USB was not quite as successful. The player’s USB port is USB 1.1 which is considerably slower than USB 2.0. This poses a problem for areas of video with maxed out bitrates.

But all is not lost. I took my videos and reencoded them changing the maximum bitrate allowed from 4700 kbps to 3900 kbps (higher than 3900 may be possible). This was done by going into the Advanced portion of the DivX encoder and changing the Manual CLI. The portion changed was right after -vbv. I changed it from 4854000 to 4000000 resulting in that portion of the command being -vbv 4000000,3145728,2359296. Playing videos which previously stuttered during certain scenes with this new encoding has worked, for me at least.

I have a few older systems (think original Pentium) which I have around. They had small hard drives which make them difficult to do much with these days, but I had larger hard drives around which I wanted to use. The problem was that the BIOS on each of the systems are only able to recognize drives of 8GB or less correctly. This is when Grub and Linux came to the rescue.

Linux has no problem accessing the drive directly and thereby recognizing it correctly. All I had to do was get the system to boot and Linux would take care of the rest. This is where Grub comes in. Installing Grub on the hard drive doesn’t work since the BIOS doesn’t know how to access the hard drive correctly. So I was left with the option of installing Grub on a floppy. My initial install had the menu.lst file also on the floppy which caused problems when updating kernels. It also meant that the /boot/grub directory wasn’t actually where the menu.lst file being used was. This annoyed me so I went in search of a better solution.

That’s when I found my solution. I install stage 1 on the floppy but point it to the partion containing my /boot so that all information for the boot is where it should be, but I’m still able to boot my system. The way I did this was to insert a floppy disk in the drive. From the command line type “grub”. Then I set the root device for Grub with “root (hd0,0)” or whatever device your /boot is on. Then I type “setup (fd0)”. This has worked great for me. I just leave the floppy in the drive and the system boots normal like.

I have just had my first successful boot of a root filesystem completely contained in RAM using unionfs and squashfs. I used PXELinux to boot the second system. The second system downloaded the kernel and the initrd. The boot sequence began and the initrd downloaded the squashfs root filesystem and placed it on a ram disk. The initrd mounted the squashfs, then mounted a tmpfs which would act as the read/write portion of the unionfs. The squashfs and tmps were mounted into the unionfs. The initrd then called pivot_root to change to the unionfs as the root and began the init sequence of the squashfs.

The only downside was that it took about 3 1/2 minutes for the 95MB squashfs to download, but I think this was because the test was run under two virtual machines and networking for VMs is not always the best. With this complete I can now work on getting it setup to be a webserver and get the LVS setup working.

P.S. I think I might also create a Ubuntu Live CD that will load the filesystem into memory and run from there. Should result in a much quicker operating system.

I feel quite sheepish. In the previous post I described a problem of the Ubuntu 5.10 kernel booting the initrd, but the 6.06 kernel not booting it. Well after a break of a couple of days from the problem, I found the answer in under 10 minutes. the 5.10 kernel has ext2 support built into the kernel whereas the 6.06 has it built as a module. A recompile of the kernel with ext2 support built in allowed the system to boot.

After talking with my friend Andrew, I decided to look into booting a more or less standard initrd that downloaded the real rootfs and mounted that. This is when I came across squashfs. Squashfs creates a compressed readonly filesystem which is fast and compact. In conjunction with unionfs, it is possible to use squashfs as the rootfs by creating a ram disk for the purpose of storing the changes that will happen on the read only squashfs. This will provide for a smaller memory footprint allowing for less memory requirements and/or more available applications.

As a sidenote, I've done a lot of reading and searching on the Internet about diskless nodes in cluster settings, and it seems that most if not all have a dependence on a file server for the node operation. While the overall design of the web cluster called for an external storage solution, which would hold the actual website content, it would be possible to place the website within the squashfs image, thereby removing the dependence on an outside source for operation. 

In my previous post I discussed my plans of designing an easily scaled cluster. So far I've created an initrd of Ubuntu 6.06 running lighttpd and php5. The uncompressed size of the initrd is about 200MB. I've been able to load and run a system with this initrd, but have only had success with the stock 5.10 kernel. The 6.06 kernel panics with not being able to mount the rootfs. 

Tonight I attended a meeting of the BYU UUG about LVS. The focus of this presentation given by Lloyd Brown was an introduction to LVS and it's potential. The environment in which Lloyd uses LVS is quite simple and basic, but effective. His purpose was to balance the load of SSH across multiple computers with one entry point, but not concerned with high availability. LVS has one weakness (on its own). The setup calls for one director and only one director. That means that if the director goes down, it all goes down. But thanks to Linux-High Availability it is possible to set LVS up in such a way that if the main director went down, a backup can take over on the fly.

With that in mind, I was thinking of expanding on that idea. What if one used LVS-NAT for the configuration and setup the nodes (real servers) to get their configuration and filesystem via PXE? I know it is possible to boot Linux in such a way, but admittedly haven't done it before. The reason I'd want to have it PXE boot is because it would then be a simple matter to keep say a website up-to-date on all the nodes, and it is very simple to expand the cluster by simply getting a box and adding booting it. Using the heartbeat method of high availability, one would have a cluster that is highly scalable, easily scalable, and highly available.

When dealing with a handful of nodes this would most likely be overkill, but if one was dealing with 15-??? nodes, this would almost be necessary. My first step will be to PXE boot Linux by mounting the filesystem via NFS. Then I'll setup LVS for a simple website. Finally, I'll setup the heartbeat for high availability