Recently in Linux Category

You know that funky option in your computer's BIOS, "Network Boot Agent"? Okay, so it goes by a lot of names. "Networking Boot ROM," "Integrated NIC ROM," the list goes on. Maybe you've seen the "Press F12 to network boot option" around. You see this, your curiosity gets the best of you, so you hit F12. Suddenly your computer is scanning the ethernet subnet for a DHCP server and acquiring an IP address!

Only to go away really fast and continue booting up your computer without really telling you much. Awfully anti-climatic, if you ask me. I mean really, you add an option to your boot order, hit the button to make it go, and it starts doing all of these wonderful things only to promptly "stop" and advance in the boot order without telling you a thing.

Let's clear up the mysticism: what you (typically) just activated and attempted to use was this thing called PXE. PXE stands for "Preboot Execution Enviroment." Wikipedia has an awesome article (also available on the German Wikipedia) on the details of PXE, but I may be biased in thinking that because I assisted in it's writing. Admittedly, it has changed a fair amount over time, but the content of the article as a whole is still there. Now, come on, I know you're lazy and didn't read all of that artice. I'd even go as far as to say you didn't read any of it. So, if you're still wondering "What is this PXE thing?" I'll answer that here and now.

PXE is in it's most simple terms, a boot device. At least, that's what it appears to be to your BIOS. However, instead of spinning up your hard drive, it fires up the NIC in your computer and starts probing for DHCP (or BOOTP, but that won't be covered here. It's pretty much obselete). Then, once it has acquired an IP address with the needed DHCP options set, the PXE ROM goes about downloading and executing files off of a TFTP server.

So, what is PXE? A way to boot your computer without the need of a hard drive or any real physical storage medium. It's commonly known as netbooting. The process, as outlined above, is pretty simple. The NIC scans for a DHCP server, and then acquires an IP address. In it's brief exchange with the DHCP server, the client is sent several "DHCP Options" along with the IP address, one of which is commonly known as "filename." If the client does not find this option, it gives up and (typically) advances with the boot order. If it finds this option, however, it tries to download the specified file off of a TFTP server. An additional option which can be given is "next-server" which is the IP address of the TFTP server to contact in order to download "filename." If the "next-server" paramater is omitted, then it defaults to the same IP as the DHCP server, and likewise tries to download "filename" and in turn, execute the file it downloads.

That's it. That right there is the majority of what PXE "is" and how it works. Why did your computer acquire an IP address only to just continue on booting? Because you didn't have the needed DHCP options set. To be fair, the huge majority (99%) of all home routers lack the ability to configure the needed options, so it's likely you've never even heard of "DHCP Options." However, my personal feelings on how retarded home routers are do not belong here.

Let's move on to a "What is/isn't PXE" list real quick.

PXE is:

• A way of booting your computer without a hard drive or CD-ROM (or floppy, for you old people)
• Very useful - does not require physical storage in the computer to work
• Light - DHCP options and a TFTP server are the only requirements
• Powerful - ever wonder what it'd be like to walk into a room of computers, turn them all on, press F12, and come back an hour later to fresh installs of (your OS here)? I've done it with Windows, and I must say, it's management/installation/reinstallation bliss.

PXE isn't:

• A way to "network boot this ISO image I have here" (but it is possible given time)
• ... even related to the boot loader or actual software side of the computer. It downloads a file, it runs a file, that's IT. It's not a kernel, it lacks any real form of hardware support. It exists to run something else, not run your system for you.
• Diskless booting. Sure, it CAN do that, but again, PXE isn't there to run your system for you.
• Thin clients. Refer to above statement. And statement above said above statement. You get the idea.
• Overly detailed. When I started messing with PXE, it made little sense as a whole and felt very hacked together once I got it working. This was largely due to a lack of documentation.

In sum, PXE has a vast number of capabilities, but PXE in and of itself is pretty much worthless. You can't feed it an ISO of a bootable CD and say "Go!," nor can you magically make an entire lab of computers run Firefox without hardrives. I'll admit it in full: PXE does not run your computer for you. You are in charge of that. But, it certaintly can help in installing OSs or running entire diskless labs. If this seems unclear, I'm sure the latter articles will clear it up.

