Servers
The Servers page lists every MTA server the web admin manages. Each server runs the node and the milter (see Deployment layouts). The web admin sends each server the rules, the settings and the license, checks its state every few seconds, and reads its message history. The page is available to administrators only and is listed under Dashboard in the navigation.
| Column | Shows |
|---|---|
| Name | The name given when the server was added |
| Address | Host and port the web admin connects to |
| State | Whether the server has the current rules and settings, see Server states. Click it to see the details. |
| Version | The MSH Zimbra Rules version running on the server |
| Milter | Running or Not running, the milter on that host as seen by its node |
| License | The license id on the server, or Missing |
| Last contact | When the web admin last reached the server |
The toolbar has:
- Add Server... - add an MTA server, see Add a server.
- Sync Now - check every server at once and send each one what it is missing, instead of waiting for the next check.
- Actions > Remove - remove the selected servers. The web admin stops sending them rules and settings. A removed server keeps filtering mail with what it received last, until you stop its services or detach it from Zimbra (see How to uninstall).
Rule and setting changes reach every server automatically. The web admin checks the servers every 10 seconds and the milter picks up new settings within 45 seconds, so a change is applied on all servers usually within a minute.
This server
When the web admin runs on the same host as a node, which is the case on a single server, it adds that node by itself as This server the first time it starts. You do not need to add it.
It is added only once. If you remove This server, it is not added back; add it again with Add Server... (host 127.0.0.1, port 7082 and the token from /opt/msh-zr/etc/node.token).
Until at least one server is listed, the Dashboard and the Servers page show the notice No server is configured, so rules are not applied to any mail.
Add a server
Install the node and the milter on the MTA host first, see MTA servers. Then click Add Server... and fill in:
| Field | Value |
|---|---|
| Name | How the server is shown here, for example mta2. Must be unique. |
| Host | Host name or IP address of the MTA host, as the web admin server reaches it. |
| Port | The node port, 7082 by default (NODE_PORT in etc/config.cf on that host). |
| Token | The content of /opt/msh-zr/etc/node.token on that host. |
Click Add. The web admin connects to the server before adding it: the token must be accepted, and the server's certificate is remembered (pinned) so later connections only trust that certificate. If the connection fails, the server is not added and the reason is shown. A server with the same name or address cannot be added twice.
Once added, the server gets the rules, settings and license right away.
The connection to the node is always HTTPS with the certificate the node created on its first start. No certificate authority is involved: the web admin trusts the certificate it saw when the server was added.
Server states
| State | Meaning | What to do |
|---|---|---|
| Checking | The web admin has not reached the server yet since it started. | Wait a few seconds. |
| Up to date | The server has the current rules and settings. | Nothing. |
| Syncing | The web admin is sending the rules and settings. | Wait. |
| Behind | The server does not have the current rules and settings yet, for example because they changed while they were being sent. | Usually resolves itself in the next check. Click Sync Now to retry at once. |
| Offline | The web admin cannot connect to the server. | Check that msh-zr-node.service runs on that host, that the host name resolves from the web admin server, and that port 7082 is open from the web admin server. |
| Token refused | The server rejected the token. | The token in etc/node.token on that host changed. Remove the server and add it again with the current token. |
| Certificate changed | The server presented a different certificate than the one remembered when it was added. | If etc/node.p12 on that host was recreated, remove the server and add it again. If not, find out why another certificate is presented before you trust it. |
| Version mismatch | The server runs an older version than the web admin. | See Version mismatch. |
| Error | Any other failure. | Click the state to see the message. |
While a server is not up to date, it keeps filtering mail with the rules and settings it received last.
Version mismatch
A server that runs an older MSH Zimbra Rules version than the web admin cannot take the current rules and settings, because they may use features it does not have. The web admin stops sending it settings, and the server keeps filtering mail with the rules and settings it received before.
Update the server to the same version as the web admin, see Update. As soon as it runs the new version, the web admin sends it the current rules and settings.
To avoid the state during an update, update the MTA servers first and the web admin last.
Shared message counts
With more than one server, the message count based on sender and message count based on recipient conditions and the autoresponder loop protection count the messages of all servers together. Every 10 seconds the web admin collects what each milter counted and passes it on to the other servers.
If the web admin cannot exchange the counts with a server, the server shows a Counts not shared badge and the Dashboard shows a notice. Until the exchange works again, message-count limits on that server count only the messages it handled itself, so a sender can pass a limit by spreading messages over servers. The cause is usually the same as for an Offline server.
A limit can also be passed by messages that arrive on several servers within one exchange interval, so treat the limits as approximate in a multi-server installation.