Date: Sat, 01 Jun 2002 09:09:37 -0700 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Daniel Blankensteiner <db@traceroute.dk>, freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign Message-ID: <3CF8F1C1.D28E5CCA@softweyr.com> References: <F67gL6wxvw0IDT8zAJ90000d078@hotmail.com> <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> <01bf01c208ec$b11a7380$6800a8c0@rafter> <3CF7FE67.868D4EF9@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
>
> Daniel Blankensteiner wrote:
> > I think it is easier to setup, let's say FTP, if you know ALL the config
> > files are in /etv/daemons/ftp. And the only place to start the ftpd from
> > when booting, is from /etc/daemons/startup.
>
> It's even easier when you don't supply knobs to twiddle in the first
> place. Can't pick a wrong setting, if there is no way to change it
> from a right setting...
>
> > When you add a user, you have to grand him or deny him access to
> > services. This you do by changing a lot of config files, maybe
> > forgetting some? So a central access file, is maybe not so bad.
> > When more services are added, /etc will "explode". We already got
> > /etc/mail and /etc/ssh, why not /etc/ftp? And then put them in
> > /etc/daemons/, it makes more sence.
>
> I will share with you "Lessons I have learned about doing business
> using Open Source: Lesson #31":
>
> There are three ways to view this:
>
> o System-centric
> o Service-centric
> o User-centric
>
> Right now, things are (mostly) system-centric. In your example of
> adding a user and establishing permissions, you have a problem which
> is user-centric. Then you propose a solution which is service-centric.
> This doesn't make a lot of sense.
>
> When you are trying to create a user-centric model (e.g. the InterJet
> was such a model), then the best possible world is to implement a
> user-centric parameter store.
>
> When you have to live in the world of attempting to leverage existing
> source code, then you have to accept some limitations that come with
> that existing source code.
>
> This was a lesson that some of our UI people never learned, and so
> they tried to change some basic underlying paradigms. Yes, it's
> possible to do what they wanted (though, probably not wise, if you
> get right down to it), but the cost would be to not be able to use
> the exisiting code out there for leverage: the job would have to be
> done "from scratch"... and there are litterally hundreds of thousands
> of man years of effort in software like DNS and sendmail, etc., that
> it would be a shame to have to duplicate.
>
> Most companies that try to base products on Open Source really fail
> to learn this lesson: sometimes you have to bend to the software,
> rather than attempt to bend the software to your will. Then, of
> course, the companies themselves fail.
>
> The best compromise for a user-centric administrative view is to
> leave the configuration file layouts and formats alone, and put
> your own database out there. Then derive the configuration data
> for the software -- in its native format -- from the contents of
> your magic user-centric database.
This is exactly the approach DoBox took to the problem. The DoBox
user database (implemented in PostgreSQL, but could be anything) was
the central store for all of the user information. Anytime a user
was addeded, deleted, or changed, an outcall was made to a program
that exported the database to whatever external configurations were
needed. It worked quite well, modulo a few potention race conditions
that were solved with a sledgehammer (giant-type semaphore).
> There are a couple of interesting problems you end up needing to
> solve when you take this approach, but they are ultimatrely
> soluable.
The solutions often end up simpler than the problem would seem in the
first place. You get to encapsulate the user design stuff in the
database and handle all the hard icky stuff like configuring mail
account information in a separate program the UI designers never
have to worry about.
> I think you are much better off trying to build something like
> this (if you are smart, it will probably be based on LDAP), than
> you are in trying to change every piece of software out there to
> fit a paradigm that is specific to FreeBSD, and will lose you the
> third party maintenance that makes the current model valuable:
> it offloads maintenance onto third parties.
Yes. Anyone looking to "improve" the configuration of FreeBSD, or any
other network-attached system, needs to consider LDAP and SNMP. Plus
whatever their eventual replaces will be.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
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?3CF8F1C1.D28E5CCA>