Matt Selsky wrote:
>
> On Oct 13, 2008, at 12:44 PM, Nic Bernstein wrote:
>
>> Wesley Craig wrote:
>>>
>>> On 03 Oct 2008, at 04:31, Simon Matter wrote:
>>>> Any update on this issue? I'm wondering whether the patch will go into
>>>> 2.3.13?
>>>
>>> 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.
>>>
>>> :wes
>> 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.
>>
>> 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.
>>
>> The documentation (man page) for imapd.conf states:
>> hostname_password: <none>
>> The password to use for authentication to the backend
>> server host-
>> name (where hostname is the short hostname of the server)
>> - Cyrus
>> Murder
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> Much thanks are due to Wesley Craig for his patience and assistance
>> in tracking down the answer to this problem.
>>
>> Thanks again, Wes.
>
> Nic, glad to hear you have things working.
>
> Can you open bugs in bugzilla for the places where the documentation
> is confusing, so we can track these properly?
I have just done so. Thanks for the tip.
-nic
--
Nic Bernstein nic@xxxxxxxxxxx
Onlight llc. www.onlight.com
2266 North Prospect Avenue #610 v. 414.272.4477
Milwaukee, Wisconsin 53202-6306 f. 414.290.0335
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
