著者: Mitsu Hadeishi 日付: To: exim-users 題目: [Exim] Different arguments in favor of Webmin
Hi,
Yes, I know this has been discussed before, and I have read the discussion in
the archives. However, I'd like to make a new argument in favor of a Webmin
module for Exim.
First of all let me say that I am a programmer, and I am perfectly comfortable
with complex low-level configuration of subsystems. However, I think there's
a misunderstanding of the nature of GUI interfaces. Essentially, I think it
is more helpful to think of them as interfaces that encode knowledge about
subsystems and apply them to allow users to think of tasks at a higher level
of abstraction. In this respect they're analogous to high-level programming
languages.
Of course one gets more control programming in, say, assembly language. And
in some cases one still may need to do this. One also gets more control
working in C or C++ than Java. However, for certain sorts of operations,
there's no particular reason to exclude the possibility of a higher-level
abstraction particularly for common tasks. One can think of a well-designed
GUI as a sort of high-level visual programming interface to a subsystem.
The ideal GUI interface would allow one to "escape out" to the substratum in
order to configure things that are not addressed in the GUI, leaving the more
common tasks to the GUI. This is, for example, the approach taken by Mac OS
X, which is a beautiful example of a GUI built on top of a full-power FreeBSD
operating system "underneath." Most common things can be done with the GUI,
some need to be done from the command line. It is possible to use both
interfaces to configure the system.
An earlier mailing list participant mentioned that a naive user might use a
Webmin module to configure an open relay, etc. Actually I don't really see
why a GUI would necessarily make it easier to configure an open relay.
Obviously, a properly designed GUI interface should make it _hard_ to do
stupid things like that. It should, in fact, only be easy to do things that
one would typically want to do --- that's just part of the proper design of a
good GUI interface. Unless the user goes out of their way to do something
not recommended, it shouldn't happen.
Of course, it may not be possible to write a Webmin or GUI interface to Exim
that would allow seamless administration of any hand-crafted Exim
configuration. Nor may it be possible or even desirable to write a Webmin
module that allows every possible Exim configuration option. However, if you
look at the Webmin sendmail module, it should be possible to configure many
things with a GUI interface, including most of the things that one might
typically want to do.
For example, WebHostManager/CPanel uses Exim as its MTA, and it is possible to
configure virtual domains, mailing lists, forwarding, per-virtual-domain POP
and IMAP accounts, spamassassin, etc., using that solution. A Webmin module
would want to be able to do more than this, get at more low-level
configuration than CPanel (Webmin modules typically allow more low-level
access to the internals than CPanel, but less than hand-editing text files),
but not the full range of possible Exim options.
A compromise architecture for a Webmin module for Exim would probably depend
upon a vanilla Exim installation (i.e., it wouldn't attempt to parse every
possible Exim config) but it would do its best to leave in hand-edited
changes to files it generates. This is what most of the other Webmin modules
do (for example I find it convenient to use the Webmin Apache config module
to set up basic parameters for virtual domains, and then go in and hand edit
the httpd.conf file to do special things --- Webmin typically preserves my
edits).
I am not interested in a flame war here --- I just felt it was worth putting
in some additional thoughts. I figure if a commercial outfit can make CPanel
work with Exim, free software developers ought to be able to produce a
workable Webmin config module.