LDAP integration

[Vulpes Velox]

On Tue, 09 Jan 2007 13:23:29 -0800
Doug Barton <dougb at FreeBSD.org> wrote:

> Vulpes Velox wrote:
> > On Sun, 07 Jan 2007 22:02:30 -0800
> > Doug Barton <dougb at FreeBSD.org> wrote:
> > 
> >> Vulpes Velox wrote:
> >>> I was just wondering. How many people here have given lots of
> >>> though about integrating FreeBSD configuration with LDAP. I've
> >>> just begun looking at it a lot more and was curious as to what
> >>> other people think in this area.
> >> It would be more useful to have this discussion if you defined
> >> what you meant by "FreeBSD configuration" in more detail. You
> >> might also want to search the archives first, there is a lot of
> >> discussion about various proposals in this area, all of which
> >> end up getting shot down because they don't offer sufficient
> >> added value to justify the pain of the change.
> > 
> > I mean exactly that. Initially I have begun looking at rc.conf as
> > a logical starting point.
> 
> Why do you consider rc.d to be a logical starting point? The issue
> of nss integration is much more useful, especially given that there
> is critical mass for support to bring ldap into the base to make
> this happen.

I do want to see it in the base, but what I want is even less
intrusive than this.

I want to get the infastructure in place for supporting doing this
type of thing. I am largely focusing on the idea of LDAP right now,
but I see no reason the base part can't be written in a neutral
manner that it can non-instrusively be included in the base in little
more than a single rc.d for kicking off a program specified in
rc.conf to take care of that. This allows the user to easily choose
from a system from the ports that fits their need.

What I am thinking is a the rc.d file runs the command specified,
the program or script prints a list of files it is going to update,
those files are then backed up, and the program then installs the new
files. Upon not being able to update, it can be leave the files in
place, run a specified command, or pull in a set of default files.

What do you think? :)

> > Initially I think seeing a rc.d stuck right in right after
> > NETWORKING would be very interesting to have. Right after
> > NETWORKING is finished, a program is kicked off that updates a rc
> > file that is then included after parsing rc.conf.
> 
> You've stated what you want to do, but you haven't said why. Please
> note carefully what I said above. You need to demonstrate
> SIGNIFICANT added value for this proposal to get any kind of serious
> consideration. All you've said so far is, "this would be neat!" I
> was serious about searching the archives, this ground has been
> pretty well covered.

The why is because I like centralized management and it would be
really handy for that. For my use, it would be handy in regards to my
laptops.

I feel better central management is extreme significant. If I had
nothing more to say than "this would be neat!" we would not still be
talking. Right now I am just poking around for other people 

I regards to searching the archives, I am not seeing any thing in
regards to LDAP outside of NSS recently. I am also not finding any
thing in regards to dynamically and automatically building various
config files.

> And yes, in case you're wondering, I _am_ being a bit harsh, but
> it's for a purpose. Unless you really want to do it anyway, I don't
> want there to be any confusion down the road when you come back to
> us with a massive patch you expect to be integrated.

There will be no massive patch for it, given it involves little more
than the inclusion of a single rc.d file and a bit of documentation.