[17415] in Kerberos_V5_Development
Re: SASL support for kldap
daemon@ATHENA.MIT.EDU (Chris Hecker)
Tue Nov 15 02:13:16 2011
Message-ID: <4EC210A2.7060601@d6.com>
Date: Mon, 14 Nov 2011 23:11:30 -0800
From: Chris Hecker <checker@d6.com>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <4EC144E0.6020008@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
> it but it's never used). Beyond that, we'd want to introduce a more
> structured convention for differentiating LDAP options between the
> KDC and kadmind before introducing 13 new config parameters with
> global, KDC, and kadmind variants.
Is there a limit on the depth of the profile nesting? In other words,
is this valid?
[dbmodules]
ldapconf = {
dbname = ldap
db_library = kldap
ldap_kadmin = {
ldap_tls_cert_file = blah
}
}
I've only ever seen three levels, not four, but I'm not very experienced
here. If it works (profile_add_relation looks like it would at a quick
glance), you could imagine reusing the same parameters and checking the
ldapconf, ldap_kadmin, and ldap_kdc levels for the most specific
version, which would get rid of a bunch of the names.
Or, were you talking about some more general solution, not sure for this
case?
> * There's also a lot of repeated code for processing these options.
> That would need to be refactored.
Ah, I didn't look at the patch yet.
Chris
On 2011/11/14 08:42, Greg Hudson wrote:
> On 11/14/2011 12:22 AM, Chris Hecker wrote:
>> Any hope of getting this integrated into the trunk?
>
> We have been regrettably slow about processing this work, due to
> resource constraints. I do have some notes about it, which I should
> have sent long ago:
>
> * There is a lot of duplication of parameter names for
> KDC/kadmind/kpasswdd. It turns out that kpasswdd isn't a separate
> service as far as the DAL is concerned (there's a constant defined for
> it but it's never used). Beyond that, we'd want to introduce a more
> structured convention for differentiating LDAP options between the KDC
> and kadmind before introducing 13 new config parameters with global,
> KDC, and kadmind variants.
>
> * There's also a lot of repeated code for processing these options.
> That would need to be refactored.
>
> * We would need to document this while integrating it, since the patch
> doesn't include amendments to our texinfo documentation (or the RST
> conversion of it).
>
> * We would need to test this, at least manually, while integrating it,
> which requires a fair amount of spin-up time on OpenLDAP setup. (Adding
> automated testing for the LDAP back end is on my private hit list for
> 1.11, but I don't know if testing SASL access is likely to be feasible
> when I do that.)
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
