[Users] Last security patch

[Frédéric Nass]

Mark,

That's interesting. Now I remember seeing these warnings before which is 
probably why I raised zimbraImapInactiveSessionEhcacheSize to 104857600 
in the past.
Can't remember exactly and apparently I didn't take note of this change 
which is quite unusual. :-D

I just had a look in mailbox.log files from 8 stores and 11.000 staff 
accounts and only found 14 records as such from March 1st till today, so 
I guess raising the value did help.

FWIW, the values you provided before (8.8.10 latest patch) are still the 
same in latest 8.8.11 P3.

Cheers,
Frédéric.

Le 19/03/2019 à 15:00, L Mark Stone a écrit :
>
> Frédéric,
>
>
> mailbox.log had errors like this (some entries modified for privacy)
>
>
> 2018-08-02 13:57:06,518 WARN [ImapSSLServer-5] [name=u 
> <mailto:cfiddle at stepbystepny.org>ser at domain.tld;ip=10.7.57.17;oip=xx.xx.xx.xx;via=10.7.57.17(nginx/1.7.1);ua=Zimbra/8.8.8_GA_3008;cid=1325;] 
> CompoundCachingTier - Error overflowing 
> '8ec5c54f-eb59-4b22-adb6-2f2707617874:5:69952:1' into lower caching 
> tier org.ehcache.impl.internal.store.offheap.OffHeapStore at 4d0b8b8b
> org.ehcache.core.spi.store.StoreAccessException: The element with key 
> '8ec5c54f-eb59-4b22-adb6-2f2707617874:5:69952:1' is too large to be 
> stored in this offheap store.
>
>
> Note this was back in August, when the system was running 8.8.8. It 
> may be that Zimbra has increased the defaults since then in later 
> versions; the farm where I provided the various ehcache values is 
> 8.8.10 with the latest patch.
>
>
> Hope that helps,
>
> Mark
>
> *_________________________________________________*
>
> *Another Message From...   L. Mark Stone*
>
>
>
>
> ------------------------------------------------------------------------
> *From:* Frédéric Nass <frederic.nass at univ-lorraine.fr>
> *Sent:* Tuesday, March 19, 2019 9:50 AM
> *To:* L Mark Stone; Victor d'Agostino; David Touitou
> *Cc:* users; Info Zeta Alliance
> *Subject:* Re: [Users] Last security patch
> Hello Mark,
>
> Can you share with us the WARN or ERROR messages that had you contact 
> Zimbra support initially  ? So we can check if we're also facing 
> Ehcache issues on our ZCS infrastructures?
>
> Regards,
> Frédéric.
>
> Le 19/03/2019 à 14:45, L Mark Stone a écrit :
>> As regards ehcache,  I had a Support Case open with Zimbra on this, 
>> and it was recommend to increase the ehcache size.
>>
>> This is what I have now:
>>
>> zimbra at my:~$ zmprov gacf | grep -i ehcach
>>
>> zimbraActiveSyncEhcacheExpiration: 5m
>>
>> zimbraActiveSyncEhcacheHeapSize: 10485760
>>
>> zimbraActiveSyncEhcacheMaxDiskSize: 10737418240
>>
>> zimbraImapActiveSessionEhcacheMaxDiskSize: 107374182400
>>
>> zimbraImapInactiveSessionEhcacheMaxDiskSize: 107374182400
>>
>> zimbraImapInactiveSessionEhcacheSize: 1048576
>>
>> zimbra at my:~$
>>
>>
>> Hope that helps,
>> Mark
>>
>> *_________________________________________________*
>>
>> *Another Message From...   L. Mark Stone*
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Victor d'Agostino <d.agostino.victor at gmail.com> 
>> <mailto:d.agostino.victor at gmail.com>
>> *Sent:* Tuesday, March 19, 2019 9:36 AM
>> *To:* David Touitou
>> *Cc:* L Mark Stone; users; Info Zeta Alliance
>> *Subject:* Re: [Users] Last security patch
>> Hello again
>>
>> Security apart the article lets suppose a 
>> /zimbraMemcachedClientServerList/ empty attribute is always safer, 
>> but IMAP performance could be better with it because the zimbra store 
>> would use the memcached service for IMAP protocol instead of EhCache.
>>
>> The official Zimbra guide says :
>> zimbraMemcachedClientServerList : list of host:port for memcached 
>> servers;*set to empty value to disable the use of memcached *
>>
>> I also have an empty attribute on my Zimbra 8.8.8 multi-store 
>> environment. If I have I/O performance issues on my zimbra stores, 
>> should I set the zimbraMemcachedClientServerList server attribute or 
>> let it empty ?
>>
>> Why does the memcached service is better than EhCache which is memory 
>> based ?
>>
>> Regards,
>> Victor
>>
>>
>>
>> Cordialement,
>> Victor d'Agostino
>>
>>
>> Le mar. 19 mars 2019 à 14:30, David Touitou <david at network-studio.com 
>> <mailto:david at network-studio.com>> a écrit :
>>
>>
>>     > Thanks David; it wasn't clear to me that the author was saying
>>     in the last
>>     > section that all these exposures had been fixed.
>>
>>     I might be wrong.
>>     But considereing there are attributed CVE numbers and patches, it
>>     looks to me as standard procedure:
>>      . vulnerability discovered and embargoed
>>      . software company contacted
>>      . software company acknowledged the vulnerability
>>      . software company issued patch
>>      . a couple days later, vulnerability went public with explanations
>>
>>     David
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zetalliance.org/pipermail/users_lists.zetalliance.org/attachments/20190319/8176cfc8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3607 bytes
Desc: Signature cryptographique S/MIME
URL: <http://lists.zetalliance.org/pipermail/users_lists.zetalliance.org/attachments/20190319/8176cfc8/attachment.p7s>