https://wiki.zimbra.com/api.php?action=feedcontributions&user=Raunaq&feedformat=atomZimbra :: Tech Center - User contributions [en]2024-03-28T17:54:08ZUser contributionsMediaWiki 1.39.0https://wiki.zimbra.com/index.php?title=Steps_to_fix_folder_list_problem_in_webclient&diff=65444Steps to fix folder list problem in webclient2018-05-27T08:47:41Z<p>Raunaq: /* Steps to fix folder list problem in webclient */</p>
<hr />
<div>===<h1>Steps to fix folder list problem in webclient</h1>===<br />
<hr><br />
<br><br />
<br />
<h2>Problem:</h2><br />
<br />
On ZCS v8.5.x and higher versions folder list is not visible in left panel of webclient.<br />
<br />
<br />
<h2>Solution:</h2><br />
<br />
Check if all mailbox servers are listed in the ''zimbraReverseProxyAvailableLookupTargets''. <br />
<br />
Also, check ''zimbraMailReferMode'' must be set to "reverse-proxied" for all mailboxes. <br />
<br />
Since ZCS v8.0.x attribtue ''zimbraReverseProxyAvailableLookupTargets'' overrides the old attribute ''zimbraReverseProxyLookupTarget''<br />
<br />
If ''zimbraReverseProxyAvailableLookupTargets'' is empty then proxy will use those mailbox servers for lookup which are having<br />
''zimbraReverseProxyLookupTarget=TRUE''<br />
<br />
'''1).''' To fix this problem add all mailbox servers to the ''zimbraReverseProxyAvailableLookupTargets'' and set ''zimbraMailReferMode'' to "reverse-proxied". <br />
<br />
zmprov mcf +zimbraReverseProxyAvailableLookupTargets <mailbox server> <br />
zmprov mcf zimbraMailReferMode reverse-proxied <br />
<br />
'''2).''' Now restart mailbox service and proxy service to take changes. <br />
<br />
zmmailboxdctl restart <br />
zmproxyctl restart<br />
<br />
The idea here is to find the mailbox where the affected user is and add it to zimbraReverseProxyAvailableLookupTargets if it has some value and if it is empty set zimbraReverseProxyLookupTarget to TRUE on that mailbox node.<br />
<br />
<br />
Submitted by: Heera Singh Koranga</div>Raunaqhttps://wiki.zimbra.com/index.php?title=Nginx_fails_to_start&diff=65443Nginx fails to start2018-05-27T08:26:42Z<p>Raunaq: /* Nginx fails to start */</p>
<hr />
<div>===<h1>Nginx fails to start</h1>===<br />
<hr><br />
<br><br />
<br />
<h2>Problem:</h2><br />
<br />
Nginx fails to start.<br />
<br />
Running zmproxyctl start giving the following error :<br />
<br />
"Starting nginx...failed. /opt/zimbra/conf/nginx.conf is missing."<br />
<br />
Configuring proxy by command - <br />
<br />
/opt/zimbra/libexec/zmproxyconfgen<br />
prompting the following error :<br />
<br />
Exception in thread "main" java.lang.NullPointerException<br />
at com.zimbra.cs.util.ProxyConfVar.isValidUpstream(ProxyConfGen.java:308)<br />
at com.zimbra.cs.util.WebEwsSSLUpstreamServersVar.update(ProxyConfGen.java:989)<br />
at com.zimbra.cs.util.ProxyConfGen.updateDefaultVars(ProxyConfGen.java:2471)<br />
at com.zimbra.cs.util.ProxyConfGen.createConf(ProxyConfGen.java:2630)<br />
at com.zimbra.cs.util.ProxyConfGen.main(ProxyConfGen.java:2827)<br />
<br />
<h2>Solution:</h2><br />
<br />
The error prompts when the proxy configuration has non-existing servers or non-mailbox servers listed with the following attributes -<br />
<br />
Note: Please check the value of ''zimbraReverseProxyAvailableLookupTargets'' at the server level as well as global level configuration :<br />
<br />
su - zimbra<br />
zmprov -l gs `zmhostname` zimbraReverseProxyAvailableLookupTargets<br />
zmprov -l gcf zimbraReverseProxyAvailableLookupTargets<br />
zmprov -l gs `zmhostname` zimbraReverseProxyAvailableLookupTargets<br />
zmprov -l gs `zmhostname` zimbraReverseProxyUpstreamEwsServers<br />
zmprov -l gs `zmhostname` zimbraReverseProxyUpstreamLoginServers<br />
<br />
zmprov -l gcf zimbraReverseProxyAvailableLookupTargets<br />
zmprov -l gcf zimbraReverseProxyUpstreamEwsServers<br />
zmprov -l gcf zimbraReverseProxyUpstreamLoginServers<br />
<br />
Check the above attributes and put only valid mailbox server name in these attributes. If there are non-existing mailbox servers then we can change the attribute value by using below commands - <br />
<br />
zmprov ms server_name zimbraReverseProxyUpstreamEwsServers <mailbox_server_name><br />
zmprov mcf zimbraReverseProxyUpstreamEwsServers <mailbox_server_name><br />
<br />
Then try again to configure zimbra-proxy<br />
<br />
zmproxyconfgen -s `zmhostname` -w /tmp/<br />
/opt/zimbra/libexec/zmproxyconfig -m -w -e -x redirect -H `zmhostname`<br />
<br />
<br />
<br />
<br />
Submitted by: Sourabh Bhushan</div>Raunaqhttps://wiki.zimbra.com/index.php?title=LDAP&diff=65420LDAP2018-05-17T05:11:30Z<p>Raunaq: /* LDAP uses in ZCS */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=LDAP=<br />
{{KB|{{Unsupported}}|{{ZCS 8.0}}|{{ZCS 7.0}}|}}<br />
{{WIP}}<br />
== [[LDAP]] Overview ==<br />
=== [[LDAP]] uses in ZCS ===<br />
[[LDAP]] is used in ZCS to store data for<br />
<br />
* Global configuration<br />
* USER and Authentication<br />
* SERVER<br />
* DOMAIN<br />
* COS<br />
<br />
Additionally, information relating to:<br />
* External [[LDAP Authentication]]<br />
* External GAL<br />
<br />
Most of this data can be viewed and configured via the [[:Category:Administration|Admin Console]] or with [[zmprov]].<br />
<br />
=== [[LDAP]] in the system architecture ===<br />
In every ZCS installation, there will be one and only one ''Master'' [[LDAP]] server. This server is authoritative for user information, server configuration, etc. <br />
<br />
Additionally, one or more [[LDAP#LDAP replication|Replicas]] may be defined, to improve performance and reduce the load on the Master.<br />
<br />
During installation in a multi-server environment, the [[LDAP]] server must be the first installed and configured, and must be running during any subsequent installations. The [[LDAP]] server must also be the first started in a multi-server environment.<br />
<br />
== [[LDAP]] troubleshooting ==<br />
<br />
==="no objectClass attribute" and "index_param failed" warnings in zimbra.log===<br />
You may see lines like below in /var/log/zimbra.log. Lines are informational, reporting that certain attributes are not indexed. This is not a problem. This logging has been removed for ZCS 4.5.7 and later.<br />
<br />
Aug 29 19:07:22 host slapd[30824]: is_entry_objectclass("", "2.5.6.1") no objectClass attribute<br />
Aug 29 19:07:22 host slapd[30824]: <= bdb_equality_candidates: (zimbraDomainType) index_param failed (18)<br />
<br />
=== Installation Problems ===<br />
If you're seeing '''ERROR: service.FAILURE (system failure: getDirectContext) (cause: javax.naming.CommunicationException localhost.localdomain:389)''' on installation, you're in the right place.<br />
<br />
<br />
[[LDAP]] initialization generally fails due to the following<br />
* Failure to start the [[LDAP]] server<br />
* Failure to resolve the [[LDAP]] server<br />
* Failure to connect to the [[LDAP]] server<br />
<br />
=== Startup failures ===<br />
The startup of the [[LDAP]] server during installation happens when the initialization script calls the ldap start script.<br />
<br />
If this startup fails, all further initialization fails.<br />
<br />
If you see something like the following when upgrading, verify that the [[sudoers]] file contains the proper allowances for the zimbra user.<br />
<br />
[zimbra@mailhost ~]$ zmcontrol start<br />
Host mailhost.domain.com<br />
Starting ldap...Password:<br />
<br />
<br />
==== Detecting startup failure ====<br />
After the initialization script exits (successfully or otherwise) slapd should be running. To verify that the slapd process is running:<br />
<br />
<tt>ps auxww | grep zimbra | grep slapd</tt><br />
Should return a line containing:<br />
<tt>/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldaps:// ldap://:389/ -f /opt/zimbra/conf/slapd.conf</tt><br />
<br />
If there is no output, [[LDAP]] is not starting. See the [[LDAP#Correcting startup failure|next section]] <br />
<br />
If this line is present, verify that the zimbra system is detecting it (run as the [[zimbra user]]):<br />
<br />
<tt>ldap status</tt><br />
A return of:<br />
slapd running pid: ''7568'' (your PID will vary)<br />
is successful.<br />
<br />
If you get no such response from the <tt>ldap status</tt> command, it's likely that the running slapd process is hanging around from a previous installation. To kill it manually:<br />
<br />
<tt>killall -TERM slapd</tt><br />
<tt>ps auxww | grep zimbra | grep slapd</tt><br />
If the process is still there, determine it's PID (second column in the '''ps''' output) and <br />
<tt>kill -9 ''PID''</tt><br />
<br />
After cleaning up old [[LDAP]] processes, you should re-attempt the initialization by re-running zmsetup.pl.<br />
<br />
==== Ubuntu 6.10 LDAP Startup Solution ====<br />
''This applies to running the Debian build on Ubuntu, not the Ubuntu build''<br />
<br />
If you are getting the dreaded:<br />
<br />
LDAP startup ... FAILED (256) on UBUNTU, I solved my problems with 2 changes:<br />
<br />
1 UBUNTU by default symlinks /bin/sh to /bin/dash which does not support the 'source' command. <br />
To fix<br />
rm /bin/sh<br />
ln -s bash /bin/sh<br />
<br />
2 UBUNTU Server distro does not have a Java runtime, the certification startup <br />
The zimbra installer requires the java runtime in the /jre directory. <br />
Zimbra has a JRE available so simply a second symlink will solve the problem<br />
To fix:<br />
ln -s /opt/zimbra/jdk1.5.0_08/jre /jre<br />
<br />
==== Correcting startup failure ====<br />
If the [[LDAP#Detecting startup failure|previous section]] indicates that ldap is not starting at all, attempt ldap startup manually (as the [[zimbra user]]);<br />
sh -x bin/ldap start<br />
output from this should indicate the source of the problem<br />
<br />
The problem may not be indicated in the command above. Instead, you should check your syslog, for logs originating from local0.<br />
<br />
An alternative method is to execute the command executed by "ldap start", in my case, this was:<br />
<br />
sudo /opt/zimbra/openldap-2.3.21/libexec/slapd -d7 -l LOCAL0 -4 -u zimbra -h ldap://localhost:389/ -f /opt/zimbra/conf/slapd.conf<br />
<br />
Note the -d7 in the middle is used to troubleshoot and read debug logs on the screen.<br />
<br />
=== [[LDAP]] and [[DNS]] ===<br />
<br />
[[LDAP]] uses [[DNS]] to resolve the ldap host, ''even if it's localhost''<br />
<br />
To verify that you're able to resolve the ldap host:<br />
:<tt>host ''ldap-hostname''</tt><br />
<br />
Make sure you understand [[DNS]].<br />
<br />
=== Failure to Connect ===<br />
<br />
To detect connection failure (using the hostname configured for the ldap server):<br />
telnet ''ldaphostname'' 389<br />
<br />
If this times out, or the connection is refused, there could be several causes.<br />
<br />
If resolution succeeds, the initialization may fail because the [[LDAP]] server [[LDAP#Correcting startup failure|failed to start]]<br />
<br />
==== Firewall problems ====<br />
If the server is running a local firewall, make sure it's allowing port 389 connections.<br />
<br />
If the ldap hostname resolves to a [[DNS|public IP]] on an external firewall, make sure that firewall is allowing connections through on port 389.<br />
<br />
== Integration with external [[LDAP]] servers ==<br />
=== External Authentication ===<br />
<br />
Please see [[King0770-Notes#External_Authentication_with_LDAP]] for information on this.<br />
<br />
=== External GAL ===<br />
== Connecting to an External LDAP Server with SSL ==<br />
<br />
If the external LDAP server has a self-signed certificate, you will need to add the cert to the Zimbra keystore(s). Use the following command (substitute your chosen alias and the path to your cert file; all on one line):<br />
<br />
<pre><br />
sudo /opt/zimbra/java/bin/keytool -import \<br />
-alias EXTERNAL-LDAP \<br />
-keystore /opt/zimbra/java/jre/lib/security/cacerts \<br />
-storepass changeit \<br />
-file EXTERNAL-LDAP-CERT-FILE<br />
</pre><br />
<br />
After adding the cert to the keystore, you'll need to restart Tomcat. As the zimbra user, do this:<br />
<pre><br />
tomcat stop && tomcat start<br />
</pre><br />
<br />
Make sure that you have selected SSL when configuring use of the external ldap server in the admin console. You can verify on the command line that this returns an "ldaps" url:<br />
<br />
<tt><br />
:zmprov gd DOMAIN.COM | grep zimbraAuthLdapURL<br />
</tt><br />
<br />
PS : in order to download the certificate, you can use openssl from the zimbra server :<br />
<br />
openssl s_client -connect EXTERNAL-LDAP:636 > EXTERNAL-LDAP-CERT-FILE<br />
<br />
You just have to clean the resulting file a bit...<br />
<br />
===Find out if your external auth cert had expired===<br />
If your users cannot access their accounts from the web-client, check to see if the external authentication server's ssl cert expired.<br><br />
<br />
If the external authentication's ssl cert expired, you may see errors in the /opt/zimbra/log/mailbox.log file.<br />
<br />
<tt><br />
'''Caused by: javax.naming.CommunicationException: simple bind failed: 192.168.2.15:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed]'''<br />
</tt><br />
<br />
To check to see the the external authentication's ssl cert expired, run the following commands:<br />
<br />
<code><pre><br />
openssl s_client -connect EXTERNAL-LDAP:636 > EXTERNAL-LDAP-CERT-FILE.crt<br />
<br />
openssl x509 -in EXTERNAL-LDAP-CERT-FILE.crt -noout -text<br />
</pre></code><br />
<br />
Near the top of the output, you should see Validity dates.<br><br />
Example:<br><br />
Not Before: Apr 23 13:54:47 2008 GMT<br><br />
Not After : Apr 23 13:54:47 2009 GMT<br><br />
<br />
Tip: For a short-term workaround, set localconfig key '''''ssl_allow_untrusted_certs''''' to ''true'' from ''false''.<br />
<pre>zmlocalconfig -e ssl_allow_untrusted_certs=true</pre><br />
<br />
== Provisioning users in [[LDAP]] ==<br />
The basic form for this is:<br />
[[zmprov]] ca ''username@domain'' ''password'' <br />
<br />
Additional attributes can be specified on the same command:<br />
[[zmprov]] ca ''username@domain'' ''password'' ''attribute'' ''value'' ''attribute'' ''value''<br />
<br />
For creation of a single user, the admin console is the preferred method. If you need to bulk provision users, during initial installation, it can be easier to create a script.<br />
<br />
EXAMPLE - creating several users at once:<br />
<br />
Create a file containing all of the [[zmprov]] commands that you wish to run:<br />
<br />
ca user1 user1pass<br />
ca user2 user2pass<br />
ca user3 user3pass<br />
ca adminuser adminuserpass zimbraIsAdminAccount TRUE<br />
ca user4 user4pass zimbraMailAlias user_4 zimbraMailAlias user_four zimbraMailAlias user.four<br />
ca nopassuser ''<br />
<br />
Save this file (eg, ''usercreate.txt'' ). Then, run [[zmprov]], redirecting standard input from this file:<br />
zmprov < usercreate.txt<br />
<br />
With this method, it's relatively straightforward to dump an existing ldap directory into a text file, format it for zmprov, and bulk-provision the users in the ZCS [[LDAP]] instance.<br />
<br />
If you are using [[LDAP#External Authentication|external LDAP authentication]] you can create the users with no local password by supplying the empty string "" after the username<br />
<br />
== [[LDAP]] replication ==<br />
<br />
=== Installation ===<br />
Your [[LDAP]] Master server (machine 1) should be installed using normal ZCS installation options. The replica will be installed on a separate server (machine 2).<br />
<br />
=== Replica Configuration ===<br />
After the master server is up, enable replication on the '''master''' with the command <tt>/opt/zimbra/libexec/zmldapenablereplica</tt><br />
<br />
===Install Replica Server===<br />
<br />
To install the replica server:<br />
* Make sure the master is up and running before you apply the configuration to machine 2 and complete the installation. <br />
* Use standard install.sh options, including the zimbra-ldap server.<br />
* Set the master [[LDAP]] server for machine 2 to be machine 1.<br />
* Set the [[LDAP]]root password to the correct value (run zmlocalconfig -s ldap_root_password on the master to determine this value)<br />
* Set the [[LDAP]] replication password to the correct value (run zmlocalconfig -s ldap_replication_password on the master to determine this value)<br />
* Installation will complete as normal, and both servers will have their ZCS servers up, except for slapd on machine 2.<br />
<br />
'''''Note:''' In order to install an LDAP replica server with no MBS (Mailbox Server), set '''zimbra_zmprov_default_to_ldap''' to '''true''', using the following command: '''zmlocalconfig -e zimbra_zmprov_default_to_ldap=true'''. If you later add an MBS to your LDAP replica server, set '''zimbra_zmprov_default_to_ldap''' to '''false.'''''<br />
<br />
If you want to install an [[LDAP]] replica on a previously existing Zimbra server, you will need to use install.sh to install zimbra-ldap on the server. When install.sh asks if you wish to perform an upgrade, select Yes, then select Yes when it asks to install zimbra-ldap. The rest of the install will be similar to installing a disabled [[LDAP]] server on a new box.<br />
<br />
When this is complete, you're done. You can test the replica by creating a few accounts<br />
through the administrative interface on the master server. You should be able to see them<br />
immediately with an [[LDAP]] search run against machine 2.<br />
<br />
[[LDAP]] logging will appear in /var/log/zimbra.log. It is recommended this setting be enabled only for testing and troubleshooting.<br />
<br />
===Running LDAP replica===<br />
Any services running on the '''replica''' server itself will automatically query the '''replica''' first.) <br />
<br />
The order for the <tt>ldap_url</tt> key on the hosts using the '''replica''' should be '''replicas''' first, with the '''master''' listed last. The '''master''' must always be included!<br />
<br />
== Promoting LDAP Replica to be LDAP Master ==<br />
To see instructions for promoting a replica to LDAP master, go to [[Promoting_Replica_to_LDAP_Master]]. This procedure shows how to move the [[LDAP]] Master from one host to another. This is not recommended for use by those without at least some LDAP expertise.<br />
<br />
<br />
== LDAP Logs ==<br />
For /var/log/zimbra.log<br />
<br />
===Change Levels===<br />
There are two methods.<br><br />
<br />
1)<br><br />
<br />
<code><pre><br />
<br />
zmlocalconfig -e ldap_log_level=256<br />
<br />
ldap stop<br />
<br />
ldap start<br />
<br />
</pre></code><br />
<br />
2)<br><br />
<br />
<code><pre><br />
**this method does not require ldap stop/start**<br />
<br />
ldapmodify -x -h <host> -D "cn=config" -W <hit enter><br />
<enter ldap_root_password><br />
dn: cn=config<br />
changetype: modify<br />
replace: olcLogLevel<br />
olcLogLevel: 256 **if you want to disable ldap log, type in 'none'**<br />
<enter> <enter><br />
<br />
</pre></code><br />
<br />
<br />
<br />
=== Levels ===<br />
<pre><br />
Default: 32768 (OR 0x8000 OR none) would just log critical stuff<br />
<br />
zmlocalconfig -e ldap_log_level=32768<br />
zmcontrol stop/start<br />
<br />
Note that in ZCS 6+ ldap_log_level has been replaced by ldap_common_loglevel.<br />
<br />
We tried 16640 = stats + sync for a few releases and found it overhwelming - but it's good for debug.<br />
<br />
LDAP<br />
Master: 32768 none (critical only)<br />
Replicas: 49152 = none + sync = 32768 + 16384 (no stats but syncrepl entries<br />
are logged)<br />
<br />
For instance to set that replica value it would be:<br />
zmlocalconfig -e ldap_log_level=49152<br />
OR<br />
zmlocalconfig -e ldap_log_level="none sync"<br />
<br />
You can define it several ways (single interger in decimal or hexadecimal, or keywords) and then you can combine them - for instance these are equivalent:<br />
loglevel 129<br />
loglevel 0x81<br />
loglevel 128 1<br />
loglevel 0x80 0x1<br />
loglevel acl trace<br />
<br />
hexadecimal <> decimal conversion tool<br />
<br />
The keyword any can be used as a shortcut to enable logging at all levels (equivalent to -1).<br />
<br />
The keyword none, or the equivalent integer representation (32768 or 0x800), causes those messages that are always logged regardless of the configured loglevel to be output (specified & critical stuff). In fact, if no loglevel (or a 0 level) is defined, no logging occurs, so at least the none level is required to have high priority messages logged.<br />
<br />
In short, 32768 (OR 0x8000 OR none) = only messages that get logged whatever log level is set, thus you get critical stuff.<br />
</pre><br />
<br />
== ZCS 6.0+ ==<br />
<pre><br />
When the GnR ZCS 6.0 release comes out, our entire OL setup has changed with our move to OpenLDAP 2.4.<br />
<br />
<br />
OpenLDAP DB is now in /opt/zimbra/data/ldap/{config,hdb,accesslog}/<br />
<br />
We've moved to using the cn=config backend rather than text files for configuration. This means that any changes made to the configuration<br />
database are preserved across restarts and upgrades. As a part of this, I've made it so many more portions of the OL configuration can be<br />
controlled (See bug#20972). This means that sites will no longer have to modify slapd.conf by hand every release for changes they want to see<br />
persist. In particular, note that ldap_log_level is no longer an LC key, it has been replaced by ldap_common_loglevel.<br />
<br />
Modfications to the ldap_{commmon,db,accesslog,overlay}_* LC keys are monitored by zmmtaconfig, and will push the those changes to the LDAP<br />
server within 2 minutes or less. This means easy on-the-fly loglevel changes, for example. A few options (ldap_common_require_tls) currently<br />
require a restart to take effect, but may not in the future. Some (ldap_common_threads) always will.<br />
</pre><br />
{{Article Footer|Zimbra Collaboration 8.0, 7.0|04/16/2014}}<br />
[[Category:Architecture and Components]]<br />
[[Category:LDAP]]<br />
[[Category:Pending Certification]]</div>Raunaqhttps://wiki.zimbra.com/index.php?title=HidemobilenumberinGAL&diff=65155HidemobilenumberinGAL2018-03-06T09:32:59Z<p>Raunaq: Hide Mobile Number in GAL</p>
<hr />
<div>=Hide Mobile Number in GAL=<br />
{{KB|{{ZC}}|{{ZCS 8.8}}|{{ZCS 8.7}}||}}<br />
<br />
==Issue==<br />
Need to hide mobile numbers of users in GAL<br />
<br />
==Resolution== <br />
<br />
* zmprov mcf -zimbraGalLdapAttrMap "mobileTelephoneNumber,mobile=mobilePhone"<br />
* zmgsautil forcesync -a galsync@example.com -n InternalGAL<br />
* zmprov fc all</div>Raunaqhttps://wiki.zimbra.com/index.php?title=Unable_to_create_Zimbra_profile_with_Outlook_2016&diff=64497Unable to create Zimbra profile with Outlook 20162017-10-03T07:39:44Z<p>Raunaq: Unable to create Zimbra profile with Outlook 2016</p>
<hr />
<div><br />
=Unable to create Zimbra profile with Outlook 2016=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}|{{ZCS 8.6}}||}}<br />
<br />
<br />
Starting with MS Outlook Version 16.0.8431.2046 (approx.) it is no longer possible to select "Other Accounts" in Outlook account setup dialog. Thus it makes it impossible to create Zimbra Profiles although the Zimbra OLK was installed correctly/successfully. <br />
<br />
Bug https://bugzilla.zimbra.com/show_bug.cgi?id=108476 is filed for the same<br />
<br />
To workaround the issue you need to disable simplified Account Creation in Outlook 2016.<br />
<br />
Steps to disable simplified Account Creation in Outlook 2016:<br />
1. Exit Outlook.<br />
2. Start Registry Editor. To do this, use one of the following procedures,as appropriate for your version of Windows.<br />
<br />
-Windows 10, Windows 8.1 and Windows 8: Press Windows Key + R to open a Run dialog box. Type regedit.exe, and then click OK.<br />
-Windows 7: Click Start, type regedit.exe in the search box, and then press Enter.<br />
<br />
3. In Registry Editor, locate and then click the following subkey in the registry: <br />
<br />
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Setup. <br />
<br />
4. After you select the key that is specified in step 3, point to New on the Edit menu, and then DWORD (32-bit) Value.<br />
<br />
5. Type DisableOffice365SimplifiedAccountCreation, and then press Enter.<br />
<br />
6. Right-click DisableOffice365SimplifiedAccountCreation, and then click Modify.<br />
<br />
7. In the Value data box, type 1, and then click OK.<br />
<br />
8. On the File menu, click Exit to exit Registry Editor.</div>Raunaqhttps://wiki.zimbra.com/index.php?title=ZNG_HSM_Volume_on_S3&diff=64480ZNG HSM Volume on S32017-09-27T17:15:49Z<p>Raunaq: HSM NG and S3 buckets</p>
<hr />
<div>=HSM NG and S3 buckets[ZNG]=<br />
<br />
{{KB|{{ZC}}|{{ZCS 8.8}}|}}<br />
{{WIP}}<br />
<br />
<br />
Secondary volumes created with HSM NG can now be hosted on S3 buckets, effectively moving the largest part of your data to secure and durable cloud storage.<br />
<br />
==S3-compatible Services==<br />
<br />
While any storage service compatible with the Amazon S3 API should work out of the box with HSM NG, Amazon S3 and DellEMC ECS are the only officially supported platforms.<br />
<br />
==Local Cache==<br />
<br />
This feature requires a local directory to be used for item caching, which must be readable and writable by the zimbra user.<br />
<br />
The local directory must be created manually and its path must be entered in the HSM NG section of the Administration Zimlet in the Zimbra Administration Console.<br />
<br />
If the Local Cache directory is not set, you won’t be able to create any secondary volume on an S3-compatible device or service.<br />
<br />
Failing to correctly configure the cache directory will cause items to be unretrievable, meaning that users will get a No such BLOB error when trying to access any item stored on an S3 volume.<br />
<br />
==Bucket Setup==<br />
<br />
HSM NG doesn’t need any dedicated setting or configuration on the S3 side, so setting up a bucket for your volumes is easy. Although creating a dedicated user, bucket and access policy are not required, they are strongly suggested because they make it much easier to manage.<br />
<br />
'''All you need to start storing your secondary volumes on S3 is''':<br />
<br />
An S3 bucket. You need to know the bucket’s name and region in order to use it.<br />
<br />
A user’s Access Key and Secret.<br />
<br />
A policy that grants the user full rights on your bucket.<br />
<br />
S3 Buckets<br />
<br />
Instead of adding the bucket’s data each time you add a new secondary volume, you can save it on the Zimbra Administration Console at Configure > Global Settings > S3 Buckets.<br />
<br />
==Creating a Secondary Volume on S3==<br />
<br />
'''To create a secondary volume on S3:'''<br />
<br />
*Click the HSM NG entry of the Administration Zimlet in the Zimbra Administration Console.<br />
<br />
*Click Add under the Secondary Volumes list.<br />
<br />
*Select S3 bucket.<br />
<br />
*Enter the volume’s name and prefix, then either add a bucket’s information or load those from the ones saved in the Global Settings.<br />
<br />
*Define whether to use the Infrequent Access storage class, and if so, set its size threshold.<br />
<br />
*Define whether the new volume is set as Current or not.<br />
<br />
*Click Finish to create the new volume.</div>Raunaqhttps://wiki.zimbra.com/index.php?title=Installing_a_LetsEncrypt_SSL_Certificate&diff=63568Installing a LetsEncrypt SSL Certificate2017-06-16T05:12:28Z<p>Raunaq: /* Zimbra Collaboration 8.7 and above */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Installing a Let's Encrypt SSL Certificate=<br />
{{KB|{{Unsupported}}|{{ZCS 8.7}}|{{ZCS 8.6}}|}}<br />
<br />
[[File:Letsencrypt-en.png|1024px]]<br />
<br />
==Purpose==<br />
Step by Step Wiki/KB article to install a Let's Encrypt Commercial Certificate. <br />
'''Disclaimer'''<br />
The Let’s Encrypt Client is '''BETA SOFTWARE'''. It contains plenty of bugs and rough edges, and it should be tested thoroughly in staging environments before use on production systems.<br />
For more information regarding the status of the project, please see https://letsencrypt.org. Be sure to check out the [https://community.letsencrypt.org/t/frequently-asked-questions-faq/26#topic-title Frequently Asked Questions (FAQ)].<br />
<br />
==Resolution==<br />
Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. It could be an option to protect Zimbra Servers with a valid SSL certificate; however, please be aware that is a Beta for now. Some stuff could not work or have issues, so use it at your own risk.<br />
<br />
===Installing Let's Encrypt on a Zimbra Server===<br />
Let's Encrypt must be installed on one Linux machine to obtain the proper SSL Certificate, CA Intermediate, and Private Key. It is not required that it be on the same Zimbra Server, but it could save time and help to obtain the renewals, etc.<br />
* First Step is to stop the jetty or nginx service at Zimbra level<br />
zmproxyctl stop<br />
zmmailboxdctl stop<br />
* Second step is to Install git on the Server (apt-get install git/yum install git), and then do a git clone of the project on the folder we want<br />
** Note: On RedHat/CentOS 6 you will need to enable the EPEL repository before install.<br />
git clone https://github.com/letsencrypt/letsencrypt<br />
cd letsencrypt<br />
* Let's now run Let's Encrypt in auto mode and use the certonly option, because for now the project can't automatically install the cert on Zimbra servers.<br />
root@zimbra86:~/tmp/letsencrypt# ./letsencrypt-auto certonly --standalone<br />
If you need to have multiple hostnames on the same SSL, so a Multi-SAN, SSL, please run instead, where -d are your domains:<br />
root@zimbra86:~/tmp/letsencrypt# ./letsencrypt-auto certonly --standalone -d xmpp.example.com -d conference.example.com<br />
** (This step only happens the first time. This process will not occur when renewing the SSL Certificate if using the same machine.) The process will download all of the OS dependencies that Let's Encrypt needs, and after a few minutes:<br />
<pre>Creating virtual environment...<br />
Updating letsencrypt and virtual environment dependencies...../root/.local/share/letsencrypt/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.<br />
InsecurePlatformWarning<br />
./root/.local/share/letsencrypt/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.<br />
InsecurePlatformWarning<br />
</pre><br />
*** The process will ask for an Email Address in case of emergency contact or to recover the lost key.<br />
<br />
[[File:Letsencrypt-002.png]]<br />
<br />
*** The process will ask if we agree with the ToS.<br />
<br />
[[File:Letsencrypt-003.png]]<br />
<br />
**** In case we run a renewal, or a request for a new FQDN, the process will just take a few seconds.<br />
Updating letsencrypt and virtual environment dependencies.......<br />
Running with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly<br />
*** Let's Encrypt will prompt for the domain to protect, in this lab case (zimbra86.zimbra.io):<br />
<br />
[[File:Letsencrypt-004.png]]<br />
<br />
* The process will take a few seconds to validate and then will end:<br />
<pre>IMPORTANT NOTES:<br />
- Congratulations! Your certificate and chain have been saved at<br />
/etc/letsencrypt/live/zimbra86.zimbra.io/fullchain.pem. Your cert<br />
will expire on 2016-03-04. To obtain a new version of the<br />
certificate in the future, simply run Let's Encrypt again.<br />
- If like Let's Encrypt, please consider supporting our work by:<br />
<br />
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate<br />
Donating to EFF: https://eff.org/donate-le</pre><br />
<br />
===Where are the SSL Certificate Files?===<br />
You can find all your files under '''/etc/letsencrypt/live/$domain''', where $domain is the fqdn you used during the process:<br />
<pre>root@zimbra86:/etc/letsencrypt/live/zimbra86.zimbra.io# ls -al<br />
total 8<br />
drwxr-xr-x 2 root root 4096 Dec 5 16:46 .<br />
drwx------ 3 root root 4096 Dec 5 16:46 ..<br />
lrwxrwxrwx 1 root root 42 Dec 5 16:46 cert.pem -> ../../archive/zimbra86.zimbra.io/cert1.pem<br />
lrwxrwxrwx 1 root root 43 Dec 5 16:46 chain.pem -> ../../archive/zimbra86.zimbra.io/chain1.pem<br />
lrwxrwxrwx 1 root root 47 Dec 5 16:46 fullchain.pem -> ../../archive/zimbra86.zimbra.io/fullchain1.pem<br />
lrwxrwxrwx 1 root root 45 Dec 5 16:46 privkey.pem -> ../../archive/zimbra86.zimbra.io/privkey1.pem</pre><br />
<br />
'''cert.pem''' is the certificate<br />
<br />
'''chain.pem''' is the chain<br />
<br />
'''fullchain.pem''' is the concatenation of cert.pem + chain.pem<br />
<br />
'''privkey.pem''' is the private key<br />
<br />
Please keep in mind that the private key is only for you.<br />
<br />
===Build the proper Intermediate CA plus Root CA===<br />
Let's Encrypt is almost perfect, but during the files the process built, they just add the chain.pem file without the root CA.<br />
You must to use the IdenTrust root Certificate and merge it after the chain.pem<br />
* [https://www.identrust.com/certificates/trustid/root-download-x3.html https://www.identrust.com/certificates/trustid/root-download-x3.html]<br />
Your chain.pem should look like:<br />
<pre><br />
-----BEGIN CERTIFICATE-----<br />
YOURCHAIN<br />
-----END CERTIFICATE-----<br />
-----BEGIN CERTIFICATE-----<br />
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/<br />
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT<br />
DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow<br />
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD<br />
Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB<br />
AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O<br />
rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq<br />
OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b<br />
xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw<br />
7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD<br />
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV<br />
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG<br />
SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69<br />
ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr<br />
AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz<br />
R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5<br />
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo<br />
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ<br />
-----END CERTIFICATE-----</pre><br />
To sum up: chain.pem has to be concatened with the root CA. First the chain and the end of the file the root CA. The order is important.<br />
<br />
===Verify your commercial certificate. ===<br />
Copy all the Let's Encrypt folder with all files '''/etc/letsencrypt/live/$domain''' into /opt/zimbra/ssl/letsencrypt:<br />
root@mail2:~# mkdir /opt/zimbra/ssl/letsencrypt<br />
root@mail2:~# cp /etc/letsencrypt/live/mail2.next.zimbra.io/* /opt/zimbra/ssl/letsencrypt/<br />
root@mail2:~# chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*<br />
root@mail2:~# ls -la /opt/zimbra/ssl/letsencrypt/<br />
total 24<br />
drwxr-xr-x 2 root root 4096 Jul 15 22:59 .<br />
drwxr-xr-x 8 zimbra zimbra 4096 Jul 15 22:59 ..<br />
-rw-r--r-- 1 zimbra zimbra 1809 Jul 15 22:59 cert.pem<br />
-rw-r--r-- 1 zimbra zimbra 2847 Jul 15 22:59 chain.pem<br />
-rw-r--r-- 1 zimbra zimbra 3456 Jul 15 22:59 fullchain.pem<br />
-rw-r--r-- 1 zimbra zimbra 1704 Jul 15 22:59 privkey.pem<br />
====Zimbra Collaboration 8.7 and above====<br />
As '''zimbra''' user<br />
<pre>zimbra@zimbra87:/opt/zimbra/ssl/letsencrypt/# /opt/zimbra/bin/zmcertmgr verifycrt comm privkey.pem cert.pem chain.pem <br />
** Verifying cert.pem against privkey.pem<br />
Certificate (cert.pem) and private key (privkey.pem) match.<br />
Valid Certificate: cert.pem: OK</pre><br />
<br />
====Zimbra Collaboration 8.6 and previous====<br />
As '''root''' user<br />
<pre>root@zimbra86:/opt/zimbra/ssl/letsencrypt/# /opt/zimbra/bin/zmcertmgr verifycrt comm privkey.pem cert.pem chain.pem <br />
** Verifying cert.pem against privkey.pem<br />
Certificate (cert.pem) and private key (privkey.pem) match.<br />
Valid Certificate: cert.pem: OK</pre><br />
<br />
===Deploy the new Let's Encrypt SSL certificate===<br />
====Backup Zimbra SSL directory====<br />
Before deploying a good practice is to make a backup.<br />
cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.$(date "+%Y%m%d")<br />
====Copy the private key under Zimbra SSL path====<br />
Before deploying the SSL Certificate, you need to move the privkey.pem under the Zimbra SSL commercial path, like this:<br />
cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key<br />
<br />
====Final SSL deployment====<br />
Then deploy the certificate as follows: <br />
=====Zimbra Collaboration 8.7 and above=====<br />
As '''zimbra''' user<br />
<pre>zimbra@mail2://opt/zimbra/ssl/letsencrypt/$ /opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem chain.pem <br />
** Verifying 'cert.pem' against '/opt/zimbra/ssl/zimbra/commercial/commercial.key'<br />
Certificate 'cert.pem' and private key '/opt/zimbra/ssl/zimbra/commercial/commercial.key' match.<br />
** Verifying 'cert.pem' against 'chain.pem'<br />
Valid certificate chain: cert.pem: OK<br />
** Copying 'cert.pem' to '/opt/zimbra/ssl/zimbra/commercial/commercial.crt'<br />
** Copying 'chain.pem' to '/opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt'<br />
** Appending ca chain 'chain.pem' to '/opt/zimbra/ssl/zimbra/commercial/commercial.crt'<br />
** Importing cert '/opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt' as 'zcs-user-commercial_ca' into cacerts '/opt/zimbra/common/lib/jvm/java/jre/lib/security/cacerts'<br />
** NOTE: restart mailboxd to use the imported certificate.<br />
** Saving config key 'zimbraSSLCertificate' via zmprov modifyServer mail2.next.zimbra.io...failed (rc=1)<br />
** Installing ldap certificate '/opt/zimbra/conf/slapd.crt' and key '/opt/zimbra/conf/slapd.key'<br />
** Copying '/opt/zimbra/ssl/zimbra/commercial/commercial.crt' to '/opt/zimbra/conf/slapd.crt'<br />
** Copying '/opt/zimbra/ssl/zimbra/commercial/commercial.key' to '/opt/zimbra/conf/slapd.key'<br />
** Creating file '/opt/zimbra/ssl/zimbra/jetty.pkcs12'<br />
** Creating keystore '/opt/zimbra/mailboxd/etc/keystore'<br />
** Installing mta certificate '/opt/zimbra/conf/smtpd.crt' and key '/opt/zimbra/conf/smtpd.key'<br />
** Copying '/opt/zimbra/ssl/zimbra/commercial/commercial.crt' to '/opt/zimbra/conf/smtpd.crt'<br />
** Copying '/opt/zimbra/ssl/zimbra/commercial/commercial.key' to '/opt/zimbra/conf/smtpd.key'<br />
** Installing proxy certificate '/opt/zimbra/conf/nginx.crt' and key '/opt/zimbra/conf/nginx.key'<br />
** Copying '/opt/zimbra/ssl/zimbra/commercial/commercial.crt' to '/opt/zimbra/conf/nginx.crt'<br />
** Copying '/opt/zimbra/ssl/zimbra/commercial/commercial.key' to '/opt/zimbra/conf/nginx.key'<br />
** NOTE: restart services to use the new certificates.<br />
** Cleaning up 3 files from '/opt/zimbra/conf/ca'<br />
** Removing /opt/zimbra/conf/ca/41b01cbb.0<br />
** Removing /opt/zimbra/conf/ca/ca.key<br />
** Removing /opt/zimbra/conf/ca/ca.pem<br />
** Copying CA to /opt/zimbra/conf/ca<br />
** Copying '/opt/zimbra/ssl/zimbra/ca/ca.key' to '/opt/zimbra/conf/ca/ca.key'<br />
** Copying '/opt/zimbra/ssl/zimbra/ca/ca.pem' to '/opt/zimbra/conf/ca/ca.pem'<br />
** Creating CA hash symlink '41b01cbb.0' -> 'ca.pem'<br />
** Creating /opt/zimbra/conf/ca/commercial_ca_1.crt<br />
** Creating CA hash symlink '4f06f81d.0' -> 'commercial_ca_1.crt'<br />
** Creating /opt/zimbra/conf/ca/commercial_ca_2.crt<br />
** Creating CA hash symlink '2e5ac55d.0' -> 'commercial_ca_2.crt'</pre> <br />
=====Zimbra Collaboration 8.6 and previous=====<br />
As '''root''' user<br />
<pre>root@zimbra86:/opt/zimbra/ssl/letsencrypt/# /opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem chain.pem <br />
** Verifying cert.pem against /opt/zimbra/ssl/zimbra/commercial/commercial.key<br />
Certificate (cert.pem) and private key (/opt/zimbra/ssl/zimbra/commercial/commercial.key) match.<br />
Valid Certificate: cert.pem: OK<br />
** Copying cert.pem to /opt/zimbra/ssl/zimbra/commercial/commercial.crt<br />
** Appending ca chain chain.pem to /opt/zimbra/ssl/zimbra/commercial/commercial.crt<br />
** Importing certificate /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt to CACERTS as zcs-user-commercial_ca...done.<br />
** NOTE: mailboxd must be restarted in order to use the imported certificate.<br />
** Saving server config key zimbraSSLCertificate...failed.<br />
** Saving server config key zimbraSSLPrivateKey...failed.<br />
** Installing mta certificate and key...done.<br />
** Installing slapd certificate and key...done.<br />
** Installing proxy certificate and key...done.<br />
** Creating pkcs12 file /opt/zimbra/ssl/zimbra/jetty.pkcs12...done.<br />
** Creating keystore file /opt/zimbra/mailboxd/etc/keystore...done.<br />
** Installing CA to /opt/zimbra/conf/ca...done.</pre><br />
<br />
Then you need to restart the services, which will restart the nginx or jetty you stopped before:<br />
zmcontrol restart<br />
<br />
===Test the new SSL Certificate===<br />
The last step is to go to your Web Browser and open the URL of your Zimbra server where you installed the Let's Encrypt SSL Certificate:<br />
<br />
[[File:Letsencrypt-006.png|1024px]]<br />
<br />
You can expand the Certificate Information to see the new SSL Certificate your server is using:<br />
<br />
[[File:Letsencrypt-007.png]]<br />
<br />
===Test the new SSL Certificate with OpenSSL===<br />
You can use openssl cli tools to check and test the new SSL certificate:<br />
echo QUIT | openssl s_client -connect $domain:443 | openssl x509 -noout -text | less<br />
where $domain is the fqdn you used during the process<br />
<br />
===Building Multi-SAN SSL Certificate and complex scenarios===<br />
You can do almost everything you need, like Subject Alt Names, different domains, etc. But to see more about this, visit [https://letsencrypt.org/ the web of the official project].<br />
<br />
Here is an example using two FQDN:<br />
./letsencrypt-auto certonly --standalone -d fqdn1 -d fqdn2<br />
<br />
===Verifying SSL certificate is not expired===<br />
SSL certificates issued by let's encrypt are valid for 90 days during the BETA phase.<br />
You need to check the expiration of your SSL certificate. We can suggest using monitoring tools like Nagios. With nagios plugins there's a command which can check the expiration:<br />
/usr/lib/nagios/plugins/check_http --sni -H '<FQDN>' -C 30,14<br />
A warning will be issued 30 days before the expiration, a critical will be issued 14 days before the expiration.<br />
<br />
Here is a nagios config file excerpt:<br />
define command{<br />
command_name check_https_vhost<br />
command_line /usr/lib/nagios/plugins/check_http --sni -H '$ARG1$' -C 30,14<br />
}<br />
<br />
define service{<br />
use generic-service<br />
host_name <FQDN><br />
service_description SSL <FQDN><br />
check_command check_https_vhost!<FQDN><br />
}<br />
<br />
==Additional Content==<br />
* Let's Encrypt User Manual - https://letsencrypt.readthedocs.org/en/latest/using.html<br />
* Let's Encrypt Official Project - https://letsencrypt.org/<br />
<br />
=Automatic methods=<br />
Since Letsencrypt has gone public several scripts were created to automate the deployment of free SSL certificates in Zimbra. In order of appearance:<br />
<br />
* [https://github.com/VojtechMyslivec/letsencrypt-zimbra/ Vojtěch Myslivec on GitHub] <br />
* Grown from a long discussion on the [https://forums.zimbra.org/viewtopic.php?f=15&t=60781 forum] [https://github.com/JimDunphy/deploy-zimbra-letsencrypt.sh Jim Dunphy developed a script] based on Neilpang's acme.sh script<br />
* A nearly fully automated script developed by [https://github.com/yetopen/certbot-zimbra Maxxer@YetOpen on GitHub]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.6, 8.5|12/05/2015}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certificates]]</div>Raunaqhttps://wiki.zimbra.com/index.php?title=Zm-lookup-user-not-found&diff=63559Zm-lookup-user-not-found2017-06-02T08:49:54Z<p>Raunaq: Created page with "=zm lookup: user not found= {{KB|{{ZCS 8.7}}||}} The problem was the Proxy would direct the loading of the ZWC client bits to the wrong mailstore hosts and when it then rende..."</p>
<hr />
<div>=zm lookup: user not found=<br />
{{KB|{{ZCS 8.7}}||}}<br />
<br />
The problem was the Proxy would direct the loading of the ZWC client bits to the wrong mailstore hosts and when it then rendered the entire left side pane was missing.<br />
<br />
I found this, in the nginx.log <br />
<br />
<pre>2017/05/26 20:22:44 [warn] 20355#0: *38 zmauth: an error occurs during zm lookup: user not found:61333e88-d023-458b-81f2-07007ad01fe7, fall back to IPHASH to get the upstream route, client: 10.51.4.121:51552, server: webmail.example.org, request: "GET /service/zimlet/res/Zimlets-nodev_all.css?language=en&country=US&cosId=beee5c1e-e860-4000-876e-d235fbb0bd53 HTTP/1.1", host: "zmproxymta1.example.org", referrer: "https://zmproxymta1.example.org/zimbra/"<br />
2017/05/26 20:22:45 [error] 20355#0: *32 zm lookup: an error is returned by zimbra lookup handler: user not found:61333e88-d023-458b-81f2-07007ad01fe7, client: 10.57.34.169:51546, server: webmail.example.org, request: "GET /zimbra/js/Contacts_all.js.zgz?v=141215153642 HTTP/1.1", host: "zmproxymta1.example.org", referrer: "https://zmproxymta1.example.org/zimbra/"</pre><br />
<br />
The issue was the below parameter<br />
<br />
zimbraReverseProxyMailHostQuery '(|(zimbraMailDeliveryAddress=${USER})(zimbraMailAlias=${USER}))' <br />
<br />
<br />
The default for this parameter is (|(zimbraMailDeliveryAddress=${USER})(zimbraMailAlias=${USER})(zimbraId=${USER}))<br />
<br />
<br />
Resetting it to default solved the issue. Please note that restart of both Proxy and mailbox nodes is required for the changes to come into affect .</div>Raunaqhttps://wiki.zimbra.com/index.php?title=Smime_error_codes&diff=63469Smime error codes2017-04-24T04:41:06Z<p>Raunaq: Created page with "=SMIME Error Codes= {{KB|{{ZCS 8.7}}||}} ==List of possible error codes during signing== smime.LOAD_CERTIFICATE_FAILED : Failed to load users certificate smime.MULTIPLE_CE..."</p>
<hr />
<div>=SMIME Error Codes=<br />
{{KB|{{ZCS 8.7}}||}}<br />
<br />
<br />
==List of possible error codes during signing==<br />
<br />
smime.LOAD_CERTIFICATE_FAILED : Failed to load users certificate<br />
<br />
smime.MULTIPLE_CERTIFICATES_FOUND : If the certID is not provided in SendSecureMessage request and there are multiple user certificates.<br />
<br />
smime.USER_CERT_EXPIRED : Users certificate is expired<br />
<br />
smime.USER_CERT_NOT_YET_VALID : Users certificate validity period has not yet started<br />
<br />
smime.USER_CERT_REVOKED : Users certificate has been revoked<br />
<br />
smime.USER_CERT_NOT_TRUSTED : Users certificate is not trusted by any existing trust anchors<br />
<br />
smime.USER_CERT_EMAIL_ADDRESS_NOT_MATCHING : The email ID in certificate not matching with users email ID<br />
<br />
smime.CERT_VALIDATION_FAILED : The users certificate validation failed<br />
<br />
smime.MSG_SIGNING_FAILED : Message signing failed due to some other reason<br />
<br />
<br />
==List of possible error codes during signature verification==<br />
<br />
SIGNER_DIGEST_MISMATCH : If the original message was tampered<br />
<br />
VERIFIER_NOT_VALID_AT_SIGNING_TIME : The message was signed with invalid/expired certificate<br />
<br />
CERTIFICATE_EXPIRED : The signers certificate has been expired<br />
<br />
CERTIFICATE_NOT_YET_VALID : The signers certificate validity period has not yet started<br />
<br />
CERTIFICATE_REVOKED : The signers certificate has been revoked<br />
<br />
CERTIFICATE_NOT_TRUSTED : The signers certificate is not trusted by any existing trust anchors<br />
<br />
CERTIFICATE_EMAIL_ADDRESS_NOT_MATCHING : The email ID in certificate not matching with signers email ID<br />
<br />
CERTIFICATE_VALIDATION_FAILED : The signer certificate validation failed<br />
<br />
INVALID_SIGNATURE : The signature is not valid<br />
<br />
SIGNATURE_VALIDATION_FAILED : The signature is valid, but it does not prove the signer identity<br />
<br />
==List of possible error codes during encryption==<br />
<br />
smime.RECIPIENT_SMIME_CERT_NOT_FOUND : If no valid certificate found for one or more recipients<br />
<br />
smime.MSG_ENCRYPTION_FAILED : Message encryption failed due to some other reason<br />
<br />
<br />
==List of possible error codes during decryption==<br />
<br />
LOAD_CERTIFICATE_FAILED : Failed to load users certificate<br />
<br />
LOAD_PRIVATE_KEY_FAILED : Failed to load users private key<br />
<br />
DECRYPTION_FAILED : Message decryption failed for any other reason<br />
<br />
USER_CERT_MISMATCH : message was not encrypted with user's current certificate</div>Raunaqhttps://wiki.zimbra.com/index.php?title=Mysql_Crash_Recovery&diff=63321Mysql Crash Recovery2017-02-24T12:15:37Z<p>Raunaq: </p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Mysql Crash Recovery=<br />
{{KB|{{ZC}}|{{ZCS 8.5}}|{{ZCS 8.0}}|{{ZCS 7.0}}}}<br />
<br />
In the event of database corruption it may be necessary to manually perform database recovery. See [http://bugzilla.zimbra.com/show_bug.cgi?id=15797 Bug 15797] for an example of an issue with mysql that will require database recovery. In that example, a warning message like the following appeared in the mysql error log:<br />
<br />
InnoDB: Serious error! InnoDB is trying to free page 716<br />
InnoDB: though it is already marked as free in the tablespace!<br />
InnoDB: The tablespace free space info is corrupt.<br />
InnoDB: You may need to dump your InnoDB tables and recreate the whole<br />
InnoDB: database!<br />
<br />
Before beginning a full database recovery, check to see if the corruption may be limited to a single mboxgroup or a single user within an mboxgroup. This type of corruption frequently lets the server run normally for extended periods of time, with crashes occurring only when an affected user attempts to access certain mailbox items. If this is the case, it may be possible to dump, drop and recover only the affected entries without disrupting the database as a whole. Please see the instructions in the [http://wiki.zimbra.com/wiki/Mysql_Crash_Recovery_%28alternate_method%29 Mysql Crash Recovery (alternate method)] article.<br />
<br />
=Overview of Recovery Process=<br />
<!-- make sure to update section numbering if steps are changed here --><br />
# Configure mysql to start in recovery mode<br />
# Generate SQL dumps of all relevant databases<br />
# Remove all existing (and possibly corrupt) databases<br />
# Re-create all databases<br />
# Repopulate the databases with the data from the SQL dumps<br />
#Test databases and start all ZCS services<br />
<br />
=Details of Recovery Process=<br />
<br />
==1. Configure mysql to start in recovery mode==<br />
# Edit the file /opt/zimbra/conf/my.cnf and add a line like '''innodb_force_recovery = 1''' under the '''[mysqld]''' section ''(Note that it may be necessary to increase the recovery level depending on the extent of the database corruption, as shown at the end of the database dump step)''<br />
# Save the file and re-start mysqld<br />
mysql.server start<br />
<br />
==2. Generate SQL dumps of all databases==<br />
# Load some mysql configuration into shell variables (i.e. $mysql_socket and $mysql_root_password; note that you will use these again in step 3)<br />
# Make a list of the existing databases<br />
# Create a directory to hold the SQL dumps<br />
# Generate the SQL dumps from the database list<br />
<br />
<pre>source ~/bin/zmshutil ; zmsetvars</pre><br />
<pre>mysql --batch --skip-column-names -e "show databases" | grep -e mbox -e zimbra > /tmp/mysql.db.list</pre><br />
<pre>mkdir /tmp/mysql.sql </pre><br />
<pre>for db in `cat /tmp/mysql.db.list`; do<br />
~/mysql/bin/mysqldump $db -S $mysql_socket -u root --password=$mysql_root_password > /tmp/mysql.sql/$db.sql<br />
echo "Dumped $db"<br />
sleep 10<br />
done</pre><br />
<br />
'''Note: If you encounter any mysql errors while dumping the databases, start over by re-editing /opt/zimbra/conf/my.cnf, incrementing the value for innodb_force_recovery by one, and restarting mysqld.''' The maximum recovery level is 6. Please see MySQL's [http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Forcing InnoDB Recovery] guide for more information. <br />
<br />
'''Note: Starting 8.7 , path of mysqldump has been changed from /opt/zimbra/mysql/bin/mysqldump to /opt/zimbra/common/bin/mysqldump . Please update the command accordingly if you are doing this for a system >= ZCS 8.7.x<br />
<br />
'''Note: An error of ''"bash: /tmp/mysql.sql/$db.sql: ambiguous redirect"'' probably indicates your using an apostrophe or single quote ' rather than a tick ` -- which is one the same key as the tilde ~ .'''<br />
<br />
'''Note: Do not reboot the machine, as some Operating Systems will remove all contents in the /tmp directory during the reboot sequence, i.e. your /tmp/mysql.sql will be removed.'''<br />
<br />
'''HINT''' Did the dump work or not, try grep -L "Dump completed" /tmp/mysql.sql/*.sql [those that didn't] and grep "Dump completed" /tmp/mysql.sql/*.sql [those that did].<br />
<br />
==3. Remove all existing (and possibly corrupt) databases==<br />
<br />
'''Note:''' Take a copy of /opt/zimbra/db/data before dropping the databases. This will ensure a copy of old database.<br />
<br />
Note that we drop the zimbra database last because the mboxgroup* databases depend on it<br />
<br />
<pre><br />
for db in `cat /tmp/mysql.db.list |grep mbox`<br />
do<br />
mysql -u root --password=$mysql_root_password -e "drop database $db"<br />
echo -e "Dropped $db"<br />
done<br />
</pre><br />
<pre>mysql -u root --password=$mysql_root_password -e "drop database zimbra"</pre><br />
<br />
Remove existing InnoDB tablespace and log files<br />
rm -rf /opt/zimbra/db/data/ib*<br />
<br />
'''Note: First, use with caution - this shouldn't need to be used often. Issue came about because of some rsync issues.''' ''Can't dump db's because of 'connection' issues at this point? One could move the /opt/zimbra/db/data directory - mv /opt/zimbra/db/data /opt/zimbra/db/data-old and then make the db - mkdir /opt/zimbra/db/data w/ ownership of zimbra:zimbra . Remove the innodb_force_recovery line from /opt/zimbra/conf/my.cnf . Then recreate a default mysql db by running /opt/zimbra/libexec/zmmyinit --sql_root_pw $mysql_root_password and then attempt this steps over again to confirm you can drop them.'' Also note that you may have to reset the zimbra password manually in mysql, then set it again in Zimbra with the instructions from this page: http://wiki.zimbra.com/wiki/Resetting_LDAP_%26_MySQL_Passwords<br />
<br />
==4. Re-create all databases==<br />
# Run mysql in non-recovery mode<br />
## Remove the '''innodb_force_recovery''' line from /opt/zimbra/conf/my.cnf<br />
## Save the file and restart mysqld<br />
# Re-create the databases from the database list<br />
<br />
<pre>mysql.server restart</pre><br />
<br />
<pre><br />
for db in `cat /tmp/mysql.db.list`<br />
do<br />
mysql -e "create database $db character set utf8"<br />
echo "Created $db"<br />
done<br />
</pre><br />
<br />
==5. Repopulate the databases with the data from the SQL dumps==<br />
Import the data from the SQL dumps. Note that we import the zimbra database first because the mboxgroup databases depend on it<br />
<br />
<pre>mysql zimbra < /tmp/mysql.sql/zimbra.sql</pre><br />
<pre><br />
for sql in /tmp/mysql.sql/mbox*<br />
do<br />
mysql `basename $sql .sql` < $sql<br />
echo -e "Updated `basename $sql .sql` \n"<br />
done<br />
</pre><br />
<br />
==6. Test databases and start all ZCS services==<br />
Note that this is an example query. If you know of any particular databases that were corrupt, you may want to construct other queries to verify normal access to the data.<br />
<pre>mysql zimbra -e "select * from mailbox order by id desc limit 1"</pre><br />
<br />
Once you are satisfied that the databases are restored intact, start the rest of the zimbra services.<br />
<pre>zmcontrol start</pre><br />
<br />
Check /opt/zimbra/log/mysql_error.log and /opt/zimbra/log/mailbox.log for database errors.<br />
<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.5, 8.0, 7.0|8/13/2007}}<br />
<br />
[[Category:MySQL]]<br />
[[Category:Disaster Recovery]]<br />
[[Category:Troubleshooting]]</div>Raunaqhttps://wiki.zimbra.com/index.php?title=Mysql_Crash_Recovery&diff=63320Mysql Crash Recovery2017-02-24T12:11:49Z<p>Raunaq: </p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Mysql Crash Recovery=<br />
{{KB|{{ZC}}|{{ZCS 8.5}}|{{ZCS 8.0}}|{{ZCS 7.0}}}}<br />
<br />
In the event of database corruption it may be necessary to manually perform database recovery. See [http://bugzilla.zimbra.com/show_bug.cgi?id=15797 Bug 15797] for an example of an issue with mysql that will require database recovery. In that example, a warning message like the following appeared in the mysql error log:<br />
<br />
InnoDB: Serious error! InnoDB is trying to free page 716<br />
InnoDB: though it is already marked as free in the tablespace!<br />
InnoDB: The tablespace free space info is corrupt.<br />
InnoDB: You may need to dump your InnoDB tables and recreate the whole<br />
InnoDB: database!<br />
<br />
Before beginning a full database recovery, check to see if the corruption may be limited to a single mboxgroup or a single user within an mboxgroup. This type of corruption frequently lets the server run normally for extended periods of time, with crashes occurring only when an affected user attempts to access certain mailbox items. If this is the case, it may be possible to dump, drop and recover only the affected entries without disrupting the database as a whole. Please see the instructions in the [http://wiki.zimbra.com/wiki/Mysql_Crash_Recovery_%28alternate_method%29 Mysql Crash Recovery (alternate method)] article.<br />
<br />
=Overview of Recovery Process=<br />
<!-- make sure to update section numbering if steps are changed here --><br />
# Configure mysql to start in recovery mode<br />
# Generate SQL dumps of all relevant databases<br />
# Remove all existing (and possibly corrupt) databases<br />
# Re-create all databases<br />
# Repopulate the databases with the data from the SQL dumps<br />
#Test databases and start all ZCS services<br />
<br />
=Details of Recovery Process=<br />
<br />
==1. Configure mysql to start in recovery mode==<br />
# Edit the file /opt/zimbra/conf/my.cnf and add a line like '''innodb_force_recovery = 1''' under the '''[mysqld]''' section ''(Note that it may be necessary to increase the recovery level depending on the extent of the database corruption, as shown at the end of the database dump step)''<br />
# Save the file and re-start mysqld<br />
mysql.server start<br />
<br />
==2. Generate SQL dumps of all databases==<br />
# Load some mysql configuration into shell variables (i.e. $mysql_socket and $mysql_root_password; note that you will use these again in step 3)<br />
# Make a list of the existing databases<br />
# Create a directory to hold the SQL dumps<br />
# Generate the SQL dumps from the database list<br />
<br />
<pre>source ~/bin/zmshutil ; zmsetvars</pre><br />
<pre>mysql --batch --skip-column-names -e "show databases" | grep -e mbox -e zimbra > /tmp/mysql.db.list</pre><br />
<pre>mkdir /tmp/mysql.sql </pre><br />
<pre>for db in `cat /tmp/mysql.db.list`; do<br />
~/common/bin/mysqldump $db -S $mysql_socket -u root --password=$mysql_root_password > /tmp/mysql.sql/$db.sql<br />
echo "Dumped $db"<br />
sleep 10<br />
done</pre><br />
<br />
'''Note: If you encounter any mysql errors while dumping the databases, start over by re-editing /opt/zimbra/conf/my.cnf, incrementing the value for innodb_force_recovery by one, and restarting mysqld.''' The maximum recovery level is 6. Please see MySQL's [http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Forcing InnoDB Recovery] guide for more information.<br />
<br />
'''Note: An error of ''"bash: /tmp/mysql.sql/$db.sql: ambiguous redirect"'' probably indicates your using an apostrophe or single quote ' rather than a tick ` -- which is one the same key as the tilde ~ .'''<br />
<br />
'''Note: Do not reboot the machine, as some Operating Systems will remove all contents in the /tmp directory during the reboot sequence, i.e. your /tmp/mysql.sql will be removed.'''<br />
<br />
'''HINT''' Did the dump work or not, try grep -L "Dump completed" /tmp/mysql.sql/*.sql [those that didn't] and grep "Dump completed" /tmp/mysql.sql/*.sql [those that did].<br />
<br />
==3. Remove all existing (and possibly corrupt) databases==<br />
<br />
'''Note:''' Take a copy of /opt/zimbra/db/data before dropping the databases. This will ensure a copy of old database.<br />
<br />
Note that we drop the zimbra database last because the mboxgroup* databases depend on it<br />
<br />
<pre><br />
for db in `cat /tmp/mysql.db.list |grep mbox`<br />
do<br />
mysql -u root --password=$mysql_root_password -e "drop database $db"<br />
echo -e "Dropped $db"<br />
done<br />
</pre><br />
<pre>mysql -u root --password=$mysql_root_password -e "drop database zimbra"</pre><br />
<br />
Remove existing InnoDB tablespace and log files<br />
rm -rf /opt/zimbra/db/data/ib*<br />
<br />
'''Note: First, use with caution - this shouldn't need to be used often. Issue came about because of some rsync issues.''' ''Can't dump db's because of 'connection' issues at this point? One could move the /opt/zimbra/db/data directory - mv /opt/zimbra/db/data /opt/zimbra/db/data-old and then make the db - mkdir /opt/zimbra/db/data w/ ownership of zimbra:zimbra . Remove the innodb_force_recovery line from /opt/zimbra/conf/my.cnf . Then recreate a default mysql db by running /opt/zimbra/libexec/zmmyinit --sql_root_pw $mysql_root_password and then attempt this steps over again to confirm you can drop them.'' Also note that you may have to reset the zimbra password manually in mysql, then set it again in Zimbra with the instructions from this page: http://wiki.zimbra.com/wiki/Resetting_LDAP_%26_MySQL_Passwords<br />
<br />
==4. Re-create all databases==<br />
# Run mysql in non-recovery mode<br />
## Remove the '''innodb_force_recovery''' line from /opt/zimbra/conf/my.cnf<br />
## Save the file and restart mysqld<br />
# Re-create the databases from the database list<br />
<br />
<pre>mysql.server restart</pre><br />
<br />
<pre><br />
for db in `cat /tmp/mysql.db.list`<br />
do<br />
mysql -e "create database $db character set utf8"<br />
echo "Created $db"<br />
done<br />
</pre><br />
<br />
==5. Repopulate the databases with the data from the SQL dumps==<br />
Import the data from the SQL dumps. Note that we import the zimbra database first because the mboxgroup databases depend on it<br />
<br />
<pre>mysql zimbra < /tmp/mysql.sql/zimbra.sql</pre><br />
<pre><br />
for sql in /tmp/mysql.sql/mbox*<br />
do<br />
mysql `basename $sql .sql` < $sql<br />
echo -e "Updated `basename $sql .sql` \n"<br />
done<br />
</pre><br />
<br />
==6. Test databases and start all ZCS services==<br />
Note that this is an example query. If you know of any particular databases that were corrupt, you may want to construct other queries to verify normal access to the data.<br />
<pre>mysql zimbra -e "select * from mailbox order by id desc limit 1"</pre><br />
<br />
Once you are satisfied that the databases are restored intact, start the rest of the zimbra services.<br />
<pre>zmcontrol start</pre><br />
<br />
Check /opt/zimbra/log/mysql_error.log and /opt/zimbra/log/mailbox.log for database errors.<br />
<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.5, 8.0, 7.0|8/13/2007}}<br />
<br />
[[Category:MySQL]]<br />
[[Category:Disaster Recovery]]<br />
[[Category:Troubleshooting]]</div>Raunaq