Search K
Appearance
Appearance
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.
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.
The MSS User Check 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.
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 here.
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 here.
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 here.
Related forum thread.
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.
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.
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.queueLike 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=longrequestWhere: