From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 11 02:10: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 43A1516A580 for ; Thu, 11 Jan 2007 02:10:48 +0000 (UTC) (envelope-from SRS0=LVA8ua=GU=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout06.yourhostingaccount.com (mailout06.yourhostingaccount.com [65.254.253.51]) by mx1.freebsd.org (Postfix) with ESMTP id 0149813C457 for ; Thu, 11 Jan 2007 02:10:47 +0000 (UTC) (envelope-from SRS0=LVA8ua=GU=vvelox.net=v.velox@yourhostingaccount.com) Received: from scan03.yourhostingaccount.com ([10.1.1.233] helo=scan03.yourhostingaccount.com) by mailout06.yourhostingaccount.com with esmtp (Exim) id 1H4pAK-0004Mg-Q3 for freebsd-hackers@freebsd.org; Wed, 10 Jan 2007 20:55:40 -0500 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] ident=exim) by scan03.yourhostingaccount.com with spamscanlookuphost (Exim) id 1H4pAK-0003VY-KM for freebsd-hackers@freebsd.org; Wed, 10 Jan 2007 20:55:40 -0500 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] helo=authsmtp09.yourhostingaccount.com) by scan03.yourhostingaccount.com with esmtp (Exim) id 1H4pAJ-0003VR-Eo for freebsd-hackers@freebsd.org; Wed, 10 Jan 2007 20:55:39 -0500 Received: from [69.92.217.33] (helo=vixen42) by authsmtp09.yourhostingaccount.com with esmtpa (Exim) id 1H4pAI-00036r-4e; Wed, 10 Jan 2007 20:55:39 -0500 Date: Wed, 10 Jan 2007 19:55:39 -0600 From: Vulpes Velox To: Lamont Granquist Message-ID: <20070110195539.68e60812@vixen42> In-Reply-To: References: <20070107190616.73dee7b0@vixen42> <45A1DE76.7000201@FreeBSD.org> <20070108185247.2b6e1f69@vixen42> <45A407D1.9030101@FreeBSD.org> <20070109184346.135e0bf4@vixen42> <45A56107.5050205@FreeBSD.org> <20070110174709.534b1f16@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: Thu, 11 Jan 2007 02:10:48 -0000 On Wed, 10 Jan 2007 17:10:36 -0800 (PST) Lamont Granquist wrote: > > > On Wed, 10 Jan 2007, Vulpes Velox wrote: > > On Wed, 10 Jan 2007 13:56:23 -0800 > > Doug Barton wrote: > >> Lamont Granquist wrote: > >>> 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? > >> > >> Indeed. For a "many systems" problem, cfengine is a great tool. I > >> think the OP is more interested in the "dynamically configured > >> laptop" problem, which is also an interesting/difficult one, but > >> I don't think it's a good problem for LDAP to solve. It still > >> feels like "I have LDAP that I want to use as a solution, so > >> what problem can I point it at?" to me. > > > > Stuff like this is what LDAP truely shines for. It keeps > > everything in a nicely organized manner that is easily accessible > > and searchable. > > I agree that database-driven config management is good. I do not > agree that LDAP is the best way to go about doing it since LDAP > works best as a read-mostly directory service and not as an > mixed-read/write database which is what I've seen these kinds of > configuration management databases scale and turn into. LDAP is > great for stuff that barely ever changes. When you add SOX audit > trails and error reporting and other junk into the database LDAP > stops being appropriate. Right. LDAP should not be used for logging at all. That is what SQL is awesome for. :) > I also don't understand the focus on dynamically > generating /etc/rc.conf since that is actually not what I want in > my database. Inside my database I want to configure a machine as > an ftp server or a web server and deal with the high-level roles > that the machine plays. In order to generate an rc.conf file I > want to take the roles as inputs and construct the rc.conf file > specific to the machine. I am starting with rc.conf because it is a logical place to start for what I want. I am not interested in the autoconfiguration stuff in this project. Just reeling in the configuration, I am largely focusing LDAP because it is what would be most handy in my situation, but I am aiming at the idea of making that part is interchangable. I plan to start work the actual parts, once I am happy with the schema. That is going to take a bit of time to get worked out because there are a few things to iron out. There is also a lot of attributes that need to be defined.