On May 30, 2008, at 8:03 AM, Trevor Jacques wrote:
OddSox wrote: It sounds to me as if 10.5.3 is doing exactly what it
should do under the circumstances
It's one possible way to portray what is in the master.cf file.
I doubt that there is any GUI available anywhere for Postfix/Cyrus
et al that can correctly interpret and display all the possible
permutations of available settings - it's probably impossible.
True, but bear in mind that 10.5.2 worked fine in this regard.
Yes, but that was just luck. You introduced a mail configuration
change outside the scope of the GUI tools by hand-editing the config
file, and then continued to expect the GUI tools to function properly.
As far as I know, this is not an advertised feature of Server, except
in specific cases (for example see the apache config files, which are
heavily commented describing what is safe to change and what is not).
You were skating on thin ice the first time you loaded the Mail
settings view in Server Admin after editing the file...
As others have noted and you have experienced, this is a potentially
risky proposition.
When such unanticipated configuration changes are made outside the
scope of the 'easy-mode' tools, it becomes the responsibility of the
admin to test and maintain that configuration over time, for ever and
ever; for example, every system update and every security update
(although I might also recommend testing before upgrading production
systems as a matter of course, even if you don't have any custom hand
edited configuration). Do not underestimate the amount of work that
can be created by hand-editing Mac OS X Server config files...
Essentially you are signing on as a card-carrying unix sysadmin. On
top of that, in the non-apple unix world, at least part of the
equation is arguably easier, as there is typically not another agent
trying to rewrite your configuration :)
I think there's a strong argument to be made that such a change in
behaviour should be documented in the installation notes...
If Apple published documentation of every change to the OS that
*might* affect somebody based on any possible permutation of any
possible configuration of every service that ships on Server, you
would probably still be reading ;) It would also be an impossible
task, since Apple can't test every possible case.
For what it's worth, I share your frustration at the root cause...
It's another example of what happens when custom service configuration
is not handled properly - this has cropped up several times before.
Ideally, Server would be able to deftly composite hand-written
configuration file content with automatically generated content in
such a way that all of the functionality that Apple advertises
continues to work, and all the custom configuration is preserved
across updates / upgrades / handstands / backflips. I envision a
system-level configuration abstraction layer to fill this need. It
would probably require descriptions for each configuration file format
that contain a fair amount of knowledge of the semantics of the
format.. for example it might be nice to know if two given directives
are mutually exclusive or otherwise incompatible. This way, you could
know immediately that a given configuration element is invalid or
incompatible at the time you attempted to load it, instead of sometime
later. Access to the custom configuration could be provided perhaps a
"viconfig" (in the tradition of "vipw"), or maybe even just tacked
onto Server Admin / serveradmin... 'customsettings' instead of
'fullsettings', and an Inspector pane for the GUI side, etc :) Hook up
some change notifications for all the config file paths (and use the
templates to learn how to look for includes!), offer a kill switch or
perhaps even require an 'opt in', offer functions for importing or
exporting of either the custom or generated config contents, and
please please please do *automatic versioning* of all configuration,
both custom and generated.
Until (or if) that day comes , I might recommend to either a) stick to
the GUI and the relatively few Apple sanctioned hand edits, or b) use
the CLI to hand edit to your heart's content, but don't expect any
Server Admin / serveradmin functionality for the relevant service. You
will probably find that Server Admin / serveradmin *do* continue to
work *most* of the time, even after you have introduced valid hand
edits, but it's important to understand that this is usually an
unsupported thing to do (in the sense that Apple doesn't expect or
advertise that this should necessarily work). I might even opine that
the existence of your expectation of this level of functionality
suggests that it does actually work pretty well most of the time, even
when it's not supposed to ;)
Cheers,
-Andre
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
