Kickstart and LVM

There are no examples of reusing an LVM partition after a kickstart. So here we go. Two scenarios: In the first we keep a partition, but blow away the LVM. In the second, we retain one or more of the LVs.

Scenario 1:

# fdisk -l /dev/sda
--- output truncated ---
  Device       Start       End       Blocks   Id   System
/dev/sda1         1        13      104391   83   Linux
/dev/sda2       14      1033   8193150   8e   Linux LVM
/dev/sda3    1034     1670    5116702   83   Linux

We want to keep /dev/sda3, so we can't do a clearpart --all.
The kickstart code:

clearpart --none
part /boot --onpart /dev/sda1 --fstype ext3
part pv.16 --onpart /dev/sda2
volgroup vg0 pv.16 --pesize=32768
logvol swap --fstype swap --name=swap --vgname=vg0
  --size=4096
logvol / --fstype ext3 --name=root --vgname=vg0
  --size=5000
logvol /var --fstype ext3 --name=var --vgname=vg0
  --size=512
logvol /tmp --fstype ext3 --name=tmp --vgname=vg0
  --size=512

Take note of the --onpart statements. Since all the listed items include --fstype, they are all formatted. Since /dev/sda3 was not formatted, we need to have /etc/fstab mount it at boot time. In the post add:

echo "/dev/sda3   /home   ext3   defaults   0 0" >> /etc/fstab

Another Attempt At "mail-to-blogger"

Much to my astonishment... This worked rather quickly:

This feature has been uniformly unreliable in the past, but since their picture post mechanism is offline, I thought I'd try this again, as a alternative.  Normally it takes "a day or two" for the posts to show up.  Pretty pathetic, huh.  Lets time it:

Post sent 11/20/2008 09:54am Eastern

PS: I sent this from my gmail account.  This will be our control value, as it too is under the Google umbrella.

It showed as a draft, even though it is set to publish immediately. Next, an "external address".

To make life easier, I've combine the results in one post.

This one from a Yahoo account.
Post sent 11/20/2008 10:06am Eastern

Both Google and Yahoo took about two minutes.

From My Mobile E-mail
Post sent 11/20/2008 10:12 AM Eastern

About four minutes on this one.

Since the mobile post made it (to drafts, any way), I attached a picture, and tried again. The image took about twelve minutes to process. It was the first time I have been able to post an image in about six months.

KVM "TCP/IP error: VNC"

I got an error when attempting to use virt-manager to connect to the console of a virtual machine. TCP/IP error: VNC connection to hypervisor host got refused or disconnected! This seem to be from spawning a new console too fast after closing a console to the same machine. Here's a work-around:

[root@adama qemu]# virsh vncdisplay valk-b
:3
[root@adama qemu]# vncviewer 127.0.0.1:3

This assumes you have X Window support.

GigE Benchmark, Pt. 3

More performance tuning, this time using FTP instead of NFS.

Adama from Scully:
a. 100M, 962,465,792 11.2M/s in 82s
b. GigE, 962,465,792 13.4M/s in 68s
Mulder from Scully:
c. GigE, 962,465,792 14.4M/s in 64s
Adama from Mulder:
d. GigE, 962,465,792 21.0M/s in 43s

Look at the performance difference between "a" and "d" simply by downloading from a 1G rather than a 300M CPU. But... I have one more trick up my sleeve.

Mulder had an overclocked Celeron running at 1G, but with a front side bus at 66mhz. I swapped the CPU with a PIII 600, with a front side bus speed of 133mhz. I don't think this will help us on the PCI, but let's give it a try:

Adama from Mulder w/PIII:
e. GigE, 962,465,792 21.7M/s in 43s

Any performance gain was insignificant. One last test:

Mulder w/PIII from Adama:
f. GigE, 962,465,792 19.0M/s in 52s

GigE Benchmark, Pt. 2

I added a third node to the GigE backbone. Benchmarks for Adama and Mulder copying from Scully via NFS. Test file is an ISO of slightly under 1G size. The goal of the test it to determine the effect of processor speed on GigE throughput.

[root@mulder ~]# echo -n "`date +%T.%N` - "; \
  cp /mnt/isos/RHEL4-dvd-docs.iso .; date +%T.%N
09:40:46.403907606 - 09:42:23.930183317
-------------------------------------
[root@adama ~]# echo -n "`date +%T.%N` - "; \
  cp /mnt/isos/RHEL4-dvd-docs.iso .; date +%T.%N
14:08:53.343940918 - 14:10:12.375121976

(Obviously, somebodies clock is out of sync.)

Given that Scully is our "control value", we get:
  mulder = 1:37.53
  adama  = 1:19.03
Mulder has a 1G CPU and Adama has a 2G CPU. A minor difference that could have been caused by several factors. Now the big test. Scully is a PII 300Mhz. Lets see the transfer rate between Adama and Mulder.
  from mulder to adama = 1:22.48
  from adama to mulder = 1:03.18
Bottom Line
A system's CPU has a effect its transfer rate. Paradoxically, the best speeds come from having the faster system on the server side, rather than the client side. Of course the problem with this is that, in this case, the high speed system is needed for the application.

KVM virt-clone

One of the things I love about Vmware is the ability to deploy a VM from a template. Linux has never had the same capacity, but there is a clone feature. Just as with Vmware, the original VM must be powered off. This is because we can't copy and image file if the VM is making live changs to the image.

