Re: Create in frontend: Unknown/invalid partition
BTW. 29.01.2008 16:52, Alexey Lobanov пишет: A log from frontend: 120151877915 list Maillists.%.% 1201518779* LIST (\HasNoChildren) . Maillists.DSBL.majordomo * LIST (\HasNoChildren) . Maillists.DSBL.removal 15 OK Completed (0.000 secs 3 calls) 120151878917 create Maillists.ttt 120151878917 NO Unknown/invalid partition This IMAP_PARTITION_UNKNOWN (imap/imap_err.et) status seems to be bogus anyway in a frontend server having no any partitions at all. I am looking in imap/imapd.c now without understanding. The only IMAP_PARTITION_UNKNOWN is line 8080, do_xfer_single(). It is not related to Create, is it? Alexey 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
Re: Create in frontend: Unknown/invalid partition
Hello Michael. 29.01.2008 16:11, Michael Menge пишет: Hi, i think the problem is that folders under user can only be created on the backands, as the frontend has noway to know on which backend the new folder No, it is not a problem because it is a properly documented behavior. New users should be created at their home backends. BTW, Thunderbird or any other regular IMAP clients just are not able to create new users and INBOX'es, and the whole story is about user-level operations with folders under an existing user INBOX. A log from frontend: 120151877915 list Maillists.%.% 1201518779* LIST (\HasNoChildren) . Maillists.DSBL.majordomo * LIST (\HasNoChildren) . Maillists.DSBL.removal 15 OK Completed (0.000 secs 3 calls) 120151878917 create Maillists.ttt 120151878917 NO Unknown/invalid partition So, we see that parent box Maillists exists (at a backend, of course) but new Maillists.ttt should be created at an unknown partition. The backend server logs nothing for this Create, it does not reach the backend. should be created. Other folders like user.testuser.test or a rename will use the parent/old backend and partition. Yes, It should work but it does not work somewhy. http://cyrusimap.web.cmu.edu/ag.html The following operations occur for CREATE on the front end: 1. proxyd: verify that mailbox doesn't exist in MUPDATE mailbox list. 2. proxyd: decide where to send CREATE (the server of the parent mailbox, as top level mailboxes cannot be created by the proxies). 3. proxyd - back end: duplicate CREATE command and verifies that the CREATE does not create an inconsistency in the mailbox list (i.e. the folder name is still unique). Alexey Quoting Alexey Lobanov [EMAIL PROTECTED]: Hello all. I am building a Cyrus IMAP cluster for corporate use and the only problem now is Create command. In accordance with the manuals, a frontend should redirect Create to the appropriate backend, and after that the backend propagates changed list through mupdate. In my system any Create at any frontend is cancelled instantly with NO Unknown/invalid partition. Rename works fine both at frontends and at backends, and changes are propagated properly in whole cluster. All regular mail access operations work fine. The server roles are: one is master+frontend, two are pure backends (just old production servers), one is frontend+backend. The mentioned behavior is seen in both frontends. Cyrus version is 2.3.9, imapd-disable-referrals patch does not affect anything. The clients are Cyradm and Thunderbird. Any ideas for tests are highly appreciated. Both frontend Cyrus instances are not in production use and can be tweaked freely. Alexey 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 M.Menge Tel.: (49) 7071/29-70316 Universitaet Tuebingen Fax.: (49) 7071/29-5912 Zentrum fuer Datenverarbeitung mail: [EMAIL PROTECTED] Waechterstrasse 76 72074 Tuebingen 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 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
Create in frontend: Unknown/invalid partition
Hello all. I am building a Cyrus IMAP cluster for corporate use and the only problem now is Create command. In accordance with the manuals, a frontend should redirect Create to the appropriate backend, and after that the backend propagates changed list through mupdate. In my system any Create at any frontend is cancelled instantly with NO Unknown/invalid partition. Rename works fine both at frontends and at backends, and changes are propagated properly in whole cluster. All regular mail access operations work fine. The server roles are: one is master+frontend, two are pure backends (just old production servers), one is frontend+backend. The mentioned behavior is seen in both frontends. Cyrus version is 2.3.9, imapd-disable-referrals patch does not affect anything. The clients are Cyradm and Thunderbird. Any ideas for tests are highly appreciated. Both frontend Cyrus instances are not in production use and can be tweaked freely. Alexey 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
Re: Create in frontend: Unknown/invalid partition
Hi, i think the problem is that folders under user can only be created on the backands, as the frontend has noway to know on which backend the new folder should be created. Other folders like user.testuser.test or a rename will use the parent/old backend and partition. Quoting Alexey Lobanov [EMAIL PROTECTED]: Hello all. I am building a Cyrus IMAP cluster for corporate use and the only problem now is Create command. In accordance with the manuals, a frontend should redirect Create to the appropriate backend, and after that the backend propagates changed list through mupdate. In my system any Create at any frontend is cancelled instantly with NO Unknown/invalid partition. Rename works fine both at frontends and at backends, and changes are propagated properly in whole cluster. All regular mail access operations work fine. The server roles are: one is master+frontend, two are pure backends (just old production servers), one is frontend+backend. The mentioned behavior is seen in both frontends. Cyrus version is 2.3.9, imapd-disable-referrals patch does not affect anything. The clients are Cyradm and Thunderbird. Any ideas for tests are highly appreciated. Both frontend Cyrus instances are not in production use and can be tweaked freely. Alexey 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 M.Menge Tel.: (49) 7071/29-70316 Universitaet Tuebingen Fax.: (49) 7071/29-5912 Zentrum fuer Datenverarbeitung mail: [EMAIL PROTECTED] Waechterstrasse 76 72074 Tuebingen smime.p7s Description: S/MIME krytographische Unterschrift 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
