From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 10 23:37:31 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 B6A0916A55A for ; Wed, 10 Jan 2007 23:37:30 +0000 (UTC) (envelope-from SRS0=e45MbK=GT=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout16.yourhostingaccount.com (mailout16.yourhostingaccount.com [65.254.253.133]) by mx1.freebsd.org (Postfix) with ESMTP id 06B2D13C467 for ; Wed, 10 Jan 2007 23:37:29 +0000 (UTC) (envelope-from SRS0=e45MbK=GT=vvelox.net=v.velox@yourhostingaccount.com) Received: from scan08.yourhostingaccount.com ([10.1.1.238] helo=scan08.yourhostingaccount.com) by mailout16.yourhostingaccount.com with esmtp (Exim) id 1H4n0b-00040K-CQ for freebsd-hackers@freebsd.org; Wed, 10 Jan 2007 18:37:29 -0500 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] ident=exim) by scan08.yourhostingaccount.com with spamscanlookuphost (Exim) id 1H4n0a-0000U4-4G for freebsd-hackers@freebsd.org; Wed, 10 Jan 2007 18:37:28 -0500 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] helo=authsmtp09.yourhostingaccount.com) by scan08.yourhostingaccount.com with esmtp (Exim) id 1H4n0Y-0000U0-Lp for freebsd-hackers@freebsd.org; Wed, 10 Jan 2007 18:37:26 -0500 Received: from [69.92.217.33] (helo=vixen42) by authsmtp09.yourhostingaccount.com with esmtpa (Exim) id 1H4n0X-0001oY-Nd; Wed, 10 Jan 2007 18:37:26 -0500 Date: Wed, 10 Jan 2007 17:37:26 -0600 From: Vulpes Velox To: Lamont Granquist Message-ID: <20070110173726.466bdc48@vixen42> In-Reply-To: References: <20070107190616.73dee7b0@vixen42> <45A1DE76.7000201@FreeBSD.org> <20070108185247.2b6e1f69@vixen42> <45A407D1.9030101@FreeBSD.org> <20070109184346.135e0bf4@vixen42> 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, Doug Barton 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 23:37:31 -0000 On Wed, 10 Jan 2007 13:26:57 -0800 (PST) Lamont Granquist wrote: > > > > On Tue, 9 Jan 2007, Vulpes Velox wrote: > > 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. > > Why are you doing this in the FreeBSD rc scripts directly? Why not > install cfengine and work on making cfengine play better with > database-driven config? I've looked at it once a long time ago and have looked at it again today. It has never held my interest for too long. I find perl and LDAP much more interesting. More user friendly as well. > And if you're looking specifically at the /etc/rc.conf config file, > what would be more useful would be an /etc/rc.conf.d/ directory. > That gets away from the need to tweak and edit the /etc/rc.conf > config file with multiple inputs tweaking a single file. Instead > you can drop whole orthogonal fragments into /etc/rc.conf.d/inetd > to manage the inetd config which would make it more friendly to > radmind-like approaches. It also makes it easier to use with > cfengine since orthogonal cfengine modules aren't doing editfiles > touches to the same files. The /etc/cron.d directory that (most?) > linux distros have is similarly very useful to drop in files that > contain completely orthogonal config (and may be written by > entirely different config management tools -- e.g. system config > management vs. application deployment/management), and > the /etc/periodic functionality is not flexible enough to cover all > cases. This honestly sounds like a massive and complete pain in the ass. I don't even see how this is remote admin friendly. It just means way more to muck around with. If cfengine can not generate rc.conf in a nice manner, it seems more like a problem with cfengine. On a similar note, rc.conf.local supported? I saw it referenced in the man file for rc.conf, but never hear any thing about it and I've not finished picking rc.subr apart yet.