Directadmin Docs

Multi-Server Setup

The Multi-Server Setup (MSS) feature is used for multiple DirectAdmin servers to communicate with each other.

Below, we'll list what this feature started with, and how its functionality has expanded over the years.

For all examples, we'll refer to box A as the master, where you're logged into box A looking at the MSS page, looking at of list of B servers, and box B as the remote slave. All cases 'push' data from A to B for saving data on disk on the remote B side.

  1. The original purpose of this tool was to allow for DNS zone mirroring. You can have a User with domainA.com on box A, and DirectAdmin will sync the domainA.com zone over to box B. This tool also prevents anyone from creating domainB.com on box A, should domainB.com exist on box B (created under UserB).

  • The sync feature is called Zone Transfer and pushes local zones from A to B, when saved on A.

  • The remote zone check is called Domain Check where the creation of domainB.com is blocked on A, if zone exists on B.

  • You can set up box B to point back to box A, allowing for A=ns1, B=ns2, and have Users on both A and B, allowing full use of A+B for Users+Domains.

  • If restoring UserA on box B where userA.com exists in B's DNS, use the following Admin Backup/Transfer Setting: On restore, check for domain conflict in domainowners, rather than the named.conf, or remote named.conf files. if you need to overwrite the local userA.com zone on both A+B (assuming B » A Zone Transfer enabled).
    This is because slave B might have the zone userA.com, but won't exist as a full domain on B yet. This alters the unique index check from the named.conf to the domainowners file, so that the MSS Zone Transfer does not interfere with the block (but B » A Domain Check would still block)

  • When deleting a User from A, use the 'Leave DNS' option if the zone should remain on A+B, when Zone Transfer is enabled.

    More information on DNS clustering can be found here.

  1. User Check

The MSS User Checkopen in new window option is used to prevent creating "fredB" on box A, if 'fredB' exists on box B.

This is very important to use if you have a single shared remote MySQL/MariaDB server (say box C), because DirectAdmin uses the usernames as prefixes for databases. This means that duplicate Usernames on both A and B mean either User (with the same name) can see each other's databases. For example, if you have 'fredB' on both A and B, logging into A, you'd see the database 'fredB_dbname' of 'fredB', regardless of which server actually created them. In essence, they'd be sharing the same list of DBs. If you use a remote DB server where multiple boxes A/B share the same C DB server, be sure to set up two-directional MSS with User Check enabled: A » B and B » A.

  1. E-Mail Accounts

The E-Mail Accounts option is a more hands-on feature which makes assumptions based on the setup.

The feature itself will keep the list of accounts in /etc/domain.com/passwd synced from box A to box B. This assumes that B has the same User setup that exist on box A, as well as the same domain name.

It does not sync the User, and does not create the domain. See the "User Accounts" option below. More information on E-Mail Accounts sync can be found hereopen in new window.

  1. Show All Users

The Show All Users option will let the Show All Users page on box A, also include the list of all Users/domains from box B.

When you view this page on box A (CMD_ALL_USER_SHOW or /admin/users), it will add another column clarifying which box the item is from. Clicking on that Username will either go to the local "view account" page, or if it's a remote account, it will provide a URL to that remote server's "view account" page (login required).

More information on the Show All Users feature can be found hereopen in new window.

  1. User Accounts

ALPHA/LIMITED TESTING

The User Accounts option, which is not production ready and disabled by default, will have any User/domain created on box A, also be created on box B. As mentioned above, it's not fully finished nor tested, but does work on a basic level of User/domain creation and deletion (at your own risk). It does not sync anything else. It's useful if you're also looking to use the E-Mail Accounts sync, as it would do its best to ensure the remote User/domain is set up and ready to go when it's time for E-Mail account creation on A, synced to B.

More information on the User Accounts sync can be found hereopen in new window.

  1. enable_threads=1

ALPHA/LIMITED TESTING

As with any MSS feature where you have multiple remote servers set up (let's use 3, for example), doing 3 sequential requests will take 3 times as long as doing 3 parallel calls all at the same time. The enable_threads=1 directadmin.conf setting currently works for options User Check and User Accounts, with plans to add support for Zone Transfer/Domain Check for faster MSS syncs when more than one B slave exists on the MSS page of A.

Transferring Users between linked Multi-Server Setup boxes is done by using this guide.

Remote E-Mail Account sync

Related forum threadopen in new window.

This will simply sync the account information over to the other DA box. It will use the API to login as this remote User (using the "login-as") and will match the commands done locally.

Currently supports:

  • create account
  • change account
  • delete accounts
  • suspend/unsuspend accounts

Currently does not support:

  • pop disk usage reported to main box
  • send count reported to main box

Optional files for fine control:
/usr/local/directadmin/data/admin/cluster_email_allow.list
/usr/local/directadmin/data/admin/cluster_email_deny.list

Both of these lists can contain Users and/or domains.

  1. If neither file exists, all Users/Domains are synced.
  2. If allow exists, no Users/Domains are synced, unless in this file. This file overrides deny.
  3. If User and/or Domain is the deny, email will not be synced.
  • Only one of the User or Domain is required in the allow file. If either is present, email is synced.
  • If either of the User or Domain is in the deny, the email will not be synced, unless already allowed via "allow"
  • If allow exists, the deny is never checked.

SYNC

When you first turn on the feature, if A has accounts, but B does not, you can sync A to B with:

echo "action=rewrite&value=email_passwd" >> /usr/local/directadmin/data/task.queue

FAILURES

Like the DNS clustering options, DA uses a task.queue retry for all commands, as long as you set the directadmin.conf setting "remote_dns_retries" to a non-zero value.

The format of the task.queue entry is:

action=sync&type=cluster&value=email&username=fred&host=1.2.3.4&count=10&request=longrequest

Where:

  • fred is the DA username that called the email command
  • host is the host that failed, so it will only retry the single failed host
  • count counts down from the directadmin.conf option remote_dns_retries, until 0. The default is 0, so retries are not enabled by default.
  • longrequest is URL encoded post from the original client request. DA basically passes it to the User in the same manner.

REQUIREMENTS

  • Both the DirectAdmin Username and domain must exist on both servers. This may require you shut off the MSS on both servers until the account/domain exists, then turn it back on.
  • The receiving server (mirror) does need DA 1.48.0+
  • DA will call the CMD_API_POP command on the remote server, so ensure this is allowed in your login key.
  • The "Login As" feature is used, so ensure this is allowed on the remote box, for the given login key.
Last Updated: