Date: Thu, 23 Apr 1998 00:30:18 -0600 (MDT) From: allen campbell <allenc@verinet.com> To: config@FreeBSD.ORG Subject: Re: Config Databases Message-ID: <199804230630.AAA15142@const.> In-Reply-To: <353DFA79.A466D08@xmission.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> One of the unique benefits of using a read/write portal is the
> 'sameness' of the administration model. On a stand-alone system,
> administration is done by editing the files, which simply exist on
> the disk. In a domain member, administration is done by editing
> the files, which don't really exist on disk, but look like they do.
> No additional code has to be written to provide the distributed
> features to system administration tools, or to consumers of system
> administration information; all of the complexity *and differences*
> are moved into the portal.
>
> This is a GOOD THING.
Files in a portal file system are expected to behave in a manner
similar to 'real' files. I think this precludes the possibility
of a writable configfs. This becomes obvious when you begin to
consider the possible failure modes.
Bob, the administrator, invokes vi on /etc/passwd to add an account.
Bob is kind of new at this and he forgets to specify a login shell
for this new account. By writing to /etc/passwd, Bob has implicitly
invoked a 'portal process', because /etc/passwd is a file in our
portal file-system.
Now our portal process is expected to parse the buffer and put the
result in our configuration database. Fortunately, the portal
process in question was implemented very well and the login shell
omission is noticed.
Now what? What is the portal file system supposed to do with this?
Being the rank amateur that I am, I have to consult write(2) to
get an idea of what methods our portal process might try to convey
its discovery. The return value I find which is the least distant
from the notion of a ill-formated /etc/passwd file is
[EIO] An I/O error occurred while reading from or writing to the
file system.
This is what would happen to vi when it attempted to write the
buffer. Kinda vague no? If you expect to use canonical tools,
like vi, against the portal file system, then that file system has
to behave like a 'normal' file system. We can't just make up new
error codes to suit the needs of parsing configuration files. Even
if we could, an error code can not convey a specific line number,
or a man page reference in an effort to help Bob get this done.
Bob is left with a passwd file he cannot save. Step 2: send mail
to HELP!@FreeBSD.ORG...
I posed an alternative to this which you failed to address, even
in criticism. From a root shell, type vipw. Lo! Your editing
master.passwd. When you finish, the buffer is used to build the
password database stored in /etc/pwd.db (see pwd_mkdb for the whole
story.) Oh, and should you happen to be Bob that day, vipw won't
let you save your work. Instead, vipw reports the problem to you
and asks you to correct the problem (or abandon the attempt.) If
Bob is the iconoclastic type, he may define EDITOR to specify what
ever alternative editor he prefers. Bob gets the same benefit of
data validation regardless.
This model could be generalized to handle almost any format of
configuration file. A read-only (portal file system) configfs
would export files, which are then edited and parsed back into the
database with a user space process like pwd_mkdb. As vipw has
already proven, very little change is imposed on administrators.
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?199804230630.AAA15142>