Bugzilla Cleanup - Your Help Needed and Much Appreciated!
Hello there, The Cyrus Bugzilla is a very important component for all of us, community users and Cyrus developers alike! I suppose most of us have, at least once or twice, logged a new report in Bugzilla, but then what happens with that report? >From the other side, the Cyrus team sometimes doesn't sort through the series of legacy tickets to see what (in terms of tickets) it is they are supposed to be working on or which tickets they need to close. As a result, reports quickly back up in the queue and are soon to be rarely paid sufficient attention to. Similarly, I can imagine, it must sometimes be... confusing to see a large number of tickets still be open, or a large list of versions you never know existed, and the version or milestone of a ticket be set to something that doesn't really make sense. Ergo; something needs to be cleaned up. While some things I can just go ahead and do (after short deliberation within the Cyrus team, of course), *WE NEED YOUR HELP!* Let me emphasize that point; Without your help, all I can do is close the tickets and wait for people (probably some of you) to reopen them... Here's some of the things I can do and have done to make it easier on all of us; - I've cleaned up the list of versions by accumulating versions the Cyrus team is unlikely to pay much attention to, into series of versions. Ergo, 2.1.1 through 2.1.13 have all become one single '2.1.x' entry. Note that this includes the 2.2 series, while 2.3 has been released ~5 years ago. Same goes for milestones. - I've installed the BugzillaReports extension for Mediawiki, so we can easily create lists of bugs and share those lists. See, for example, the following Mediawiki page; http://www.cyrusimap.org/mediawiki/index.php/Bugs_Resolved_in_2.4.1 You can help us make Bugzilla just a little bit more accessible! Here's how (the contents of lists are updated instantly); - A list of Open Bugs per legacy version has been created: http://www.cyrusimap.org/mediawiki/index.php/Bugzilla_Cleanup - A description of what you can do with such reports is described here; http://www.cyrusimap.org/mediawiki/index.php/Bugzilla_Cleanup_Guidelines We're talking a list of 174 bugs at the time of this writing. What we would like to see, is have this list be smaller. If you have any questions (like, any, whatsoever, somewhat related to Cyrus), please feel free to drop me a line, or contact my directly in the #cyrus IRC channel on irc.freenode.net. Thank you, in advance or in retrospect or both, for your contribution(s), Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Problem with Shared Mailbox - Cyrus Aggregation - Backend - 2.4.1
Hi, Bron, This works with Cyrus Frontend 2.4.1 Thanks On Tue, Oct 19, 2010 at 3:20 AM, Bron Gondwana wrote: > On Tue, Oct 19, 2010 at 01:14:12AM -0200, Lucas Zinato Carraro wrote: >> My configuration >> >> User Inbox - Backend cyrus 2.4.1 >> +SharedFolderA - Backend cyrus 2.4.1 >> +SharedFolderB - Backend cyrus 2.3.16 >> >> Client used Mozilla Thunderbird 3.1.4 >> >> In File Subscribe i can see all Folders ( INBOX, SharedFolderA, >> SharedFolderB ) >> When i click in subscribe, i dont have any problem or erroneus message >> >> I see " shared folder" in my HOME server normal, but folders in >> another server ( SharedFolderB ) >> appears in Grey Italic. >> >> Reference: >> >> http://kb.mozillazine.org/Grey_italic_folders >> >> "" A IMAP folder will be displayed in grey italics if the folder has a >> \Noselect flag. Normally this means >> the folder can contain child folders, but not messages. [1] This is a >> IMAP protocol flag, not one of >> the folder flags that can be set using the Folder Flag extension. >> >> If i uncheck the option "Show only subscribed folder" in Config >> >> Account >> Server >> Advanced. >> I can work normal with all mailboxes... >> >> This is the correct behavior in Cyrus 2.4.1 ? >> >> In Cyrus 2.3.16 i dont have to set this option, i can subscribe normal in >> remote mailboxes servers. >> >> With Cyrus 2.4.0 i see the folders to subscribe, but the folders are >> not avaiable i dont see >> any folder, in Cyrus 2.4.1 i see this folders, but in grey italic. > > Ok - what's the version on your frontend? If that's running 2.4.1 > (and restarted) then it should be filtering out the \Noselect flag > if (and only if) the mailbox exists in murder. > > All your "LSUB" response is coming from the Inbox server - and it > has \Noselect for all the folders that aren't on that same server. > The frontend the passes this to pipe_lsub (in imap_proxy.c) which > filters the \Noselect flag off. > > There was a bug in 2.4.0 (and presumably earlier, I didn't touch > that code before) where it wasn't removing \Noselect, despite a > comment to the effect that it should be. Upgrade your frontend > to 2.4.1 and that will be fixed. > > Bron. > Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Problem with Shared Mailbox - Cyrus Aggregation - Backend - 2.4.1
On Tue, Oct 19, 2010 at 07:25:49AM -0200, Lucas Zinato Carraro wrote: > Hi, Bron, > > This works with Cyrus Frontend 2.4.1 > Thanks Excellent :) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
cyradm referall 2.4.1 version
I have 3 Frontends in DMZ, 4 Backends in Intranet and a Administrative Station in other network. The administrative station, and clients stations can not connect direct to backend servers. In imapd.conf i enable the parameter: proxyd_disable_mailbox_referrals: 1 With 2.3.16 dont have problem to issue commands direct in frontends using cyradm. cyradm --user cyrus frontend2316 info user/mailbox - OK lam user/mailbox - OK sam user/mailbox - OK cm user/mailbox - OK With 2.4.X : cyradm --user cyrus frontend241 info user/mailbox - OK lam user/mailbox - OK sam user/mailbox - timeout error cm user/mailbox - timeout error Without firewall ( frontend - firewall - backend ) : info user/mailbox - OK lam user/mailbox - OK sam user/mailbox - Ask for backend password cm user/mailbox - Ask for backend password I keep same config between cyrus 2.4.1 and cyrus 2.3.16. Its possible to disable referall to cyradm ? Regards Zinato Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus IMAPd 2.4.2 Released
I am pleased to announce the release of Cyrus IMAPd 2.4.2. This is a single fix to 2.4.1 to remove strcasestr so that it compiles on Solaris. There is no need to upgrade unless you are having compliation problems with 2.4.1. My apologies for the compilation problems. I have now tested this on a Solaris 10 box and confirmed the bug is fixed! URL for this release: ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.2.tar.gz Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or cyrus-b...@andrew.cmu.edu. Thank you, Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyradm referall 2.4.1 version
I'm not sure what the story is with this one. Ken might have a better idea since they use murder and cyradm at CMU (I just use telnet directly or Perl modules that talk pure IMAP, and we don't use murder at FastMail). I've CC'd him. Would be great if you can create bugs in bugzilla too, just so we can track them. And thanks for all your testing and feedback. You've found more bugs than anyone else so far (not counting FastMail users of course - they got to test all this stuff long before the public release!) Bron. On Tue, Oct 19, 2010 at 07:54:13AM -0200, Lucas Zinato Carraro wrote: > I have 3 Frontends in DMZ, 4 Backends in Intranet > and a Administrative Station in other network. > > The administrative station, and clients stations can not connect > direct to backend servers. > > In imapd.conf i enable the parameter: > > proxyd_disable_mailbox_referrals: 1 > > > With 2.3.16 dont have problem to issue commands direct in frontends > using cyradm. > > cyradm --user cyrus frontend2316 > > info user/mailbox - OK > lam user/mailbox - OK > sam user/mailbox - OK > cm user/mailbox - OK > > With 2.4.X : > > cyradm --user cyrus frontend241 > > info user/mailbox - OK > lam user/mailbox - OK > sam user/mailbox - timeout error > cm user/mailbox - timeout error > > Without firewall ( frontend - firewall - backend ) : > > info user/mailbox - OK > lam user/mailbox - OK > sam user/mailbox - Ask for backend password > cm user/mailbox - Ask for backend password > > I keep same config between cyrus 2.4.1 and cyrus 2.3.16. > > Its possible to disable referall to cyradm ? > > > Regards > Zinato > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: sync_client fails to exit when manual replication and rolling replication are combined (2.3.16-8)
> On Saturday, October 16, 2010 12:49 AM, Bron Gondwana wrote (2.3.16-8) >> >> On Fri, Oct 15, 2010 at 03:42:21PM -0400, Simpson, John R wrote: >> > However, if I have run sync_client manually while rolling replication >> is >> enabled the rolling replication instance will not exit. Instead, it >> appears to start spawning subprocesses and throwing database errors. >> The >> change in database errors (below) appears to coincide with the >> completion >> of "Exporting cyrus-imapd databases". The critical DB error messages >> continue until sync_client is killed. >> >> [ ... ] >> >> > Oct 15 14:51:41 eml-store04 sync_client[25333]: DBERROR db4: PANIC: >> fatal region error detected; run recovery >> > Oct 15 14:51:41 eml-store04 sync_client[25333]: DBERROR: critical >> database situation >> > Oct 15 14:51:41 eml-store04 sync_client[25353]: DBERROR db4: PANIC: >> fatal region error detected; run recovery >> > Oct 15 14:51:41 eml-store04 sync_client[25353]: DBERROR: critical >> database situation >> > ... continue until sync_client is killed ... >> >> Nothing magic about sync_client itself here - it's something with the >> hand >> run sync_client and attaching/detaching from the environment. This has >> been on the TODO list at FastMail for a while - and your information may >> actually help us narrow down the cause. We don't use BDB, but the log >> messages annoy us too! > > If there's else anything I can do to help track this down, please let me > know. It was interesting to see that the errors were coming from the > original, rolling replication sync_client process, not a manually > initiated sync_client that didn't exit properly. > > The reason I'm running sync_client manually is to seed the replica with > the existing users and mailboxes on the master server, as described in > http://www.cyrusimap.org/docs/cyrus-imapd/2.3.16/install-replication.php. > Would it be better to use rsync? > > Is there any reason not to add code to clean up any remaining sync_client > processes to the "stop" function in /etc/rc.d/init.d/cyrus-imapd? Yes, that could get a little tricky because the init script has multi instance support and so you don't have to only identify sync_client processes running outside master but also identify which instance they bwlong to. Beside that, init scripts usually _only_ terminate services they have started, not anything else. > > I am pretty sure we're not using BDB either, but I found a log file, > /var/lib/imap/db/log.01, that appears to be a Berkeley DB log > file. Right, as long as BDBless builds are not possible, we will always see BDB being initialized, even if not used :( BTW, I can't help you much with sync_client because I have never used it. However, I'm quite sure shutting down cyrus-imapd while sync_client is running may do bad things with your databases. The init script tries to convert all BDB to skiplist and the cleaning up the BDB environment. I guess that's not good while sync_client is running. Simon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: sync_client fails to exit when manual replication and rolling replication are combined (2.3.16-8)
Hi,
> On Tue, 19 Oct 2010 14:22:06 +0200
> "Simon Matter" said:
> I am pretty sure we're not using BDB either, but I found a log file,
> /var/lib/imap/db/log.01, that appears to be a Berkeley DB log
> file.
simon> Right, as long as BDBless builds are not possible, we will always see BDB
simon> being initialized, even if not used :(
I believe recent Cyrus IMAPd can be built without Berkeley DB by
giving --with-bdb=no to configure.
Since 2.4.X doesn't use Berkeley DB by default, I'm building it
without Berkeley DB, and I don't see /var/imap/db/log.* anymore.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: user_deny.db, very high load and Apple-Spotlight
On 10/14/2010 06:30 AM, Marc Patermann wrote: > > I created user_deny.db with touch to make the one error message go away. > Now I have lots of "fetching ..." messages in the log (2.3.16). > > Is there anything to do about this? > I think the suggested solution is don't use bdb for the /var/lib/cyrus databases? The default in 2.4.x is skiplists. I know this has been mentioned or alluded to several times, but I'm still a bit unclear on how to convert an existing set of cyrus bdb databases to skiplists on a production system. -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: user_deny.db, very high load and Apple-Spotlight
Correction: I think you have to compile cyrus with no bdb support for the user-deny.db error message to go away: configure --without-bdb On 10/19/2010 01:20 PM, Patrick Goetz wrote: > On 10/14/2010 06:30 AM, Marc Patermann wrote: >> >> I created user_deny.db with touch to make the one error message go away. >> Now I have lots of "fetching ..." messages in the log (2.3.16). >> >> Is there anything to do about this? >> > > I think the suggested solution is don't use bdb for the /var/lib/cyrus > databases? The default in 2.4.x is skiplists. > -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyradm referall 2.4.1 version
On 19 Oct 2010, at 05:54, Lucas Zinato Carraro wrote: > I have 3 Frontends in DMZ, 4 Backends in Intranet > and a Administrative Station in other network. > > The administrative station, and clients stations can not connect > direct to backend servers. > > In imapd.conf i enable the parameter: > > proxyd_disable_mailbox_referrals: 1 > > With 2.3.16 dont have problem to issue commands direct in frontends > using cyradm. > > cyradm --user cyrus frontend2316 > > info user/mailbox - OK > lam user/mailbox - OK > sam user/mailbox - OK > cm user/mailbox - OK > > With 2.4.X : > > cyradm --user cyrus frontend241 > > info user/mailbox - OK > lam user/mailbox - OK > sam user/mailbox - timeout error > cm user/mailbox - timeout error > > Without firewall ( frontend - firewall - backend ) : > > info user/mailbox - OK > lam user/mailbox - OK > sam user/mailbox - Ask for backend password > cm user/mailbox - Ask for backend password > > I keep same config between cyrus 2.4.1 and cyrus 2.3.16. > > Its possible to disable referall to cyradm ? In 2.3.16, the getquotaroot command was referred if an administrator issued the command, even if mailbox referrals were disabled. As of 2.4.0, getquotaroot is proxied if the mailbox is remote, regardless of who issues the command or whether mailbox referrals are enabled. This is more correct, IMO. Here's the commit: http://git.cyrusimap.org/cyrus-imapd/commit/?id=9177afa1f1ab80da5334b2318e2c8f62362c361f http://git.cyrusimap.org/cyrus-imapd/commit/?id=06979236d2319ad586208c554a53aed7c50dc5e5 In 2.3.16, your admin station was most like connecting directly to the appropriate backend. I expect the behavior you're seeing in 2.4.x is related to your network configuration. I suggest tracing the imapd on the 2.4.x frontend to see what it's doing wrong. Perhaps it's attempting to connect from the wrong interface? :wes Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
One replica server for two murder backends
Hello! I want to install cnfiguration, where two murder backends are synced to one replica server. I suppose theoretically this is possible, because there are no mailboxes with identical names across backends. Any ideas, or may be someone already tested this configuration? Is there a chance that subscribtions for users from one backend to mailboxes from another one would work in such config with single backend? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Replication question
I have a new 2.3.16 back-end server and a replication server. (For those following my saga, I decided to upgrade the to-be-retired 2.2.12 rsync backup server to 2.3.16. I did this so I could test replication. Turns out this server was previously built with source RPMs, and the upgrade was a breeze. A big Thank You to Simon!) In testing replication I discovered that partition names must match. That is, the replication server has a single 1T default partition, while the new back-end server has a series of .5T partitions. As an experiment I configured the replication server thus: partition-default: /var/spool/imap defaultpartition: default partition-par1: /var/spool/imap That is, both default and par1 pointing to /var/spool/imap. And, this works! Is there any reason I should not do this? Note, this machine will be both the rsync server from the current 2.2.12 backend, and the replication server for the new 2.3.16 backend during the transition. Once all the mailboxes are moved to the new back end I'll have a free machine I can upgrade (OS, disks and Cyrus) to be the new replication server. (As an aside, it would no doubt be more cost effective to buy new hardware, but that's not going to happen.) A simple question, how does guid_mode: sha1 work? Does it need to be set on both master and replication server, and will it, for example, affect the unique ids returned by pop3? We have too many pop3 users. Mike -- Michael D. Sofka sof...@rpi.edu C&MT Sr. Systems Programmer, Email, HPC, TeX, Epistemology Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Replication question
On Tue, Oct 19, 2010 at 04:55:48PM -0400, Michael D. Sofka wrote: > I have a new 2.3.16 back-end server and a replication server. (For > those following my saga, I decided to upgrade the to-be-retired 2.2.12 > rsync backup server to 2.3.16. I did this so I could test replication. > Turns out this server was previously built with source RPMs, and the > upgrade was a breeze. A big Thank You to Simon!) Yay Simon! > In testing replication I discovered that partition names must match. > That is, the replication server has a single 1T default partition, while > the new back-end server has a series of .5T partitions. > > As an experiment I configured the replication server thus: > > partition-default: /var/spool/imap > defaultpartition: default > partition-par1: /var/spool/imap > > That is, both default and par1 pointing to /var/spool/imap. And, this > works! > > Is there any reason I should not do this? Should be fine. There's actually explicit checks for this situation in the code to make sure we don't do anything stupid when moving mailboxes around. In my perfect world[tm] this partition name matching requirement would not exist, but that's a long way off. I've talked about it to lots of people now, but it's a lot of work. Unified murder/replication. It will rock. Gotta find some spare cycles to write and test the damn thing though. > Note, this machine will be both the rsync server from the current 2.2.12 > backend, and the replication server for the new 2.3.16 backend during > the transition. Once all the mailboxes are moved to the new back end > I'll have a free machine I can upgrade (OS, disks and Cyrus) to be the > new replication server. (As an aside, it would no doubt be more cost > effective to buy new hardware, but that's not going to happen.) > > A simple question, how does guid_mode: sha1 work? Does it need to be > set on both master and replication server, and will it, for example, > affect the unique ids returned by pop3? We have too many pop3 users. Yes, set it on both. No, it doesn't affect the UIDL for pop3, which will still be UIDVALIDITY.UID. It works by calculating the sha1 of the rfc822 message both (i.e. the file stored on disk) and embedding it in the index record. This allows efficient de-duplication of copies on the replica, because the messages have the same GUID. In Cyrus 2.4, sha1 GUID is the only supported mode, and is required, and is checked for correctness during replication, so you can't accidentally replicate bogus information. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Welcome Greg and Max
I'd like to take this opportunity to welcome Greg and Max to the Cyrus mailing lists, and the Cyrus team at FastMail/Opera Software. They are both excellent programmers who we were lucky to hire. It's always hard to find great developers because they don't change jobs that often, and we were really lucky to be able to make these positions available when they were looking! Now that Cyrus 2.4 has been released with a lot of the groundwork for bandwidth efficient replication in place, Max is going to be working on improving the management tools and monitoring of the replication process. Our goal is to support master-master replication with safe conflict resolution, and multiple replication topologies including replication with more than two copies. This will allow efficient failover within a single datacentre as well as geographically distant close-to-real-time disaster recovery. Greg has already done some great work tidying up some of the worst offences against good taste in the codebase (like trailing whitespace) and collecting the discussions about coding standards from the mailing list into a coherent document so we can all work to the same standards going forwards. The goal is to document what we actually do rather than enforce anything new, but keep it easy to understand each others' code as we have more people working on the codebase. Greg will also be working on enhanced search capabilities and cross folder functionality that will allow us to present "conversations" - similar to threads but not constrained to a single folder. I'd like you all to make them feel at home here. It's fantastic to have the additional resources available - both the time Opera has allowed me in getting 2.4 finished, and now these additional programmers to speed the work on new features. FastMail has always had Cyrus as the core of our email system, and we're really happy to be working within the project to make it even better for us (and everyone else at the same time.) Regards, Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
cyrus squat + change runtime
Hi there, it is possible to change runtime of the cyrus squatter ? I've restarted cyrus service at 12:45 PM - in this time is a lot of users logged in and system is a little "slower". So I wanna to change its time. It is possible or I have to remember and wake up in the midnight and restart cyrus to change squatter runtime ? :) Thanks for advice. J.K. This message was sent using IMP, the Internet Messaging Program. binvThrYsZMTQ.bin Description: Veřejný PGP klíč Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus squat + change runtime
On Wed, Oct 20, 2010 at 07:16:33AM +0200, Josef Karliak wrote: > Hi there, > it is possible to change runtime of the cyrus squatter ? I've > restarted cyrus service at 12:45 PM - in this time is a lot of users > logged in and system is a little "slower". So I wanna to change its > time. It is possible or I have to remember and wake up in the > midnight and restart cyrus to change squatter runtime ? :) Can you show us your cyrus.conf? EVENTS This section lists processes that should be run at specific intervals, similar to cron jobs. This section is typically used to perform scheduled cleanup/maintenance. cmd= The command (with options) to spawn as a child process. This string argument is required. period=0 The interval (in minutes) at which to run the command. This integer value is optional, but SHOULD be a positive integer > 10. at= The time (24-hour format) at which to run the command each day. If set to a valid time (-2359), period is automatically set to 1440. This string argument is optional. So if you put in an "at=" item instead of a period, you should be set. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus squat + change runtime
Hi,
this is a part of the cyrus.conf. Thanks for right kick to right way.
EVENTS {
# this is required
checkpointcmd="ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd="cyr_expire -E 3" at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd="tls_prune" period=1440
# -JMAT- 070410 SQUAT je indexovaci file pro rychle vyhledavani mezi mboxy
# Bude pusten 1x za 24 hodin
squatter cmd="squatter -r user" period=1440
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL messages older then 30 days.
# enter 'man 8 ipurge' for more details
# cleanup cmd="ipurge -d 30 -f" period=60
}
I presume if I add after "period" argument "at" argument with hours
I wanna to run:
squatter cmd="squatter -r user" period=1440 at=0300
Is it all right ?
Thanks.
J.K.
Cituji Bron Gondwana :
On Wed, Oct 20, 2010 at 07:16:33AM +0200, Josef Karliak wrote:
Hi there,
it is possible to change runtime of the cyrus squatter ? I've
restarted cyrus service at 12:45 PM - in this time is a lot of users
logged in and system is a little "slower". So I wanna to change its
time. It is possible or I have to remember and wake up in the
midnight and restart cyrus to change squatter runtime ? :)
Can you show us your cyrus.conf?
EVENTS
This section lists processes that should be run at specific
intervals, similar to cron jobs.
This section is typically used to perform scheduled
cleanup/maintenance.
cmd=
The command (with options) to spawn as a child process.
This string argument is required.
period=0
The interval (in minutes) at which to run the
command. This integer value is optional,
but SHOULD be a positive integer > 10.
at=
The time (24-hour format) at which to run the command
each day. If set to a valid time
(-2359), period is automatically set to 1440. This
string argument is optional.
So if you put in an "at=" item instead of a period, you should be set.
Bron.
This message was sent using IMP, the Internet Messaging Program.
bin9jgpcNaG01.bin
Description: Veřejný PGP klíč
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus squat + change runtime
You can remove period and just use at. It even handles daylight saving changes.
"Josef Karliak" wrote:
>Hi,
>this is a part of the cyrus.conf. Thanks for right kick to right way.
>
>EVENTS {
> # this is required
> checkpointcmd="ctl_cyrusdb -c" period=30
>
> # this is only necessary if using duplicate delivery suppression
> delprune cmd="cyr_expire -E 3" at=0400
>
> # this is only necessary if caching TLS sessions
> tlsprune cmd="tls_prune" period=1440
>
> # -JMAT- 070410 SQUAT je indexovaci file pro rychle vyhledavani mezi mboxy
> # Bude pusten 1x za 24 hodin
> squatter cmd="squatter -r user" period=1440
>
> # Uncomment the next entry, if you want to automatically remove
> # old messages of EVERY user.
> # This example calls ipurge every 60 minutes and ipurge will delete
> # ALL messages older then 30 days.
> # enter 'man 8 ipurge' for more details
>
> # cleanup cmd="ipurge -d 30 -f" period=60
>}
>
> I presume if I add after "period" argument "at" argument with hours
>I wanna to run:
>
> squatter cmd="squatter -r user" period=1440 at=0300
>
> Is it all right ?
> Thanks.
> J.K.
>
>Cituji Bron Gondwana :
>
>> On Wed, Oct 20, 2010 at 07:16:33AM +0200, Josef Karliak wrote:
>>> Hi there,
>>> it is possible to change runtime of the cyrus squatter ? I've
>>> restarted cyrus service at 12:45 PM - in this time is a lot of users
>>> logged in and system is a little "slower". So I wanna to change its
>>> time. It is possible or I have to remember and wake up in the
>>> midnight and restart cyrus to change squatter runtime ? :)
>>
>> Can you show us your cyrus.conf?
>>
>>EVENTS
>>This section lists processes that should be run at specific
>> intervals, similar to cron jobs.
>>This section is typically used to perform scheduled
>> cleanup/maintenance.
>>
>>cmd=
>> The command (with options) to spawn as a child process.
>> This string argument is required.
>>
>>period=0
>> The interval (in minutes) at which to run the
>> command. This integer value is optional,
>> but SHOULD be a positive integer > 10.
>>
>>at=
>> The time (24-hour format) at which to run the command
>> each day. If set to a valid time
>> (-2359), period is automatically set to 1440. This
>> string argument is optional.
>>
>>
>> So if you put in an "at=" item instead of a period, you should be set.
>>
>> Bron.
>>
>
>
>
>
>This message was sent using IMP, the Internet Messaging Program.
>
>
>Cyrus Home Page: http://www.cyrusimap.org/
>List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus squat + change runtime
Great!
Thank you very much :).
J.K.
Cituji Bron Gondwana :
You can remove period and just use at. It even handles daylight
saving changes.
"Josef Karliak" wrote:
Hi,
this is a part of the cyrus.conf. Thanks for right kick to right way.
EVENTS {
# this is required
checkpointcmd="ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd="cyr_expire -E 3" at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd="tls_prune" period=1440
# -JMAT- 070410 SQUAT je indexovaci file pro rychle vyhledavani mezi mboxy
# Bude pusten 1x za 24 hodin
squatter cmd="squatter -r user" period=1440
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL messages older then 30 days.
# enter 'man 8 ipurge' for more details
# cleanup cmd="ipurge -d 30 -f" period=60
}
I presume if I add after "period" argument "at" argument with hours
I wanna to run:
squatter cmd="squatter -r user" period=1440 at=0300
Is it all right ?
Thanks.
J.K.
Cituji Bron Gondwana :
On Wed, Oct 20, 2010 at 07:16:33AM +0200, Josef Karliak wrote:
Hi there,
it is possible to change runtime of the cyrus squatter ? I've
restarted cyrus service at 12:45 PM - in this time is a lot of users
logged in and system is a little "slower". So I wanna to change its
time. It is possible or I have to remember and wake up in the
midnight and restart cyrus to change squatter runtime ? :)
Can you show us your cyrus.conf?
EVENTS
This section lists processes that should be run at specific
intervals, similar to cron jobs.
This section is typically used to perform scheduled
cleanup/maintenance.
cmd=
The command (with options) to spawn as a child process.
This string argument is required.
period=0
The interval (in minutes) at which to run the
command. This integer value is optional,
but SHOULD be a positive integer > 10.
at=
The time (24-hour format) at which to run the command
each day. If set to a valid time
(-2359), period is automatically set to 1440. This
string argument is optional.
So if you put in an "at=" item instead of a period, you should be set.
Bron.
This message was sent using IMP, the Internet Messaging Program.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
This message was sent using IMP, the Internet Messaging Program.
binlPCm9ct7WD.bin
Description: Veřejný PGP klíč
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
