From: Clifton Royston (no email)
Date: Mon Apr 01 2002 - 18:10:07 EST
On Tue, Apr 02, 2002 at 01:00:46AM +0300, Liviu Daia wrote:
> On 1 April 2002, <> wrote:
> > On Tue, 2 Apr 2002, Liviu Daia wrote:
> > > That won't work as long as some files / sockets / whatever
> > > associated to maps are opened before going into the chroot jail
> > > while others are opened (not necessarily by Postfix --- think MySQL)
> > > after that operation.
> >
> > It does not have to catch all problems, it just has to be useful. If
> > the map checks are part of "postfix validate" rather than "postfix
> > check" false positives for error conditions are OK.
>
> IMO, a "postfix validate" should actually do what is says: validate
> the config. IOW, it should be 100% accurate. The utility you suggest
> is simply too fragile --- it would both generate false positives and
> miss real problems (f.i. for reasons related to permissions).
Hmmm, is this turning into an argument on semantics? OK, perhaps it
should be called "postfix check_a_bit_more_thoroughly" or something
like that. Likewise "false positive" errors are not necessarily bad,
viewed as what one would normally call "warnings" in the context of a
compiler - "you are doing something unclear here, and I, the software,
can not tell if it is correct or not." (I forget which compiler
authority said that the main job of a compiler writer is to issue
errors and warnings to the programmer about their incorrect syntax;
occasionally by chance someone gives you a correct program and you have
to actually compile it.)
I do see the point that Wietse and you are both making - it is in
principle impossible to be sure that the configuration files are
correct without recreating the entire runtime environment for the
system. However, even in a chrooted environment I believe it would be
possible to check a little more than is done at present. (Just as
programs which compile without warnings do not thereby do what the
author intended!)
Beyond the newbie problem, the other problem I am looking ahead to is
at the other end of the spectrum - if one makes even a minor change to
the configuration of a large system with high reliability demands, it
seems to me that "postfix check" should not presently give one much
confidence that it's OK to proceed to "postfix reload."
I'm sure an expanded "postfix check_more" could never catch 100% of
the possible errors. Nonetheless, if it could reduce them noticeably,
I'm sure I would want to mandate it for our administrators, the same
way we expect everyone to do an "apachectl configtest" on making web
server configuration changes, even though that too will not catch all
errors. (IOW, if Victor Duchovnik codes such an enhancement, I for one
will use it.)
Again, this is a wishlist, and my wishful thinking is in no way a
criticism of postfix as it stands. Indeed, I am already grateful for
what it's clear is a marvellous mail system, and for everyone who has
contributed to it; I'm just saying if I could better protect myself and
my staff against our own errors, I'd want to do so.
Yours,
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect --
"What do we need to make our world come alive?
What does it take to make us sing?
While we're waiting for the next one to arrive..." - Sisters of Mercy
-
To unsubscribe, send mail to with content
(not subject): unsubscribe postfix-users
|
|
|