
Re: [nssldap] release 0.2 of nss-ldapd
[Date Prev][Date Next] [Thread Prev][Thread Next]Re: [nssldap] release 0.2 of nss-ldapd
- From: Klaus Steinberger <Klaus.Steinberger [at] physik.uni-muenchen.de>
- To: Buchan Milne <bgmilne [at] staff.telkomsa.net>
- Cc: Ralf Haferkamp <rhafer [at] suse.de>, nssldap [at] padl.com, Arthur de Jong <arthur [at] ch.tudelft.nl>
- Subject: Re: [nssldap] release 0.2 of nss-ldapd
- Date: Tue, 19 Jun 2007 11:34:06 +0200
> > A syncrepl replica would not be a good choice, as it would only talk with > > OpenLDAP. There are other LDAP Servers out there (and for some good > > reason) like Novell's Edirectory. > > I don't think the paragraph above was to mean that *only* syncrepl should > be allowed. But, do note that syncrepl is RFC'd, hopefully we should see > more servers support it in future. Don't forget that some LDAP Server (like Edirectory) are internally something very different, mostly more related to X.500 and support some very different types of attributes, authentication schemes and so on. > > Also I think a proxy slapd is a bad choice too for those reasons: > > > > - a too big thing for every workstation , like shooting with guns on > > little birds > > ??? > > In the past I have run slapd instances on laptops just to have disconnected > authentication ... A full blown slapd is definitly much more code than a specialized daemon. Please "keep it simple and stupid" !! > > - too complicated setup > > At present. But, what if one were to have another binary built from > OpenLDAP source which set itself up as a proxy-cache, where you only needed > to configure it with the values you currently use to configure nss_ldap ? Ok, but I don't want the big binary. > > > - it will have maybe also trouble with some other LDAP servers > > ??? For the reasons I wrote up there, think of the very different password mechanism of E-directory. > > So please do it "KISS" > > > > From what I have read in the discussion, a daemonized nss_ldap sounds > > like a interesting solution, it looks like it really solves some of the > > trouble I see with nss_ldap (even blocking the whole net on a dead > > nameserver). And it seems to be a simple enough setup. > > But, it may be possible to keep the simplicity, but have a more robust and > capable solution by going another route. Maybe.... Sincerly, Klaus -- Klaus Steinberger Beschleunigerlaboratorium Phone: (+49 89)289 14287 Am Coulombwall 6, D-85748 Garching, Germany FAX: (+49 89)289 14280 EMail: Klaus.Steinberger@Physik.Uni-Muenchen.DE URL: http://www.physik.uni-muenchen.de/~Klaus.Steinberger/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
- Re: [nssldap] release 0.2 of nss-ldapd, (continued)
- Re: [nssldap] release 0.2 of nss-ldapd, Arthur de Jong
- Re: [nssldap] release 0.2 of nss-ldapd, Volker Lendecke
- Re: [nssldap] release 0.2 of nss-ldapd, Howard Chu
- Re: [nssldap] release 0.2 of nss-ldapd, Buchan Milne
- Re: [nssldap] release 0.2 of nss-ldapd, Klaus Steinberger
- Re: [nssldap] release 0.2 of nss-ldapd, Andreas Hasenack
- Re: [nssldap] release 0.2 of nss-ldapd,
Howard Chu
- Re: [nssldap] release 0.2 of nss-ldapd, David Houlder
- Prev by Date: Re: [nssldap] release 0.2 of nss-ldapd
- Next by Date: Re: [nssldap] release 0.2 of nss-ldapd
- Previous by thread: Re: [nssldap] release 0.2 of nss-ldapd
- Next by thread: Re: [nssldap] release 0.2 of nss-ldapd