<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Wesley Craig wrote:
<blockquote cite="mid:69240BC1-A146-43D4-B6D6-27996A7285F3@umich.edu"
type="cite">On 03 Oct 2008, at 04:31, Simon Matter wrote:
<br>
<blockquote type="cite">Any update on this issue? I'm wondering
whether the patch will go into
<br>
2.3.13?
<br>
</blockquote>
<br>
Nic and I are still talking. This patch will likely be applied after
2.3.13 is released. We've already made "last call" for 2.3.13. I did
find a bug in the version Nic tried, so if you're messing with it, you
should get it again.
<br>
<br>
:wes
<br>
</blockquote>
I wanted to follow up to the list on this issue so that others may
learn from my experience. The issue here was one of poor documentation
and confusing examples rather than a software bug.<br>
<br>
The configuration in question involves numerous hosts on a
geographically diverse WAN with similar systems in multiple locations.
Frontends in these locations are named imap.xx.example.com and backends
are called mailbox.xx.example.com, where xx is a two letter state or
country code. For purposes of configuring cyrus imapd to use the
correct mechanisms and passwords with these numerous systems the
hostname_mechs and hostname_password configuration elements were used.<br>
<br>
The documentation (man page) for imapd.conf states:<br>
<blockquote>hostname_password: <none><br>
The password to use for authentication to the backend
server host-<br>
name (where hostname is the short hostname of the server)
- Cyrus<br>
Murder<br>
</blockquote>
Short hostname is a somewhat ambiguous term. There are many examples
floating around on the web, in mailing lists, etc. in which people
define the hostname_password and hostname_mechs settings for multipart
hostnames, such as imap.wi, by using an underscore (_) character, like
so: imap_wi, since everything to the right of a period (.) in these
settings would otherwise be discarded by the parser.<br>
<br>
My error was that I trusted these examples, and followed them in my
configurations. Thus I had mailbox_wi_password and mailbox_wi_mechs
settings, which were simply ignored by the software, as it ignored
everything after the the first dot when looking for passwords, and not
finding an entry for, say mailbox_password, it failed the
authentication.<br>
<br>
So, since my hostnames are not unique in their "short hostname" (I will
have eight systems named "mailbox" and eight named "imap" by this
definition) I am not allowed to define unique passwords or mechanisms.
I have fallen back to using common passwords for all hosts and the
"proxy_password" setting.<br>
<br>
I must confess that I see this as a somewhat capricious limitation of
the software, frustrated by the vague documentation and lack of
debugging information. In this case the error logged was "no worthy
mechanisms" which led to a wild goose chase for a mechanism problem
when in fact the problem was that no password was being defined.<br>
<br>
I hope that the software is changed to allow for FQDNs to be defined
for these host specific configuration variables. The limitation of
only allowing "short hostnames" seems baseless. I also hope that the
wiki is enhanced with more specific examples of murder configurations
which show how these various settings interact. It is frustrating to
waste so much time on configuration issues like this simply because of
the dearth of good clear examples, and the proliferation of bad
examples on the web.<br>
<br>
For example, a search for murder configurations on Google will turn up
many examples with "mupdate_admins" when this is not actually a
configuration setting used by cyrus imapd. When the only examples
around are erroneous, errors will proliferate.<br>
<br>
I will be glad to offer up some concrete working examples with
explanations once my own implementation is complete, and would be glad
to contribute them to the wiki. Is there any consensus as to where
such documentation should go on the wiki?<br>
<br>
Much thanks are due to Wesley Craig for his patience and assistance in
tracking down the answer to this problem.<br>
<br>
Thanks again, Wes.<br>
<br>
Cheers,<br>
-nic<br>
<pre class="moz-signature" cols="72">--
Nic Bernstein <a class="moz-txt-link-abbreviated" href="mailto:nic@onlight.com">nic@onlight.com</a>
Onlight llc. <a class="moz-txt-link-abbreviated" href="http://www.onlight.com">www.onlight.com</a>
2266 North Prospect Avenue #610 v. 414.272.4477
Milwaukee, Wisconsin 53202-6306 f. 414.290.0335
</pre>
</body>
</html>