Difference between revisions of "Installation (Zimbra)"

Jump to navigation Jump to search
1,506 bytes added ,  11:24, 19 June 2012
Updated post install section (continuation of rewrite)
(Re-write for v7 install - further updates required still)
(Updated post install section (continuation of rewrite))
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>


=== High CPU Workaround ===
Requires a restart to take effect...
Zimbra seems to have some real issues with constant high CPU spikes every minute, to limit reduce the logging retention and failed process checking.
zmcontrol restart
<pre>
su - zimbra
zmlocalconfig -e zmmtaconfig_interval=6000
zmprov mcf zimbraLogRawLifetime 7d
zmprov mcf zimbraLogSummaryLifetime 30d
/opt/zimbra/libexec/zmlogprocess


crontab -e
For more info see http://wiki.zimbra.com/wiki/CLI_zmtlsctl_to_set_Web_Server_Mode
*/60 * * * * /opt/zimbra/libexec/zmstatuslog
</pre>


* <code> zmlocalconfig -e zmmtaconfig_interval=6000 </code>
=== High CPU Workaround ===
** Increase service failure watchdog interval to 6000 secs
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.
{| class="vwikitable"
! Command !! Comments !! Default
|-
| <code> zmlocalconfig -e zmmtaconfig_interval=600 </code> || Increase service failure watchdog interval to 600 secs (10 mins) || <code>60</code>
|-
| <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
|}


'''Above seems to help, but doesn't fix things...!'''
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>)
Additionally, to disable the logging process, maybe (uncomplete)
{| class="vwikitable"
<pre>
! Original !! Change to !! Comments
su - zimbra
|-
hostname                # Gives your server's hostname
| <code> */2 * * * * /opt/zimbra/libexec/zmstatuslog </code> || <code> */60 * * * * /opt/zimbra/libexec/zmstatuslog </code> || Reduce status logging to hourly (from every 2 mins)
zmprov ms <hostname> -zimbraServiceEnabled logger
Will cause a bigger CPU spike on the hour.
</pre>
|-
| <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
|}


== References ==
== References ==

Navigation menu