Date: Wed, 10 Jan 2007 17:00:04 -0800 (PST) From: Lamont Granquist <lamont@scriptkiddie.org> To: Vulpes Velox <v.velox@vvelox.net> Cc: freebsd-hackers@freebsd.org, Doug Barton <dougb@freebsd.org> Subject: Re: LDAP integration Message-ID: <Pine.GSO.4.60.0701101651530.6289@sploit.scriptkiddie.org> In-Reply-To: <20070110173726.466bdc48@vixen42> References: <20070107190616.73dee7b0@vixen42> <45A1DE76.7000201@FreeBSD.org> <20070108185247.2b6e1f69@vixen42> <45A407D1.9030101@FreeBSD.org> <20070109184346.135e0bf4@vixen42> <Pine.GSO.4.60.0701101316300.5305@sploit.scriptkiddie.org> <20070110173726.466bdc48@vixen42>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Jan 2007, Vulpes Velox wrote: >> 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. Actually, cfengine is perfectly capable of doing that, it has an obscenely flexible ability to edit files 'in place' to do this kind of tweaking and tuning to manage monolithic config files like rc.conf or inetd.conf which may have orthogonal configuration inputs from different apps running on the machine. The problem is that with orthogonal inputs to the same config file it becomes more likely that entirely seperate pieces of config will be twiddling the same file, and those pieces of code will be built and maintained by entirely different people and that increases the chances of simple file editing errors. Once you start hitting the problem of dozens of system admins trying to collaboratively manage 1000s of systems these kinds of issues come up. They're not apparent when you've got single administrative owners for all the machines. The radmind model of system configuration alone, however, doesn't let you do this since it is built around pushing only whole files. You can construct all the different flavors of the monolithic files that you're managing and try to make sure that the correct image gets on the correct system but that requires higher-level wrapping -- or you can just have radmind call out to cfengine to construct files like this. Still, avoiding monolithic files makes system configuration friendlier to those who use the radmind-approach.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.60.0701101651530.6289>