Stripping of attachments using Horde 4/IMP 5.

[anant at isac.gov.in]

----- Message from simon.matter at invoca.ch ---------
     Date: Mon, 31 Dec 2012 10:33:31 +0100
     From: Simon Matter <simon.matter at invoca.ch>
  Subject: Re: Stripping of attachments using Horde 4/IMP 5.
       To: anant at isac.gov.in
       Cc: awilliam at whitemice.org, info-cyrus at lists.andrew.cmu.edu


>> ----- Message from awilliam at whitemice.org ---------
>>      Date: Sun, 30 Dec 2012 18:56:36 -0500
>>      From: Adam Tauno Williams <awilliam at whitemice.org>
>> Reply-To: awilliam at whitemice.org
>>   Subject: Re: Stripping of attachments using Horde 4/IMP 5.
>>        To: info-cyrus at lists.andrew.cmu.edu
>>
>>
>>> On Sun, 2012-12-30 at 12:23 +0530, anant at isac.gov.in wrote:
>>>> Dear experts,
>>>> I had extensive discussion on this issue in Horde/IMP mailing list.
>>>> Later I reported the problem in RedHat Bugzilla.  The details of the
>>>> problem are also part of bugzilla.
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=885620
>>>> Though patch for cyrus-imapd was given to me for testing, I was
>>>> suppose to reproduce the problem in another server.  I am unable to
>>>> reproduce the problem.  Now, I have a feeling that, the problem may be
>>>> due to /var/lib/imap residing in NetApp storage (though not NFS).
>>>> I have a feeling, the problem may solve, if I make /var/lib/imap part
>>>> of OS disk.  Your opinion please...
>>>
>>> Are you using Berkley databases?  If it does seg-fault what does the
>>> backtrace look like? [I don't see a backtrace in the bug report, just a
>>> core file; but the core isn't really useful unless one has the same
>>> version of the software].
>>>
>>> --
>>> Adam Tauno Williams  GPG D95ED383
>>> Systems Administrator, Python Developer, LPI / NCLA
>>>
>>> ----
>>> 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
>>>
>>
>> The databases used are:
>>
>> -rw------- 1 cyrus mail 144 Dec  9 09:29 ./annotations.db
>> ./annotations.db: Cyrus skiplist DB
>>
>> -rw------- 1 cyrus mail 144 Dec 30 11:30 ./db.backup1/annotations.db
>> ./db.backup1/annotations.db: Cyrus skiplist DB
>>
>> -rw------- 1 cyrus mail 1882668 Dec 30 11:30 ./db.backup1/mailboxes.db
>> ./db.backup1/mailboxes.db: Cyrus skiplist DB
>>
>> -rw------- 1 cyrus mail 144 Dec 30 11:00 ./db.backup2/annotations.db
>> ./db.backup2/annotations.db: Cyrus skiplist DB
>>
>> -rw------- 1 cyrus mail 1882668 Dec 30 11:00 ./db.backup2/mailboxes.db
>> ./db.backup2/mailboxes.db: Cyrus skiplist DB
>>
>> -rw------- 1 cyrus mail 18038784 Dec 30 11:30 ./deliver.db
>> ./deliver.db: Berkeley DB (Btree, version 9, native byte-order)
>>
>> -rw------- 1 cyrus mail 1882668 Dec 29 14:33 ./mailboxes.db
>> ./mailboxes.db: Cyrus skiplist DB
>>
>>
>> I don't have backtrace?  I am using RHEL rpms.
>
> Unfortunately we can also not see what has been changed in the patched
> RPMs you got from RH.
>
>>
>> But, is it OK to use NetApp Storage for /var/lib/imap file system?
>
> NetApp often sounds like NFS but you told us you are not using NFS but FC
> attached disks? If so I don't know why it shouldn't work exactly as local
> disks would.
>
> But when I hear Horde/IMP I remember a problem that some people hit after
> upgrading Horde/IMP. I don't remember what it was but you should find it
> in the archives. IIRC it has been fixed in the latest version of
> cyrus-imapd.
>
> Regards,
> Simon
>
> Regards,
> Simon

I had a thread with the same subject with Horde Team.  As per the IMAP  
logs which I provided to them, they say, IMAP server is broken.  Based  
on this input, I filed a bug report with RHEL.  The version of  
Cyrus-imapd which is installed on my RHEL is the latest version  
provided by RHEL.

I am using FC attached NetApp disks.

-Anant.

>


----- End message from simon.matter at invoca.ch -----



------------------------------------------------------------------------------
Confidentiality Notice: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
------------------------------------------------------------------------------