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.

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.

Pra Pra Pra

I've lost a machine.

In the monster setup I'm doing in the 404, I blew a static DHCP setup and directed an IPMI NIC over to an address it couldn't have -- it was taken.  After the dust cleared from the resulting fight between it and a photocopier that was squatting on that IP - right in the middle of the range I'd pre-allocated - the IPMI NIC seems to have gone away.  It's not at the IP it should be, it's not at the IP I set aside for it during the squabble and to which it never went, and it's not sleuthable at a 169.254.x.y IP as it also could be.  I'm all but sunk on that one machine until I can get a human to dump the power on the box (that's why we have IPMI) and bring it back up.  It should kick the IPMI back onto the state table and get it networking again.  Ugh.

I've since learned two things:  arping and inarp.

Arping, here, helps me ensure an IP is really vacant before I allocate it.  DHCP should, too, but it wasn't doing so well in this case since I hard-coded it into the config.  This, folks, is why we define pools and stick to them.  All the problems with "dhcp causing IP conflicts", as some hicks in the 561 claimed, were all through mis-use like I did here.  So, do this next time:

# arping -D 192.168.1.6 -w 5
ARPING 192.168.1.6 from 0.0.0.0 eth0
Unicast reply from 192.168.1.6 [00:04:01:EF:D8:4C] for 192.168.1.6 [00:04:01:EF:D8:4C] 0.650ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

arping -D 192.168.1.112 -w 5
ARPING 192.168.1.112 from 0.0.0.0 eth0
Sent 6 probes (6 broadcast(s))
Received 0 response(s)

And we can be sure that something's there if it replied within 5 seconds.

The next thing, which I dearly need now, is a linux implementation of Inverse ARP, or inarp.  It's different from RARP ("who am I on this MAC") because it solicits for a third party, essentially asking "What IP is on that MAC?"

No inarp.c though.  I found one for Windows, but I don't have control of a winbox on that network, where I can inject arps.  Argh.

Anyone found a decent Inverse ARP tool for linux?  I'll even take one in perl.