https://wiki.zimbra.com/api.php?action=feedcontributions&user=SusanUllman&feedformat=atomZimbra :: Tech Center - User contributions [en]2024-03-28T22:35:11ZUser contributionsMediaWiki 1.39.0https://wiki.zimbra.com/index.php?title=Mail_Queue_Monitoring&diff=17673Mail Queue Monitoring2010-01-29T21:33:05Z<p>SusanUllman: /* Another cause, Zimbra account has been disabled */</p>
<hr />
<div>== Mail Queue Overview ==<br />
<br />
Incoming and outgoing mail is processed by postfix in a series of queues; normally, mail moves from the ''incoming'' queue to the ''active'' queue, from which it is delivered. If delivery is deferred, mail is moved to the ''deferred'' queue, and automatically reprocessed later.<br />
<br />
Additionally, mail can be put in the ''hold'' queue, which will prevent it from being delivered until it is manually removed from the ''hold'' queue.<br />
<br />
== Monitoring Queues ==<br />
<br />
Queues can be monitored from within the admin console; select ''Manage Mail Queues'' from the left sidebar and your queue information will be shown.<br />
<br />
== Troubleshooting Queue Monitoring ==<br />
<br />
=== Common Errors ===<br />
<br />
The most common problem is authentication to the mta server. This shows in the mailbox.log logfile as:<br />
<br />
Message: system failure: exception during auth {RemoteManager: MAIL.DOMAIN.COM->zimbra@MAIL.DOMAIN.COM:22}<br />
com.zimbra.cs.service.ServiceException: system failure: exception during auth {RemoteManager: <br />
MAIL.DOMAIN.COM->zimbra@MAIL.DOMAIN.COM:22}<br />
at com.zimbra.cs.service.ServiceException.FAILURE(ServiceException.java:174)<br />
at com.zimbra.cs.rmgmt.RemoteManager.getSession(RemoteManager.java:197)<br />
at com.zimbra.cs.rmgmt.RemoteManager.execute(RemoteManager.java:134) <br />
<br />
etc...<br />
<br />
Regenerating keys may very well fix this however, one other place to look is your ''/var/log/secure'' file. If you see something similar to:<br />
<pre><br />
sshd[16312]: Authentication refused: bad ownership or modes for directory /opt/zimbra<br />
</pre><br />
<br />
It's possible you only need to fix your ownership and permissions.<br />
<br />
<pre><br />
su - zimbra<br />
zmcontrol stop<br />
exit<br />
</pre><br />
<br />
Now login as root -- this command must be run as root, run zmfixperms, and start zimbra back up:<br />
<pre><br />
/opt/zimbra/libexec/zmfixperms <br />
su - zimbra<br />
zmcontrol start<br />
</pre><br />
<br />
If this doesn't fix any errors you'll probably need to regenerate your keys.<br />
<br />
=== Regenerating Keys ===<br />
<br />
To regenerate the ssh keys, on all hosts (as the zimbra user):<br />
zmsshkeygen<br />
<br />
To deploy the keys, on all hosts (as the zimbra user):<br />
zmupdateauthkeys<br />
<br />
=== Verifying sshd configuration ===<br />
<br />
The authentication method assumes that sshd on the mta is running on port 22, and that RSA Authentication is enabled. You can test the ssh command with:<br />
<br />
ssh -i .ssh/zimbra_identity -o strictHostKeyChecking=no zimbra@MAIL.DOMAIN.COM<br />
<br />
(Swap MAIL.DOMAIN.COM for your hostname, as it appears in the error).<br />
<br />
You should NOT be prompted for a password; if you are, recreate the ssh keys and retry the test.<br />
<br />
If you're not running sshd on port 22, modify the zimbraRemoteManagementPort attribute on the server:<br />
zmprov ms MAIL.DOMAIN.COM zimbraRemoteManagementPort 2222<br />
<br />
Verify in /etc/sshd_config that the zimbra user is an allow user<br />
AllowUsers admin zimbra<br />
<br />
Note: applying this change resulted in not being to ssh as root. Should we add root to the list of AllowUsers!<br />
<br />
=== /etc/hosts.allow ===<br />
The Zimbra hostname may be different than the system. Add the Zimbra hostname to ''/etc/hosts.allow''.<br />
ALL: zimbra.domain.tld<br />
<br />
=== Another cause, Zimbra account has been disabled ===<br />
If the above steps do not work then enable verbose output for ssh with:<br />
ssh -vi .ssh/zimbra_identity -o strictHostKeyChecking=no zimbra@MAIL.DOMAIN.COM<br />
<br />
If the output from ssh indicates that ''Next authentication method: password'' as below, then the Zimbra account may be locked.<br />
<br />
debug1: Next authentication method: publickey<br />
debug1: Offering public key: /opt/zimbra/.ssh/zimbra_identity<br />
debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive<br />
debug1: Next authentication method: keyboard-interactive<br />
debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive<br />
debug1: Next authentication method: password<br />
zimbra@MAIL.DOMAIN.COM's password:<br />
<br />
To verify this, as root check /etc/shadow. Locate the zimbra account. If the account has one or more ! in the line then the account is locked.<br />
zimbra:!!:13634:0:99999:7:::<br />
<br />
Use this command to unlock the zimbra account (or you can edit the shadow file directly and remove them).<br />
usermod -U zimbra<br />
<br />
Then check /etc/shadow again, there should be no ! for the zimbra account. You may need to do this multiple times to remove the ! and unlock the account.<br />
<br />
Once the account is unlocked, this command should work (it did for us!).<br />
ssh -i .ssh/zimbra_identity -o strictHostKeyChecking=no zimbra@MAIL.DOMAIN.COM<br />
<br />
[[Category:Pending Certification]] Whitepapers: [uk.bestessays.com/essay_service.html Essay writing services]</div>SusanUllman