On 08/26/2013 02:15 PM, Dan McAllister wrote:
On 8/26/2013 3:52 PM, Eric Shubert wrote:
I'm not suggesting a QMT-specific package. (What would be the point?)
Most of a 'stock' QMT includes packages that aren't *-toaster specific.
I don't think it should necessarily be a requirement either. Choice is
good. As Dan has pointed out, QMT doesn't *require* an onboard resolver.
None the less, QMT needs to use a resolver. I think in the case of a
'stock' setup, it's easier to install and configure pdns-recursor
(it's the same for everyone) than it'd be to say "edit the
/etc/resolv.conf and insert the ip addresses of appropriate DNS
resolvers of your choice".
If someone wanted to customize their resolver by using something else,
there should (and would) be nothing prohibiting that.
Is there problem?
Eric...
OK -- question then... if a user has just imaged a new system and
desires to run a QMT "stock" mailserver on it...
Just how would they download QMT to begin with if they had not already
configured a resolving DNS service??
Part of the process of building a QMT host is to load the OS from
scratch and configure networking. This is where a recursor is set up and
configured, hopefully with the help of some scripting. This would be
done before the system is brought up to date (yum update) and also
before any QMT components are installed.
I say leave well enough alone (e.g. don't mess with their already chosen
method of DNS resolution), but still to recommend it for optimum
performance.
I agree.
I realize that this is getting persnickety... but its that kind of "we
know what's best for you" arrogance that drives many users AWAY from
Micro$oft to begin with!
I hope we don't come across that way. My intention is to make QMT as
flexible as possible, with the ability to be applied to many situations.
One size does not fit all.
Also, it would be reasonable (even suggested) that we put a check in at
the END of the QMT install/update programs that checks DNS resolution --
and if it's NOT local, to recommend doing it locally -- preferably with
the pdns-resolver package.
Having some scripts to verify various operational aspects would be terrific.
My QMT-CentOS6.sh script does something similar -- if the "me" control
file's host name is not in /etc/hosts, it declines to start QMT and
instead warns that starting it might be counter productive.
Would you like to spearhead development of a command which checks
various things? (Preferably by invoking other sub-commands, such as
queue-repair.py or others yet to be written).
I'll climb down now... just give me a moment, as it is a very fine high
horse I'm on just now! :-)
Ha!
As always, Thanks Dan.
--
-Eric 'shubes'
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
