From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 10 00:58:48 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8519F16A40F for ; Wed, 10 Jan 2007 00:58:48 +0000 (UTC) (envelope-from SRS0=e45MbK=GT=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout17.yourhostingaccount.com (mailout17.yourhostingaccount.com [65.254.253.139]) by mx1.freebsd.org (Postfix) with ESMTP id 49AC313C45E for ; Wed, 10 Jan 2007 00:58:48 +0000 (UTC) (envelope-from SRS0=e45MbK=GT=vvelox.net=v.velox@yourhostingaccount.com) Received: from scan06.yourhostingaccount.com ([10.1.1.236] helo=scan06.yourhostingaccount.com) by mailout17.yourhostingaccount.com with esmtp (Exim) id 1H4RZ8-0007dj-W3 for freebsd-hackers@freebsd.org; Tue, 09 Jan 2007 19:43:43 -0500 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] ident=exim) by scan06.yourhostingaccount.com with spamscanlookuphost (Exim) id 1H4RZ8-0005RL-Fc for freebsd-hackers@freebsd.org; Tue, 09 Jan 2007 19:43:42 -0500 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] helo=authsmtp09.yourhostingaccount.com) by scan06.yourhostingaccount.com with esmtp (Exim) id 1H4RZ6-0005R7-OQ for freebsd-hackers@freebsd.org; Tue, 09 Jan 2007 19:43:40 -0500 Received: from [69.92.217.33] (helo=vixen42) by authsmtp09.yourhostingaccount.com with esmtpa (Exim) id 1H4RZ5-0005I9-Lj; Tue, 09 Jan 2007 19:43:40 -0500 Date: Tue, 9 Jan 2007 18:43:46 -0600 From: Vulpes Velox To: Doug Barton Message-ID: <20070109184346.135e0bf4@vixen42> In-Reply-To: <45A407D1.9030101@FreeBSD.org> References: <20070107190616.73dee7b0@vixen42> <45A1DE76.7000201@FreeBSD.org> <20070108185247.2b6e1f69@vixen42> <45A407D1.9030101@FreeBSD.org> X-Mailer: Claws Mail 2.7.0 (GTK+ 2.10.7; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: Vulpes Velox Cc: freebsd-hackers@freebsd.org Subject: Re: LDAP integration X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 00:58:48 -0000 On Tue, 09 Jan 2007 13:23:29 -0800 Doug Barton wrote: > Vulpes Velox wrote: > > On Sun, 07 Jan 2007 22:02:30 -0800 > > Doug Barton 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.