Problems with frontend to backend authentication in murder 2.3.12

[Matt Selsky]

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?


-- 
Matt