Cannot xfer or rename mailbox in murder

Nic Bernstein nic at onlight.com
Fri May 4 10:34:38 EDT 2012


On 05/04/2012 09:23 AM, Dan White wrote:
> On 05/04/12 07:32 -0500, Nic Bernstein wrote:
>> In trying to bring up a murder with *2.4.10*, I am encountering a 
>> problem I just cannot seem to get past.  I've got a Mupdate master, 2 
>> backends and 2 frontends.  Everyone seems to be exchanging 
>> mailboxes.db info just fine, but I cannot move a mailbox (user inbox) 
>> from the original backend (used to be single, standalone system) to 
>> the second backend.
>>
>> Here is sample cyradm session, first to a frontend:
>>
>>   # cyradm -user cyradmin mail
>>   Password:
>>   mail>  xfer user.nic mailbox.wi
>>   xfermailbox: bad parameters to function
>>
>>   mail>  rename user.nic user.nic mailbox.wi
>>   renamemailbox: The remote Server(s) denied the operation
>>
>> and to the backend holding the mailbox to be moved:
>>
>>   # cyradm -user cyradmin mailbox
>>   Password:
>>   mailbox>  xfer user.nic mailbox.wi
>>   xfermailbox: The remote Server(s) denied the operation
>>
>>   mailbox>  rename user.nic user.nic mailbox.wi
>>   renamemailbox: The remote Server(s) denied the operation
>>
>> Here are protocol traces from the hosts involved:
>> From the first session:
>>
>>   On host<mail>
>>   ---------- cyradmin Fri May  4 07:01:01 2012
>>
>> <1336132861<4 RLIST "" ""
>> >1336132861>* LIST (\Noselect) "." ""
>>   4 OK Completed (0.000 secs)
>> <1336132870<5 XFER user.nic mailbox.wi
>> >1336132871>5 NO bad parameters to function
>> <1336132898<6 RENAME user.nic user.nic mailbox.wi
>> >1336132898>6 NO The remote Server(s) denied the operation
>>
>>   On host<mailbox.wi>
>>   ---------- murder Fri May  4 07:01:10 2012
>>
>> <1336132871<Q01 LOGOUT
>> >1336132871>* BYE LOGOUT received
>>   Q01 OK Completed
>>
>>   On host<postman>  (with clock drift)
>>   ---------- postman Fri May  4 07:03:26 2012
>>
>> <1336133006<X0 ACTIVATE {8+}
>>   user.nic {26+}
>>   mailbox.occinc.com!default {63+}
>>   nic    lrswipcda    admin    d    cyrus    lrswipkxtea    
>> cyradmin    lrswipkxtecda
>> >1336133006>X0 OK "done"
>> <1336133006<Q01 LOGOUT
>> >1336133006>Q01 OK "bye-bye"
>>
>> And from the second:
>>
>>   On host<mailbox.wi>
>>   ---------- murder Fri May  4 07:14:51 2012
>>
>> <1336133691<Q01 SETQUOTA {9+}
>>   +user.nic (STORAGE 3500000)
>> >1336133691>Q01 NO Permission denied
>> <1336133691<Q01 LOGOUT
>> >1336133691>* BYE LOGOUT received
>>   Q01 OK Completed
>>   ---------- murder Fri May  4 07:15:00 2012
>>
>> <1336133700<Q01 SETQUOTA {9+}
>>   +user.nic (STORAGE 3500000)
>> >1336133700>Q01 NO Permission denied
>> <1336133700<Q01 LOGOUT
>> >1336133700>* BYE LOGOUT received
>>   Q01 OK Completed
>>
>>   On host<postman>  (again with clock drift)
>>   ---------- postman Fri May  4 07:16:38 2012
>>
>> <1336133798<X0 ACTIVATE {8+}
>>   user.nic {26+}
>>   mailbox.occinc.com!default {63+}
>>   nic    lrswipcda    admin    d    cyrus    lrswipkxtea    
>> cyradmin    lrswipkxtecda
>> >1336133798>X0 OK "done"
>> <1336133798<Q01 LOGOUT
>> >1336133798>Q01 OK "bye-bye"
>>
>> So it looks to me like the ACL is not being transferred, and the 
>> entire operation is buggered from there on.  Right?  What's the fix 
>> to this?  Is there some overarching ACL which I'm missing?
>>
>> Here are the pertinent (sanitized) portions of the configurations 
>> from both backends:
>>
>>   # mailbox - main backend
>>   admins: cyrus cyradmin
>>   allowplaintext: yes
>>   sasl_pwcheck_method: saslauthd
>>   sasl_mech_list: PLAIN
>>   sasl_minimum_layer: 0
>>   sasl_auto_transition: no
>>   servername: mailbox.example.com
>>   proxyservers: cyradmin murder
>>   allowusermoves: true
>>   idlemethod: idled
>>   allowallsubscribe: true
>>   altnamespace: true
>>   defaultacl: anyone lrsip
>>   mupdate_server: postman.example.com
>>   mupdate_username: postman
>>   mupdate_authname: postman
>>   mupdate_password: password1
>>   proxy_authname: murder
>>   proxy_password: password2
>>   force_sasl_client_mech: PLAIN
>>   postman_mechs: PLAIN
>>   mailbox_mechs: PLAIN
>>   serverlist: mailbox mailbox.wi
>>   ----------------------
>>
>>   # mailbox.wi - new backend
>>   admins: cyrus cyradmin
>>   allowplaintext: yes
>>   sasl_pwcheck_method: saslauthd
>>   sasl_mech_list: PLAIN LOGIN
>>   sasl_minimum_layer: 0
>>   sasl_auto_transition: no
>>   servername: mailbox.wi.example.com
>>   allowallsubscribe: true
>>   duplicatesuppression: true
>>   expunge_mode: delayed
>>   proxyservers: cyradmin murder
>>   allowusermoves: true
>>   mupdate_server: postman.example.com
>>   mupdate_username: postman
>>   mupdate_authname: postman
>>   mupdate_password: password1
>>   proxy_authname: murder
>>   proxy_password: password2
>>   force_sasl_client_mech: PLAIN
>>   postman_mechs: PLAIN
>>   mailbox_mechs: PLAIN
>>   serverlist: mailbox mailbox.wi
>>
>> For what it's worth, all authentication is via saslauthd with LDAP.  
>> I am able to create new mailboxes on the new backend, and access them 
>> via all frontends, etc.   I am just not able to transfer mailboxes, 
>> which is kind of the critical part of this whole effort (distribute 
>> mail from centralized location to remote sites).
>>
>> Any assistance would be greatly appreciated.
>
> Which version are you running on these 4 systems? Are they all
> the same?

Yes, they are all 2.4.10.

> The doc at:
>
> http://cyrusimap.org/docs/cyrus-imapd/2.4.16/install-murder.php
>
> claims that the proxy_authenticating user will need to be a full admin
> (section: Additional backend configuration):
>
> admins: cyrus cyradmin murder

Ahh, that wasn't clear.  Okay, this fixed my problem.  Another note for 
the Wiki.  I will summarize my steps once I've got this complete.

> and you may not need 'murder' in your proxyservers.

I will test that next.

> Check your syslog for any additional output. Focus on the case where 
> you're
> connecting directly to the original backend when performing the transfer,
> rather than the frontend. I don't know if transfers are allowed from a
> frontend.

Again, one more for the WIki.

Thanks so much for your help.  I'm Cc:ing the list for completeness.

Cheers,
     -nic

-- 
Nic Bernstein                             nic at onlight.com
Onlight, Inc.                             www.onlight.com
219 N. Milwaukee St., Suite 2a            v. 414.272.4477
Milwaukee, Wisconsin  53202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20120504/1947b5cf/attachment-0001.html 


More information about the Info-cyrus mailing list