What's Chris been doing?

VirtualBox and I fought all day. Eventually I scored a victory on points. I made it work by trying out a new virtual machine on a new real machine, abandoning everything I’d tried last week. It seems happier running on a Dell 755 than on last week’s HP 7900. However I’ve still somehow ended up with a VM which refuses to boot from its hard disk unless I press F12 during the boot process and instruct the thing to boot from its hard disk. Compared to the problems I’ve had with VirtualBox over the past couple of days this is a small price to pay for actually getting the dratted thing up and running. Anyway, I got my f12 virtual machine installed and booted, and even rebooted, and managed to add a few test results to the test results table.
With this success I’ve finally been able to send an invitation out to colleagues to try F12, kick its tyres and take it for a spin.

• I have my f12 VirtualBox client installing to the point where the fstab component attempts to make filesystems. The installation fails at that point every time I try it, telling me that the disk doesn’t appear to exist. When I try the same mke2fs command that the fstab component just got a failure from, it succeeds for me perfectly. Alastair saw the same thing several weeks ago but with him it was only an intermittent problem, whereas with me it’s happening every time. Alastair suggested setting fstab.dopartition_sda to false then trying again. This does get the install past the mke2fs stage and on to updaterpms.
• Next problem with the install: updaterpms installs a few dozen RPMs then fails with multiple disk errors. This happens repeatably: I’ve now tried three installs in a row and all fail after installing a few dozen RPMs. Alastair suggested changing the virtual machine disk from IDE to SATA. No joy. The install fails at the same point each time: during the installation of the glibc-common RPM.
• I tried turning off the vm’s use of hardware virtualisation features. This makes it slower, and the installation procedure actually manages to install the glibc-common RPM this way, but it still fails a few packages later on: “Buffer I/O error on device sda1″, etc.
• There’s a sense of relief in the MPU today: Stephen has tried the Dell Optiplex 780, the stop-gap new PC choice that’s been forced on us, with our standard SL5 installation and has found no apparent problems. Phew.
• I’ve been given an old HP 7100 to test f12 on. Apparently they’re proving to be more durable than our (newer) Dell GX620s which are dropping like flies, so the plan is for our 7100s to have a productive old age. Anyway, it tests out OK; F12 works fine; the beast even suspends and resumes successfully. It now has an entry in the test results table.

• My GDM login screen is now rather more civilised than before. It now offers a choice of session type, language and keyboard layout to choose from – though the choice only appears after you’ve typed in your username, oddly. I’ve also installed KDE, Xfce and LXDE so we have a number of session types to choose between. I haven’t been able to add these to the base list yet though as some of the packages depend on versions which, though already available in our mirror, are too recent for our f12 updates list. I’ll add them when it becomes possible.
• About the network failure when switching from dhcp to our normal style of networking: Alastair’s machine has a similar setup but doesn’t suffer from this. The difference seems to be that his machine doesn’t use the openldap component. This bears further investigation.
• I’m experimenting with VirtualBox. At the moment my LCFG-controlled f12 installation isn’t cooperating but it’s early days.

