This post provides a bit more information on that provided in the previous post Configuring stock SL6 to use DICE and LDAP changes. The main change as noted in that post is “that the package nss_ldap has been replaced by two packages – pam_ldap (containing /lib/security/pam_ldap.so and /etc/pam_ldap.conf) and nss-pam-ldapd (containing /usr/lib/libnss_ldap.so, /usr/sbin/nslcd and /etc/nslcd.conf)”.
The reasons for, and details of, this change are summarised well in Arthur de Jong’s design document.
All nss ldap lookups now go through the nslcd daemon and the configuration information which was previously all held in /etc/ldap.conf is now split between /etc/nslcd.conf (for nslcd) and /etc/pam_ldap.conf (for pam).
The lcfg-openldap component changes necessitated by this are as follows:
- There is now an openldap resource, nss_package, which should be set to either nss_ldap (f13, sl5) or nss-pam-ldapd (sl6)
- If nss_package is set to nss-pam-ldapd, the component will configure /etc/nslcd.conf and /etc/pam_ldap.conf (to the best of our knowledge, no lcfg user currently uses pam ldap authentication, so this file is minimally configured – it could of course be enhanced).
- /etc/ldap.conf is always still generated, in case other things rely on it (this will be removed in time, for nss-pam-ldapd systems)
- The resources required for nss_ldap and nss-pam-ldapd are different (see the man page for details)
- The nslcd daemon is not currently managed by the openldap componen (it’s started and stopped by the boot component) but will be restarted if lcfg-openldap modifies nslcd.conf. This is likely to change, with either the nslcd daemon being completely managed by lcfg-openldap, or its own component.
- We should consider use of nss_ldap to be deprecated in favour of nss-pam-ldapd
- These changes are implemented in lcfg-openldap-3.1.61-1 (with a
schema version of 5).
RHEL 6.1 has been released. See RHEL 6.1 release notes and RHEL 6.1 technical notes for details.
At the recent LCFG Deployers meeting we decided to alter the way we manage some of the LCFG package lists in SL6. Full details are available on the LCFG wiki.
It’s now possible to have a DICE SL6 LCFG profile. It should look
something like this:
It has to be on the develop release. Currently there is no local ldap server which means you cannot use rfe or run om as a normal user, only as root.
There is also currently no local DNS server, we’re still using the lcfg-resolvconf component rather than lcfg-dns. It might work, I’ve not tested it though.
Other than that, all the LCFG components which have been auto-built seem to be working. Even routing seems to be fine.
There is a live hacks header (
live/sl6-fixups.h) which modifies the way the standard DICE environment works. Please only use this header if there is no other way to get things working, ideally we should be adding support directly into the dice headers now.
I’ve only tested this on i386 so far, I’ve also only tried a desktop install and not the smaller ‘base-only’ install which we will use for servers.
Posted in Uncategorized
SL6 uses dracut for its initramfs. RH claims that dracut is much more capable and maintainable than the previous system. One feature of dracut is that it probes for devices (eg SCSI controllers) at boot time rather than relying on configuration derived from /etc/modprobe.conf. This means that it should no longer be necessary to include options headers for SCSI controllers in LCFG profiles – a common cause of confusion! However, it’s not yet clear to me how you can pass flags to kernel modules loaded by dracut – this will need some investigation.
I’ve now added the basic set of i686 libraries into the SL6 x86_64 package lists which should permit the running of most i686 applications (e.g. Adobe acrobat) on that platform. It adds about 60 library packages, which is not too bad, and this makes life a lot easier for anyone still stuck in the situation of having to run stupid 32bit-only binary applications on x86_64 machines. Maybe one day everything will come with multiple architecture support, how hard can it be really?
In a change from previous LCFG platforms we are not including all the internationalisation packages by default in the SL6 base or desktop package lists. The internationalisation packages are listed in the
lcfg_sl60_international.rpms package list which can be included using the
lcfg/options/international.h header file. Note that this is quite a big list, currently there are about 550 packages in there which will probably consume a large chunk of your disk space. In the past we’ve provided a facility for removing these packages, see
lcfg_sl5_removeinternational.rpms for an example, but this new opt-in approach makes more sense.
I have just been through the set of LCFG component packages which are added using individual headers (e.g.
lcfg-apacheconf is added through
lcfg/options/apacheconf.h) and built them all for SL6 using our new pkgforge service. Encouragingly, nearly all of them seem to have built without any hassle, that doesn’t mean they will necessarily work but it’s a good first step which means we can get on with the testing. We are still missing a few which have not yet made the transition from CVS to svn but that number is fewer than I thought so that is good.
The LCFG support for SL6 is stabilising nicely. I have now added the packages for all LCFG build tools. It all seems to work just fine, at least when using subversion, who still uses CVS anyway?…
It turns out that the openafs packages shipped by Scientific Linux have init-scripts which are substantially different from those in the standard packages provided on the openafs.org website. Although it was possible to start the AFS client with the LCFG openafs component we could not actually configure it correctly. I’ve now got around to fixing this problem by building the RPMs for SL6, annoyingly though this has revealed a problem with building 1.4.14 packages on SL6. We can build 1.6.0pre packages on SL6 but it looks like there is a packaging bug which prevents building 1.4.14 on SL6.