Problems with frontend to backend authentication in murder 2.3.12

[Nic Bernstein]

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.

Cheers,
    -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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20081013/66d863a2/attachment.html