On Sat, 2009-04-18 at 16:10 +0200, Sergio Gelato wrote: > You almost make it sound like /etc/nsswitch.conf ought to be a > conffile after all. But then why are you editing it in postinst? > (Unconditionally, I may add: the admin doesn't get a chance to say > "leave nsswitch.conf alone"; you're asking a series of yes/no > questions for the various services and always call either nss_enable > or nss_disable for each of them.)
I'm not saying nsswitch.conf should be a conffile. What I'm saying is that if an admin manually made changes to a file, those changes should not be automatically undone when some package is removed. There is no way for nss-ldapd's postrm to determine if the entries in nsswitch.conf were put there by an administrator manually or by nss-ldapd's postinst. I don't agree with your assessment that nss-ldapd edits nsswitch.conf unconditionally. The default is to leave nsswitch.conf alone (the selected defaults for the debconf multiselect) and only edit it if the admin selected to enable (or disable) ldap through debconf questions. I see the postinst like a limited, but easy, editor of nsswitch.conf only for LDAP lookup purposes. I agree that if a package automatically edits nsswitch.conf in postinst it should undo those edits in postrm (either at remove or purge). > I certainly agree that it must be possible for an admin to edit > nsswitch.conf "manually" (maybe with a helper tool, but your > nss_enable() and nss_disable() don't support the full range of > possible syntax; things like [NOTFOUND=return] come to mind, not to > mention the choice of ordering when multiple name services are > enabled). I agree that the way nss_enable() and nss_disable() are a very poor solution to full nsswitch.conf editing. The postinst questions are meant as an easy way for people to easily get a works-in-most-cases configuration up and running. What the config script does is a trade-off between complexity and ease of use. For most people just installing the package and answering the questions should be enough to get a working installation. I think that is expected of a Debian package. > I have yet to see a PAM module package that edits files in /etc/pam.d/ > on installation or removal. I think it would be more consistent for > NSS module packages to likewise leave nsswitch.conf alone (libnss-ldap > does it this way, for example); but since a decision seems to have > been made that editing nsswitch.conf in postinst/prerm is OK, then for > consistency one should undo those edits on purging the package (maybe > even on simple removal). The reason I implemented nsswitch.conf editing at installation was to get LDAP name resolution up and running right after installation. It was one of the things I found missing from nss_ldap. About PAM, actually I understand that PAM module authors are encouraged to provide information so the modules can be automatically enabled. See: http://lists.debian.org/debian-devel/2009/03/msg00003.html (haven't read this completely yet though so I may be missing something) > Maybe a workable compromise would be for nss-ldapd's config script to > ask one more question, i.e. whether nsswitch.conf should be managed > manually or by debconf, and use the recorded answer at prerm time. I don't like this solution much because you are asked at install time to make a decision about what to do when the package is removed (which could be years later) and Debconf answers aren't meant to persist that long. Also, nsswitch.conf isn't "managed" by debconf, the user is asked whether a simple change should be made to it. I think I'm going for the prompt-on-remove (and/or purge) option until a better solution comes along. > The next step might be to refactor the editing of nsswitch.conf out of > the individual nss module packages into an update-nsswitch command; > but that would require a broader discussion. I agree that such a tool would be a good thing. My solution sucks anyway ;-). There was a GSOC project about this. Some information about this can be found here: http://gnucrash.wordpress.com/category/google-summer-of-code/ http://www.milliways.fr/2009/01/28/debian-2008-where-now-2/ http://bugs.debian.org/496924 http://bugs.debian.org/496915 Anyway, thanks for your feedback. It's always good to get different perspectives on these kind of things. -- -- arthur - [email protected] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
