Problems with frontend to backend authentication in murder 2.3.12

[Nic Bernstein]

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 at onlight.com
Onlight llc.                              www.onlight.com
2266 North Prospect Avenue #610	          v. 414.272.4477
Milwaukee, Wisconsin  53202-6306          f. 414.290.0335