Re: Cyrus 2.3.13 RC2
Kenneth Marshall wrote: There have been 5 major releases of PostgreSQL since 7.2 was released and 7.2 is EOL in the next few months. I think it is completely reasonable to not support version 7.1/7.2 in a new system considering that 7.1 is EOL and 7.2 will be shortly. Cheers, Ken Oh seriously, don't even waste time worrying about it. 7.2 died a long time ago, 7.3 was EOL the beginning of this year [1], and 7.4 is about to go the same way real soon now. Normally adding 7.3 support is fairly easy if required, whereas going back to 7.2 is often a complete pain, plus you have to live with several unfixable data loss bugs... The point is that I'm maintaining cyrus-imapd rpms for RedHat/Fedora and always try to provide maximum functionality with them. PostgreSQL 7.1 is still supported there, not by the PostgreSQL team but by RedHat, so that's not a security problem or whatever. However, I understand now that it doesn't make sense to support those old version with cyrus-imapd because of the changes on the PostgreSQL side. Simon 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
Mstone Benchmark
Hello, Does anyone have a cyrus.wld or a special configuration in order to bench imap with Mstone ? Because the result of mstone doesn't fit exactly my needs ! Thanks in advance. begin:vcard fn:Mathieu Kretchner n:Kretchner;Mathieu org:INRIA;Syslog adr;dom:;;2004 route des lucioles - BP93;Sophia Antipolis;;06902 CEDEX email;internet:[EMAIL PROTECTED] tel;work:04 92 38 76 67 x-mozilla-html:FALSE version:2.1 end:vcard 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: Cyrus 2.3.13 RC2
On 08 Oct 08, at 0536, Bron Gondwana wrote: On Mon, Oct 06, 2008 at 11:33:18AM -0400, Ken Murchison wrote: I just put together a second release candidate for Cyrus 2.3.13. I'd appreciate any independent testing before I release this to the masses. Sorry about the delay in testing - we've had a few exciting issues here that had to be fixed first. If there are any outstanding issues that you believe still need to be addressed in 2.3.13, please let me know. No, it's looking good. I just removed the patches that have gone into CVS from my build tree and it built fine. Running on our test server now with no problems. All the patches that have gone upstream have been running happily on our production machines for a bit too. I think now's a good time to release a 2.3.13. What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. ian 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: Cyrus 2.3.13 RC2
Ian G Batten wrote: On 08 Oct 08, at 0536, Bron Gondwana wrote: On Mon, Oct 06, 2008 at 11:33:18AM -0400, Ken Murchison wrote: I just put together a second release candidate for Cyrus 2.3.13. I'd appreciate any independent testing before I release this to the masses. Sorry about the delay in testing - we've had a few exciting issues here that had to be fixed first. If there are any outstanding issues that you believe still need to be addressed in 2.3.13, please let me know. No, it's looking good. I just removed the patches that have gone into CVS from my build tree and it built fine. Running on our test server now with no problems. All the patches that have gone upstream have been running happily on our production machines for a bit too. I think now's a good time to release a 2.3.13. What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. Minimal. My boss asked if we could try to get away from BDB and move to something like SQlite. I dusted off an old SQL patch that I wrote while working for my old employer and ported it to the 2.3 code. We set it up on a test machine and threw a couple of low volume users on it and the campus didn't burn down. We haven't done any kind of load testing or performance testing yet. That's why its listed as experimental -- use at your own risk. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus 2.3.13 RC2
On Wed, 8 Oct 2008 09:24:49 +0100, Ian G Batten [EMAIL PROTECTED] said: What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. You are aware that cyrus replication replicates DB records for all the important things as well, aren't you? Bron. -- Bron Gondwana [EMAIL PROTECTED] 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: Cyrus 2.3.13 RC2
We were only looking at SQL to replace BDB (deliver.db, tls_sessions.db), because we still think that skiplist is superior from mailboxes.db and seen.db. If you do some heavy testing with the BDB code we'd be interested in your results. OK, that's interesting. I'll get 2.3.13 onto batten.eu.org and try some testing. The whole instance is under ZFS so I can roll back if necessary. ian 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: Cyrus 2.3.13 RC2
On 08 Oct 08, at 1119, Bron Gondwana wrote: On Wed, 8 Oct 2008 09:24:49 +0100, Ian G Batten [EMAIL PROTECTED] said: What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. You are aware that cyrus replication replicates DB records for all the important things as well, aren't you? Yes, of course. It's just that having, many years ago, experienced the loss of a cyrusdb, being able to keep up-to-date copies of it which I can use without the nuclear option of failing over to my off- site replica is a good thing. So I will shortly have my whole Cyrus instance (~60K mailboxes, ~1000 users, ~4TB of mail) replicated via GigE to a remote site. But if my local instance went south just because Cyrus DB had gone, being able to simply switch cyrusdb to a MySQL/PostgresQL replica while keeping mail service on the master is preferable to doing a full off-site failover. ian 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: Cyrus 2.3.13 RC2
Ian G Batten wrote: On 08 Oct 08, at 1119, Bron Gondwana wrote: On Wed, 8 Oct 2008 09:24:49 +0100, Ian G Batten [EMAIL PROTECTED] said: What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. You are aware that cyrus replication replicates DB records for all the important things as well, aren't you? Yes, of course. It's just that having, many years ago, experienced the loss of a cyrusdb, being able to keep up-to-date copies of it which I can use without the nuclear option of failing over to my off-site replica is a good thing. So I will shortly have my whole Cyrus instance (~60K mailboxes, ~1000 users, ~4TB of mail) replicated via GigE to a remote site. But if my local instance went south just because Cyrus DB had gone, being able to simply switch cyrusdb to a MySQL/PostgresQL replica while keeping mail service on the master is preferable to doing a full off-site failover. We were only looking at SQL to replace BDB (deliver.db, tls_sessions.db), because we still think that skiplist is superior from mailboxes.db and seen.db. If you do some heavy testing with the BDB code we'd be interested in your results. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: ACL to deny move mailbox/folder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ken Murchison wrote: tarjei wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I got a shared folder where I want users to be able to create subfolders, but where I want to restrict the users so they do not move or delete the shared folder. The folder is a top level shared folder. I read through the cyradm documentation, but it wasn't very clear on how to do this. Is it possible? What version of Cyrus? If you're using 2.3.x, removing the 'x' right from your users will prevent them from deleting the mailbox. I'd have to check the ACL RFC, but I believe it will also prevent renaming (I think RENAME need delete on the source and create on the destination). 2.3.7. Interestingly enough, it seems that removing the 'x' right isn't possible : localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain sam Fag anyone lrswipktecda localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain sam Fag anyone write localhost.localdomain lam Fag anyone lrswipkxtecd localhost.localdomain sam Fag anyone lrswipktecda localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain After some fooling around, I found out that the problem is that if you give the user the a right, then you also grant the e and t rights. Also, cyradm doesn't document what the c and d rights are. A small documentation update would be nice here. Anyhow, thanks for the tip - it solves my problem I think. Kind regards, Tarjei -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI7H2LYVRKCnSvzfIRAiwGAJ9VItud/O1CGvJGwNP1cJaD8y3MxwCgul26 vp1Bg7KB7OGVWwue9WJ/ovE= =Dqmo -END PGP SIGNATURE- 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: ACL to deny move mailbox/folder
tarjei wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ken Murchison wrote: tarjei wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I got a shared folder where I want users to be able to create subfolders, but where I want to restrict the users so they do not move or delete the shared folder. The folder is a top level shared folder. I read through the cyradm documentation, but it wasn't very clear on how to do this. Is it possible? What version of Cyrus? If you're using 2.3.x, removing the 'x' right from your users will prevent them from deleting the mailbox. I'd have to check the ACL RFC, but I believe it will also prevent renaming (I think RENAME need delete on the source and create on the destination). 2.3.7. Interestingly enough, it seems that removing the 'x' right isn't possible : localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain sam Fag anyone lrswipktecda localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain sam Fag anyone write localhost.localdomain lam Fag anyone lrswipkxtecd localhost.localdomain sam Fag anyone lrswipktecda localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain After some fooling around, I found out that the problem is that if you give the user the a right, then you also grant the e and t rights. This would only be the case if you have 'deleteright' set to 'a'. Also, cyradm doesn't document what the c and d rights are. They are legacy rights macros that are now macros. If the 'deleteright' option in imapd.conf is set to the default of 'c', the c='kx' and d='et'. By explicitly granting 'd' above, you're implicitly granting 'x'. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
