Comment 30 for bug 806761

Okay, another patch rev and a big-huge post addressing Arthur's last concerns (thanks again to him for taking the time to review the patch).

-Regarding serialization of network interface bring-ups, I've addressed this by running the flock command asynchronously. As far as I can tell, this doesn't affect the serialization of nslcd startup attempts, which is all we really care about. Testing on my laptop and desktop has gone well.

This change does mean that there is the possibility of a noticeable delay between the time a network interface comes up and the time nslcd is ready to service requests, but that strikes me as more of a login management concern.

-I thought about only emitting an event when the nslcd-k5start script was actually needed. However, it would have made the nslcd script much more complicated (checking for the appropriate configuration options, etc). Having these checks in the nslcd-k5start scripted seemed like a much better separation of concerns, and also makes a future migration to a nslcd-kerberos package easier.

-I do not know of a way to model the mail server dependency info in Upstart. Perhaps someone on the ubuntu-sponsors list has an idea about this.

-I think Arthur's recommendation about waiting for a cache to be established is quite valid, but using the post-start stanza appears to be more idiomatically correct. See http://upstart.ubuntu.com/cookbook/#post-start

-I added the nscd cache invalidation so the nscd cache was refreshed whenever a connection was established to the authoritative source (i.e. the LDAP directory). However, invalidating the cache has led to problems over unstable (e.g. WiFi) connections: if the connection comes up long enough to invalidate the cache and then drops, the cache contents are lost. On the other hand, relying on the nscd cache means that current, up-to-date user/group information isn't available to the user until the nscd cache expires, times out, or is manually invalidated.

Computing the stability of a network connection is definitely outside the scope of this patch, so I've removed the cache invalidation for now. I think a good short-term solution to the issue of cache invalidation for stable connections would be a flag to control invalidation of the cache. Ideally, this flag would be per-connection.

-I agree that the use of /etc/defaults/nslcd is a bit awkward (and apparently is being deprecated), but it's not only the nslcd user and group that use expansion: several of the k5start-related variables use it as well. I think we're sort of stuck with the defaults file until expansion is available in Upstart's "env" stanza.

-I'm not seeing a lintian warning/error on Ubuntu. Since Arthur's wanting to test this out in Ubuntu first, I'd prefer to leave it as-is until such a time it seems expedient to merge the changes into Debian.

ubuntu-sponsors: it would seem Arthur prefers to have this patch tested in Ubuntu first. What's the next step forward in that process? Also, any thoughts on modeling the mailserver dependency information in Upstart?