Re: uppercase usernames
Le 11/03/2013 23:00, Joerg Maier a écrit : > Hi Julien, > > Thanks for the hint! > > My system is (now) Ubuntu 12.04.2 LTS. I found normalizeuid in the > docs, which I set to 0. Still with the same result. > > I scanned the code a bit as well, I find such a patch in the Ubuntu > distribution patches > (cyrus-imapd-2.4.2-903-normalize-authorization-id.patch). If I > understand the code, it is initialized with 0, and only if set to 1 if > config says. > > I think now, the best solution would be to install a debug version > somewhere and see which of the 68 tolower calls in the code performs > my unwanted tolower and why. > > As I only have 20 mailboxes with UpperCase letters in them, and after > testing I found that a combination of "rename user/CamelCase > user/camelcase" plus "sam user/camelcase camelcase lrswipcda" plus > some account changing in the database will fix my issue, > - without any manual configuration steps for the users > - still the rcpt to:CamelCase mails will get to the renamed account > > Thanks for all your help. I guess the next person who runs into this > and reads this thread needs to debug a bit or study the code investing > more time. > > Joerg Maybe it's the same patch than in RedHat. There the issue is that cyrus configuration code is separated in 2 parts: one in the core library (pretty much static; values accessed with libcyrus_config_getxxx/libcyrus_config_setxxx), the other being accessible in all services and populated from the content of imapd.conf (values accessed with config_getxxx). The patch declares the option in both parts and uses libcyrus_config_getxxx to query the value because it is needed in the core library. From what I could see, what is lacking is a line of code - usually in imap/global.c:cyrus_init - do get the value from imapd.conf and set it in the core library, like it is already done for some other options. Example with username_tolower: libcyrus_config_setswitch(CYRUSOPT_USERNAME_TOLOWER, config_getswitch(IMAPOPT_USERNAME_TOLOWER)); I don't know who is in charge of this patch, but maybe Jeroen can help fix the issue on RedHat side. Actually he seems also linked to the patch on Debian ? (http://git.kolabsys.com/apt/cyrus-imapd/diff/debian/patches/cyrus-imapd-2.4.2-903-normalize-authorization-id.patch?h=debian/master&id=e3af2e17dc0d31ad8c8f7360970f93fe7fbf6d3e) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: uppercase usernames
Hi, Is your system RedHat/CentOS/Fedora ? I think their version (since 2.3.x) have a patch that "normalize" (lowercase + strip leading and trailing whitespaces) authentication ids. From what I could see it appears it was added as a configuration option, but the code is not complete and so the default value (enabled) applies. Le 11/03/2013 08:49, Joerg Maier a écrit : > Hi Dan, > > Thanks for you suggestion! > > Unfortunately, testing the solution i have in mind, i renamed and > finally deleted my one CamelCase testaccount. And now, when I try to > create a mailbox with CamelCase with cyradm, the default acls are set to > a user with lowercase username, and I am not able to set additional acls > to a user with CamelCase with sam. > > I suppose that "username_tolower: 0" just does not does what I thiought > it did in the source installation. > > The solution I want to use for my users now is: > - renaming user to lowercase in userdatabase > - renamin cyrus account with cyradm rename to lowercase > - creating a virtual forward rule, so postfix delivers the mail sent to > CamelCase address -> camelcase (and keep lmtp_downcase_rcpt: 0 and > username_tolower: 0 until last CamelCase adress is converted. > > Thanks, Joerg > > > On 2013-03-11 0:29, Dan White wrote: >> On 03/10/13 23:28 +0100, Joerg Maier joerg.maier wrote: >>> Hi List, >>> >>> I am using cyrus since ~8 years for a mailserver with ~200 >>> mailaccounts. >>> >>> After transferring a mailserver from cyrus 2.2 to 2.4, I have an >>> issue >>> with usernames containing uppercase letters. Up to now, i did tread >>> the >>> part before the @ as case sensitive, and i allowed users to create >>> mailboxes like TestCApital. >>> >>> I have set: >>> lmtp_downcase_rcpt: 0 >>> username_tolower: 0 >>> >>> When I try: >>> testsaslauthd -u TestCApital. -p >>> I get >>> 0: OK "Success." >>> >>> But when I try to logon via imap, i see in the logs: >>> ... saslauthd[24118]: do_auth : auth failure: >>> [user=testcapital.] [service=imap] [realm=] [mech=pam] >>> [reason=PAM auth error] >>> >>> What is the best solution to work around this? >> Do you get the same result with imtest? > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyr_expire (2.3.16) problem
Hi, Le 13/02/2013 14:02, Frank Elsner a écrit : > Hello, > > from time to time we have this type of problem during the nightly cyr_expire: > > Feb 10 04:01:50 mailbackend-4 cyrus-backend/cyr_expire[15569]: IOERROR: > user. zero index/expunge record 299/301 > Feb 10 04:01:50 mailbackend-4 cyrus-backend/cyr_expire[15569]: failure > expiring user.: System I/O error > Feb 11 04:01:48 mailbackend-4 cyrus-backend/cyr_expire[2010]: IOERROR: > user. zero index/expunge record 299/301 > Feb 11 04:01:48 mailbackend-4 cyrus-backend/cyr_expire[2010]: failure > expiring user.: System I/O error > Feb 12 04:02:19 mailbackend-4 cyrus-backend/cyr_expire[27580]: IOERROR: > user. zero index/expunge record 299/301 > Feb 12 04:02:19 mailbackend-4 cyrus-backend/cyr_expire[27580]: failure > expiring user.: System I/O error > Feb 13 04:03:15 mailbackend-4 cyrus-backend/cyr_expire[19753]: IOERROR: > user. zero index/expunge record 299/301 > Feb 13 04:03:15 mailbackend-4 cyrus-backend/cyr_expire[19753]: failure > expiring user.: System I/O error > > This leaves cyrus.*.NEW files in the mailbox directory of the user and > requires a reconstruct. > > What's behind? And how can we avoid this problem? If you got into a situation like ours, you may have reached the limit for the number of opened file descriptors at some point on your server. If so you may find a bunch of errors at that time in your logs; there should also be some of the messages mentioning "Too many open files in system" or similar. In such a situation, there is a bug that can lead to empty (zeros) index records being added when a message is received, which later triggers "zero index/expunge record" errors. If that's the case, you may try to find how many cyrus processes can run at the same time (maxchild of each service) and how many file descriptors each usually consume to determine a "safe" limit on your system. Note that each shared library consume one file descriptor (mmap by the run-time linker apparently). I believe this situation should not happen anymore in cyrus 2.4 (there is an assertion preventing that). But I don't know what happens for those empty records upon migrating from cyrus 2.3 to 2.4. Regards, Julien Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Strange cyrus quota problem
Le 24/11/2011 11:09, Thomas Kirchtag a écrit : > I am rather new to cyrus imap. We took over a client who uses it and has a > strange quota problem. One single user keeps getting "Over quota" alerts > although cyrus (as well as the client show very small quota usage (24%...) > > ... > > > I gather from this that the server sends the "over quota" alert (194 * > NO [ALERT] Mailbox is over quota) and a few lines down the server finds that > the user uses 24% of his quota (204 * QUOTA user. (STORAGE > 2441822 1000)) > > I tried setting the quota to several different values increasing, decreasing > it from the 1, even setting it to none but the result is always as > above. I tried running quota -f and restarting cyrus several times without > any result. > Hi, The problem with versions older than 2.3 is that quota data are handled through 32-bits variables: signed for limit, unsigned for usage. In your case quota usage is handled correctly (under the 2^32-1 limit), but your quota limit being 1000 KiB triggers the quota alert because it is compared to the quota usage in bytes: 1000*1024 exceeds the capacity of the 32-bit signed variable. Actually I believe you are experiencing the same thing that we did with 2.1.x versions some years ago: when overflowing a 32-bit value, the sign bit would be flipped (e.g. 2^31 in a signed variable would become -2^31). So for example in your case cyrus would believe the actual limit is 1000*1024 - 2*(2^32) (variable overflowed two times): the usage would thus be around 150%, that is over quota. So in those old versions you will experience all kind of issues when dealing with quota over 2GiB. Of course the code was reworked since cyrus 2.3 and now works as expected. Regards Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