In the next few parts, I'll use the following software: ISC DHCP, tftp-hpa, pxelinux, memtest86+, and maybe a little bit of the debian installer. Who knows, maybe I'll splurge and go overboard with some CentOS installation over PXE, but for the most part, you're safe with the previous list. (Don't go downloading all of the debian CDs though, as we won't be using them.)
It should also be noted that I have written and maintain the only wiki (that I know of anyways) that is dedicated to the topic of PXE booting. For the curious, that wiki is available here.

I maintain two websites for my company. By "maintain", I mean "run the server, and let someone else update them." I wrote the code for one of them, and the other is a static webpage which hasn't changed in years. Those are just the public ones, and I have plans to add several more internal websites as we expand.

Oh, "as we expand." Seeing as every site will have it's own T1 line, point to point T1 line, and linux/windows server combo, this means that I could host the public (and private) websites on a lot of IPs, and a lot of servers. However, I really really didn't want to have to maintain and update website code on multiple servers. The solution? Subversion.

As it stands now, we have company sites A, B, and C. C is merely a remote location without any servers, linked into it all with a point to point T1. Likewise, we're going to ignore that site completly. A is considered the "home" building, and I work in the B building. The B building actually has space for IT equiptment, and likewise that's where the large majority of it resides. Sites A and B each have a linux/windows server combo, but site B also has a decent sized RAID array. So, I picked the 1.2TB RAID array to house the actual subversion repositories.

I setup the repo server to be served over apache. I didn't bother with SSL because 1) the point to point T1 lines run IPSEC and 2) apache is configured to allow the login "server/server" from a hard-coded list of IPs (which would be the servers). The server login is not allowed write priviliges either. If you were to try to access the SVN repo from anywhere else, the server login would not work, and further I'm the only other one with a login. Seeing as I'm sitting about four feet away from the SVN server, I'm not worried about plaintext transmission (but I'll fix that when I get around to it).

The repo itself contains 1) all of the needed apache vhost config files, 2) htaccess files and 3) all of the actual website data. Due to items one and two, in httpd.conf I can throw in the line "Include /srv/conf/vhosts/*" and never worry about having to configure apache ever again. Likewise, if I really screw something up, it's easy to revert all of the servers at once to a working configuration.

Logging is still one thing I need to figure out. Currently, the vhosts are just set not to log anything at all. I need to think up a way to store the logs locally on each server, yet still manage to generate statistics for all of the servers combine. The best I can come up with so far is a daily rotation of the logs, only at the end the previous logs are shipped off to be stored somewhere (and likewise merged together, and then analyzed). Unless anyone else has any better ideas, I'll probably wind up doing that in the near future.

The servers have a cron job that runs nightly, which will execute `svn up` in /srv, and then /etc/init.d/apache2 reload. That's it. That's really all that there is to it.

Now I have a versioned setup for multiple servers. Further, it's rather easy to add additional servers: USE="mysql apache2" emerge apache php; cd /; svn co http://svn/srv. Tada. All done, just like that.

I would like to point out, however, that there is a reason I did not use NFS for this. Firstly, that's a single point of failure over an already incredibly loaded point to point T1 line. That's also the second reason: less traffic going over the links that would be better used to serve people files as they work through the day. Lastly, I just don't like NFS much.

Plus, it allows me to update any aspect of the websites from any computer. Never mind the local copy I can keep on my laptop and desktop at work.

As a direct result of installing subversion to maintain a few websites, I've simplified the management that I have to do, increased my ability to effectively admin multiple servers at once, and cut back on bandwidth running inbetween the two sites.

Subversion: what do you want to do today?

About two weeks ago, my sister was hit by an IM worm. "hey - i've got pictures of the group" from a good friend. Clickey clickey, bam, trojan'd. This happened relatively late at night, so the following evening she came down and asked me to fix it. A recap of what I found:

• Eight programs that phone home, download binaries, and run them
• Seven trojans/backdoors
• Eleven random viruses
• One spambot
  

Note the italics.

As I was cleaning the system out (before I knew of the spambot), I noticed the wireless connection was in heavy use. I didn't think too much about it, as it had several viruses on it then, but I also needed the networking in order to properly clean the system. It wasn't until I tried Trend Micro's Housecall service that I really looked into the networking problem, and noticed four packets sent for every one recieved.

Oops.

I grabbed a laptop, fired up an SSH session to my router, and then started the tcpdump. I must admit, while I hate spam, it was sending a seriously impressive volume of spam per minute. I reset tcpdump to only output data headed to :25/tcp remote, and it was connecting to a good fifty different servers per minute. Fifty different servers per minute. That's a ton of spam, and it was all going over my home cable connection.

