McDonalds bluescreen

This just cracked me up. Windows is not reliable enough to run a video loop on a plasma screen at McDonalds.

Jmeter remote testing bug

If you use Apache Jmeter on Windows, there is bug that you need to know about. Once you decompress the binary, it needs to live in the ROOT directory of your C: drive. It cannot live anywhere else. If you place it on your Windows desktop, for example, it will throw errors in the jmeter.log file that are unrelated to the problem, and you will be unable to connect to a remote load generator. It cannot live in a directory that contains spaces. Save yourself some grief, and place it at root.

Test JVM arguments

If you want to change the behavior of your JVM, you can pass it several parameters at start time. Unfortunately, you cannot pass attributes to a running JVM, and must usually set them in a config file. The JVM then reads this configuration file at start time, and initializes the JVM with the correct parameters.

This works well, except when you make a syntax error in the parameters, or string together parameters that the JVM does not support. To avoid the potential embarassment when your server fails to start with the new JVM parameters, test the new settings first. Here's how:

1) Find the Java interpreter used by the Java container. Usually, this is listed in a configuration file that points to a JRE or JDK. Note that the system JDK or JRE software will usually be located in /usr/java/

2) Create a test Java file called Hello.java that simply prints a "Hello, world!" message to the screen. Here is the code for the file:
class Hello {
public static void main(String[] args)
{
System.out.println("Hello, world!");
}
}

3) Compile the Hello.java file using the same JDK the Java container uses.
(ex: /usr/java/jdk1.4_01/jdk/bin/javac Hello.java)

4) Execute the Hello.class file with the JVM arguments you want to test. For example:
/usr/java/jdk1.4_01/jdk/jre/bin/java verbose:gc -Xmx512M -Xms128M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC Xloggc:gc.log -XX:+UseTLAB -XX:+UseParallelGC Hello

5) You should see the "Hello, world!" code return without error.

Reveal the full path of a process

ps -auxwww

Backup putty sessions

Use Putty Session Manager to backup all of your putty sessions. This great tool saves you from recreating each session on a new computer. This tool creates a .reg file as its output. On a new workstation, download the putty binary and import the .reg file. When you start putty, all of your saved sessions will be available.

Force package removal

To get rid of Sendmail, for example, issue this command:

rpm -e --nodeps sendmail

And poof, Sendmail is gone!

One Kickstart to rule them all

If you're like me, you run multiple flavors of Red Hat in your company. Some servers run RHEL3 due to application requirements, some newer servers run the AMD64 version of RHEL 4, and some non-critical "utility" servers run Fedora Core 4. It seems the number of Linux servers is always multiplying, and manually installing each server is a time-consuming, laborious process. To counter this problem, I usually create a kickstart-enabled cdrom for each flavor of Red Hat.

Since Linux is always being updated, the number of cdroms seems to multiply like mushrooms after a rainstorm. There was always a new distro, but I sometimes needed to install an older distribution. To solve that problem, I set out to create ONE cdrom that would let me kickstart any flavor of Linux that I chose. I wanted to create the Swiss army knife of kickstart installs!

The tutorial below will show you how to do precisely that.

I'm going to assume you know how to create and modify a kickstart file. If you do not, you can learn more here and here. Put simply, a kickstart file is a text file that contains answers to all of the questions asked by the anaconda installer. The beauty of kickstart is the ability to customize your server builds to your exact needs, and build a new server in mere minutes.

I will also assume that you have a remote repository, accessible via HTTP, FTP, or NFS. This repository hosts the cdrom contents of each Red Hat OS you wish to install. A previous blog entry defines how to create such a repository. Since I try not to reinvent the wheel, I went looking for anyone who tried to do this before me. I came across Don O'Neill's excellent article, "Creating a Single Installation CD for Red Hat/Fedora Distributions" and used it as my jumping off point.

The first step is to ensure you have the ISO image of disk 1 for each distribution. We will be extracting needed files from these images. In this case, we will be working with the AMD64 version of RHEL 4.0.

Create the following scratch directories to contain your work:

mkdir -p /installcd/isolinux
mkdir -p /installcd/t1
mkdir -p /installcd/t2

Mount the first CD from one distribution into the /installcd/t1 directory.

mount -o loop RHEL4-U1-x86_64-AS-disc1.iso /installcd/t1/

Mount the boot image from /installcd/t1 into the /installcd/t2 directory.

mount -o loop /installcd/t1/images/boot.iso /installcd/t2

Copy the kernel (vmlinuz file) to an distribution-specific directory under the /installcd/isolinux directory.

mkdir -p /installcd/isolinux/RHEL4_AMD

cp /installcd/t2/isolinux/vmlinuz \ /installcd/isolinux/RHEL4_AMD

Extract the initial ramdisk (initrd) file to the same directory:

cp /installcd/t2/isolinux/initrd.img \ /installcd/isolinux/RHEL4_AMD.img

Copy the following files from the /isolinux directory on disc 1 of any Red Hat release into your /installcd/isolinux directory:

boot.cat
boot.msg
isolinux.bin
isolinux.cfg
splash.lss

Edit the isolinux.cfg file to look like similar to this:

timeout 600
prompt 1
display boot.msg

# ------------------------------------------
# Red Hat Enterprise Linux 4.0 Update 1 AMD
# ------------------------------------------
label RHEL4AMD
kernel RHEL4AMD
append ks=cdrom:/isolinux/RHEL4AMD_ks.cfg \ initrd=RHEL4AMD.img ramdisk_size=8192

Finally, name your kickstart file RHEL4AMD_ks.cfg, and move it into the /installcd/t2/isolinux/ directory.

If you wanted to add another distribution, say Fedora Core 4, you would simply repeat this process. You simply need to grab the kernel and initrd files, place them in the proper directory, and add an entry for it in the isolinux.cfg file.

Once you are done adding distributions for your cd, create a new ISO file from the contents of the /installcd/isolinux directory. You will need to have the mkisofs package installed before performing this step.

cd /installcd/isolinux
mkisofs -o /root/multiple.iso -b isolinux/ISOLINUX.BIN -c isolinux/BOOT.CAT -no-emul-boot -boot-load-size 4 -boot-info-table -R -J -v -T /installcd

Burn the ISO file named multiple.iso to a blank cdrom.

cdrecord -scanbus
cdrecord -v dev=2,0,0 driveropts=burnfree /root/multiple.iso

That's it. Your CDROM is now ready to kickstart any flavor of Red Hat.

Get up2date errata for all RH distros

Brian Long has submitted a patch to Red Hat's product marketing group that enables a single machine to pull down RHN updates for multiple RHEL releases across multiple platforms. Methinks this is a great idea, and it allows one server to grab all the updates for any RH version. Since we run 2.1 and 4.x (both Intel and AMD), this makes creating a patch repository much easier.