• I spent the morning up to my elbows in network scripts trying to establish why my machine’s network is totally cut off when I switch from DHCP to our normal networking setup then reboot the machine. The resulting /etc/sysconfig/network-scripts/ifcfg-eth0 looks pretty similar to the one you get on sl5 DICE machines and also on Stephen’s f12_64 inf machine:

  DEVICE=eth0
  ONBOOT=yes
  IPADDR= (the correct IP address)
  NETMASK=255.255.252.0
  NETWORK= (em>(the first three parts of the IP address followed by .0 - looks good to me)
  BROADCAST=+
  

  I must be missing something but so far I don’t see what.

• Spent the rest of the day looking into gdm and kdm, playing with GConf, but again not getting anywhere.

• Alastair has fixed the keyboard-input-on-boot problem with a new version of lcfg-upstarthooks.
• I’ve got my Dell Optiplex 755 rebooting instead of hanging on reboot. You have to add reboot=bios to the kernel arguments. I finally got the workaround from this Ubuntu bug. It’d be nice to track down a more exactly relevant bug report.
• On closer inspection, the Dells whose internal speakers were so silent in my hardware tests actually don’t have any internal speakers. So that’s that cleared up then!
• lcfg-updaterpms-0.100.50 now officially supports F12 and is the default version. (I thought this had been done ages ago but apparently not. Some kind of oversight maybe.)

Whoops: I’ve neglected this for the last few days. This post therefore has to be something of a catch-up. Sorry for the length.

• On the 15th I built lcfg-openafs and lcfg-openldap for f12_64. (Stephen has been enthusing about Mock for a long time now, and I can see why – it’s extremely useful to be able to build packages without having to install all the Requires and BuildRequires packages on the build machine.) lcfg-openafs-0.0.32 is now officially ported to F12.
• I also confirmed that switching my F12 machine from Kerberos configuration by the file component, to configuration by the kerberos component, kills my keyboard stone dead on reboot. I get a prompt for my admin principle and the keyboard totally fails to work. I’ve gone back to the file component method and reinstalled…
• Most of the rest of the 15th and 16th was taken up with hardware tests: results here. The problems I found were:

  755 doesn’t reboot

  Whenever the 755 tries to reboot it announces “Rebooting system.” then hangs.

  745 doesn’t mount CDs

  If you insert a CD into a 745 it whirrs but nothing appears on the desktop.

  HP 7900 CD support is dodgy

  Sometimes an inserted CD doesn’t mount on the 7900′s desktop, sometimes it does.

  Dell sound is dodgy

  There’s no audio output from speakers on some Dells.

  Audio or sleep troubles on 755

  The X login screen disappeared from a 755 after it had undergone an intensive programme of frequent suspends and resumes. On checking the logs it seemed that rtkit-daemon was logging to syslog a lot at resume time. On the very first resume it logged

  rtkit-daemon[4569]: Sucessfully made thread 4567 of process 4567 (/usr/bin/pulseaudio) owned by '42' high priority at nice level -11.
  rtkit-daemon[4569]: Sucessfully made thread 4573 of process 4567 (/usr/bin/pulseaudio) owned by '42' RT at priority 5.
  rtkit-daemon[4569]: Sucessfully made thread 4574 of process 4567 (/usr/bin/pulseaudio) owned by '42' RT at priority 5.
  

  Then on the second resume it logged:

  rtkit-daemon[4569]: The poor little canary died! Taking action.
  rtkit-daemon[4569]: Rampaging.
  rtkit-daemon[4569]: Successfully demoted thread 4573 of process 4567 (/usr/bin/pulseaudio).
  rtkit-daemon[4569]: Successfully demoted thread 4574 of process 4567 (/usr/bin/pulseaudio).
  rtkit-daemon[4569]: Demoted 2 threads.
  

  and on subsequent resumes:

  rtkit-daemon[4569]: The poor little canary died! Taking action.
  rtkit-daemon[4569]: Rampaging.
  rtkit-daemon[4569]: Demoted 0 threads.
  

  Some hours later this eventually became

   rtkit-daemon[4569]: Rampaging.
   rtkit-daemon[4569]: Demoted 0 threads.
   gdm-simple-slave[4497]: WARNING: Child process -4519 was already dead.
   gdm-simple-slave[4497]: WARNING: Unable to kill D-Bus daemon
   console-kit-daemon[1811]: WARNING: Couldn't read /proc/4556/environ: Failed to open file '/proc/4556/environ': No such file or directory
   gdm-binary[4464]: WARNING: GdmDisplay: display lasted 0.844015 seconds
   gdm-binary[4464]: WARNING: GdmDisplay: display lasted 0.834487 seconds
   gdm-binary[4464]: WARNING: GdmDisplay: display lasted 0.829573 seconds
   gdm-binary[4464]: WARNING: GdmDisplay: display lasted 0.829621 seconds
   gdm-binary[4464]: WARNING: GdmDisplay: display lasted 0.830660 seconds
   gdm-binary[4464]: WARNING: GdmDisplay: display lasted 0.835599 seconds
   gdm-binary[4464]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors
   init: prefdm main process (4464) terminated with status 1
   init: prefdm main process ended, respawning
   gdm-binary[13695]: WARNING: GdmDisplay: display lasted 0.833754 seconds
  

  and so on. Judging by these two posts on Ubuntu forums it may be the case that PulseAudio should be stopped on suspend and started on resume. I’ve checked our pm-tools sleep.d scripts and that’s not happening on our F12 machines.

  “rtkit” by the way is “real time kit”, it’s required by PulseAudio but not yet by anything else.
  I spent some time today debugging a pm-utils sleep.d hook script which would suspend PulseAudio on system suspend and resume it on resume, but without success. I think I’ve spent enough time on this; for now we’ll just have to have lcfg-sleep disabled on 755s. I’m modifying lcfg/defaults/sleep.h accordingly.
  A note for the future: my failed sleep hook script needed to run nsu or sudo so it could run pactl as the user running pulseaudio. Root doesn’t have permission to nsu, and I subsequently noticed some console messages saying “root: sorry, you must have a tty to run sudo”. So that explains those failures, anyway.

• Alastair has got us round the keyboard/kerberos problem. Apparently scripts called from Upstart can’t get interactive input! See this Ubuntu support thread. Setting kerberos.hostkeyless to true gets us round the problem for now, at the cost of not having any automatically generated host keys. I’ve changed inf/options/kerberos-client.h accordingly. But what a pain. We really don’t like Upstart. Edit: it may be plymouth rather than Upstart. Hopefully we’ll be able to chuck or disable plymouth as a workaround.

• For my own machine I’ve backed out the lcfg-kerberos changes we tried yesterday and reverted to configuring Kerberos with the file component:

  #define INF_OPTIONS_KERBEROS_CLIENT
  #include <inf/os/f12.h>
  #include <inf/options/kerberos-client-by-file.h>
  

  Stephen reckons I was just unlucky yesterday. By tomorrow I may have enough courage to give lcfg-kerberos another try.

• F12 now uses the openldap component if you #define USE_OPENLDAP_COMPONENT at the top of the profile. The component has so far only been built and submitted on 32 bit though as a build dep (lsb) is missing on the 64 bit machine.
• I’ve built and submitted the last dependencies for lcfg-sleep on f12_64. I used mock to do this. Initial mock failures were solved by adding a load of BuildRequires to the specfile of the package I had to build.
• Today I’ve been able to strike lcfg-pam, lcfg-grub and lcfg-sleep from the not-yet-done list on the project plan.
• An attempt to build lcfg-openafs on f12_64 failed due to dependencies not being installed. I’ll tackle this tomorrow with mock. Mock has the distinct advantage that you can have it install dependencies for you, and it does it just in its chroot: so you don’t have to muck about installing packages on a build machine, possibly annoying another person who may be using the same machine for some other purpose at the same time.
• Looking back on this I now realise that tomorrow I can also use mock to tackle lcfg-openldap on 64 bit.

lcfg-sleep is OK and working on my F12 machine with dice/options/sleep.h included. My machine is a GX745 and is sleeping far more reliably than it did with SL5. Based on this I haven’t added any model-based exclusions for F12.

lcfg-gdm on the other hand isn’t looking so good. The gdm on F12 has been totally rewritten compared to the version on SL5 and the configuration isn’t fully compatible. It looks like we’re going to need a new lcfg-gdm, or possibly we could configure gdm with lcfg-gconf.

Late yesterday I bogged up my F12 machine completely. Today I took the opportunity to reinstall it using Alastair’s shiny new F12 install process. This worked, albeit with a few hiccups, so I now have a new F12 installation.

With the new installation, the wake alarm no longer works as it did. This is how it worked until yesterday:

# echo 0 >/sys/class/rtc/rtc0/wakealarm
# date "+%s" -d "+ 5 minutes" >/sys/class/rtc/rtc0/wakealarm

That is, you zero the alarm then you set it with the number of seconds between the epoch and the date/time you want the machine to wake up. Now though, with the same kernel RPM as before, the above doesn’t work. Instead it works like this:

# echo 0 >/sys/class/rtc/rtc0/wakealarm
# echo +300 >/sys/class/rtc/rtc0/wakealarm

That is, you put in a + followed by the number of seconds between now and your alarm time. But the kernel version is the same, I think, from yesterday to today. How can the alarm behaviour have changed…?! And will it change again tomorrow? How do I write software when the kernel behaviour changes arbitrarily from one day to the next with no change of kernel RPM version?

I got the solution from here – which seems to be about Asus boards so I’m still confused as I’m using a Dell:
http://www.mail-archive.com/acpi-bugzilla@lists.sourceforge.net/msg24296.html

The day was mostly taken up with making the sleep component behave itself properly on Fedora 12. The OS’s power management facilities certainly seem to have matured: my test Dell Optiplex 745 suspends and resumes far more quickly than it did with SL5, and it seems to be doing it far more reliably as well so far. I’ve left it on an intensive suspend/resume cycle though (awake for 3 minutes, then suspend if appropriate, then wake 2 minutes later and start again) so we’ll see if that brings out any misbehaviour over the next few days.

An apparent bug whereby the pm-utils hook scripts weren’t being called was solved when I noticed that for F12 I’d switched the suspend command for my machine from /usr/sbin/pm-suspend to some other fancy suspend command. Doh. I switched it back and the pm-utils hooks were called again as they should be.

I also rewrote the part of the component’s code which sets the wake alarm to make it cope properly with either the old kernel alarm system used on SL5 (/proc/acpi/alarm) or the newer one found on F12 (/sys/class/rtc/rtc0/wakealarm).

I also discovered and fixed an edge case problem whereby the component’s shell idle time test would happily approve sleep in case where all interactive shells had an idle time of zero seconds. Repeat twenty times: I must not confuse zero with undefined in my perl scripts. Still to do: check that other sleep tests are behaving themselves (I think they are though) and check that the new code still does the right thing on SL5.

• I’ve cleaned loads of testing crud out of my F12 machine’s LCFG file. There’s now far less potential for confusion between local overrides and the default settings.
• Idea from Alastair and Stephen: I’ve added fstab resources for the current partitioning arrangement my machine has. The lack of those messed up Stephen’s machine on reboot.
• The end is in sight: most of what matters now seems to be being managed by LCFG one way or another on my, Stephen’s and Alastair’s machines; Stephen’s has had a successful LCFG-controlled reboot, with LCFG-configured grub; and Alastair has managed a successful LCFG-controlled reinstall!
• The F12 Upgrade page has been licked further into shape. It now sports a Known Issues section with a couple of problems added already.

• The test sleep machine didn’t wake up on schedule. This could be because yesterday I ignored the advice in the MythTV ACPI Wakeup page to stop the suspend-time scripts from syncing the hardware clock from the system clock; since any changes to the hardware clock after the wakeup alarm is set will make the alarm ineffective.
• Wrong guess, or insufficient; the machine wakes up when I set the alarm from the shell (good), but not when it’s set from the hacked sleep component. Need to clean up the component’s alarm setting code.
• lcfg-autoreboot now builds and installs on F12. Submitted to devel bucket. Dependency added to lcfg/autoreboot.h.
• lcfg-bugzilla now builds and installs on F12. Submitted to devel bucket.
• lcfg-cups now builds and installs on F12. Submitted to devel bucket.
• lcfg-gbios now builds and installs on F12. Submitted to devel bucket. I incremented the micro release number to make the subversion tags to make the build tools work.
• lcfg-localhome now builds and installs on F12. Submitted to devel bucket. I incremented the micro release number to make the subversion tags to make the build tools work.
• lcfg-postgresql now builds and installs on F12. Submitted to devel bucket.
• The other entries in lcfg_f12_extras.rpms are either already done, are being tackled or aren’t in LCFG subversion.
• lcfg-syslog-2.0.1 is ready to use on F12 (though not SL5 which stays with 1.1.15) and has had its platform list updated. I’ve built and submitted it for f12, adjusted lcfg_f12_lcfg.rpms to install it and adjusted inf/os/f12.h to enable it.
• On Stephen’s advice I made an fstab template in /var/lcfg/conf/fstab/fstab.sda for the existing anaconda-derived partitioning of my test machine’s disk. This should stop lcfg-fstab from blootering the current partition setup.
• Built and submitted lcfg-hardware-0.100.22 for f12; updated the version number in lcfg_f12_lcfg_installroot; enabled lcfg-hardware in inf/os/f12.h.
• Built and submitted lcfg-kernel-0.102.3 for f12; updated the version number in lcfg_f12_lcfg_installroot; enabled lcfg-kernel in inf/os/f12.h. SL5 is staying on lcfg-kernel-0.101.18 for now.
• Built and submitted everything else in subversion that would build first time and seemed even possibly relevant to F12
  • lcfg-perlex
  • lcfg-pgluser
  • lcfg-postfix
  • lcfg-procmailrc
  • lcfg-pxeserver
  • lcfg-remctld
  • lcfg-status-checks
  • lcfg-subversion
  • lcfg-sudo
  • lcfg-tibsconf
  • lcfg-websvn
  • lcfg-xen

• Components don’t seem to be reconfiguring when they get a change of resources. I had to “om boot configure” to get it to pick up changes to boot.services that were made days ago, despite several reboots since the change. I also just had to “om cron configure” to get the cron component to process a new cron job I’d added to its resources.
• inf/options/ntp.h was configuring /etc/ntpd.conf but that was all. It now starts ntpd too by adding rc_ntpd to boot.services.
• Have been having difficulties with the cron component. Then spotted that inf/os/f12.h was still removing it from profile.components and boot.services. Oops. Now removed those removals; lcfg-cron and crond now start correctly on reboot.
• I’ve worked out some things that lcfg-sleep needs in order to work on F12:
  • F12 versions of perl packages, including two which aren’t in the Fedora distribution and had to be got from CPAN (perl-DateTime-Event-Cron and perl-DateTime-Format-Epoch)
  • The newer kernel means a change to using the newer kernel alarm file /sys/class/rtc/rtc0/wakealarm instead of /proc/acpi/alarm. This is what needs perl-DateTime-Format-Epoch.
  • Removal of suspend-time and resume-time actions for LCFG components not currently in use on F12 (lcfg-ntp and lcfg-amd).
    I’ve slept the test F12 machine and woken it several times and so far it’s behaving wonderfully: nice quick wake-ups and no video problems at all. We’ll see tomorrow how the sleep component performed overnight.
• I spotted that xemacs didn’t have a full complement of packages by the fact that it was missing a perl mode. I’ve added them to lcfg_f12_base.rpms where the other xemacs packages were put a week or two ago.

• My machine now allows logins from inf.ed.ac.uk DICE users and gives them their AFS home directories by default. The final piece of this jigsaw was to add the following line to /etc/ldap.conf:

  nss_map_attribute homeDirectory afsHomeDirectory
  

  This is best done via the file component – this line is nicked from Stephen’s lcfg/bowmore file:

  !file.tmpl_ldapconf    mEXTRA(\nnss_map_attribute homeDirectory afsHomeDirectory\n)
  

• I’ve extensively hacked the F12 Upgrade page but there’s still a lot more to do.

• I’ve created an lcfg_f12_extras.rpms list.
• lcfg-openssh seems to be lacking just a submit to the lcfg bucket, so I’ve done that.
• lcfg-auth was still being disabled in inf/os/f12.h; I’ve changed this, so it’s now started and in use by default. The auth resources inherit from the fstab resources so I’ve added fstab to profile.components though not yet to boot.services.
• I’ve created and started work on the local F12 Upgrade information page.

• lcfg-prelink-1.0.5 makes its debut and supports F12 too. Support for -c lines has been added as the F12 /etc/prelink.conf has this:

  # `-c ' is used to source additional config file snippets.
  -c /etc/prelink.conf.d/*.conf
  

  Doing this has shown up the lack of a lcfg_f12_extras.rpms list. I’ll look at that tomorrow. It doesn’t do much except drive the lcfg.org website automatic lists if I remember rightly.

• I’m sure I did other stuff too, since I spent most of the day elbows deep in Fedora and LCFG, but I didn’t note it down at the time. Mostly investigating and correcting minor errors in the port so far, I think.

• We’ve got an mpu chatroom where we’re coordinating the f12 port. Feel free to join if you have access to our jabber service and you want to see what we’re doing.
• I’ve committed my changes to the lcfg_f12_kernel list and the inf/options/openafs-client.h header to upgrade us to the latest kernel and openafs versions.
• So now I have openafs-devel, so maybe now perl-AFS will build… Nope. It’s still not happy:

  gcc: /usr/lib/libafsrpc.a: No such file or directory
  gcc: /usr/lib/libafsauthent.a: No such file or directory
  

  A google search on perl-AFS dependencies returns this blog in first place. I hate it when that happens.
  We do have:

  /usr/lib/libafsrpc.so.1
  

  which is in openafs-authlibs. Aha, we probably need to install openafs-authlibs-devel. Yes, that did it… perl-AFS is now built and submitted.

• lcfg-updaterpms-0.100.49 has been built and submitted and is now the default.
• pkgsubmit-0.0.6 has been built and submitted and is now the default.
• nsu allows and denies me correctly when I start lcfg-nsu and adjust nsu resources accordingly, so I’ll say it’s working on F12. I encountered a build error when trying to build the subsequent new version on sl5:

  error: Installed (but unpackaged) file(s) found:
    /usr/lib/debug/usr/bin/nsu.debug
    /usr/src/debug/lcfg-nsu-2.5.10/nsu.c
    /usr/src/debug/lcfg-nsu-2.5.10/permit.c
    /usr/src/debug/lcfg-nsu-2.5.10/propagate_auth.c
  

  This was due to the presence of a “BuildArch: noarch” line in a sub-package. You can’t have a noarch subpackage when the main package isn’t noarch. Thanks Stephen for sorting it out. That out of the way, lcfg-nsu-2.5.11 makes its debut as the default on all supported platforms.

• Stephen said yesterday that lcfg-tcpwrappers tested out OK for him and it seems to work fine for me too, so lcfg-tcpwrappers-0.99.11 is now the default on all platforms.
• Ditto ditto lcfg-nsswitch-0.100.10.
• My machine’s clock is now properly adjusted thanks to Stephen’s blog post on ntp on f12.

• I’ve solved last night’s updaterpms conflict. My machine is now running with the PAE kernel version 2.6.32.9-70.fc12 and with openafs 1.4.12.
  The conflict was caused by two versions of kernel-firmware being listed in profile.packages, the old one and the new one. I had thought that the new one would overwrite the old one since I’d put a + in front of the new one. Then when that didn’t work I’d thought I could take out the old one by inserting a -kernel-firmware-*-* line between old and new. That didn’t work either, and today I realised why: the old kernel-firmware line specifies a context [install!=true] – and it seems you can only override a package specification that uses a context by overriding it in the same context. One I’d added [install!=true] to the -kernel-firmware-*-* line, all was well: I rebooted and the new kernel and openafs installed happily.

• Following Stephen’s fixes to sxprof, I’ve issued lcfg-etcservices-0.100.13 to mark F12 support.
• Now that openafs is configured with inf/openafs-client.h I’ve removed openafs packages from lcfg_f12_override.rpms.
• I’ve downloaded and submitted openafs 1.4.12 for f12 and f12_64 into the world bucket.
• This afternoon we had an LCFG Fedora 12 Port Meeting.

• I started the day by doing a google search on rpmReadPackageFile Unknown system – and result number one was from this blog. I hate it when that happens. Altering the search slightly, the only other site on the entire internet (google claims) which has the text “Unknown system: (null)” anywhere in it is this one, an archive of a mail message from eleven years ago, which references an RPMfind FAQ which unsurprisingly no longer exists. When I look at one which does exist it doesn’t mention that phrase anywhere.
  The actual warning message comes from the RPM 4.7.1 source file lib/rpmrc.c, specifically from the function getMachineInfo based on what it gets back after calling lookupInCanonTable. I’ve updated bug 224 with the info.

• lcfg-cron seems to be doing the right thing on f12 and f12_64 so I’ve issued lcfg-cron-2.0.13 to mark official f12 support.
• lcfg-openafs is installed but it needs perl-AFS which won’t build because:

  Path to the AFS installation (libraries, binaries, 
  header files) to be used for this installation? 	  [/usr] /usr
  /usr/bin/ld: cannot find -lubik
  collect2: ld returned 1 exit status
  ERROR from evaluation of /home/cc/RPMbuild/BUILD/AFS-2.6.1/src/Makefile.PL: 
  Could not compile test code to retrieve the version of AFS system libraries...
  error: Bad exit status from /var/tmp/rpm-tmp.5yyfci (%build)
  

  Stephen is guessing that this might be caused by the lack of (e.g.) openafs-devel. There is an openafs-devel for openafs 1.4.11 but yum won’t install it because:

  Transaction Check Error:
    file /usr/share/man/man1/compile_et.1.gz from install of openafs-devel-1.4.11-fc12.1.1.i386 conflicts with file from package libcom_err-devel-1.41.9-7.fc12.i686
  

  This may well be fixed in openafs 1.4.12 which is now out. However the OpenAFS Fedora 12 download page doesn’t mention a kmod-openafs package for my kernel version. I could possibly build my own but even if I did I’d need to reboot the machine (scary) afterwards, so I might as well upgrade the kernel and openafs when I reboot. Whatever I do it looks like a machine reboot is called for, which means it’s time to deploy Alastair’s lcfg-boot for Fedora 12.

• Speaking of which: Alastair has now deployed his F12-compatible, Upstart-compatible lcfg-boot on my machine! It was a pretty painless process, too – this is about all that’s needed:

  !profile.packages	mEXTRA(+initscripts-9.02.1-1.lcfg.1/i386 \
                                 lcfg-upstarthooks-0.0.4-1/noarch )
  
  !boot.services	mADD(rc_openafsXXDclient)
  

  Two reboots later it’s looking as if the machine is booting under LCFG control. This feels good. I hadn’t dared to boot the thing for the past couple of weeks as I didn’t know what might break.

• Spurred on by this success, I thought I’d try upgrading openafs to 1.4.12 and the kernel to something compatible with it. I decided on the most recent kernel that openafs supports for this platform, and here’s what I’m asking updaterpms to do:

  /* upgrade to newer kernel and openafs */
  !profile.packages mEXTRA(+kernel-doc-2.6.32.9-70.fc12/noarch:b)
  !profile.packages mEXTRA(+kernel-headers-2.6.32.9-70.fc12:b)
  !profile.packages mEXTRA(+kernel-2.6.32.9-70.fc12:br)
  !profile.packages mEXTRA(+kernel-PAE-devel-2.6.32.9-70.fc12:b)
  !profile.packages mEXTRA(+kernel-PAE-2.6.32.9-70.fc12:br)
  !profile.packages mEXTRA(+kernel-devel-2.6.32.9-70.fc12:b)
  !profile.packages mEXTRA(+kmod-openafs-PAE-1.4.12-1.1.2.6.32.9_70.fc12:b)
  !profile.packages mEXTRA(+kmod-openafs-1.4.12-1.1.2.6.32.9_70.fc12:b)
  !profile.packages mEXTRA(+openafs-client-1.4.12-fc12.1.1/i386:b)
  !profile.packages mEXTRA(+openafs-docs-1.4.12-fc12.1.1/i386:b)
  !profile.packages mEXTRA(+openafs-kernel-source-1.4.12-fc12.1.1/i386:b)
  !profile.packages mEXTRA(+openafs-1.4.12-fc12.1.1/i386:b)
  !profile.packages mEXTRA(+openafs-authlibs-1.4.12-fc12.1.1/i386:b)
  !profile.packages mEXTRA(+openafs-krb5-1.4.12-fc12.1.1/i386:b)
  !profile.packages mEXTRA(+openafs-server-1.4.12-fc12.1.1/i386:b)
  !profile.packages mEXTRA(+openafs-devel-1.4.12-fc12.1.1/i386:b)
  !profile.packages mEXTRA(+kernel-firmware-2.6.32.9-70.fc12/noarch:b)
  !profile.packages mEXTRA(xorg-x11-drv-ati-firmware-6.13.0-0.21.20100219gite68d3a389.fc12)
  

  This looks OK to me, but updaterpms is finding two conflicts:

  kernel-firmware >= 2.6.32.9-70.fc12 is needed by kernel-PAE-2.6.32.9-70.fc12.i686
  kernel-firmware >= 2.6.32.9-70.fc12 is needed by kernel-2.6.32.9-70.fc12.i686
  

  This is odd, because:

  rpm -qp --provides kernel-firmware-2.6.32.9-70.fc12.noarch.rpm 
  warning: kernel-firmware-2.6.32.9-70.fc12.noarch.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID 57bbccba
  kernel-firmware = 2.6.32.9-70.fc12
  

  Furthermore if I install kernel-firmware-2.6.32.9-70.fc12.noarch.rpm using the rpm command, then run updaterpms, it wants to delete the package then reinstall it then complain that what it provides isn’t there. I’m probably missing something obvious here; I’ll attack this again tomorrow.

• I’ve started looking at lcfg-mailcap. It’s just an incarnation of the file component so it should be fine, but I don’t think the default resources are sensible any more. Our mailcap resources specify particular applications to be used for different types of content, but the mailcap which comes with Fedora just gives everything straight to xdg-open which finds out what the desktop’s default application is for that mime type and hands the data to it to display. This latter course seems less error-prone, more standard and less in need of maintenance by us. Here’s an /etc/mailcap from a DICE SL5 machine:

  #
  # LCFG generated /etc/mailcap - do not edit
  #
  
  audio/mod;/usr/bin/mikmod %s
  
  audio/wav;/usr/bin/mplayer %s
  
  image/*;/usr/bin/display %s
  
  application/msword;/usr/bin/openoffice.org3 %s
  
  application/pdf;/usr/bin/acroread %s
  
  application/postscript;/usr/bin/gv %s
  
  text/html;/usr/bin/htmlview %s ; copiousoutput
  
  video/quicktime;/usr/bin/mplayer %s
  
  application/x-java-jnlp-file;/etc/alternatives/javaws
  
  application/acrobat;/usr/bin/acroread %s
  
  application/vnd.oasis.opendocument.text;/usr/bin/openoffice.org3 %s
  
  application/vnd.oasis.opendocument.presentation;/usr/bin/openoffice.org3 %s
  
  application/vnd.oasis.opendocument.spreadsheet;/usr/bin/openoffice.org3 %s
  
  video/*;/usr/bin/mplayer %s
  
  Application/VND.MS-EXCEL;/usr/bin/openoffice.org3 %s
  
  Application/VND.MS-POWERPOINT;/usr/bin/openoffice.org3 %s
  

  and here’s one from a Fedora 12 machine:

  ### 
  ### Begin Red Hat Mailcap
  ###
  
  audio/*; /usr/bin/xdg-open %s
  
  image/*; /usr/bin/xdg-open %s
  
  application/msword; /usr/bin/xdg-open %s
  application/pdf; /usr/bin/xdg-open %s
  application/postscript ; /usr/bin/xdg-open %s
  
  text/html; /usr/bin/xdg-open %s ; copiousoutput
  

  Presumably we could for F12 get lcfg-mailcap to make an /etc/mailcap which hands everything in sight to xdg-open.

• Iain has now finished finding and where necessary building and submitting Fedora 12 versions of all of the packages mentioned in lcfg_f12_lcfg.rpms. Where he hasn’t been able to do that he’s submitted a bug.

• I’ve moved untested packages from the lcfg bucket to the devel bucket. Alastair has added the devel bucket to the default updaterpms path for f12. The idea is to use the devel bucket as the temporary dumping ground for our untested packages. Tested versions will later be submitted to lcfg as normal. I’m judging a package to be tested if “Fedora12″ is in its platforms list in lcfg.yml in lcfg subversion. These packages have been moved from lcfg to devel: lcfg-auth-*, lcfg-cron-*, lcfg-fstab-*, lcfg-gdm-*, lcfg-grub-*, lcfg-hardware-*, lcfg-init-*, lcfg-kernel-*, lcfg-lcfginit-*, lcfg-mailcap-*, lcfg-network-*, lcfg-nsswitch-*, lcfg-nsu-*, lcfg-pam-*, lcfg-tcpwrappers-*, netgroup-*, perl-String-*, perl-W3C-*, pkgsubmit-*.
• After eliminating some more package conflicts I have bravely run updaterpms for real, with no visible bad consequences so far.
• Stephen has done an inf/options/openafs-client.h. This exposed the lack of a non-PAE kernel in lcfg_f12_lcfg.rpms (Alastair and I both had an updaterpms conflict) so I’ve added one.
• Checking out lcfg-auth. Our normal auth resources depend on netgroup entries which depend on openldap which I haven’t tackled yet, so I’m overriding them with entries which should recreate basic authorization files more or less as they currently are on the test machine. After an adventure or two (in particular, if you start getting errors like Can't call method "name" on an undefined value at /usr/bin/om line 300 then the account you’re logged in as has just been deleted from the passwd file, OK?) the auth component seems to be doing the right thing, and the files it’s created look as they should. I declare it OK for Fedora 12 so I’ve changed the supported platforms list and built and submitted lcfg-auth-0.102.12 for all supported platforms.
• Spent some time debugging genhdfile to find where the warning messages (bug 224) were coming from. They’re being produced by this line in genhdfile.c:

    rc = rpmReadPackageFile(ts, fd, fullrpmfile, &h);
  

updaterpms still wants to delete several dozen packages. I’m wondering what useful stuff I might have missed out of the package lists.

• I’ve added cpanspec and dependencies to the devel list. I know Fedora comes with every Perl module imaginable but I can’t rule its usefulness out entirely so we might as well have it now as later.
• I’ve added xemacs and emacs and dependencies to the base list.
• We’re now down to 39 deletions, 15 of which are multiple kernel packages, 8 lcfg packages I haven’t yet added to the lists, 10 perl and 6 stragglers.
• Oops, lcfg/options/buildtools.h already incorporated lcfg_sl5_devel.rpms into the rpmpath. I’ve changed it so it now includes lcfg/options/devel.h, which if you’ve been paying attention you’ll know incorporates lcfg_sl5_devel.rpms (or lcfg_f12_devel.rpms) into the rpmpath.
• More package list adjustments: move redhat-lsb and deps to base; add perl-Module-Build and deps to base; some extra perl test modules added to devel.
• I think we’ve sorted out updaterpms bug 235. Gory details can be found there.
• Just made my first attempt to build lcfg-server on f12. Failed pretty quickly. bug 236. Later – bug closed: we don’t need lcfg-server on f12 right now; an upcoming version is in preparation and that should work fine on f12. (Good; that simplifies things.)
• Alastair has beaten me! He now has two f12 machines managed by updaterpms and boot
• lcfg-nsu builds as i386 rather than i686 which messes up our lcfg package list which is shared between 32 and 64 bit. Reported as bug 237. Fixed in lcfg-nsu-2.5.9 by removing the BuildArch line from the specfile; BuildArch is only really needed for a “noarch” RPM.
• hidden/f12vars.h now defines ARCH_I386 as well as ARCH_I686 to save hassle.
• Iain has done a massive build and pkgsubmit of lots of components!
• The f12 kernel package now loads after the updates and overrides packages.
• The f12 devel package now loads before the updates package.

Still working on getting updaterpms to run cleanly.

• Submitted kmod-openafs-PAE (I’d missed this out before); built and submitted lcfg-pkgtools 1.0.9, lcfg-utils 1.3.3, submitted perl-W3C-SAX-XmlParser and perl-W3C-Util-Basekit.
• lcfg-afs is being added to the packages list by inf/options/afs-client.h. lcfg-afs has been replaced by lcfg-openafs. In the dice layer afs-client.h has recently been replaced by openafs-client.h. To eliminate an updaterpms error, and because my AFS is currently working, for the time being I’ll disable inf/options/afs-client.h on my machine. Later: just spoken to Stephen. He’s going to create inf/options/openafs-client.h to more or less mirror the way we set it up in DICE, using lcfg-openafs.
• corrected a typo in inf/options/packages.h. The inf_f12_env.rpms list is now loaded. It’s empty though.
• Came back from lunch to find new F12 updates and updaterpms reporting several conflicts. Some were due to my having previously added packages to lcfg_f12_overrides (which is for non-Fedora packages we want to install) when I should have added them to lcfg_f12_postship (which is for Fedora packages we want to install which have only been shipped as updates not as part of the Everything bucket). Others were new packages or new dependencies of updated versions of existing packages. Where a version of these new dependencies was shipped in Everything, I’ve added the Everything version to lcfg_f12_base. Where it was only ever shipped in updates, I’ve added it to lcfg_f12_postship.
• Created and populated lcfg_f12_devel.rpms with pkgsubmit, cmake, redhat-lsb and their dependencies. Added six waves of perl dependencies. Created empty inf_f12_devel.rpms, inf_sl5_devel.rpms, dice_sl5_devel.rpms and dice_f12_devel.rpms. Created lcfg/options/devel.h, inf/options/devel.h, dice/options/devel.h.
• updaterpms is behaving oddly – for instance it wants to delete something called kernel-PAE/i686-2.6.31.12-174.2.3.fc12/i686 when it should be recognising it as kernel-PAE-2.6.31.12-174.2.3.fc12/i686 which it’s been told not to delete. It separately reports on the latter package name, reporting that it’ll deal with it at boot time (since the package is specified with :br flags). Reported as bug 235.

• Stephen has regenerated all the F12 rpmlist and package header files, so updaterpms is now finding most of the RPMs it’s looking for.
• Judicious population of the new lcfg_f12_overrides.rpms list has eliminated all package conflicts.
• updaterpms isn’t yet entirely happy however… it still can’t find several dozen RPMs and it wants to delete too much. To fix this I need to do at least these things:
  • Create, populate and use lcfg_f12_devel.rpms (cmake, lsb, etc.)
  • Autobuild and submit a load of as yet unchecked LCFG components. Iain will be doing this.
  • Populate lcfg_f12_kernel.rpms. (Done. The beginnings of one, anyway.)
  • Submit and find a package list for the openafs packages. (Done. I used the overrides list, since openafs doesn’t seem to be part of Fedora in any way at all.)
  • Fix inf/options/packages.h so that for F12 it defines rpmlist #ifdef ARCH_I686 rather than ARCH_I386. (Done.)
  • Fix inf/options/packages.h so that for F12 it defines rpmlist in terms of layers. (Done.)
  • Some of my package conflicts and overrides may be caused by our updates mirror being out of date? This is a reminder to me to look through and find packages we don’t seem to have recent enough updates for, and tell Stephen about them.

• updaterpms wants to delete an epic amount of packages from my machine and is flagging 383 conflicts.
• Adding -a i686 to updaterpms.flags reduces this to 195 conflicts but the enormous amount of would-be deletions remains.
• There are no “noarch” indications in the lcfg_f12_base package list. Whoops! Adding those in reduces the number of conflicts to 18. However it still wants to delete a lot of RPMs and there are also still a huge number of “can’t find original RPM for” and “couldn’t find RPM header file for” messages.
• By judicious use of yum and rpm and even a few adjustments in package lists I’ve reduced the number of conflicts reported on my machine by updaterpms to 4. A lot of the problems seem to stem from my having run yum upgrade at some point. Some of the package versions on my machine are higher than those on our update package lists as well as on the base list. These higher package versions sometimes pull in extra dependencies that weren’t needed before. One updated package imposes a new dependency on ruby-libs which needs readline-5, but the machine already has readline-6 installed. I can’t help thinking that Fedora updates seem to be more of a chaotic mess than RHEL/SL updates and will need a lot of policing.
• News on bug 231: Alastair has found two problems with our packages infrastructure on F12. Firstly the attempts to write all those thousands of RPM header files to our F12 sites mirror directories has bumped us up against some maximum size limit for an AFS directory. He’s solved that by quickly making it possible to have the RPM header files in a subdir instead. Secondly the rpmlist files in each of these dirs contain full paths rather than just the names of the files, and updaterpms can’t cope with this. Fixing the rpmlist files by hand makes my updaterpms far happier. However the script which regenerates the rpmlist files will need to be fixed to make this permanent.

• perl-LCFG-PkgTools-1.0.30 is now the default on F12 and SL5 and has been built and submitted for f12, sl5 and sl5_64.
• It looks like perl-LCFG-PkgUtils is used by perl-LCFG-PkgTools, and that’s working fine, so I’ll declare perl-LCFG-PkgUtils to be OK too. perl-LCFG-PkgUtils-1.0.1 has now been built, submitted and made the default version on SL5 and F12.
• I’ve just enabled lcfg-updaterpms and tried running updaterpms for the first time. Before starting the component I set updaterpms.methods to run to prevent it from running updaterpms at “start” time – because it’ll inevitably want to do something silly the very first time it’s run so I want to run it in test mode. The component then started up successfully without attempting to run updaterpms. I then ran it myself in test mode with

  om updaterpms run -- -t
  

  and got a whole load of errors which culminated with

  [ERROR] updaterpms: There were 383 conflicts
  

  This might take some time to sort out.
  First error:

  couldn't find RPM header file for gnome-desktop-devel-2.28.2-3.fc12/i386
  

  There is a header file for that package:

  /afs/inf.ed.ac.uk/pkgs/sites/f12/updates/i386/.gnome-desktop-devel-2.28.2-3.fc12.i686.rpm
  

  but the RPM and its header file are both “i686″ not “i386″. The package is specified in the package list file like so:

  ?gnome-desktop-devel-2.28.2-3.fc12
  

  … because it’s using the default arch rather than another one such as “noarch”.
  Have I set the default arch wrongly somewhere…?
  Edit: now reported as bug 231.

• On the question of whether perl-Template-Toolkit should or shouldn’t be a dependency of lcfg-utils: No, it shouldn’t. However it would be far more on target to have it as a dependency of perl-LCFG-Utils. Strictly speaking it’s not actually required, but its presence does enhance perl-LCFG-Utils (it lets it handle new-style perl templates as well as the old-style LCFG templates) and we should have it installed for that reason. Also, perl modules which are dependencies of perl software generally aren’t mentioned specifically in the specfile as dependencies anyway, Simon tells me; instead the build system automatically notices the “use” or “require” and adds a dependency automatically. This is better than specifying such dependencies in the specfile as the dependencies can then automatically keep up to date if a module moves to a new package, for instance. So: while I’ve left it to the build mechanism to add a formal RPM dependency on perl-Template-Toolkit if it wants to (and it doesn’t seem to want to in this case), I have kept perl-Template-Toolkit and dependencies in the core-prereq section of @lcfg_f12_lcfg.rpms.
• Now I’ve got some sense into the package lists I can test qxpack, and it seems to be working. In fact it alerted me to a typo I’d made last week which I’ve now fixed. All the qxpack results I’m getting back seem sensible, so I’ll declare perl-LCFG-PkgTools to be ported and release a new version. (Later.) Hmm: I’ve made the new version but when I try and build it I get:

  % rpmbuild -ba LCFG-PkgTools-Perl-1.0.30.spec 
  error: Failed build dependencies:
          perl(Test::Differences) is needed by perl-LCFG-PkgTools-1.0.30-1.i386
          perl(Test::Exception) is needed by perl-LCFG-PkgTools-1.0.30-1.i386
  

  These aren’t installed anywhere by default, but if they’re only build-time dependencies then maybe they don’t need to be. (Later: I’ve checked with Stephen and he agrees: just install these build dependencies for the build then get rid of them again.)
  For now I’ll install them on the hosts I use to rebuild this package and we’ll see what happens. (Later.) One dependency led to another so my SL5 machine now has:

  /* BuildReq by perl-LCFG-PkgTools */
  !profile.packages  mEXTRA(perl-Test-Differences-0.47-2.el5/noarch)
  /* Req by perl-Test-Differences */
  !profile.packages  mEXTRA(perl-Text-Diff-0.35-3.el5/noarch)
  /* Req by perl-Text-Diff */
  !profile.packages  mEXTRA(perl-Algorithm-Diff-1.1902-2.el5/noarch)
  /* BuildReq by perl-LCFG-PkgTools */
  !profile.packages  mEXTRA(perl-Test-Exception-0.29-1.inf/noarch)
  /* Req by perl-Test-Exception */
  !profile.packages  mEXTRA(perl-Sub-Uplevel-0.18-2.1.inf/noarch)
  

  Some of these had several versions: I chose the highest numbered version in each case. Having done that, perl-LCFG-PkgTools-1.0.30 builds and installs on SL5, after which qxpack appears to behave just as the previous version did. It continues to work after I remove the five build-time requirements mentioned above.

• Tried installing lcfg-om and running om.
  Got the message

  Can't do setuid (cannot exec sperl)
  

  This was fixed by installing the perl-suidperl package. I’ve now added that to the specfile of lcfg-om as a Requirement. The next attempt to run “om” gave the error:

  Component group does not exist
  

  Google knows of precisely three websites in the world containing this exact phrase. (Now there will be four.) The only Linux-related site was my own SL5 LCFG port diary (!) which describes my encounter with the same problem a couple of years ago. The fix is to add the “lcfg” group to /etc/group.
  Having done this, the error message changes to the more conventional:

  No permission to run this method
  

  which is fixed by adding my username to the resource authorize.users_superusers.
  After having done that, various random “om” commands work.
  I’d say that constitutes an adequate test of both lcfg-om and lcfg-authorize so I’ll mark the port by issuing updated versions of both: lcfg-om-0.4.8 and lcfg-authorize-1.0.13.

• I’ve added perl-suidperl as a dependency of lcfg-om in the LCFG package lists. I also corrected a couple of dependencies of lcfg-authorize in the F12 LCFG package lists and made a mental note to go back and correct the package list dependencies of other packages already done for F12 – I realise I’ve neglected them.
• Change of plan: it turns out that perl-suidperl is in the base list for SL5 so isn’t in the SL5 lcfg list; and since perl-suidperl is going to be needed by all sorts of things, we should add it to the base list for F12 too. So I’ve taken it back out of the LCFG lists and added it to the F12 base list.
• In the package lists perl-Template-Toolkit is listed as a dependency of lcfg-utils. In the lcfg-utils specfile it’s not.
  My guess is that this is deliberate because Template Toolkit support is an optional feature of lcfg-utils, but that nevertheless we want to have perl-Template-Toolkit installed. I’d like to get this confirmed though. I’ve gone ahead and updated perl-Template-Toolkit in the LCFG package lists, and also updated its dependencies (which are a different list of packages this time than on SL5).

• Ditto perl-Tk and perl-LCFG-Utils: perl-Tk seems to be an optional dependency of perl-LCFG-Utils.
• In case I need to know later, these packages on SL5 require one of the targets provided by perl-Template-Toolkit:

  perl-LCFG-Build-Skeleton-0.0.12-1.noarch
  eqe-1.3.0-1.dice.1.noarch
  lcfg-autoreboot-1.0.11-1.noarch
  perl-LCFG-Build-Tools-0.0.61-1.noarch
  

  No package on SL5 requires a target provided by perl-Tk.
  This is how I found that out:

  for i in `rpm -q --provides perl-Template-Toolkit|awk -F\= '{print $1}'`; \
  do echo perl-Template-Toolkit provides $i; rpm -q --whatrequires $i; \
  done | grep -v perl-Template-Toolkit|grep -v 'no package requires'
  

• I’ll probably go back and move perl-Template-Toolkit (and dependencies) to a package list where they’re definitely needed, rather than in LCFG core. Not today though, it’s been complicated enough, and besides it is Friday afternoon: prime time for breaking things for the weekend with an ill-considered bit of hacking of core package lists.
• Hopefully a lot of the dependency problems will be sorted out quickly and easily when I get updaterpms working and can run through its list of moans and groans. Next week I hope.

• Belatedly built and submitted recently updated LCFG components for sl5_64 too.
• lcfg-pkgtools-1.0.9 supports F12 and is the default on F12 and SL5.
• lcfg-sysinfo-1.0.2 supports F12 and is the default on F12 and SL5.
• pkgsubmit seems to submit packages correctly but when run genhdfile issues warnings:

  Creating dependency file for lcfg-logserver-defaults-s1-1.2.20-1.noarch.rpm
  warning: Unknown system: (null)
  warning: Please contact rpm-maint@lists.rpm.org
  warning: Unknown system: (null)
  warning: Please contact rpm-maint@lists.rpm.org
  

  This has been reported as bug 224 (in the lcfg-updaterpms category, which is where genhdfile lives).

• logserver seems to serve logs properly when tested so logserver-1.2.20 which supports F12 and SL5 has been made and is the new default version.
• qxprof and sxprof seem to work OK on F12 so a new default of perl-LCFG-Utils-1.3.4 commemorates the fact.
• Default repository locations are now set for F12 machines in lcfg/options/installroot.h & inf/defaults.h. These are used to set default F12 package repository locations in inf/options/packages.h & lcfg/defaults/updaterpms.h. The _REPOSITORY macro (which defines the root of the local RPM repository) is joined by a new _SITES_REPOSITORY macro which defines the root of the site mirror RPM repository. Both are used for updaterpms.rpmpath on F12, so F12 RPMs will be taken straight from our Fedora mirror.
• This means that stages 2 (RPM Repositories), 3 (Package Lists) and 4 (Essential Headers) of the project are now complete.

• Bug 222 is resolved. Alastair figured it out: Fedora 12 comes with a Firewall which seems to be enabled by default. After I disabled it then made a change to the machine’s LCFG file, the new profile was picked up by the client component pretty much immediately. Take a bow lcfg-client-2.2.38 with official support for Fedora 12: now the default version on SL5 and F12.
• lcfg-ngeneric-1.2.35 now supports F12 and is the default version on F12 and SL5.
• lcfg-file-1.1.19 now supports F12 and is the default version on F12 and SL5.
• A bunch of milestones were created on the devproj page.

This week got off to a bad start.

I couldn’t login to the Fedora machine.

I eventually traced this to a DHCP problem: the machine’s minimal new LCFG profile didn’t have the dhclient component included. This meant that the machine’s MAC address didn’t get added to the right spanning map, so it didn’t make it on to the DHCP servers, so DHCP for my machine was broken. Oops. I fixed it by adding dhclient to profile.components and uncommenting dhclient.mac.

It took a while to reinstall openafs

which got broken by an ill judged “OK” to a PackageManager popup which offered to install a load of security fixes. Among these was a new kernel; when I rebooted this new kernel was selected so the openafs kernel module didn’t match as the kmod-openafs RPM is specific to the kernel version you’re using. While trying to fix the problem I ended up in a situation where the openafs yum magic which automatically selects the right version of kmod-openafs for you was guessing at a kernel version which wasn’t on my machine. I reported that problem but got round it by specifying the kmod-openafs version to yum myself. In the end the magic commands were:

yum install kmod-openafs-PAE-1.4.11-1.1.2.6.31.12_174.2.3.fc12 openafs-client openafs-krb5
cp /usr/vice/etc/ThisCell.rpmsave /usr/vice/etc/ThisCell
/etc/init.d/openafs-client start

Also,

• The LCFG client sees and downloads new kernels but isn’t seeing the UDP notification, so it only downloads a new kernel at most once every ten minutes or so (client.poll being set to 10m+30s). Bug 222.
• There’s now a tracking bug for the LCFG port to Fedora 12. All bugs related to this project block it. Bug 223.
• lcfg-utils seems to work – at least lcfgmsg seems to behave properly when tested – so I’ve added “Fedora12″ to its list of supported platforms and issued a new version (1.3.3) which has been built, submitted and made the default version on SL5, and made the default version on F12.
• I’ve created LCFG-level package lists
  lcfg_f12_lcfg.rpms,
  lcfg_f12_lcfg_installroot.rpms,
  lcfg_f12_installroot.rpms,
  lcfg_f12_installbase.rpms,
  lcfg_f12_testupdates.rpms,
  lcfg_f12_kernel.rpms.

• lcfg-etcservices doesn’t build (bug 218) because the lcfg.cmake.tt template doesn’t know how to recognise Fedora (bug 219).
• lcfg-init-1.0.12 builds and installs.
• lcfg-lcfginit-0.100.11 builds but doesn’t install because

  error: Failed dependencies:
  	lcfg-boot >= 1.2.0 is needed by lcfg-lcfginit-0.100.11-1.noarch
  

• lcfg-nsu-2.5.8 builds and installs.
• lcfg-pam-1.0.11 builds and installs.
• lcfg-syslog-1.1.15 doesn’t build because

  error: Failed build dependencies:
  	sysklogd is needed by lcfg-syslog-1.1.15-1.src
  

  On Fedora 12 sysklogd has been replaced by rsyslog, which claims that “It is quite compatible to stock sysklogd and can be used as a drop-in replacement”. I’ll go back and tackle this later.

• lcfg-tcpwrappers-0.99.10 builds and installs.
• lcfg-defetc-f12-0.1.2 created, built and installed.
• lcfg-dns-6.1.69 doesn’t build due to its use of obsolete build tools: bug 220.
• lcfg-kerberos-2.1.35 doesn’t build due to its use of obsolete build tools: bug 221.

Various items on the plan can’t be done yet so I’m pressing on with test builds and installs of various LCFG packages:

• lcfg-auth-0.102.11 builds and installs.
• lcfg-boot-1.2.20 doesn’t build: it appears to use old-style buildtools. The version in subversion is 1.2.22 but that doesn’t build either because of a missing tag. Bug 217.
• lcfg-cron-2.0.12 wouldn’t build because:

  error: Failed build dependencies:
  	netgroup is needed by lcfg-cron-2.0.12-1.src
  

  netgroup-1.1 builds and installs.
  lcfg-cron-2.0.12 then builds, but won’t install because:

  error: Failed dependencies:
  	perl(IPC::Run) is needed by lcfg-cron-2.0.12-1.noarch
  	perl(String::CRC::Cksum) is needed by lcfg-cron-2.0.12-1.noarch
  

  “yum install perl-IPC-Run” succeeds and installs perl-IPC-Run-0.84-1.fc12.noarch.
  perl-String-CRC-Cksum is not in CPAN and can’t be installed from the Fedora yum repositories – it appears to be a local RPM. A rebuild from perl-String-CRC-Cksum-0.03-1.inf.src.rpm succeeds and the resulting RPM installs.
  lcfg-cron-2.0.12 then installs.

I’d suspected that something was wrong, and after checking with Stephen it seems I overcomplicated the package building process. The thing to do is to just rebuild the LCFG source RPMs; any build errors should be reported in Bugzilla. So, some package builds:

• I’ve done that with lcfg-utils and reported the bug (LCFG bug 213). Stephen has fixed the bug in lcfg-utils-1.3.2 and this builds and installs on F12.
• lcfg-pkgtools-1.0.8 builds and installs on F12.
• lcfg-pkgtools-perl-1.0.25 needs these additional packages to be installed:
  • perl-Class-Accessor-0.34-1.fc12.noarch
  • perl-IO-Zlib-1.07-87.fc12.i686
  • perl-TimeDate-1.16-11.fc12.noarch
  • perl-Test-Differences-0.4801-3.fc12.noarch
    which pulls in these packages:
    • perl-Algorithm-Diff-1.1902-8.fc12.noarch
    • perl-Text-Diff-1.37-2.fc12.noarch
  • perl-Test-Exception-0.27-4.fc12.noarch
    which pulls in these packages:
    • perl-Test-Simple-0.92-87.fc12.i686
    • perl-Sub-Uplevel-0.2002-3.fc12.noarch

  It then builds. However it doesn’t install because:

  error: Failed dependencies:
  	lcfg-sysinfo is needed by lcfg-pkgtools-perl-1.0.25-1.i686
  	perl(LCFG::PkgUtils) is needed by lcfg-pkgtools-perl-1.0.25-1.i686
  	perl(LCFG::SysInfo) is needed by lcfg-pkgtools-perl-1.0.25-1.i686
  	perl(Readonly) is needed by lcfg-pkgtools-perl-1.0.25-1.i686
  	updaterpms is needed by lcfg-pkgtools-perl-1.0.25-1.i686
  

• updaterpms-3.2.1 builds and installs.
• lcfg-updaterpms-0.100.48 builds but doesn’t yet install:

  error: Failed dependencies:
  	lcfg-ngeneric is needed by lcfg-updaterpms-0.100.48-1.noarch
  	lcfg-om is needed by lcfg-updaterpms-0.100.48-1.noarch
  

• lcfg-ngeneric-1.2.34 doesn’t build because:

  error: Failed build dependencies:
  	perl(LCFG::Utils) is needed by lcfg-ngeneric-1.2.34-1.src
  	perl(LCFG::Template) is needed by lcfg-ngeneric-1.2.34-1.src
  	perl(LCFG::Resources) is needed by lcfg-ngeneric-1.2.34-1.src
  	perl(LCFG::SysInfo) is needed by lcfg-ngeneric-1.2.34-1.src
  

• perl-LCFG-Utils-1.3.3 doesn’t build because:

  error: Failed build dependencies:
  	perl(Module::Build) is needed by perl-LCFG-Utils-1.3.3-1.src
  	perl(ExtUtils::CBuilder) is needed by perl-LCFG-Utils-1.3.3-1.src
  

  Installed perl-Module-Build-0.3200-87.fc12.i686
  This also pulls in:
  perl-ExtUtils-CBuilder-0.24-87.fc12.i686
  perl-Archive-Tar-1.46-87.fc12.i686
  perl-Package-Constants-0.01-87.fc12.i686

  perl-LCFG-Utils-1.3.3 then builds, but doesn’t install because:

  error: Failed dependencies:
  	perl(Readonly) is needed by perl-LCFG-Utils-1.3.3-1.i686
  

  Installed perl-Readonly-1.03-10.fc12.noarch
  which also pulls in:
  perl-Readonly-XS-1.05-2.fc12.i686

  perl-LCFG-Utils-1.3.3 then installs.

• lcfg-sysinfo-1.0.0 builds and installs.
• lcfg-ngeneric-1.2.34 now builds and installs.
• lcfg-om-0.4.7 builds but doesn’t install because:

  error: Failed dependencies:
  	perl(UNIVERSAL::require) is needed by lcfg-om-0.4.7-1.noarch
  

  Installed perl-UNIVERSAL-require-0.13-1.fc12.noarch

  lcfg-om-0.4.7 now installs.

• lcfg-updaterpms-0.100.48 now installs.
• perl-LCFG-PkgUtils-1.0.0 builds and installs.
• lcfg-pkgtools-perl-1.0.25 now installs.
• perl-LCFG-PkgTools-1.0.29 builds but doesn’t install because:

  	file /usr/bin/qxpack from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  	file /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/LCFG/PkgList.pm from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  	file /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/LCFG/PkgSpec.pm from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  	file /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/LCFG/PkgTools.pm from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  	file /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/auto/LCFG/PkgTools/PkgTools.so from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  	file /usr/share/man/man1/qxpack.1.gz from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  	file /usr/share/man/man3/LCFG::PkgList.3pm.gz from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  	file /usr/share/man/man3/LCFG::PkgSpec.3pm.gz from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  	file /usr/share/man/man3/LCFG::PkgTools.3pm.gz from install of perl-LCFG-PkgTools-1.0.29-1.i686 conflicts with file from package lcfg-pkgtools-perl-1.0.25-1.i686
  

  Whoops! Looks like I shouldn’t have installed lcfg-pkgtools-perl! A quick ‘rpm -e’ later and perl-LCFG-PkgTools-1.0.29 installs successfully.

• lcfg-client-2.2.37 doesn’t build because:

  error: Failed build dependencies:
  	perl-W3C-SAX-XmlParser is needed by lcfg-client-2.2.37-1.src
  	perl-W3C-Util-Basekit is needed by lcfg-client-2.2.37-1.src
  

  These were both installed on SL5 three years ago at LCFG port time (!) and the packages were made using cpan2rpm which no longer exists. I’ll try cpanspec instead.

  Installing cpanspec-1.78-3.fc12.noarch pulls in these dependencies:
  perl-Algorithm-C3.noarch 0:0.08-2.fc12
  perl-Archive-Zip.noarch 0:1.30-1.fc12
  perl-CPAN-DistnameInfo.noarch 0:0.08-2.fc12
  perl-Class-C3.noarch 0:0.21-2.fc12
  perl-Class-C3-XS.i686 0:0.13-1.fc12
  perl-Class-MOP.i686 0:0.94-1.fc12
  perl-Compress-Raw-Bzip2.i686 0:2.020-1.fc12
  perl-Data-OptList.noarch 0:0.104-3.fc12
  perl-Devel-GlobalDestruction.i686 0:0.02-7.fc12
  perl-IO-Compress-Bzip2.noarch 0:2.005-6.fc12
  perl-List-MoreUtils.i686 0:0.22-9.fc12
  perl-MRO-Compat.noarch 0:0.11-2.fc12
  perl-Moose.noarch 0:0.92-1.fc12
  perl-Params-Util.i686 0:1.00-2.fc12
  perl-Parse-CPAN-Packages.noarch 0:2.31-2.fc12
  perl-Sub-Exporter.noarch 0:0.982-3.fc12
  perl-Sub-Identify.i686 0:0.04-6.fc12
  perl-Sub-Install.noarch 0:0.925-3.fc12
  perl-Sub-Name.i686 0:0.04-4.fc12
  perl-Task-Weaken.noarch 0:1.02-5.fc12
  perl-TeX-Hyphen.noarch 0:0.140-9.fc12
  perl-Text-Autoformat.noarch 0:1.14.0-5.fc12
  perl-Text-Reform.noarch 0:1.12.2-6.fc12
  perl-Try-Tiny.noarch 0:0.02-1.fc12
  perl-YAML.noarch 0:0.70-2.fc12

  [cc@tarragona SPECS]$ cpanspec perl-W3C-SAX-XmlParser
  Failed to parse 'perl::W3C::SAX::XmlParser' or find a module by that name, skipping...
  [cc@tarragona SPECS]$ cpanspec perl-W3C-Util-Basekit
  Failed to parse 'perl::W3C::Util::Basekit' or find a module by that name, skipping...
  

  Neither of these modules seems to exist any more.
  Reported in LCFG bug 215.
  Apparently it’s OK for us to maintain our own copies of these modules and just rebuild from SRPMs from one port to the next. So:
  perl-W3C-Util-Basekit-0.91 builds and installs.
  perl-W3C-SAX-XmlParser-0.99 builds and installs.
  lcfg-client-2.2.37 then builds and installs.

• lcfg-file-1.1.18 builds and installs.
• lcfg-logserver-1.2.19 builds and installs.
• lcfg-authorize-1.0.11 builds and installs.
• pkgsubmit-0.0.4 fails to build because:

  /usr/lib/ccache/gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -fPIC CMakeFiles/pkgsubmit.dir/pkgsubmit.c.o  -o pkgsubmit -rdynamic -lrpm -lrpmio -lz 
  CMakeFiles/pkgsubmit.dir/pkgsubmit.c.o: In function `PrintErr':
  /home/cc/RPMbuild/BUILD/pkgsubmit-0.0.4/pkgsubmit.c:72: undefined reference to `rpmErrorString'
  collect2: ld returned 1 exit status
  make[2]: *** [pkgsubmit] Error 1
  make[2]: Leaving directory `/home/cc/RPMbuild/BUILD/pkgsubmit-0.0.4'
  make[1]: *** [CMakeFiles/pkgsubmit.dir/all] Error 2
  make[1]: Leaving directory `/home/cc/RPMbuild/BUILD/pkgsubmit-0.0.4'
  make: *** [all] Error 2
  error: Bad exit status from /var/tmp/rpm-tmp.OY7FUA (%build)
  

  Reported in LCFG bug 216.

Installing lcfg-pkgtools:

The SRPM installed OK.
‘cmake .’ failed with:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
PCRE_LIBRARY
    linked by target "lcfg_pkgtools" in directory /root/rpmbuild/SOURCES/lcfg-pkgtools-1.0.8/src

-- Configuring incomplete, errors occurred!

A search for ‘pcre’ in the package’s files found this:

ChangeLog:	* specfile (BuildRequires): Added pcre-devel

My SL5 machine has pcre-devel but the F12 machine doesn’t:

[ayre]cc: rpm -qa|grep -i pcre
pcre-6.6-2.el5_1.7.i386
pcre-ocaml-5.11.1-0.dice.3.i386
pcre-devel-6.6-2.el5_1.7.i386

[cc@tarragona srpms]$ rpm -qa|grep -i pcre
pcre-7.8-3.fc12.i686

A ‘yum install pcre-devel’ succeeds without pulling in any other dependencies.
The ‘cmake .’ now succeeds, as does the rest of the build and install.

OS_RELEASE_MAJOR
OS_RELEASE_MINOR
OS_RELEASE_FULL
OS_ID_FULL

Installing lcfg-utils:

cmake >= 2.6.0
/etc/rpm/macros.cmake  
lsb  

Installing:
 cmake           i686           2.6.4-5.fc12            updates           5.2 M

Installing:
 redhat-lsb                i686      3.2-7.fc12                fedora      26 k
Installing for dependencies:
 foomatic                  i686      4.0.3-8.fc12              updates    241 k
 foomatic-db               noarch    4.0-8.20091126.fc12       updates    1.0 M
 foomatic-db-filesystem    noarch    4.0-8.20091126.fc12       updates    4.4 k
 foomatic-db-ppds          noarch    4.0-8.20091126.fc12       updates     19 M
 libmodplug                i686      1:0.8.7-2.fc12            fedora     150 k
 libmpcdec                 i686      1.2.6-6.fc12              fedora      24 k
 pax                       i686      3.4-10.fc12               fedora      67 k
 phonon                    i686      4.3.80-5.fc12             updates    152 k
 phonon-backend-xine       i686      4.3.80-5.fc12             updates    153 k
 qt                        i686      1:4.5.3-9.fc12            updates    3.1 M
 qt-sqlite                 i686      1:4.5.3-9.fc12            updates     46 k
 qt-x11                    i686      1:4.5.3-9.fc12            updates     13 M
 xine-lib                  i686      1.1.16.3-5.fc12           updates    2.2 M

(Or, a scary glimpse into the mind of Chris.)
I’m trying in this blog to keep a complete record of the port of LCFG to Fedora 12, blunders and all, because cataloguing mistakes, problems, bugs and their solutions can be really useful later on. However sometimes it does get a bit painful, and this is one of those times.
Remember the problems I had last week installing OpenAFS? Well, it turns out that I was being, let’s not mince words, really stupid. Whatever most of my brain was doing it wasn’t concentrating on the screen in front of me. As an illustration here’s what happened with my first problem.
I point my browser at www.openafs.org and click on 1.4.x Maintenance Release then Fedora. This shows me a page of handy links something like this:

• Fedora
  • Version 10
  • Version 11
  • Version 12
  • Version 8
  • Version 9

But in my haste to get along I read something like this:

• Fedora
  • Version 10
  • blah
  • blah
  • some old Fedora
  • some older Fedora

… and thought “that’s funny, I can’t see any download links for Fedora 12 or Fedora 11″. And this happened every time I checked that page: I so expected the links to be in order of Fedora release date, most recent first, that it overrode my perceptions completely.

Secondly: once I had (somehow) found the correct download area anyway, and downloaded the packages, an examination of my command history shows me managing to try just about every possible combination of RPM installs except the correct ones. I installed the dkms version of the kernel module RPM, but Fedora 12 doesn’t come with dkms by default so I got the dkms dependency error. Then I tried installing the correct kind of kernel module package (the “kmod-openafs” one) managed to get the correct kernel version number (the kernel module packages are provided for a number of kernels, very handy) but picked the package for non-PAE kernels. Guess what, my Fedora 12 machine has a PAE kernel. So that explains the dependency problems I saw there. All I needed to do at that point was install the PAE version of the kmod-openafs package instead; but no, instead I took a bizarre detour into the past and started compiling an old-style “openafs-kernel” package instead, in the hopes that that would work. It did, eventually, but here’s what I should have done:

• Navigate to the OpenAFS 1.4.x Maintenance Release download area
• Scroll down, download and install the openafs-repository-1.4.11-1.noarch.rpm. This provides a repository definition to let yum use the OpenAFS.org binary distribution provided from http://dl.openafs.org.
• The command yum install openafs-client kmod-openafs then automagically finds the correct RPMs for your kernel version and installs them for you. Very neat.
• Then start the openafs-client service, do an aklog and Bob’s your uncle. Simple. Five minutes.

Coming up this week: more speed, less haste. Or at least less haste.

My goodness. Throwing caution to the wind,
rpm -i --nodeps
works a treat. I install the openafs-kernel RPM; start up the openafs-client service; aklog; and hey presto, I have read-write access to our AFS directories.

Good news: I’ve made some progress. Bad news: not much progress, and it still feels like I’m wading through treacle.

An rpm -qi openafs gives you the rebuilding instructions which tell you among other things how to rebuild the kernel module. I rebuilt the kernel module like so:
rpmbuild -ba --define "build_modules 1" --target=i686 openafs.spec
This produced a package file named kmod-openafs-1.4.11-1.1.2.6.31.12_174.2.3.fc12.i686.rpm.
However this doesn’t install as the machine doesn’t use dkms, you get dependency problems. And the openafs instructions say to install an RPM called openafs-kernel not one called kmod-openafs anyway. Turns out you can tell it to build an old-style kernel module instead like so:
rpmbuild -ba --define "build_modules 1" --define "fedorakmod 0" --target=i686 openafs.spec
This produces a package file named openafs-kernel-1.4.11-2.6.31.12_174.2.3.fc12.i686.PAE_1.1.i686.rpm
Hooray! This is what I’ve needed all along.
So I install it:

# rpm -i /root/rpmbuild/RPMS/i686/openafs-kernel-1.4.11-2.6.31.12_174.2.3.fc12.i686.PAE_1.1.i686.rpm
error: Failed dependencies:
	kernel-i686 = 2.6.31.12-174.2.3.fc12.i686.PAE is needed by openafs-kernel-1.4.11-2.6.31.12_174.2.3.fc12.i686.PAE_1.1.i686

The installed kernel package provides these dependency targets:

# rpm -q --provides kernel-PAE-2.6.31.12-174.2.3.fc12.i686
kernel = 2.6.31.12-174.2.3.fc12
kernel-drm = 4.3.0
kernel-drm-nouveau = 15
kernel-i686 = 2.6.31.12-174.2.3.fc12.PAE
kernel-modeset = 1
kernel-uname-r = 2.6.31.12-174.2.3.fc12.i686.PAE
kernel-xen = 2.6.31.12-174.2.3.fc12
linux-gate.so.1  
linux-gate.so.1(LINUX_2.5)  
kernel-PAE = 2.6.31.12-174.2.3.fc12
kernel-PAE(x86-32) = 2.6.31.12-174.2.3.fc12

So the openafs-kernel RPM wants kernel-i686 = 2.6.31.12-174.2.3.fc12.i686.PAE but the kernel package doesn’t provide this. It does provide both kernel-i686 = 2.6.31.12-174.2.3.fc12.PAE and kernel-PAE = 2.6.31.12-174.2.3.fc12 but neither of these are good enough.
*Headdesk*
I suppose I could hack the openafs spec file for now to get me going, and fix the problem properly later. Or maybe I’ve missed something in the openafs RPM rebuild instructions.

I’ve found the instructions…
Clue: /usr/src/openafs-kernel-1.4.11/README

Starting the openafs client shows an error:

# /etc/rc.d/init.d/openafs-client start
Updating CellServDB: 
Starting openafs-client: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
FATAL: Module openafs not found.
failed to load openafs kernel module.                  [FAILED]

There was no openafs-kernel package, only an openafs-kernel-source package, which I had installed. I suppose this means that my vague hope that it would automagically compile somehow has been dashed, then…

The AFS wiki seems helpful – with its help I now at least have aklog

I’m reading these instructions: http://www.dementia.org/twiki/bin/view/AFSLore/InstallOpenAFSClient

Kerberos is working – I copied Graham’s suggested /etc/krb5.conf.

LDAP lookups are also working:

• I added the openldap-clients package (to get ldapsearch)
• ignored /etc/ldap.conf
• threw away the supplied /etc/openldap/ldap.conf and replaced it with
  URI ldap://dir.inf.ed.ac.uk
BASE dc=inf,dc=ed,dc=ac,dc=uk

• Typed ldapsearch -x to use simple authentication instead of SASL. Otherwise ldapsearch fails.

I’m now wondering:

• Do I need to make the SASL GSSAPI stuff work? I gather that in this context this is some way of connecting LDAP lookups to Kerberos but I’m hazy on the details.
• What do I need LDAP for anyway?
• How to tackle OpenAFS. The OpenAFS docs only go up to Fedora 10. By hacking URLs I converted a Fedora 10 OpenAFS download location into a Fedora 12 one and got some packages, but my attempts to install and configure them haven’t met with success. I haven’t even managed to install an aklog command – though there does seem to be a klog (which fails with Unable to authenticate to AFS because Authentication Server was unavailable). The openafs-info list seems to have some hints about what to do but I don’t currently know enough to understand how they fit in to the jigsaw. Perhaps there’s a wiki with useful info on it? I’ll try that next.

The Fedora 12 LCFG port starts not with a bang but with a whimper.

I’ve installed Fedora 12. That’s easy enough. But getting the machine onto the network, and getting Kerberos and LDAP working, is like wading through treacle. It’s fighting me every step of the way. This should be easy shouldn’t it? These modern Linux installers are meant to be idiot-proof.

Once I eventually got the machine onto the correct subnet, with the correct IP address, with a network wire which definitely worked and did provide a working connection, I hit a DHCP problem – the machine wasn’t being served by the DHCP server. I’d forgotten to specify the machine’s MAC address in its stub LCFG profile (which contributes to the spanning map which drives the DHCP servers). Doh.

This accomplished I reinstall again (I’ve already been through lots of reinstalls up to this point – the Fedora installer is getting to look very familiar) but continually hit a problem with the system config screens which come up immediately post installation. I enter my account details, a root password, network details, then configure Network Login. This lets me configure Kerberos and LDAP amongst other things. But with Network Login, however I try to configure LDAP I end up with a machine which just sits there dumbly when I try to login to it.

After another reinstall I try configuring just Kerberos, leaving LDAP off, and this time I can at least login. However a klist reveals nothing, I can’t ping any other machines, I’m not even on the network it seems. After some more experimentation it seems that I have to configure the network some more after login: System -> Administration -> Network, double click “eth0″, then enable “Activate device when computer starts”. I find it bizarre that this is not enabled by default, and more bizarre that the post-install screens don’t offer you a way to turn the network on. You’d think it would be kind of necessary to LDAP and Kerberos and the like to have a working network? Anyway, another reboot, and hey presto, I can login and after doing so I see something meaningful from a klist. I can even ping other computers.

For my next trick I shall try to re-enable LDAP. (Watch me reduce a Dell 745 to an unresponsive heap of junk once more.)

It’s change time for my development projects. The TiBS LCFG project is now complete, at least complete enough to be going on with; further developments will be tackled at some point in the Further Improvements to TiBS Component project. The next two weeks of my development time will be spent on the Server Hardware Interaction project then after that I’ll concentrate on the port of LCFG to Fedora 12. (These links are to our devproj project development site, for which you’ll need to be an authenticated School of Informatics user; if you don’t have an Informatics account you can make your own using iFriend.)

Server Hardware Interaction is a rag-bag of things which our servers could do with. First on the list is some sort of monitoring of the ambient temperature, so the machines can shut themselves down cleanly when it gets too hot (we still haven’t got the bugs fully out of our shiny new air conditioning plant). Currently the machines carry on running until each server reaches the pre-set critical point for its motherboard at which point power is cut, which saves the hardware from harm but doesn’t do the data much good. A clean shutdown would be preferable. This’ll give us a safe fall-back procedure; we can then put cleverer stuff in front of that if we like to for example shut down less important servers in a sacrificial manner when the temperature starts to rise too much. Next on the list is RAID monitoring – we need our Nagios monitoring system to alert us when a machine’s RAID disk has gone. Lower down the list is the issue of automatically (or otherwise) keeping the firmware and BIOS versions of our controllers and hardware in general up to date to help avoid problems.

Our servers are mostly Dells and OMSA is designed to deal with a lot of this stuff automatically, but our understanding is that it takes rather more control of the machine than we’re comfortable with; we’ll probably take a look at it and see if we can use bits of it, though.

Finally, it’s been a long time since my last entry here. That time was mostly spent in a long winter holiday in southern India. I’ve started putting photos up on the web from that holiday. You can see them at my photo page. At the time of writing that has pictures of Mysore, of rural Karnataka and Tamil Nadu from the train, and of rangoli or devotional decorations which are drawn on the ground every morning in front of houses.