Improving GNOME's ldap resiliency

[Jeff Schroeder <jeffschroeder computer org>]

As we move to evolve the GNOME infrastructure, it has came to my attention that:
    1.) Our ldap services sometimes go haywire and services we provide
go with it.
    2.) Our ldap master, label.gnome.org, does not have an ldap client
configured due to the chicken/egg problem.
    3.) The ldap slave in our backup (Canonical) datacenter is flaky
causing issues with services hosted there such as damned lies[1].

The sssd[2] is this nifty project written by mostly redhatters which
does the job of pam_ldap plus a lot more. Most important to us, it
does offline ldap information caching. Since we don't enable
password-based logins to our servers, it won't cache shadow attributes
but it will store group/passwd info. The package is already in EPEL
and will be the default ldap client in RHEL6. It has been in Fedora
since Fedora 11[3] and is going to be shipping with RHEL5.6.
Integrating this should be a piece of cake.

Setting up sssd on our servers fixes several existing issues:
    1.) When label goes down, users can no longer commit to gnome git.
This would have been a much bigger issue in the svn days. Yay for
dvcs!
    2.) Other services on the ldap master won't have problems if their
init script runs before ldap comes up. Example:
            Starting httpd: httpd: bad group name bugzilla [FAILED]
    3.) Home directories are mounted over NFS on all servers in our
primary (redhat) datacenter. NFS with downed ldap can get ugly unless
that info was cached locally.
    4.) ldap will no longer be perceived as a hindrance towards
rebooting label for a new kernel or some major update.

Speaking as someone who has deployed ldap + sssd in an environment
many order of magnitudes bigger than GNOME's, I highly recommend it.
In the future, sssd will support caching ssh keys (from ldap) locally
in it's own ldb cache. Do we want to explore this avenue or do we want
to continue using the the create-auth scripts? If we want to entertain
this, we should work together with upstream to integrate with our
custom ssh key ldap schema. The developers expressed they will work by
default with the openssh-lpk schema which we sadly do not use.

This email is an introduction of us to the sssd team and vice versa.
If no one voices a strong opinion against, I'm going to work on
deploying sssd over the next week or so.

[1] http://l10n.gnome.org/
[2] https://fedorahosted.org/sssd/
[3] http://fedoraproject.org/wiki/Features/SSSD
[4] http://git.gnome.org/browse/sysadmin-bin/tree/create-auth

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com