Difference between revisions of "Installation (Zimbra)"

Jump to navigation Jump to search
2,431 bytes added ,  21:32, 7 September 2014
m
(Re-write for v7 install - further updates required still)
 
(2 intermediate revisions by the same user not shown)
Line 18: Line 18:
! Specification !! CPU        !! Memory !! Free Disk !! Comments
! Specification !! CPU        !! Memory !! Free Disk !! Comments
|-
|-
| Eval / Test  || 1 x 1.5 GHz || 1 GB  || 5 GB      || Could be used for low-user count (< 10 active accounts) production environments - but certain operations will be slow.
| Eval / Test  || 1 x 1.5 GHz || 1.5 GB  || 5 GB      || Could be used for low-user count (< 10 active accounts) production environments - but certain operations will be slow.
|-
|-
| Minimum      || 1 x 2.0 GHz || 2 GB  || 10 GB    || Absolute minimum production spec advised by Zimbra
| Minimum      || 1 x 2.0 GHz || 2 GB  || 10 GB    || Absolute minimum production spec advised by Zimbra
Line 49: Line 49:
Once the install is completed, login to administer the exchange server using a URL similar to https://your-mail-svr:7071
Once the install is completed, login to administer the exchange server using a URL similar to https://your-mail-svr:7071


To enforce https for Zimbra Desktop clients use the following commands (requires a restart to take effect)...
== Post Install Config ==
<pre>
=== Enforce HTTPS for Clients ===
su - zimbra
To enforce user connections using Zimbra Desktop or the web client to [[Acronyms#H|HTTPS]] use the following command as the zimbra user (EG <code> su -zimbra </code>)
zmtlsctl https
zmtlsctl https
</pre>
 
Requires a restart to take effect...
zmcontrol restart
 
For more info see http://wiki.zimbra.com/wiki/CLI_zmtlsctl_to_set_Web_Server_Mode


=== High CPU Workaround ===
=== High CPU Workaround ===
Zimbra seems to have some real issues with constant high CPU spikes every minute, to limit reduce the logging retention and failed process checking.
Zimbra seems to have some reoccurring issues with regular high CPU spikes, some as often as every minute, caused by background maintenance tasks.  With the increasing prevalence of virtualisation, this appears to be being noticed more frequently by users, and can a reoccurring thread in the forums.  The following can aid in reducing this, which look to limit and reduce the logging retention and failed process checking that occurs.  The config changes are relatively aggressive, so you may wish to alter less from the default.
<pre>
{| class="vwikitable"
su - zimbra
! Command !! Comments !! Default
zmlocalconfig -e zmmtaconfig_interval=6000
|-
zmprov mcf zimbraLogRawLifetime 7d
| <code> zmlocalconfig -e zmmtaconfig_interval=600 </code> || Increase service failure watchdog interval to 600 secs (10 mins) || <code>60</code>
zmprov mcf zimbraLogSummaryLifetime 30d
|-
/opt/zimbra/libexec/zmlogprocess
| <code> zmprov mcf zimbraLogRawLifetime 7d </code> || Reduce raw log retention to 7 days || <code>31d</code>
|-
| <code> zmprov mcf zimbraLogSummaryLifetime 30d </code> || Reduce summary log retention to 30 days || <code>730d</code>
|-
| <code> zmprov ms <hostname> -zimbraServiceEnabled logger </code> || Toggles/disables the logger service - I don't do this myself, seems too drastic <br>
Replace <code><hostname></code> with [[Acronyms#F|FQDN]] of your Zimbra server <br>
To check services enabled  <code> zmprov gs <hostname> <nowiki>|</nowiki> grep zimbraServiceEnabled </code>
| Enabled
|}
 
Additionally its common to tune down the frequency of scheduled tasks (edit config file with <code> crontab -e </code>, some lines in table below truncated with <code>...</code>)
{| class="vwikitable"
! Original !! Change to !! Comments
|-
| <code> */2 * * * * /opt/zimbra/libexec/zmstatuslog </code> || <code> */60 * * * * /opt/zimbra/libexec/zmstatuslog </code> || Reduce status logging to hourly (from every 2 mins)
Will cause a bigger CPU spike on the hour.
|-
| <code> 00,10,20,30,40,50 * * * * /opt/zimbra/libexec/zmlogprocess ...</code> || <code> */15 * * * * /opt/zimbra/libexec/zmlogprocess ...</code> || Reduce log processing to every 15 mins
|}


crontab -e
=== Reduce AV Memory Usage ===
*/60 * * * * /opt/zimbra/libexec/zmstatuslog
Anti-virus spawns a number of threads so that it can concurrently process incoming and outgoing email.  If your server isn't expected to under much load and/or you're not too worried about mail queueing waiting to be scanned you can reduce the number of instances of amavisd that get spawned.
</pre>


* <code> zmlocalconfig -e zmmtaconfig_interval=6000 </code>
The default is 10 processes.  Reducing the number of process may reduce the amount of RAM used by AV scanning may allow other components of the system to use more RAM, effectively improving the responsiveness of the server, at the expense of reducing the speed of email delivery.  However,you may find that each process is now using more RAM so overall usage hasn't decreased.
** Increase service failure watchdog interval to 6000 secs


'''Above seems to help, but doesn't fix things...!'''
Log in to your server and as the zimbra user edit <code>/opt/zimbra/conf/amavisd.conf.in</code> and change the <code>$max_servers</code> config line.  No less than 2 is recommended, eg
Additionally, to disable the logging process, maybe (uncomplete)
* <code>$max_servers = 5; </code>
<pre>
su - zimbra
hostname                # Gives your server's hostname
zmprov ms <hostname> -zimbraServiceEnabled logger
</pre>


== References ==
== References ==

Navigation menu