Date: Wed, 15 Mar 2000 18:24:38 -0500 (EST) From: Thomas Stromberg <tstromberg@rtci.com> To: Andrew Reilly <areilly@nsw.bigpond.net.au> Cc: freebsd-arch@freebsd.org Subject: Re: Time for an /etc/ipv6 directory? (/etc in ldap?) Message-ID: <Pine.GSO.4.20.0003151803470.5932-100000@barracuda.aquarium.rtci.com> In-Reply-To: <20000316094416.A84559@gurney.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
I tend to agree here, I envision FreeBSD some day coming with OpenLDAP
built in, reading most of the config from (through nsswitch, et al.) a
directory service. Lots of problems would have to be conquered of course
with a method like that, such as:
- ease of getting the system up when it's broken enough that networking
isn't happy but that single user still works. Anyone who's dealt with
netinfo in NeXTstep knows what I'm talking about (especially when you
forget the root password).
- revision control. revision control is nice and easy with text files, we
use it for all of our servers here. Some trickery would be involved.
- ease of dealing with data. theres nothing like just having text files to
pipe through. Having a virtual fs that's talking to the ldap server would
of course be fun, but the whole issue of dependencies in having this work
if the system is in single user mode gets messy.
For example, I have a bad habit of preferring to mess with mysqldump files
in perl rather then setting up the database queries & connectivity. nis+
admins can sympathize here. I also doubt that mergemaster will be
directory aware to 'sync' any changes to the directory server for the
files kept in it.
The relationship of Directory Services and UNIX should be less
outlandish now that Solaris 8 includes a 200,000 user license for iPlanet
Directory Server, and the internal capabilities for using LDAP for
nsswitch'd items. I can't wait for the day that I can setup custom ldap
queries for who the valid accounts off of the main database should be on
the system.
As far as the symlink farms, I wholeheartedly agree. I won't even mention
some of the nasty problems encountered when we first started maintaining
all of the config as a cvs tree on our Solaris boxes. Symlinks are only
good for backwards compat, but I'm not sure how many apps/scripts there
are out there that actually expect to see /etc/protocols there rather then
using OS functions. Evidentally there were enough for Sun to make a mess
out of /etc.
I do however doubt that /etc will dissappear any time soon with a
directory server, or any kind of metabase. Theres just too much work/too
little gain from putting it all in there. /etc/rc* isn't going to go
anywhere anytime soon. I would like to however eventually see the tools
required to move the standard stuff (/etc/passwd, /etc/group, /etc/hosts,
etc.) through some scripts & nsswitch, and have the installation ask you
whether or not you want to be setup as a Directory master or a Directory
client.
Not sure if any further discussion on this dreamy directory-based world
should go to -hackers.. but I think I've spoken of utopia long enough now.
=======================================================================
Thomas Stromberg, Assistant IS Manager/Systems Guru
smtp://tstromberg@rtci.com Research Triangle Consultants, Inc.
=======================================================================
"if you do nothing enough, something's bound to happen.."
=======================================================================
On Thu, 16 Mar 2000, Andrew Reilly wrote:
> I think that symlink farms are a bad idea, and in this case they
> defeat the only purpose that increasing the depth of the /etc
> hierarchy could serve.
>
> I'd like to see /etc eventually be replaced by a portal file system
> accessing a configuration database (maybe in LDAP). But I'm just
> saying that to be argumentative.
>
> --
> Andrew
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.20.0003151803470.5932-100000>