Re: RFC: Going the LDAP/Kerberos way with NetBSD.

["matthew sporleder" <msporleder%gmail.com@localhost>]

On Wed, Apr 30, 2008 at 10:15 AM, Thor Lancelot Simon 
<tls%rek.tjls.com@localhost> wrote:
> On Wed, Apr 30, 2008 at 12:43:31PM +0200, Anders Magnusson wrote:
>  > Thor Lancelot Simon wrote:
>  > >On Tue, Apr 29, 2008 at 05:16:55PM +0200, Anders Magnusson wrote:
>  > >
>  > >>- NetBSD should have an infrastructure primary based on LDAP for
>  > >>directory services and Kerberos
>  > >> for authentication, which is used in all environments as feasible.
>  > >>Let the {s}pwd.db stuff die and
>  > >>
>  > >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  > >
>  > >This will make using NetBSD on many embedded products infeasible.
>  > >
>  > Eh, how would that ever affect embedded products?  It would just be
>  > another database to search in.
>
>  With a daemon I have to run to do the searches, which, even if it's
>  small, will doubtless be considerably larger than the existing db
>  file implementation, which is tiny.
>
>  I'm concerned about size and about complexity, as well as about having
>  to analyze code that talks on the network by default when it did not
>  before -- and persuade others that there is no remote compromise where
>  there used to be only a local one.
>
>  But I think I do not object so much if the flat file search code stays
>  and it is possible to disable all LDAP support at build time just as it
>  is currently possible to disable YP.  I agree that LDAP will be vastly
>  preferable for many purposes and that a small LDAP server will be far
>  better than OpenLDAP to ship with the system.
>


OpenLDAP has ten years of development since forking from an already
industry-standard UMich ldap server.  (I couldn't figure out how old
UMich 3.x was before it was forked into all the major ldap servers of
today)  No disrespect intended, but I seriously doubt any "small
server" is going to be more secure, give any performance, or do
anything that would make it "vastly preferable for many purposes".

If netbsd wants to go the route of implementing its own ldap server,
then it should probably do its own clients as well.  Working on making
the shipped openldap "small enough" is a much better path.