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?

** Patch added: "Patch Rev 9"
   
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3646993/+files/nslcd-upstart-9.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761

Title:
  Feature Request: Upstart scripts for nslcd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to