I decided I had better fix that little problem quickly, and that meant an iptables rule. Behold the results:

pkts bytes target     prot opt in     out     source               destination>

5488  263K DROP       tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0           tcp dpt:25

5488 different connection attempts in a matter of minutes. That's a lot of spam.

What scares me is that this was just one computer on a home residential computer. If my sister was hit with this worm, that means her friend also has it. And due to the nature of the IM networks, that likely means everyone my sister knows, and everyone of them and all of their contacts, also have this spambot churning out e-mail to the public as a whole.

Did I mention that's a lot of spam?

So, internet, sorry for not selectively blocking :25/tcp outbound in the first place. Sorry for sending out more spam in minutes than I get legit e-mail in three weeks. Oh, and sorry for having family members that don't know *nix. On the flip side, I have yet to see a good MSN client for *nix that features audio and video chat too, so until you can get me (or rather, my sister) that...

I recently installed a jabber server for my small office(s). We recently expanded to three separate buildings, one in Sandy, one in Salt Lake City, and another in Bountiful. Likewise, suddenly the ability to communicate was limited by phones and e-mail, and for the large majority (80%) of the needed communication, both of those options were either overkill (one-line e-mail?) or impractical (staying on hold for 30 minutes, tieing up a phone line, to ask a single six-word question).

It's funny how little we value the ability to easily communicate until it's suddenly not so easy.

I started out trying to install ejabberd, but failed miserably. In both the Sandy and Salt Lake offices, I have a modest linux router installed, doing all routing/firewalling/networking in general. Likewise, throw in the DNS SRV records on a per-site basis, in theory I would have been able to point all clients to the same host, but end result have them all wind up connecting to their local instance of ejabberd.

For those of you who don't know, ejabberd is famous for it's ability to cluster and fail/fault-over abilities. It uses a database that is essentially distributed by default. Further, it has a very nice web interface for management, along with a shared roster (list of people on the service) built-in. Sadly, I never was able to get the distributed part of it (the reason to use it) working. I would add a user on one side, and magically, that user would never appear on the other. Huh, oh well.

I wound up reverting back to the tried and true method (for me, anyways) of getting a jabber server up and running: jabberd2. Jabberd2 is not distributed like ejabberd, but it also typically uses MySQL as the backend (granted, ejabberd can also, and I've never tried to do so either, but I also know how to make jabberd2 work, and that's what I wanted here), which I'm rather familiar with.

