Re: ptloader problem
You can add it to the bugzilla here:
https://bugzilla.andrew.cmu.edu/
Thanks!
:wes
On 30 Jul 2008, at 05:57, Dmitriy Kirhlarov wrote:
> We find a problem -- when ptloader build with ldap support by gcc4 on
> amd64 platform it's doesn't work.
>
> After investigation ptloader core with gdb we find a problem. (I'm
> sorry, for possible unpropper problem description)
>
> 1. ldap.h have hints:
>
> #if LDAP_DEPRECATED
> LDAP_F( char ** )
> ldap_get_values LDAP_P((/* deprecated, use
> ldap_get_values_len */
> LDAP *ld,
> LDAPMessage *entry,
> LDAP_CONST char *target ));
>
>
> 2. cyrus building without "-DLDAP_DEPRECATED", by default and
> ldap_get_values is "int32"
>
> 3. ptloader running
> 3.1 call libldap
> 3.2 libldap get values from server
> 3.3 return pointer to ptloader as int64
> 3.4 ptloader get it as _int32_ and core dumping
>
> My test configuration:
> cyrus-imapd-2.3.{8,11} with ldap support
> cyrus-sasl-saslauthd-2.1.22 with ldap support
> openldap 2.{3,4}
> FreeBSD 7.0 amd64
>
> This configuration work very good on FreeBSD 6.x amd64.
> userbase in ldap, authentication over saslauthd, authorization over
> ptloader.
>
> How I can report a but to developers?
> I can provide my configs and detalize test procedure, if needed.
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
ptloader problem
Hi, list
We find a problem -- when ptloader build with ldap support by gcc4 on
amd64 platform it's doesn't work.
After investigation ptloader core with gdb we find a problem. (I'm
sorry, for possible unpropper problem description)
1. ldap.h have hints:
#if LDAP_DEPRECATED
LDAP_F( char ** )
ldap_get_values LDAP_P((/* deprecated, use ldap_get_values_len */
LDAP *ld,
LDAPMessage *entry,
LDAP_CONST char *target ));
2. cyrus building without "-DLDAP_DEPRECATED", by default and
ldap_get_values is "int32"
3. ptloader running
3.1 call libldap
3.2 libldap get values from server
3.3 return pointer to ptloader as int64
3.4 ptloader get it as _int32_ and core dumping
My test configuration:
cyrus-imapd-2.3.{8,11} with ldap support
cyrus-sasl-saslauthd-2.1.22 with ldap support
openldap 2.{3,4}
FreeBSD 7.0 amd64
This configuration work very good on FreeBSD 6.x amd64.
userbase in ldap, authentication over saslauthd, authorization over
ptloader.
How I can report a but to developers?
I can provide my configs and detalize test procedure, if needed.
WBR
Dmitriy
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: even more questions on replication and expire
Bron Gondwana wrote: > On Tue, Jul 29, 2008 at 05:09:05PM +0200, Per olof Ljungmark wrote: >> Bron Gondwana wrote: >>> On Tue, Jul 29, 2008 at 12:16:01PM +0200, Rudy Gevaert wrote: Per olof Ljungmark wrote: > In the course of setting up delayed expunge on our production > server I came across the following; > > - With delayed_expunge on the master, messages that are expunged by > a user will be retained -X days on the master but immideately > deleted on the replica unless it has delayed_expunge too. > > So if I implement delayed_expunge on the replica, do I need > cyr_expire to permanently remove messages after -X days or will > sync_client do that? yes >>> That's "yes" to "you need to run cyr_expire on the replica too". >> Thanks for the info. I can't help wonder if this was a firm design >> decision? From a user perspective it should be easier if this followed >> the synchronization I believe. >> >> Anyway, thanks, that was the last piece needed to finish off. > > I would much prefer that it was done via synchronisation as well. It's > a pain from a consistency point of view. Yes indeed. This is gonna be interesting. Sorry to bugger the list with all those perhaps already answered questions but I'm on my toes here. First run of cyr_expire on a replica exhibited this: cyr_expire[5829]: Expunged 4 messages from user.user1 cyr_expire[5829]: IOERROR: reading cache record for user.user2: got bogus offset 1935894896 for 4/1617; try reconstruct master[4384]: process 5829 exited, signaled to death by 11 What does the figure 4/1617 tell me if anything? I assume the cure here is "reconstruct -r -f -k user/user2" ? If I omit the "-k", will I end up without cyrus.expunge and orphaned message files or will they be deleted? Thanks again all. 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
Problem with Cyrus and blank space in mailbox folder
Hi, I have a Problem with cyrus and procmail. I use procmail, to check the mails and sort them into the right folders. In the procmail recipes (rc) I call cyrus to deliver the mails, this works fine so far. But if the Folder has a blank space inside its name, it doenstn't work. If I take a look into the logs I know whats the problem procmail: Assigning "BLA=/usr/cyrus/bin/deliver -a [EMAIL PROTECTED] -m user/username/b [EMAIL PROTECTED] but i didn't find a way to mask this blank space. I tried backspace, double backspace, etc but nothing works. Has anyone an idea? Bye, Martin 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
singleinstancestore and replication
Hi, I'm seeing a big difference in used space on my replicas and masters. Given the facts - that a mailbox is in sync; - I'm using the same configuration on master and replica; I can only see that the hard link count of certain files don't match. I can easily see how this can happen and don't see a way how we can prevent it. It's not even a problem. But, what I was wondering is. Am I not seeing anything over the head? Other issues that might be a cause for the difference in used space. Thanks, -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert [EMAIL PROTECTED] tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office Groep SystemenSystems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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
