Whither be Withered Stateless Linux?

I've been pocking at Stateless Linux for a while.

Probably since it was called Diskless Linux.  Names change.

Anyway, I stumbled over a stateless linux page referring to a tech preview in RHEL5, which sounds awesome.

Sadly it doesn't appear to be available.  "Install FC7," it says, not knowing that FC7's stereotypical 3-week support window closed at least a week ago, and thus any projects using it will simply not work.

So where did the Tech Preview go?  If it was a tech preview way back in 1992 or whenever RHEL5 was released, should it not be at least a tech preview now?

I worry that the Open Source Community has an attention span even shorter than mine.

False Start on Cobbler Repos -> Apt RepoMD statements

Man, I know so little python.  And while I hate it, I see that it's a deficiency I need to fix.  That sucks, but I may just find it useful eventually.

So I was poking around, and started to extend cobbler to feed an apt sources.list files the same as it does for a yum repo file when a given profile or system has supplemental repos attached. 

But all I did was start.  The curve's a bit high since I know so little, and I have so many other things I have to do -- like, for money.

Here's a tiny patch so far.  I'll find the rest eventually:

--- kickgen.py  2010/09/29 03:40:45     1.1
+++ kickgen.py  2010/09/29 07:06:23
@@ -175,10 +175,15 @@
         blended = utils.blender(self.api, False, obj)
         if is_profile:
            url = "http://%s/cblr/svc/op/yum/profile/%s" % (blended["http_server"], obj.name)
+           lru = "http://%s/cblr/svc/op/apt/profile/%s" % (blended["http_server"], obj.name)
         else:
            url = "http://%s/cblr/svc/op/yum/system/%s" % (blended["http_server"], obj.name)
+           lru = "http://%s/cblr/svc/op/apt/system/%s" % (blended["http_server"], obj.name)

-        return "wget \"%s\" --output-document=/etc/yum.repos.d/cobbler-config.repo\n" % (url)
+        ulines = "wget \"%s\" --output-document=/etc/yum.repos.d/cobbler-config.repo\n" % (url)
+#        ulines += "wget \"%s\" --output-document=/etc/apt/sources.list.d/cobbler-config.list\n" % (lru)
+
+        return ulines

     def generate_kickstart_for_system(self, sys_name):

Yeah, that's all I've got.  Lose the comment on the ulines+= line, and then find out the part where /op/apt/system/ actually rolls the template snippet for the apt sources.list file.  I see it here and there but can't nail down the bit in the code.  Frustrating, almost as much as running out of frivolity time.


Learning is fun, when I have time.

Kickstarting ESX VMs and Physical Hosts -- Knowing Which is Which

UPDATE: This method also does not work. Sorry.

Cobbler and kickstarting is my new cool toy.  I tinker with it FAR too much. I had a problem, though, that I need to install the vmware tools only on the VMs, and install smartmontools only on the physical hosts.  What's a guy to do?

After some digging, coding, hacking, testing, cursing, I finally discovered a decent switch I can use to identify a box by its mac.

Then I lost that code.

So I found another method.  This one's ugly as sin, but it may actually work.  Check this nasty-ass kung-fu:

#if ":".join($interfaces.eth0.mac_address.split(':')[0:3]) in "00:50:56 00:0C:29"

[code]

#end if

Yeah.  That's one ugly baby.  If Blogspot again truncates that line all to hell, remember the #if statement is all on the first line of 3.

Now to see how well it works.

Pruning Bogus Value Spikes from MRTG Gauge Values after a Reboot

MRTG is awesome and simple.  I use it in a bunch of places to quickly figure out roughly what's going on over my networks and servers.  Traffic numbers, disk space, the usual stuff.  My usage of it is strictly ghetto, but it works really well for me even when I misuse it.

When I reboot a machine, though, I find my gauges all spike.  Traffic numbers, CPU load, etc, there's a spike right at the point where I rebooted the machine.  It seems to be that MRTG sees the gauge is reset, but it treats it as an overflow, as if the gauge wrapped around, and not as if it's been zeroed out.  So the spike may be its attempt to account for the massive jump in data that would cause a wraparound.

the only solution I have just yet - because I can't use ABSMax or MaxBytes parameters - is to prune the ugly data points:

val=500000; \
for F in /var/www/html/mrtg/{cpu,dev-*}/*.{log,old};\
  do awk -vX=$val '
    NF < 4 || ($2 < X && $3 < X && $4 < X && $5 < X)
  ' $F | diff -u $F - | patch $F;\
done

Really, though, you should use the ABSMax and MaxBytes parameters whenever and wherever you can.  It'll prevent this spike when you reset your machine.

Finally, I'm sorry if the above code snippet looks like absolute ass.  There is some formatting for reading ease, while I usually do it all on one line, but also what is with the pathetic format munging in this 'new, better' editor?  It's horrid!  Can we roll it back, please?

TCPDump Top-Talkers script

I remember back in the days of cypress Linux, or Red October, that we in the MH office had a top talkers script.  It was good to see, for instance, that the streaming radio you were listening to didn't impact the network too noticeably.  I don't know what the network guys did out there, but I had a need to cook up something out East again.  So I googled it up, found a tcpdump cheat-sheet with it, and there ya go.  Top talkers:

tcpdump -tnn -c 20000 -i eth0  |\
   awk -F "." '{print $1"."$2"."$3"."$4}' |\
   sort | uniq -c | sort -nr |\
   awk ' $1 > 100 ' 

It's nothing like perfect, for it only shows the number of packets a machine's blowing out the NIC and not the size of each one, but that's something which we can add in, I figure.  It's quick, though, and gives a relatively useful ballpark figure, which is all I need today.

Yay for google and tcpdump!

Centos5-i386 -- LVM Root on a Kickstart?

I've gotta be doing something wrong.  But it looks good from so close to the problem.  Here's a snippet of the kickstart I'm using:

part pv.01  --size 32 --grow --asprimary
volgroup vg01 pv.01
logvol / --fstype ext3 --name=root --vgname=vg01 --size 10240

When it all comes down, though, it's a little screwed.  There's a pic.  The thing is, it's not really an LVM issue, since the space is there and the PV's been created.

A little investigation, though, shows the device /dev/vg01/root hasn't been created.  Simple fix?

lvm vgchange -a y

Then the devices are up.  It's too easy.  Bad news?  Can't happen in a kickstart.  The install pattern, as they say, is full, and it's missing the VG startup.

So where from here?