So, about twenty minutes after I gave up on ejabberd, I had a functional jabberd2 server, up and ready to go. (For those of you curious, I have a 1.2TB RAID5 array, on which the database server is running. Overkill, yes, but I don't want to burden the router down with a database server.) Now for the fun part: the client, the program that everyone will actually be using.

All of the clients are running Windows XP, along with two or three Windows 2000 boxes. jabber.org has an impressive list of jabber clients, for pretty much any OS under the sun. In the end, I chose Miranda IM, for several reasons:

• Final distributed file size: I wound up with a 556kb .msi installer that I built for it (more on that later).
• Runtime size: I'm pretty sure that everyone lost maybe a megabyte of RAM from running this, if that. Small, light, and fast are all words that I'd use to describe this.
• Ability to customize: at it's core, it's a small executable with a large army of plugins (DLLs), providing additional functions. Likewise, I just cut out everything except the jabber components, and hey, I have a perfect IM client for jabber and jabber only.
• mirandaboot.ini: A little-known feature of Miranda. Drop this file into the install directory, and you can change program defaults. In this case, it's set to automatically create a user profile in their own user's directory, named after their domain logon name.
• Looks for DNS SRV records and uses them (Hey, gaim, where are you? Oh, right, you're STILL LACKING THIS HORRIBLY SIMPLE FEATURE. What's so hard about a DNS lookup, really?).
• Easy to use, simplistic.

All in all, this is pretty much a perfect client for people. It's simple enough to use, effective, small, and to top it all off, free. The only thing it was missing was a .msi installer package (it is being installed on a windows domain after all), and the official stance from the Miranda devs consists of, "you have a .zip and a .exe installer, and what we provide works. If you want a .msi package, feel free to build it yourself." As a result, I did, and I used Wix to do it. Yay for open source and free Microsoft programs that get the job done, and get it done well. The posts I saw on the Miranda forums included a lot of users wanting a .msi installer, so once I polish it off, I'll post both the Wix .xml file, along with the final .msi for people to abuse. For now, I'll link to the .msi which I'm using here. This includes jabber components only, and installs without prompting to Program Files. This file is suitable for usage anywhere, as it saves all settings in places where anyone can write to, and it is multi-user sane (in the sense that user A can't see user B's settings and contacts).

Earlier, I mentioned that ejabberd has shared rosters, where basically everyone can see the same group of people. Sadly, jabberd2 lacks this feature, but makes up for it in another way: it has MySQL as it's backend. This makes is horribly easy to write a small script which clears the existing roster table, and re-populates it with everyone else who is registered with the service. This makes it pretty easy to accomplish a similar "shared roster", and it bypasses the semi-complicated process to add a user, consisting of:

• Finding the person to talk to,
• Adding the person to talk to,
• Waiting for the the person on the other end to both sign in, and click allow,
• Waiting for the person on the other end to add you themselves,
• Finally allowing that user access to talk to you.

For people who only know how to use computers as far as clicking File, Print goes, the automatic addition of new users to their lists saves time and effort all the way around. Not to mention the new person doesn't have to go and add thirty other people, and then wait for all thirty people to add and authorize the new person.

In the end, I wound up with a setup that's as close to perfect as it can get. Shared rosters, easy to use client, and a client that works perfectly and easily.

I'm rather liking this whole "run your own IM server" idea now that I'm using it on a scale larger than two users. And hey, so are all of the employees.
Links:

• miranda-0.5.1-1st.msi (.msi installer, jabber components only)
• miranda-1st.xml (Wix .xml file, used to create your own .msi, jabber components only)
• miranda.xml (Wix .xml file used to create your own .msi, all Miranda IM components)

Once again, these files do not include a GUI installer of any sort, but rather will install the program automatically without prompting. There's your warning.

The other day, I resized my NTFS partition from taking the entire disk, and made some others: a 100MB partition at the beginning of the drive, and then 15GB at the end. The 15GB was split into 1GB/14GB. I'm sure that most of you can imagine what each partition was for: /boot, swap, and /.

I popped in my gentoo livecd, fired up gentoo-nofb, and went to work installing gentoo. Firing up fdisk, I saw that my partition table was out of order. And hey, it was! I had only resized my existing partition, not made additional ones. Likewise, the large NTFS partition sitting in the middle of the drive had partition ID #1, and the 100MB before it had ID #2. "Why not" I said, and told fdisk to fix the partition table order for me. Which, hey, it did, and did perfectly.

Recall from previous posts that Window's boot loader (NTLDR) is a little finicky. It was installed to the first partition, likewise, when starting Windows, it tried to load files from partition one.

Which, was now 100MB in size and formatted ext2.

To complicate the matter, I had left my CD binder at a friend's house the day before, preventing me from popping in the XP CD and hitting the "Repair" option. I also needed to boot into Windows (hey, don't judge me!), and by fixing the problem, I had broken it. I recall a small bit of IRC chat that occured while I was trying to fix this:

him: iirc, fdisk has a fix partition order option, maybe that'll help?
me: That's what I used, I need it in it's broken state to work
him: oh, okay.

So, fdisk is not of use, and I need to change my partition table entry. Luckily, the MBR (which houses the partition table) is only 512 bytes in length, and the partition table is an even smaller subset of that. So, what do you do when you have a linux livecd to repair your partition table?

Google, `dd`, and `echo`.

1. Google the partition table format and location
2. Use fdisk to dump the current partition table (it dumps it so that I can see offsets, enter fdisk and then press 'x', 'd' to see what I mean)
3. Backup the current MBR (dd if=/dev/hda of=MBR.bin bs=512 count=1; scp MBR.bin user@host:~/)
4. Use a combination of `echo blah > file` and `dd if=file of=/dev/hda bs=1 count=1 seek=blah` to change the partition table order.
5. Reboot and hope that it works at all.

And guess what?

It worked, first try.

I might have gone absolutely nuts once I saw that it worked.

I wound up deleting the initial /boot partition, and resizing the
NTFS partition to take that initial hundred megs. I'm booting without a /boot partition, but hey, it isn't exactly required.

Of course, an hour later, I realized that I could have just:

1. Deleted the /boot partition
2. Deleted the swap partition
3. Made a new /boot partition, numbered one, after the number two (NTFS) partition
4. Re-fix the partition order (again)

Oh well. At least I can say that I've manually re-written an MBR now using echo and dd.