VMware templates: post-processing for SUSE Linux Enterprise Server and openSUSE

Well, I’ve been fiddling around with SLES and openSUSE VMware templates. I know it’s a stupid idea when you have a PXE server from which you could install this in a matter of minutes (seriously the SLES PXE installation takes about 5 minutes).

However, when dealing with DMZ’s (yeah, they exist!) you usually don’t have any PXE servers there. So I decided to go with simple VMware templates (like we do with Windows already), but had to iron out a few kinks.

  1. There’s no way to run a set of scripts after the deployment scripts from VMware have been run
  2. The hostname isn’t changed everywhere (/etc/postfix/main.cf for example)


So of I went and wrote a short (70 line ..) init script, which will do exactly that.

You’ll also need to create a file (/etc/template), which’ll hold the template’s hostname and will be used for the comparison if VMware’s post-processing is already finished.

Installserver: Regenerate PXE base menu

Well, here’s the promised script to regenerate the main PXE menu based on the menu entries created by register-suse and register-vmware.

Installserver: Publish a SLES/OpenSUSE ISO – register-suse

Well, I’ve been tinkering with a way to “unify” the way we deploy new OpenSUSE/SLES ISOs onto our installation server, once they are released. So here, I’ll show you the script I came up with:

This also needs a second script, as this will only create a menu entry, not the menu itself. You’ll find the script in the next post!

SLES11.1 and updated multipath-tools

Well, after I scripted the installation the other day, I tried installing SLES11.1-Updates to the freshly installed systems. Guess what ? The thing broke. Initially (it was late Friday afternoon – like 6 PM – before my one week vacation) I didn’t have much time to debug the issue, so I sat down last week and looked at the issue.

During the installation, when first starting multipath via command line, the scsi-mpatha device appears, and each and every occurance of this is subsequentially being used (and other stuff replaced by this actually) during the whole installation phase.

But what is this multipath-tools update doing ? No clue what exactly, however after installing the update the system is bricked. The system is basically looking for /dev/scsi/by-id/scsi-disk-mpatha and waiting for this device to appear. But since the update robbed the device, the system is no longer starting.

So I went ahead and digged around in the /dev/disk/by-id directory. Turns out /dev/disk/by-id/scsi- is actually pointing to the right device, and thus I ended up using it. So I rewrote all my scripts (profile and chroot/post-chroot adjustments) as you can see below, and for now at least, I have a working installation that lets you install updates! (careful it gots electrolytes)

Now what’s left to do for tomorrow is “fixing” the already (previous to those changes) installed systems, so we can install security updates on those too!