On 13 Mar 2012, at 10:02, Dave McMurtrie wrote:
> 1) Developers (and sometimes system administrators) want a ChangeLog to show
> them exactly which things have changed in the code base.
I'd like the change log & the closed bugs to be correlated. Not something hard
to do, but requires some disci
getrusage() "works" on all platforms, AFAIK, at least in the POSIX sense: the
fields are there, and they may or may not be filled in, but everything will
compile. This is why I wonder if specifying a what usage ought to be logged
(including nothing) wouldn't make sense. If you're on a platform
I don't see a good reason to include code that digs around in /proc when
getrusage() has the exact same data. I think adding, e.g., I/O to the
telemetry calls would be peachy, either as a runtime option or if someone wants
to exercise their autoconf-foo, at build time as appropriate to the plat
I'd think you'd want to add this to telemetry_rusage(). Seems like you can get
this data from getrusage() since kernel 2.6.22?
:wes
On 12 Jul 2011, at 12:14, Olivier ROLAND wrote:
> Linux kernel 2.6.20 and later supports per process I/O accounting.
> You can access every process/thread's I/O re
On 06 Jan 2011, at 13:02, Jeroen van Meeuwen (Kolab Systems) wrote:
> I suppose for the switching to the cyrus user, what I always do is, for
> example:
> # su - -s /bin/bash cyrus -c '/usr/lib/cyrus-imapd/ctl_mboxlist -d'
> Because the cyrus user does not have a valid shell in RPM based distribu
On 17 Oct 2010, at 06:53, Jeroen van Meeuwen (Kolab Systems) wrote:
> I'm in favor to have (in our current X.Y.Z versioning schema) Z be bumped
> with
> bug-fixes only. If we keep it to bug-fixes only, this means we can rapidly
> release the fixes to the community.
I'm definitely in favor of th
On 16 Oct 2010, at 00:51, Bron Gondwana wrote:
> There's a stack of small things accumulating that I think are going to
> be enough to justify releasing 2.4.1 some time this week. The only
> major blocker I can see is LSUB across backends. I'm going to have a
> look at it during this flight to Au
On 12 Oct 2010, at 13:57, Henrique de Moraes Holschuh wrote:
> Well, I've seen in some other projects information get lost because of
> mass cleanups where there was not an effort to "unshelf" still important
> bugs. This is stuff that has been left idle for a long time because
> they were not pur
On 12 Aug 2010, at 04:29, Jeroen van Meeuwen (Kolab Systems) wrote:
My proposition is to distinguish between the following groups of
configurables:
- Gets the job done (novice)
- Gets your particular job done (advanced)
- You're on your own (expert)
It's a "human interface" mistake to allow us
On 10 Aug 2010, at 10:34, Jeroen van Meeuwen (Kolab Systems) wrote:
How do you propose we do that, given the manpages are generated from
lib/imapoptions by tools/config2man?
I haven't experimented with this myself, but it appears to me that
lib/imapoptions *is* the man page *and* the code. T
For duplicate db, how about not syncing?
I don't have a problem with exposing the interface.
:wes
On 08 Aug 2010, at 03:33, Bron Gondwana wrote:
I just
watched a duplicate_prune for over 1/2 hour doing stacks of
fdatasync as it wrote every single delete.
On 21 Jul 2010, at 16:17, Patrick Goetz wrote:
What about stuff that's a bug but not really a bug?
If it's not clear that it ought to be submitted to Cyrus's Bugzilla,
discuss it on the developer list. In the case of stupidshared, we
concluded that it can be removed. 2.3.16 includes both
On 21 Jul 2010, at 15:27, Patrick Goetz wrote:
Meanwhile, I'm going over the patches the redhat people added to
cyrus-imapd-2.3.16-5.src (actually, first comparing the
differences between this newer version and cyrus-
imapd-2.3.16-3.fc13.src) to see if there's anything there that
needs to
On 17 Jul 2010, at 10:34, Bron Gondwana wrote:
And that wasn't as short as I'd hoped. My apologies. Thanks for
reading.
Thanks for the concise & thorough discussion. I have no questions at
this time. Looks right (and good) to me.
Probably we should include your note in the docs.
:wes
On 05 Jul 2010, at 07:51, Rudy Gevaert wrote:
However if you are running replica's and masters on the same server
(of different instances) you'll have your sync_password on the
server in plain text. And thus the possibility of getting it
abused (only on the replica).
However, if you want
On 02 Jul 2010, at 23:11, Henrique de Moraes Holschuh wrote:
Also, this thing should really be two or three separate patches :p and
the manpage needs to document "-J".
I'd like to see these changes split into separate patches &
documentation of the (non-obvious) issues addressed included in
On 30 Jun 2010, at 11:19, Patrick Goetz wrote:
Speaking of coding, no one ever responded to the lib/
map_stupidshared.c thing. Is this file really necessary in the
modern code base? Is anyone really still running DEC machines?? I
ask because there's a debian patch for it which I'll need to
On 28 Jun 2010, at 21:35, Bron Gondwana wrote:
HASH || DASH
Agreed. Spacing around double bars is correct IMHO.
HASH|DASH
And no sparcing around single bars. I'm happy with that.
I'd say space around | and ||, both.
Similarly, space around mathematical operators.
Ye
On 29 Jun 2010, at 21:13, Bron Gondwana wrote:
I think we're bikeshedding here. Let's codify what's there rather
than
trying to invent out favourite style.
I don't know what bikeshedding is, but I understood defining what's
here to be the exercise. In limited cases it might make sense to
On 28 Jun 2010, at 18:21, Bron Gondwana wrote:
Parantheses cuddle close
This is not how I write C (as you know...), tho I recognize that the
majority of Cyrus is written this way. I also "over space"
statements like:
HASH || DASH
because I've been burned trying to find cases whe
On 18 Jun 2010, at 16:55, Patrick Goetz wrote:
I hope you guys aren't getting tired of these bug reports...
Not at all, but you can you input them to the cyrus bugzilla? I'd
hate for one to be over looked in email.
:wes
Seems like a reasonable suggestion. Where was it reported, exactly?
:wes
On 14 Jun 2010, at 17:46, Patrick Goetz wrote:
I'm trying to work through the patch list for currently incomplete
debian/Ubuntu cyrus 2.3.16 packages (the version of cyrus
currently available on debian/Unbuntu is 2.2.
When I moved all of my other projects to SF, I did it so (a) the
projects wouldn't be locked inside UMich when I left, and (b) other
contributors could be given access trivially. Having no feel for the
internal politics at CMU, I don't know whether (a) is an issue, but
(b) has been an issu
On 05 Jan 2010, at 22:16, Bron Gondwana wrote:
Not that I can see, except we might want to switch to git or
something else newer than CVS at some point - which would make
the whole issue moot.
I'd also like to move to git for Cyrus development.
:wes
On 16 Nov 2009, at 07:40, Dave McMurtrie wrote:
Дилян Палаузов wrote:
Can somebody enlighten me what is the policy for accepting patches
in cyrus/imap? I mean particularly bugs #3054 and 3113. Will
they be integrated in future releases, who can tell me when will
this happen?
Officially,
, at 23:52, Michael Bacon wrote:
So I spent several hours today working on this patch, before I
realized that Wesley Craig had already developed a patch. I notice
that his hasn't been accepted into the trunk on CVS yet. Let me
just state that this was a blocker bug for our implement
Please open a report in bugzilla and mark it was a "blocker". Thanks
for finding the issue.
:wes
On 17 Jun 2009, at 09:44, Michael Bacon wrote:
It turns out that this was an issue with mupdate being a multi-
threaded daemon, and in a critical place in the non-blocking prot
code (in prot_fl
On 30 Mar 2009, at 12:41, Dave McMurtrie wrote:
The fundamental problem is that kick_mupdate() returns void. If a
mupdate slave is not currently listening on its local AF_UNIX socket
(like when it disconnects because it loses contact with the mupdate
master) kick_mupdate() will attempt to connec
On 30 Mar 2009, at 08:52, Dave McMurtrie wrote:
I was reading through the mupdate.c code this morning looking for a
solution to a problem we're experiencing.
What problem is that?
That led to me reading the
pthread_mutex_lock() manpage. The mupdate.c code is using "fast"
mutexes. pthread_mu
Could you enter this in Bugzilla as a feature request, please? Also,
a unified diff would be preferable.
:wes
On 26 Mar 2009, at 06:38, Cyril Servant wrote:
Here is the patch for ipurge.c 2.3.14 :
On 24 Mar 2009, at 06:47, Thomas Jarosch wrote:
Thanks for calling. I don't like to spoil the party,
what about the issue which allows to create empty ACLs?
I seem to have forgotten to open a bug report,
what do you think is the best approach?
2.3.14 is more or less baked and people have been
IMAP RFC is nearly silent on the maximum length of a mailbox name
(length should fit in unsigned 32-bit integer). The next obviously
limit is related to MAXPATHLEN, assuming it's defined.
:wes
On 06 Feb 2009, at 17:17, Bron Gondwana wrote:
Anyone have an opinon on a good length limit?
On 04 Feb 2009, at 14:33, Thomas Jarosch wrote:
auth_unix.c:mycanonifyid() used to but now doesn't. Perhaps the
problem is this:
https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/
lib/auth_unix.c.diff?r1=1.37;r2=1.38 Removing those lines allows
canonicalization of zero length
On 02 Feb 2009, at 01:32, Bron Gondwana wrote:
It does change the regex syntax in sieve, and is probably non-
standardly evil! )
Oh? As I (minimally) understand sieve and it's extensions, the regex
syntax is thoroughly specified. Deviating from those standards is
probably a problem.
Als
rfc4314 seems to specifically disallow empty identifiers. Also, I
think you patch would probably permit an identifier of "-". BTW, I
have a patch to this code that I'm currently holding, which
introduces a leading "+" to identifiers. It's for the case of
XFERing mailboxes with invalid AC
Replying with +1 to basically anything on this list is not helpful.
There's no voting going on here. If you have commentary, it's
welcome. Please keep the nonsense off list, tho.
:wes
On 30 Jan 2009, at 05:11, Duncan Gibb wrote:
I think what Giuseppe is asking for is a mechanism whereby the user's
action triggers the learning command directly, rather than relying
on an
external agent (eg your cron job or our daemon) to come round and look
what the user has done.
One of th
On 29 Jan 2009, at 16:50, Giuseppe Ghibò wrote:
in many situations cyrus-imapd is used in configuration with
postfix as
MTA, and amavis-new
(http://www.ijs.si/software/amavisd/) which uses also to
"spamassassin",
"clamav"
and IIRC there should be the possibility to add support for dspam
(alt
I have no plans to implement it, at least not at this time. If I
were designing such a system, I'd problem want a configuration that
"watched" a special folder, and if refiling actions too place on that
folder, logged (or perhaps took an action on) a header. If you're
interested in writin
On 29 Jan 2009, at 11:46, Farzad FARID wrote:
I, too, second the use of a modern VCS for Cyrus Imap whether it's
a distributed one or not. But let's not forget that the available
web interfaces count a lot for the ease of use and popularity of
the VCSs.
I see no up side to moving from CVS
I've seen this before... :)
Looks fine. Is there a BZ open for it?
:wes
On 27 Jan 2009, at 23:15, Bron Gondwana wrote:
Gosh mboxlist_lookup provides a dangerous interface!
Looks good.
:wes
On 27 Jan 2009, at 23:15, Bron Gondwana wrote:
We're seeing some DB errors which are probably quota related,
but the debugging info isn't very clear. This will make it
much more clear exactly what is wrong!
On 27 Jan 2009, at 23:15, Bron Gondwana wrote:
If a non-user mailbox is being considered for promotion to a USER
event in sync_client, it trys to xstrdup the folder name starting
at the user name - except that's a NULL string and it segfaults.
This patch tests the result of mboxname_isusermailbo
Looks fine. Is this an open bugzilla? I recall you reporting the
problem.
:wes
On 27 Jan 2009, at 23:15, Bron Gondwana wrote:
We were truncating to the size of the mmaped area rather than the
length of the file, causing blocks of bogus zero bytes in the
resulting cache file after an aborted
On 05 Jan 2009, at 23:38, Bron Gondwana wrote:
mboxlist_lookup returns a live pointer to a malloc'ed copy of the
acl. So far so good.
Except (I presume to reduce memory management effort for callers of
the function) this value is overwritten next time you call
mboxlist_lookup again.
So - user_
On 24 Nov 2008, at 10:29, DEMBKOWSKI, Henryk ((Henryk)) wrote:
Is it possible to have two different versions of Cyrus installed on
two
different box
and they can talk to each other?
I see that function do_mailbox_single() is different between 2.3.7 and
2.3.13.
I am wondering if replication wil
On 04 Nov 2008, at 14:11, Duncan Gibb wrote:
I just posted a patch to make starttls in mupdate do something other
than time out. However, the crypto code is not thread-safe. Under
moderate load TLS negotiations fail all over the place and mupdate
segfaults fairly frequently.
Both of these pat
On 15 Oct 2008, at 13:53, Brian Awood wrote:
It seems like this could generally be described as the
local database is only authoritative if the mailbox is local,
otherwise
the mupdate master is authoritative.
That's more or less what I'd like to see happen. I'd like
ctl_mboxlist (regardle
On 03 Oct 2008, at 07:19, Lorenzo M. Catucci wrote:
As for bugzilla, the bug-tracker should be better advertised both on
the website and in released documentation;
I agree. I'd really like it if the main cyrus page was just a
framework to get to bugzilla, the wiki, the mailing lists, and the
Sounds like a blocker to me.
:wes
On 08 Oct 2008, at 09:11, David Carter wrote:
index.c: index_get_ids()
/* grab the References header */
if ((refstr = stristr(headers, "references:"))) {
Isn't a sensible thing to do given the following input:
On 25 Sep 2008, at 09:01, Ken Murchison wrote:
Anyone want to comment on these requests? I had planned on getting
to these patches, but then the push to get out 2.3.13 began.
On 25 Sep 2008, at 08:52, Michael Menge wrote:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2991
This bug seams
On 02 Oct 2008, at 12:23, Lorenzo M. Catucci wrote:
I'd be very happy if the perl patchlet and the update of
config.guess/sub
I wrote about on may, 27 would be applied too;
Is there some reason we wouldn't move to the latest config.guess/
sub? Also, can you submit a bugzilla about the perl
On 02 Oct 2008, at 11:47, Dmitriy Kirhlarov wrote:
Some time ago I report ptloader problem:
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2008-August/
029512.html
is it fixed in 2.3.13?
I'm sure not. Did you post a fix? Also, the report doesn't seem to
have ever made it into bugzilla.
On 25 Sep 2008, at 15:59, John Capo wrote:
statuscache_db.c assumes an off_t is 32bits.
if (p < dend) scdata->index_size = strtoul(p, &p, 10);
and in the printf that generates the string for the DB.
Attached is an autoconf patch that Lorenzo Catucci posted to the
mailing list in May.
Was
On 02 Oct 2008, at 10:20, Ken Murchison wrote:
#2873 is marked as a blocker, but its from 2006. Do we know if
there are still problems with OSX? I'm checking to see if I can
get my hands on, or access to, a Mac on campus.
Goodness knows. The error seems to be that the locally built cyrus-
On 30 Sep 2008, at 21:23, Ken Murchison wrote:
Using list-wildcards would always be a bad idea IMHO.
UMich has a lot of mailboxes with * in their names. It's not a
problem, tho you're probably right that it's a bad idea. I guess
IMAP implementations usually use literals to communicate. W
On 30 Sep 2008, at 20:00, Ken Murchison wrote:
Wesley Craig wrote:
UMich has added this list:
#$%'()*;<>?[]^`{|}
for years without any reported issues. These were added primarily
to deal with transition from UWIMAP to Cyrus, I'm not making a
case for any of them, pers
On 30 Sep 2008, at 16:33, Ken Murchison wrote:
While looking over bug #3002, https://bugzilla.andrew.cmu.edu/
show_bug.cgi?id=3002
I started wondering what other special characters we might want to
allow. The original authors were more restrictive with GOODCHARS
than the RFC. AFAICT the f
On 30 Sep 2008, at 09:36, Ken Murchison wrote:
Given your follow-up email about too many config options, should we
combine this with the existing rfc3028_strict option?
I don't think the point of that comment was to say that there are
"too many" per se. Just that "technically better" does n
I agree, and I think that would make a good reason to release
something called "2.4" -- it will break a bunch of stuff. With that
in mind, I'm about to propose another pair of config options. These
will control whether sieve should be compatible with draft 8 or 9 in
terms of response to A
On 26 Sep 2008, at 23:35, Rob Mueller wrote:
Rob suggests an imapd.conf option to control the new sieve utf-7
behavior discussed here:
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2008-September/
029778.html
Someone working on that? Is there a bugzilla for it?
Not that I know of for bo
On 25 Sep 2008, at 18:21, Bron Gondwana wrote:
. which looks for cases of MODSEQ being inappropriately set to 0 and
correcting it to be 1. Several buggy versions were released into
the
wild, so it's quite likely that there are MODSEQ 0 mailboxes out
there.
Xfer-ing them to a machine with th
On 25 Sep 2008, at 11:35, Ken Murchison wrote:
Wesley Craig wrote:
On 23 Sep 2008, at 22:43, Bron Gondwana wrote:
That's my entire wishlist for 2.3.13 (plus the buffer size patch you
already included)
I think there should be an RC2.
I don't see:
https://bugzilla.andr
On 23 Sep 2008, at 22:43, Bron Gondwana wrote:
That's my entire wishlist for 2.3.13 (plus the buffer size patch you
already included)
I think there should be an RC2.
I don't see:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3075
included in RC1. I gathered that *was* on your wish
On 23 Sep 2008, at 20:51, Ken Murchison wrote:
Its a separate tool with no changes to the rest of the codebase,
and its a tool that my boss' boss asked for for the University. I
always do what gets me paid.
Me too! ;)
Just to confirm, this tool doesn't get built unless a specific:
On 23 Sep 2008, at 19:53, Bron Gondwana wrote:
It looks to me like a standalone daemon that doesn't run unless you
explicitly invoke it. So long as the file compiles, it doesn't really
make much difference!
That's a good point, of course, but I think we've all agreed that
significant new fea
On 18 Sep 2008, at 22:42, Shawn Nock wrote:
I followed the recent thread about this, and I agree. Looking back on
this thread there has been very little traffic since your last post.
I'll streamline application of this patch to our systems.
Please let me know if it corrects the issue you've see
On 20 Aug 2008, at 18:25, John Capo wrote:
Tested patch attached.
I committed this.
:wes
On 04 Oct 2007, at 19:37, Shawn Nock wrote:
1. Looking at the code, if the client side of bitpipe is closed... I
can't see a scenario where the backend of the bitpipe is kept
alive. The
clean up code seems pretty much bullet proof, yet the behavior I am
seeing is that the client side of bitppi
On 06 Apr 2008, at 11:28, Alain Spineux wrote:
I opened a new bug on bugzilla.
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2987
I think you mean:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3053
I've reviewed the patch. Please address my comments to get it
committed. Than
uses. Another option might be appropriate, e.g.,
proxyd_allow_admin_referrals, to specifically permit commands that
won't retain privileges over proxy. This version, however, is simpler.
Any comments before I commit it?
:wes
cyrus-imapd-quota-referral.diff
Description: Binary data
On
Wesley Craig wrote:
We could make ldap_proxy_authz tri-valued: legacy, on, and off.
Legacy would be the default and would revert to the old behavior.
Of course, that means that it wouldn't support imapd.conf's typical
0/1, on/off, t/f "switch" syntax.
The complem
I've tried the following in a production system for a while. Seems
to address at least the POP issue (as expected), without introducing
any other obvious problems. Independent confirmation would be
helpful before I commit it, tho. I'm also not sure what the original
problem this:
http
I see 12 items in the bugzilla (one of which is the skiplist foreach
bug) which I think can be closed. So, yes, I think we should get
these various fixes committed and begin rolling 2.3.13. Can you make
sure bugzilla has the versions of these various patches that you
think should be appli
On 29 Aug 2008, at 02:31, Bron Gondwana wrote:
Please find attached a tested patch that fixes the problem and
refactors
the bloody mess that was locking code into a couple of nice, neat
functions.
A quick rewiew looks good to me. I'll review it closely this
afternoon and deploy it on a tes
On 20 Aug 2008, at 03:42, Thomas Jarosch wrote:
I've noticed a little piece of code and wanted to ask about the
original idea behind it. In mycanconifyid() is a special code path
if the identifier begins with "group:". If so, we call getgrnam()
and then copy the resulting group name into the
On 21 Aug 2008, at 05:01, Thomas Jarosch wrote:
Is this mailinglist or bugzilla the right place to submit patches?
The mailing list is a good place to discuss changes. For example,
before a patch is written, it's a good place to get input. Or after
a patch is written, the list is a good p
On 20 Aug 2008, at 09:56, John Capo wrote:
That does work on FreeBSD 6.3.
If many entreis are not NULL terminated, perhaps all of the string
formats should be %.*s with a specified length, then. Are you
willing to submit a tested patch?
:wes
I wonder if:
printf("Subjct>{%d}%.*s\n", CACHE_ITEM_LEN(cacheitem), CACHE_ITEM_LEN
(cacheitem),
cacheitem + CACHE_ITEM_SIZE_SKIP);
wouldn't do the trick?
:wes
On 19 Aug 2008, at 19:55, John Capo wrote:
mbexamine depends on cache file entries being NULL terminated and
some (many) are
On 15 Aug 2008, at 15:54, Michael Loftis wrote:
Can you point me to any code lines so maybe I can start looking?
Might be it's just not causing a core dump in my version but it's
still causing auth issues "somehow".
The bug I'm thinking of was introduced in 2.3, so it won't be the
same.
On 15 Aug 2008, at 14:07, Michael Loftis wrote:
Our 2.2.13 frontends seem to have some...weird authentication
problems with our (one remaining) 2.1 backend. after some
indeterminate amount of time or transactions they can no longer
authenticate to the backends, but ONLY the imap proxyd's.
else {
prot_write(pout, buf, c);
}
} while (c == sizeof(buf));
if ((err = prot_error(pin)) != NULL) {
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:cyrus-devel-
[EMAIL PROTECTED] De la part de Wesley Craig
Envoyé : mercredi 11 j
On 28 Jul 2008, at 04:19, Øyvind Kolbu wrote:
Ah, didn't think of using include, thanks! Though the included file
would
become another file I'll need to maintain outside CVS, hence
the proxy_passfile option is still wanted.
How is the management of an included file different from the
manage
Is there some reason why the quota commands aren't fully proxied?
E.g., this comment from cmd_getquotasroot:
/* If they are an admin, they won't retain that
privledge if we
* proxy for them, so we need to refer them -- even if
they haven't
* told us t
On 19 Jun 2008, at 12:08, Sebastian Langenhorst wrote:
C: E1 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID MUPDATE=mupdate://
mupdate/ STARTTLS AUTH=PLAIN AUTH=GSSAPI SASL-IR ACL RIGHTS=kxte
QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT
CHILDREN MULTIAPPEND
On 10 Jun 2008, at 10:07, Ken Murchison wrote:
Any suggestions? I'm off thinking about other things at the moment.
The comment associated with the change is:
make sure we send all available data, not just one buffer full.
this solves a pipelining problem where a response to a command
Looks like this change:
https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/
proxy.c.diff?r1=1.3;r2=1.4
is in error. The old code was wrong, but this change is also wrong.
:wes
On 09 Jun 2008, at 08:52, Brasseur Valery wrote:
I am using cyrus 2.3.11 in a murder setup... from
On 31 May 2008, at 17:25, Igor Brezac wrote:
Wesley Craig wrote:
On 31 May 2008, at 00:06, Igor Brezac wrote:
sasl used to be required for ldap proxy authz, but I do not think
this is the case any more. I suggested that both ldap_sasl and
ldap_proxy_authz do the same thing.
Perhaps I
On 31 May 2008, at 00:06, Igor Brezac wrote:
sasl used to be required for ldap proxy authz, but I do not think
this is the case any more. I suggested that both ldap_sasl and
ldap_proxy_authz do the same thing.
Perhaps I misunderstand you. Since SASL authN and proxy authZ are
more or less
cating why. A more sensible solution would be to make the limit
10 or 100. Is there a limit on the number of groups Cyrus allows?
For ldap_member/group_method of "attribute", a limit of 1 is probably
smart, since it reduces extraneous traffic.
:wes
Wesley Craig wrote:
I have a
I have a number of ptclient & ldap bug fixes and improvements to make:
1) In 2.3.12p2, if ldap_sasl is enabled, user DNs are obtained
through SASL authN/Z proxying. This assumes that the LDAP server
supports authN/Z proxying and that ptclient/ldap has authorization to
proxy for all users.
I've committed this patch, adjusted only slightly to apply cleanly to
CVS HEAD.
:wes
On 17 Mar 2008, at 20:28, Andrew Morgan wrote:
I wanted to make sure that our frontends never return a referral to
a backend (Pine seems to trigger this a lot). Attached is a patch
which adds an option to
This is a show stopper, i.e., it results in data loss:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2919
The two fixes are pretty trivial. I have other comments on running
ctl_mboxlist -m from cyrus.conf START, but those are probably not as
critical as these fixes.
This is brok
On 25 Jul 2007, at 03:51, David Carter wrote:
Just checked one of my live mailstores. It has 900 deleted
mailboxes out of 65287. 722 of those are empty postponed messages
mailboxes from our Webmail application and PINE, which I imagine is
rather unusual.
In the UMich environment, we curren
On 13 Jul 2007, at 05:03, David Carter wrote:
1) admin users can see the deleted mailboxes and just rename them back
into the live mailbox space:
DELETED/453f56443/user/dpc22/foo -> user/dpc22/foo
A downside of this approach is that the total size of the mailbox
list is increased. Th
On 12 Jul 2007, at 16:32, David Carter wrote:
rename() isn't quite as safe as linking each message in turn and then
removing the source mailbox: if the power fails after the rename() but
before the mboxlist is updated then you have a missing mailbox.
However:
1) Mailbox renames are rare
Ac
On 17 Jan 2007, at 03:10, Brasseur Valéry wrote:
Is it normal staht slave ALWAYS disconnect after receiving some
command update of the master ? And retry a full update 20sec later ?
The replica shouldn't be talking to the mupdate master. Remove the
mupdate_server config option from the repl
I hate replying to myself...
On 01 Nov 2006, at 14:51, Wesley Craig wrote:
I've updated this bug report:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2871
to include a patch adding support for a configuration option,
delete_mode, which takes the options "delayed"
I've updated this bug report:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2871
to include a patch adding support for a configuration option,
delete_mode, which takes the options "delayed" and "immediate". The
patch saves certain kinds of deleted mail in the cyrus spool
hierarc
I've attached fixes for bug #2870, that xfer can cause sync_client to
die:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2870
I also discovered that rename has a similar problem, and included a
fix for that as well. As I was analyzing this problem, I came to the
conclusion that
1 - 100 of 105 matches
Mail list logo