Unlike Vmware, we have the advantage of being able to use Logical Volumes in Linux, rather than image files. An LVM image provides better performance that a flat file because we are "closer to the bare metal" of the drive, rather than inside a file system. We can resize an LMV image using native Linux commands, rather than using a third party tool. Unfortunately, this mean cloning requires one extra step: we have to preallocate the LogVol. That should take about 10 seconds.

[root@adama ~]# lvcreate -L 5G img -n vm06f8
  Logical volume "vm06f8" created
[root@adama ~]# virt-clone -o vcl02 -n vcl03 \
  -f /dev/img/vm06f8 --force
Cloning from /dev/img/vm05f8 to /dev/img/vm06f8
Cloning domain... |         5.0 GB     02:55

In this example, we created the image LogVol, /dev/img/vm6f8, and replicated Dom vcl02 as vcl03. Since we were using a preallocated volume, we needed the --force. (No, it is not smart enough to make the the LogVol. Yes, I tried.)

Our big problem now is that both VMs have the same hostname and IP address. Since vcl02 is down, we can bring vcl03 up, and make the changes with out an conflicts. If... You had used LVM inside vcl02, and you used a different VG name than on Dom0, then you could use kpartx to mount the root filesystem, and change the config files directly.

Vista & D-Link -VS- Samba

I'm going to blame this on Vista, but I think it may be D-Link's fault. For the last few weeks, the three Vista laptops have not been able to access the FC4 Samba server. The four XP machines can. When attempting to access \\Scully\Samba i got the message: the network or server is unreachable. (NOTE: If I connect the laptop via LAN cable, everything works.)

I stumbled across a similar post regarding Ubuntu and Belkin where the solution was to use the IP address of the server rather than the name, in other words: \\192.168.69.13\Samba This works.

That means the problem is either DNS or or Windows Name Resolution. From CMD, I can ping scully, so it has to be on the Windows side (PNRP or LMhosts?) When I map to \\192.168.69.13\Samba, the drive is available. Just for fun, I added the IP address to the hosts file, and now the name works.

Since this is Vista, however, we cannot simply add the IP to the hosts file:

1. Click the Vista icon (or press [Ctrl][Esc])
2. In the Start Search box, type CMD.
3. An icon will appear under Programs.
4. Right click on the icon, and select Run as administrator.
5. Confirm all warnings.
6. At the command prompt, type:
    notepad C:\Windows\System32\Drivers\etc\hosts
7. Add the IP address and Windows machine name.

Now, we can map network drives by host name.

IPtables Port Foprwarding

I'm battling a firewall issue. Machine "A" can not see machine "B", so I want to bounce through machine "C". Unfortunately, it has to be a selective redirect, as "A" needs services from "C", as well. Three steps, executed on machine "C":

[root@c]# echo 1 /proc/sys/net/ipv4/ip_forward
[root@c]# iptables -A PREROUTING -t nat -i eth0 -p tcp
    --dport 3389 -j DNAT --to 10.11.12.13:9833
[root@c]$ iptables -A FORWARD -p tcp -m state --state NEW
    --dport 3389 -j ACCEPT

First step enables forwarding. Second step takes all packets for port 3389 (machine "C" doesn't run MS terminal services), sends them to 10.11.12.13, and twists them to 9833. Thirds step fires them back out.

Reverse Hex Dump

Here's a nasty hack. I needed to automate a VNC user password in a kickstart file. The password, generated by vncpasswd was not easily transportable. Consider this example:

[doug@vinci .vnc]$ vncpasswd
Password: password
Verify: password
[doug@vinci .vnc]$ cat passwd
ÛØ<ýrzX

That's a mess. How are we going to get that into an ASCII file?

[doug@vinci .vnc]$ hexdump passwd
0000000 d8db fd3c 7a72 5814
0000008

Okay: that's hex. But how do we get it back to ASCII?

[doug@vinci .vnc]$ for HEX in d8 db fd 3c 7a 72 58 14; do echo -en "\x$HEX" | awk '{printf "%c", $1}'; done
ØÛý<zrX

With a few stategically placed spaces, it's back into hex.

Ah... It's not quite right. Look at the characters. They're out of order

[doug@vinci hexdump -C passwd
00000000   db d8 3c fd 72 7a 14 58     |..<.rz.X|
00000008
[doug@vinci .vnc]$ for HEX in db d8 3c fd 72 7a 14 58; do echo -en "\x$HEX" | awk '{printf "%c", $1}'; done
ÛØ<ýrzX

Much better. Dare I say perfect. And we don't even need to add the spaces.

Obituary for E-mail Spam

I can not believe this isn't the lead story for every major news venue. Am I the only one that noticed? I actually had to check my e-mail server this morning to ensure it was online. Why? Because there was no spam in my Inbox. I could see spam being denied from Europe, Russia, and Asia-- but no American spam.

Where had it gone?

After checking all my normal news outlets and finding no reason for this great event, I checked in on Brian Krebs' Security Fix at the Washington Post. He is normally a part of every Monday, and slow Thursdays, but not only did he have the answer... but he was the answer.

Turns out, Monday, Brian Krebs solved the American spam problem. He found that all the spam in a the US was coming from one system and he had it disconnected. (It was actually about 75%.) Since then, no spam to my server. Unfortunately, this is only a temporary reprieve as they will be back online by week's end. And then... It will be Blue Frog all over again.

Happy No Spam Day!