Date: Mon, 20 Apr 1998 03:48:42 -0600 (MDT) From: allen campbell <allenc@verinet.com> To: allenc@verinet.com, tlambert@primenet.com Cc: config@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. Message-ID: <199804200948.DAA10086@const.> In-Reply-To: <199804192133.OAA14057@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > How do you address an assertion which says dependency on a database
> > reduces robustness because of, for instance, database corruption?
> > Do you disregard the assertion based on evolutionary necessity
> > ('bite the bullet') or do you dispute that there is any significant
> > compromise at all?
>
> I dispute that there is a significant compromise.
>
> There *is* a potential compromise. Opponents of using a database
> design point to partial corruption equalling partial recoverability
> in the flat file.
>
> I would point out to this position that the flat files use the
> underlying file system, which has the same semantics as those
> that have been proposed for the user space code.
>
> The assumption here seems to be that you can't build a robust, user
> space transactioning system on top of a robust, kernel space
> transactioning system.
>
> It's pretty easy to prove this assumption wrong from a technical
> perspective. We can take the example of pwd_mkdb, the program
> that synchronizes the passwd/pwd.db files. It has exactly the same
> issues to deal with.
>
> In fact, pwd_mkdb is a rather nifty example, because it shows us
> a feature that we can't get anywhere else: schema enforcement. If
> the proposed change would render the database inconsistent, the
> change is refused.
>
> The compromise lies in the non-robustness assumption; it not real,
> because it's silly to assume that people who *can't* write robust
> user space code *can* write robust kernel space code. It's pretty
> much binary: they can or the can't, and the user/kernel qualification
> is irrelevant.
>
I meant the question in regard to database integrity as opposed to
schema data consistency. My ambiguity.
My own experience with SQL database systems leads me to agree with
you. A robust file system supporting a proven transaction engine
makes for very solid system, even in the face of severe conditions
such as power failure or inadequate resources. A database system
also presents good opportunities for safeguards, such as replication
and remote fail-over.
The paranoid can make use of the configuration portal file system
(configfs?) to squirrel away whatever they value most. :)
>
> > Does a configuration database imply a client/server design and,
> > therefore, a daemon to implement the server, or do you expect that
> > a static/shared library would allow the client direct access? The
> > former provides for a very thin client and powerful concurrency
> > control (such as signaling registered clients when the hostname
> > changes.) The latter has the appeal of not requiring an daemon
> > which would be tough to support in minimalist applications. Both
> > perhaps?
>
> I would prefer the client/server design.
>
> This simplifies the local database access by making it the same as
> the remote database access.
I was thinking smaller because my interest in this is motivated by
the need for a database which is up-gradable via automation, and
to provide an abstraction layer against which multiple user interface
tools could be authored. By themselves, these goals don't benefit
much from a true transaction engine. As Mike described with his
Romeo and Juliet model, client/server design is called for, but
the minimalist in me notes that a server in this case does not have
to be an actual daemon. Clearly there are goals beyond these that
do benefit from a transaction engine and I agree that this is best.
> If you have followed the SMBFS discussions in the past, the rest
> can be very effectively handled through a credential management
> interface attached to the login session.
>
> The most convenient place to put this seems, to me, to be in a UNIX
> session manager. All credential requests from the kernel to a process
> would be indirected through the session manager process, which could
> choose to answer the requests on the user's behalf.
Does anything similar to this currently exist that could be exploited
for this need? I see your model is correct, but it is also a rather
large cathedral. I agree (as you point out below) it is not required
initially.
> This leads to three models:
>
> 1) User query, where the session manager butts in and asks the
> user for the credential. This is best suited to X and to
> the local console, and such other devices as could refresh
> the screen transparently without the application having to
> know the query has taken place.
>
> 2) Operation time query. For example, the mount system call
> could return ENEEDAUTH, and the mount command could, if
> isatty(fileno(stdout)) was true, interrogate the user for
> a password.
>
> 3) Preload, where the credential information is preloaded by
> the user before the operation is attempted. This is less
> useful interactively, but would allow a "password cache"
> type facility.
I envision something like a line mode 'registry' editor (configsh?)
which would allow appropriate access to go unchallenged after
authentication. In this case, 'Preload' would be very useful
interactively, as the operator moved among domains in the hierarchy.
The session manager would attempt to answer each challenge on behalf
of configsh as the operator performed administration tasks.
> It wouldn't be necessary to require a session manager initially; one
> is only required when you start trying to do tricky stuff that relies
> on you already having the associated infrastructure.
Even if it only provides a simple security mechanism, it would
probably be best if it existed from the start.
> I personally dislike the idea of splitting administrative control
> into functional domains (in that direction lies SCO ODT and UNIX ES),
> but I agree that it shouldn't be architected against, in case someone
> else wants to implement it for some strange reason.
Somehow, all the domains eventually aggregate onto one person
anyhow, whatever the strange reason. :)
Allen Campbell
allenc@verinet.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-config" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804200948.DAA10086>