Date: Fri, 24 Apr 1998 01:10:08 -0600 (MDT) From: allen campbell <allenc@verinet.com> To: config@FreeBSD.ORG Subject: Re: Config Databases Message-ID: <199804240710.BAA16897@const.> In-Reply-To: <2195.893365441@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> No, ENOTHING. As I said, the operations should just silently > "succeed" in the cases where the user has attempted to do a bonehead > file operation but not reflect the change. "Never check for an error > condition you don't know how to handle." :-) I underestimated the appeal of a fully reflexive configuration file system. :) Perhaps I'm wrong, but I don't think we can do without a solid way to interactively report detected errors. I came up with a possible solution. Most configuration files support some form of comment. Why not use this facility to report inconsistencies? The result of writing a bogus /etc/passwd might look like; [ previous entries snipped ] # << The following errors have been detected: >> # << Missing login shell >> # << The following entry has been ignored >> # << See passwd(5) for further information >> foo:*:1003:1003:Foo Bar III:/home/foobar If you happen to catch something more subtle than a syntax error... [ previous entries snipped ] foo:*:1003:1003:foo:/home/foo:/bin/sh # << The following errors have been detected: >> # << Non-unique UID value >> # << The following entry has been ignored >> # << See passwd(5) for further information >> bar:*:1003:1004:bar:/home/bar:/bin/sh This could make configfs downright helpful. The ability of configfs to annotate configuration files could be used pro-actively... [ from somewhere in the equivalent of rc.conf ] # << WARNING, hostname remains unassigned. >> # << See hostname(1) for further information. >> hostname="myname.my.domain" The file system could have the ability to provide variable levels of annotation. Experienced users could turn off the noise (and turn it back on when they need help being experienced. :) The distribution default would naturally be verbose. This might lead to the portal file system becoming the primary interface for configuration. However, other configuration tools would be able to benefit from the same validation and error reporting. Assuming they consistently interact with configfs through a protocol or write to the portal files directly, the configuration file system becomes the final arbiter of configuration. <disclaimer> I use /etc/passwd as a hypothetical example only. I understand there are larger implications to be considered with /etc/passwd. </disclaimer> 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?199804240710.BAA16897>