Ian Kent wrote: > On Sun, 3 Apr 2005, mzozd wrote: >> >>a) Open /etc/ldap.conf to read any rootbinddn option. >>b) Open /etc/ldap.secret to read any password if the rootbinddn option >>is in the conf. >>c) Try to initiate TLS with the server (assuming the path to the >>certifacte(s) is defined in /etc/openldap/ldap.conf). > > > We shouldn't need care about the certificate. This should be taken care of > with an API call either succeeding or failing. That is exactly what the patch does. the start_tls function is taking care of the certificate. The current patches interact with /etc/ldap.conf(pam/nss_ldap conf file) and NOT /etc/openldap/ldap.conf. Sorry if i didn't put it right. In my point of view it was obvious that the patch was not doing any "library" work. > > >>d) Bind with rootdn and password defines in the configuration files. > > > All this stuff is openldap specific. > > Can we do this via an LDAP API? There is no ldap library, as far as i know, capable of parsing the config file. Other programs (like sudo) use the same approach.
> How much of this can be done using a generalised dn? The patch is parsing the /etc/ldap.conf file in order to find any user supplied DN and /etc/ldap.secret for the password. What do you mean generalised dn? > > This may already be the case as I haven't had a look yet but can we > seperate out the LDAP implementation specific stuff to a seperate module? It is already seperated. Any further changes suggest major rewrite for the autofs module. autofs has to query TWICE (three times actually including the ldap bind test) the ldap server in order get 1) the autofs ldap auto master entries(via /usr/lib/autofs-ldap-auto-master) and 2) retrieving the e.g ldap auto.home entries via automount daemon. > > > > I have another patch that generalises the dn format and cleans up the LDAP > module. It looks quite good but is very much out of date. The LDAP module > is quite ugly and certainly needs work. Please, supply a url where i can see that patch. > > It's going to be quite a big job to merge these patches. Hopefully > we can work together on this. We can try to work together on that. What troubles me, is the enormous number of patches available at the autofs directory. What is the policy for patching autofs ? Please note: Me, and other people using CRUX, are already using this patch with no problems. Thank you for your reply, MzOzD > > Ian > > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
