F12 Progress, 12 April 2010

There's PXE but it's on zip. PXE installs therefore need a resource to say this which you can find in the lcfg file of plato. Alastair will move PXE to tummy this afternoon.

How do we maintain the install infrastructure automatically given the incompatibility between versions of RPM on SL5 and F12? We decided that for now Alastair will make a tarball rather than an RPM for tftpboot. Soon though we should replace the elderly tummy with a server running F12.

Stephen has been working on lcfg-pam. The DICE level is very complex so for inf level he's modelled it on Fedora's simpler and more understandable pam stack. While he was at it he tidied the pam setup somewhat to help make it more comprehensible. The reasons for some of the DICE pam complexity are not obvious: we could do with them being documented.

Stephen rewrote lcfg-pam in Perl. This exposed another bug in the LCFG template library! Variables are global, so their value hangs around from the processing of one template to the processing of other templates. With shell components this didn't matter as you got a fresh instance of sxprof for each template but it matters for perl components. Stephen has corrected the template processing to remove the globals.

lcfg-kerberos and lcfg-openldap have been ported to the new buildtools (hooray) and Stephen has imported them to Subversion (hooray). Chris will give them a try on F12. He could try configuring openldap in simple client mode.

Stephen has rationalised the network component somewhat with new "autoup" and "autodown" resources. This carries the penalty of the component having to query interface resources from the previous run when an interface goes away.

Alastair has been working on the installroot. The existing one sends debug messages to tty2. On F12 that can't be done reliably so instead everything is logged to /var/log/messages. At the end of the install this is copied to the newly installed machine as /var/lcfg/log/installlog or similar. We will therefore have a useful record of exactly what happened when a machine was installed. It also has the advantage of making the screen-based install messages less verbose, so errors will be more likely to stand out.

Re hardware testing, these additional tests were suggested: change virtual terminals; test the sound; test a USB key; try CDs and/or DVDs.

Re the F13Upgrade page, we should document a sample F12 profile and tell people how to install a machine.

We won't bother with build servers for now: people can use our machines.

These components can be marked up and struck off: lcfg-pam, lcfg-openafs, lcfg-sleep, lcfg-grub.

Re gdm, Stephen comments that it would be cleaner to have a new gdm component than to use lcfg-gconf, just to avoid having a big confusing pile of gconf resources, but that's not to say we couldn't reuse gconf component code. We could even maybe revert to xdm.

We should aspire to dump the ed level in the future as it's not really necessary and isn't being used for much. We'll take it to a future Deployers meeting.

Chris will move his F12 inf level mailcap settings to the lcfg level.

Here are two enhancement ideas for lcfg-auth:

  • throw a warning when removing accounts [which were added by some other method].
  • run every night from boot.run after updaterpms has run. Not only would the auth setup be guaranteed to be up to date but it could also clean up after any rogue account adjustment done in RPMs.

The F13Upgrade page now has a lot more on it; could we all check it please?

Package Lists

You can #include one package list in another. This opens up interesting options. You can have some packages effectively in two package lists because they're included from the same underlying list - so there will be no conflict as the version numbers will be the same. For instance some perl packages could be in both the devel and desktop lists.

Also, updates happen before the lcfg list. Prereqs in the lcfg list will therefore not be subject to automatic updates and conflicts will be flagged up whenever they happen. In the case of the lcfg list this is an advantage as it will make us aware of and review all updates of prereqs and check them for continued functionality.

-- ChrisCooke - 12 Apr 2010

Topic revision: r2 - 11 Aug 2010 - 08:40:14 - StephenQuinney
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies