Updating Cobbler on RHEL5 to Import ESXi5 for PXE Install

So you want to play with ESXi5, but on RHEL5, today, the latest version of cobbler (2.2.1?) doesn't yet support it.  Cobbler 2.2.3 does, though, but it's not available at all yet.  Nooooooo.

Here's what you do:

1. install an RPMbuild of cobbler 2.2.3 .  Normally this is laughable-stupid, but we know the official one's coming eventually and we'll get the update from the official channels automatically.
   1. From the cobbler release_22 branch, go get the TGZ file for the latest 2.2 release:
      https://github.com/cobbler/cobbler/tarball/release22
   2. unpack that
      tar -C /tmp -xf cobbler-cobbler-cobbler-2.2.3-2-0-g80d646a.tar.gz(or just do it all in one go:
        wget -qO-  https://github.com/cobbler/cobbler/tarball/release22 | tar -C /tmp -xzf - )
   3. change and build it
      make -C /tmp/cobbler-cobbler-80d646a  rpms
   4. if you're me, you'll then remake it just to get the right apt repo, but hey.  People like to make things inside-out, and forget that the packaging is on the outside of the build.  Be nice to them, though, as they may be amateurs, and it's easy like rolling a stop-sign.
   5. install cobbler over what you have:
      rpm -Uvh  /tmp/cobbler-cobbler-80d646a/rpm-build/cobbler-2.2.3-2.noarch.rpm
   6. watch it fail when you do a cobbler check due to a missing and unreported dependency:
      cobbler check
   7. install said dependency, re-run cobbler check, think disapproving thoughts of the packagers:
      yum -y install python-ctypes
      cobbler check
2. grab your ESXi5 ISO
3. import that
   mount -o loop VMware-VMvisor-Installer-5.0.0.update01-623860.x86_64.iso /mnt/cdrom
   cobbler import -name esxi5 --path /mnt/cdrom/
4. rejoice
   more beer

It really is that easy, once you have a cheat-sheet.  Now go hack up a decent esxi5 KS and start installing like a boss.

Mac OS/X Password Recovery

So there we were, trying to set up a pic synch config for the photos, and - wouldn't you know it? - we couldn't remember the admin password on the mactop.

So we poke around the net for a while, and found this reference.  And it was easy:

1. Boot into single (hold command-S) and kill the /var/db/.applesetupdone .
   
   • fsck -fy
   • mount -uw /
   • rm /var/db/.applesetupdone
   • reboot
2. Create a New User Account upon System Boot, and let it go into the desktop
3. Reset the Lost Password via System Preferences

It's that easy.  It's awesome, and doesn't need the CD.  What a great hack!

And we got the photo thing set up too.  Double-score!

ReCollecting the FileProvides

I use APT for RPMs, as it's the most versatile tool out there.  Some folks don't seem to understand that APT was ported for RPMs about a decade ago, and those using Yum for their RPM management are encouraged to do so, lest their horizons grow too broad.  The truly genius folks at Conectiva used APT to great benefit, and allowed massive flexibility;  upgrading in-place over a major release was a possible, easy and well-tested procedure, as I recall.  But this isn't for the Apt-RPM genius so recently localized at Conectiva and now lost to the rest of the world.

Lately there's been another change to the repository format and layout as used by YUM;  this is nothing new, as many open-source de-facto standards are developed and grow in the same kind of seeming vacuum, and the gaijin must adapt.  If you're suffering as I was, your apt-get update invocations will look like this:

E: Error occured while processing sec (CollectFileProvides)
E: Problem with MergeFileProvides /var/lib/apt/lists/archive_cobbler_repo%5fmirror_epel5-i386_repodata_277d21a2341fe766d0daff22b2846905517bcd71-primary.sqlite

I'm using Cobbler to mirror many, many repos locally; almost anywhere I have more than one machine.  The update to the createrepo invocation will either come from /etc/cobbler/settings or the createrepo flags in a particular repository item.

Here's my change:

--- /etc/cobbler/settings~      2011-09-23 07:03:38.000000000 -0700
+++ /etc/cobbler/settings       2011-09-26 14:24:32.000000000 -0700
@@ -58,7 +58,7 @@
 # enables working with Fedora repos from F11/F12 from EL-4 or
 # EL-5 without python-hashlib installed (which is not available
 # on EL-4)
-createrepo_flags: "-c cache -s sha -C --update"
+createrepo_flags: "-q -c cache -s sha --update -d"

 # if no kickstart is specified to profile add, use this template
 default_kickstart: /var/lib/cobbler/kickstarts/default.ks

You will need to adjust to suit, as the patch will not apply cleanly unless you've been mucking about there already, but take the patch and make yours match the result.  Restart cobbler when you're done and your repos will be updating madly as expected.

As always, sorry if the Blogspot editor butchers my blockquotes.

Fixing the Dependency Graphs in Bugzilla 3 EPEL RPM

Got the Epel bugzilla RPM?  I did, and it's pretty good, considering how challenging BZ is to package in a way that even begins to satisfy FHS and FSSTND.  Some collections of app-like data files are difficult to package correctly.

But the dependency graphs were pooched.  They seemed to want to send me off to http://host/var/lib/bugzilla/webdot/foo.png.  See why?  Yeah, but the problem is deeper than that, and it's not just a minor packaging bug:  bugzilla code actually uses a static CGI-bin dir to dictate the location of a dynamic spool dir containing the product of the dot calls -- the dependency graphs.  This is muy bad in terms of FHS.

But, after wading through a dozen PL files to get to where I could either mod the template, the code or the PM file containing the constants which dictate the locations and how one relates to the other ...

I just dumped in a cheap apache conf.d hack to provide a proper location for the png files without changing their real or interpreted location and without rendering in a cleaner fashion at all:

cat <<-EOF> /etc/httpd/conf.d/bugzilla-fix.conf
Alias /var/lib/bugzilla/data/webdot /var/lib/bugzilla/data/webdot
EOF

I mean, why mod the code if the next install will just hose the changes anyway (talk to me after to do the Dependency Graph Arrow Fix I've done for the last 8 years or so) and why change the templates, its generator or the PM file to suit?  Toss in a symlink so they just go to the right place while the code thinks it is generating the PNGs in the wrong place anyway?

The thing was bound to still be a bit of a mess either way, when I was done, and while I expect the package made a herculean effort to make the excellent package that it is, the source code uses so many wrong literal strings for everything that it's a big hairy ball of squidbait I didn't want to start to get into.  So I chased the code, did some soul-searching and optest for the ugliest but most reliable and maintainable fix I could.

Sorry.