Maintaining domains, users, resellers

How to rename a domain

If you've got a domain, say domain1.com, and you wish to rename it to domain2.com, go to:

User Level -> Domain Setup -> Change a Domain Nameopen in new window

Select the domain to change and type in the new value you wish to use.

This will affect both web data and email data.

It does not affect Database data, but if the database name doesn't change, then the scripts should continue to work (though you may need to update any script settings to the new domain's path).

How to change a username

If you've got a username that needs to be changed, it can be done the following way:

cd /usr/local/directadmin/scripts
./change_username.sh olduser newuser

NOTE: .sql database backups are highly recommended when renaming a user.

How to transfer a domain from one user to another

A script has been prepared to accomplish this:

cd /usr/local/directadmin/scripts
./move_domain.sh domain.com olduser newuser

If the newuser does not exist yet, then create newuser with fakedomain.com, transfer the domain, then delete fakedomain.com.

NOTE: domain names are not assigned to MySQL databases, so, please use the rename_database_with_user.sh script to transfer needed databases to the new account.

How to merge accounts

There are various reasons you may want to merge existing DA accounts, but for this guide, we'll assume you're doing it for the purpose of unifying things into 1 account such that you are below the Personal License limit of 1 account.

We'll premise the guide with the scenario that you had a license with a higher limit and have downgraded to the 1 account license.

We'll assume:
Admin:
User:

Where we'd need to merge all data under fred into the admin account (there must be 1 Admin on the server).

There are a few ways of going about this, so check the options below to see which scenario will work best for you.

As with any action that involves moving data around, be sure to make full backups of all data before proceeding.

User upgrade

Upgrade fred to be an Admin, delete admin, then optionally rename fred to admin.

First we'll upgrade fred to be an Admin. There is a script to upgrade Users to Resellers, so we'll rely on that for most of the heavy lifting. Log in to ssh as root, and type the following:

cd /usr/local/directadmin/scripts
./user_to_reseller.sh "fred"

Then, to go from a Reseller to Admin, it is three steps:

echo "fred" >> "/usr/local/directadmin/data/admin/admin.list"
perl -pi -e 's/^fred\n//' "/usr/local/directadmin/data/admin/reseller.list"
perl -pi -e 's/usertype=reseller/usertype=admin/' "/usr/local/directadmin/data/users/fred/user.conf"

From this point, you can log in to the new fred Admin Level account, and delete admin. This does assume admin does not have any relevant data under it.
This last step is optional. Since we have a fred Admin account, it can either be left as-is, or can be [renamed](/directadmin/general-usage/domains-users-resellers.html#how-to rename-a-domain) to admin.

Restore Merge

The next option is if you have a backup of fred, who does not currently exist on this box (the User could be deleted to get into this state), rename the user.{{admin}}.{{user2}}.tar.gz to admin.root.{{admin}}.tar.gz and restore. There is a guide for this method here.

Moving data between accounts

The last option is the most difficult, but allows both accounts to remain, while moving data between them. It's not great to move non-domain specific data, like cronjobs or databases, but not impossible.

Move all domains from fred to admin. This guide can help with that.
Moving non-domain specific data, we can first move database data for each database name, using this guide.
Moving crons between Users does not currently have a script. The simplest (assuming direct_crons=1 is enabled) is to, as root, type:

crontab -u "fred" -l

to list all crons, then edit the admin crons list

crontab -u "admin" -e

and copy/paste the output into the editor, and save. There may be other non-domain specific data, like ssh_keys, but the other methods above may be a better choice should that much detail be needed.

Domain already exists

This message will appear if the domain is already on the system. The primary way that DirectAdmin checks to see if the domain is already on the system is by looking in the named.conf file. (CentOS or CloudLinux: /etc/named.conf, Debian or Ubuntu: /etc/bind/named.conf).

If you are positive that domain has not been added anywhere in DirectAdmin (use Show All Accountsopen in new window in the Admin Panel tp check), then it should be safe to remove the zone from the named.conf file either manually, or by removing the zone from Admin Panel -> DNS Admininstrationopen in new window. Be sure to backup the zone if you do not wish to lose the DNS data.

With the addition of the Multi Server option, DNS can now be hosted on other DA servers. Ensure that any Servers you have listed in your Admin Level -> Multi Server Setupopen in new window page also do not have the domain in their named.conf files. If you disable the "check domain" option, then that server will not be queried.

You'd also want to ensure the domain is not in the following:

Remote Multi-Server Setup IP, with "Domain Check" option
/etc/virtual/domains file
/etc/virtual/domainowners file
/etc/virtual/domain.com directory
any /var/named/*.nzf file if rndc is used for adding/removing zonesopen in new window

'Show All Users' is missing some users

The CMD_SHOW_ALL_USERS (Admin -> Show All Usersopen in new window) page is generated from a cache file /usr/local/directadmin/data/admin/show_all_users.cache. This file can be recreated by typing:

echo "action=cache&value=showallusers" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d

This file is kept updated by DA and is updated for any domain or user changes. This cache file is also recreated in its entirety during the nightly tally. The single user updates only update the file for that one entry.

NOTE: you can also delete the show_all_users.cache file and load the Admin -> Show All Usersopen in new window page. If there is no cache file, DA will generate the page on the fly, which will be slower and look slightly different, but it will give you a definite real-time look at who's on the system. The show_all_users.cache will be recreated automatically with the nightly tally, or with the above echo command.

The /usr/local/directadmin/data/admin/show_all_users.cache cache file have an extra field for each user:

email_daily_limit=##

where it sets the limit for that User (/etc/virtual/limit or /etc/virtual/limit_fred). Any errors in determining the limit will cause it to be set to -1.

With that, the /CMD_ALL_USER_SHOW (Admin -> Show All Usersopen in new window) page will add an extra value to the "Send E-Mail" column, where if an email was sent today, then that column will look like this:

1  (Today: 1 / 100)

If no emails were sent today, then the column will look like this:

where "5" would be the sum of all emails sent this month, before today. The limit is not shown if no email was sent today.

How to send mail to all email accounts on the system

The DirectAdmin panel provides an interface to message all email accounts (for all domains). These must be 'local' accounts, meaning it will only deliver to local domains listed in /etc/virtual/domains.

A reseller/admin can find this tool here at the Reseller level:
Reseller Tools" > "Message All Usersopen in new window More information on the message systemopen in new window

Relating to the "Create Message" tool, e.g.,

If the 'All E-Mail Accounts' option is checked, the message is :

Delivered to all User/Reseller accounts that were selected just as before
Plus all E-Mail accounts that exist under domains for those selected User accounts

For Admins, the only way to truly message all email accounts on the system, is to use:
Admin Level -> Show All Users -> Advanced Search -> Items per Page = "All" -> Searchopen in new window
Then top right, click "Select", scroll down, and click "Send a Message". Ensure both E-Mail Only and All E-Mail Accounts are both selected when sending the message.

Since the list of email accounts is assembled before delivery, this list can get to be rather large. As a result, like the user=multiple, user=all, user=all_resellers options, the all_email_accounts=yes option will also push delivery to the background with the dataskq, and the sender will get a Message System notice after it's sent.

The "All E-Mail Accounts" option will send those virtual E-Mails as the Admin/Reseller, rather than "diradmin" which is used for the system account "E-Mail Only" part.

This means that if there are any blocks by Exim for this account to send emails, they will be handled accordingly.

Note: the SpamBlocker outbound limits do not apply to local email delivery, so that's not really an issue. These limits probably would just apply mainly to full system account email delivery blocking, like:
/etc/virtual/blacklist_usernames
/etc/virtual/blacklist_script_usernames

How to override suspending reseller account on overlimit

By default, the only global setting for "Suspend at Limit" for Reseller accounts is at: Admin Settings -> Suspend a Reseller and their Users when the Reseller goes over their Bandwidth limitopen in new window.

It could be overwritten with the reseller.conf file for any desired reseller(s):

suspend_at_limit=ON|OFF

which can be ON or OFF, where the set value will override the global Admin Settingsopen in new window option.

If no suspend_at_limit is set in reseller.conf, or it's set but not set to ON nor OFF, then it's ignored, and the global Admin Settingsopen in new window value is used.

**Note:**The admin.conf uses suspend=YES|NO for the global feature, but the decision was made to match the user.conf suspend_at_limit naming scheme.

How to suspend/unsuspend user from command line

This feature requires Directadmin v1.595 or newer.

A directadmin command line option exists to allow you to easily suspend/unsuspend accounts from ssh as root:

Suspend account (any account type):

/usr/local/directadmin/directadmin --suspend-user user=fred

Unsuspend account:

/usr/local/directadmin/directadmin --unsuspend-user user=fred

Suspend domain:

/usr/local/directadmin/directadmin --suspend-domain domain=domain.com

Unsuspend domain:

/usr/local/directadmin/directadmin --unsuspend-domain domain=domain.com

You can include a reason for suspending with a key:

reason=X

Where X must be one of the reason indexes (left side) in the file /usr/local/directadmin/data/templates/suspension_reason.txt, for example:

/usr/local/directadmin/directadmin --suspend-user user=fred reason=abuse

Omitting a reason will set the reason to be "root ssh" as it was before.

NOTE: The suspension_reason.txt is now only used from internal list for translation purposesopen in new window, though you can still copy it to custom/ directory for customizing the suspension reasons.

Suspend in the background

There is an optional an optional directadmin.conf value for suspending/unsuspending in the background. The internal default is: background_suspend_if_num_users=0

In order for DirectAdmin to suspend/unsuspend users in the background, set it to the number of selected users + sub-users.

For example, if you select a reseller then you have 1 selected user, plus the ones that were created by that reseller (sub-users).

So if you select 1 Reseller that has 9 users, you'll need to set it to 10:

/usr/local/directadmin/directadmin set background_suspend_if_num_users 10
systemctl restart directadmin

This is useful if the process is taking too long on your system (case: usermod issue taking too long to return).

Unable to read the user data file

When restoring a backup, if you get the error:

Unable to read the User data files for username

this would mean that the account likely already exists on the system in /etc/passwd, and the the data in /usr/local/directadmin/data/users/username does not exist.

If there is not yet any data for the User on the system (e.g., named.conf, /home/username/*, databases, /etc/virtual/domain.com, etc.), then remove the account from the system, and try the restore again.

userdel -r username

If there is data set up everywhere that you do not want to delete, then try repairing the DA account with:

cd /usr/local/directadmin/scripts
./fix_da_user.sh username user domain.com

How to run fix_da_user.sh for all the users

If you've managed to delete the contents of your /usr/local/directadmin/data/users directory, and you need to recreate them, you can use this guide. Note that if you have backups, it may be easier to start over and just restore the backups.

The fix_da_user.sh script will add any missing fields into the users' data configs for DA.
The below script will run it for each user and each domain stored in the /etc/virtual/domainowners file (assuming you didn't delete that as well).
You'll need to make sure your /usr/local/directadmin/data/users directory is created and chown'd to diradmin:diradmin.
Create a fix.sh script with the contents below, chmod the script to 755, then run it.
Running it on existing data shouldn't hurt things (in theory), since it only adds missing fields and ignores fields that are not missing.

#!/bin/sh

while read line
do
     domain=`echo $line | cut -d: -f1`;
     user=`echo $line | cut -d\  -f2`;

     echo "Fixing $domain for $user ...";

     /usr/local/directadmin/scripts/fix_da_user.sh $user user $domain

done < /etc/virtual/domainowners

**NOTE: **This will create all missing users with a default set of data, like unlimited limits, for example. It will also create them with the "admin" account as their Reseller. If you need to change the creator after, do so from: Admin Level -> Move Users between Resellersopen in new window.

Also, if any of the accounts created by fix_da_user.sh are actually Reseller accounts, you must upgrade them to Reseller accounts using the /usr/local/directadmin/scripts/user_to_reseller.sh script.

How to rebuild all resellers' users.list files

If your users.list files for all of your Resellers/Admins becomes corrupt, you can run this script to rebuild them all. Corruption can happen during any instance where multiple processes are writing to the users.list file simultaneously (locking issue). Things like backup restores in the background could in theory cause it, while browsing in DA. It assumes that usertype=user, and creator=hiscreator exists in all user.conf files.

Create a fix.sh somewhere and fill it with the following code:

#!/bin/sh

cd /usr/local/directadmin/data/users

for r in `ls */reseller.conf | cut -d/ -f1`; do
{
     echo "fixing Reseller $r ..."

     echo -n '' > $r/users.list

     for u in `grep "^creator=${r}$" */user.conf | cut -d/ -f1`; do
     {
         ISUSER=`grep -c usertype=user $u/user.conf`
         if [ "$ISUSER" = "1" ]; then
             echo $u >> $r/users.list
         fi
     };
     done;
};
done;

Make it executable with chmod 755 fix.sh and run it.

It can be run repeatedly as the users.list files are emptied before the run starts.

How to rebuild the reseller.list file

If your reseller.list file becomes corrupt, you can run the command below to rebuild it. Corruption can happen during any process that writes the reseller.list file when multiple processes are saving the file at the same time (locking issue). Things like backup restores in the background could in theory cause it, while browsing in DA.

cd /usr/local/directadmin/data
grep -H "usertype=reseller" users/*/user.conf | cut -d/ -f2 > admin/reseller.list

How to upgrade a user to a reseller

If you have a User account which you wish to upgrade to a Reseller, use the following guide. Replace username with the User you wish to upgrade.

cd /usr/local/directadmin/scripts
./user_to_reseller.sh username

How to upgrade a reseller to an admin

If you have a Reseller account which you wish to upgrade to an Admin, use the following guide. Replace username with the User you wish to upgrade.

cd /usr/local/directadmin/data/users/username
perl -pi -e 's/usertype=reseller/usertype=admin/' user.conf
cd /usr/local/directadmin/data/admin
perl -pi -e 's/^username\n//' reseller.list
echo username >> admin.list

How to downgrade a reseller to a user

If you've got a Reseller account which you'd like to downgrade to a User account, the process is fairly simple.

You can use a script to accomplish this, or do it manually.

To do so via script, use the /usr/local/directadmin/scripts/reseller_to_user.sh script. This script is used to convert a reseller to a user.

Usage:

  ./reseller_to_user.sh <user> <reseller>

where:

user: name of the account to downgrade.
reseller: name of the new creator of the User: eg: admin To do so manually, following these instructions. We'll assume the Reseller's name is , and fred will soon be a User. We'll also assume that fred has no Users below his account. If he has, move the user to another reseller.

Convert fred's account type to be a User. Edit /usr/local/directadmin/data/users/{{user2}}/user.conf and change the line:

usertype=reseller

to become:

usertype=user

Update the lists. Edit /usr/local/directadmin/data/admin/reseller.list and remove fred from it.
Edit /usr/local/directadmin/data/users/admin/users.list and add fred to it.
Give fred the bad news that his account has been downgraded.

We don't need to delete the Reseller-related files, since they won't hurt anything. They're also handy in the event that you want to upgrade him later.

How to change the package for all users

If you wish to change the package from one value to another for all Users:

Create a script newpack.sh with the following code:

#!/bin/sh

OLD=custom
NEW=fancy

for i in `ls /usr/local/directadmin/data/users`; do
{
       COUNT=`grep -c usertype=user /usr/local/directadmin/data/users/$i/user.conf`
       if [ "$COUNT" -eq 0 ]; then
               continue;
       fi

       echo "Updating User $i";

       perl -pi -e "s/package=$OLD/package=$NEW/" /usr/local/directadmin/data/users/$i/user.conf
};
done;
exit 0;

which will change all Users who have a custom package, to have a fancy package (replace with real package names).

Make it executable and run:

chmod 755 newpack.sh
./newpack.sh

To activate the values and limits in the user.conf, save or edit the fancy package from the DirectAdmin interface, and all Users with it will be updated accordingly.

How to change the package for all users under a reseller

The script from the previous guide could be improved to change a package for all users under a given creator.

DirectAdmin does not have a bulk "Move Users to package" (for now), but a simple script could be used to accomplish things, in combination with a simple "save" through DA. Let's assume the following variables:
Creator:
Package:

Create a script with the following code:

    #!/bin/sh
    CREATOR="silver"
    TOPACKAGE="gold"

    USERS=/usr/local/directadmin/data/users
    for u in `ls $USERS`; do
    {
           UCONF=$USERS/$u/user.conf
           C=`grep ^creator= $UCONF | cut -d= -f2`
           if [ "$C" != "$CREATOR" ]; then
                   continue;
           fi
           T=`grep ^usertype= $UCONF | cut -d= -f2`
           if [ "$T" != "user" ]; then
                   continue;
           fi
           perl -pi -e "s/^package=.*/package=${TOPACKAGE}/" $UCONF
    };
    done;
    exit 0;

Save the script, chmod it to 755, and run it. All Users below silver should now be set to gold.
Lastly, we need to activate the actual numerical data from your gold package into the user.conf files. Login to DirectAdmin as silver, go to Reseller Level -> Manage User Packages -> gold -> Saveopen in new window, which will go through all Users with this package and update them to these values.

How to shut off mail_sni per domain

The back-end allows mail_sni to be disabled per domain by modifying the /usr/local/directadmin/data/users/username/domains/domain.com.conf file by adding:

mail_sni=OFF

followed by a full SNI rewrite to purge the domain from the exim/dovecot configs:

echo "action=rewrite&value=mail_sni" >> /usr/local/directadmin/data/task.queue; /usr/local/directadmin/dataskq d

Alternate email for high-volume messages

You can manually add a field to your user.conf which will be used for brute-force monitor notices, where multiple values are supported:

alternate_email=attacks@domain.com,other@email.com

This will free up your inbox from getting flooded, while still being able to get notified of the attacks via a separate email address.

How to disable DKIM per user or domain

When dkim=1 is set in the directadmin.conf, this is globally set for all Users, and cannot be turned off when a domain is created. Some Users might not want this (e.g., external DNS servers), so this override allows you to shut off DKIM processing for their account.

Regardless of the directadmin.conf setting, you can now edit their /usr/local/directadmin/data/users/username/user.conf and add:

dkim=0

to override the global setting.

Any domains created under this account will not have DKIM created, even if dkim=1 is set in the directadmin.conf.

You can also do the same thing on a per-Domain basis in: /usr/local/directadmin/data/users/username/domains/domain.com.conf but if you set dkim=0 in the user.conf, the domain.com.conf won't be checked.

If you want per-Domain control, you shouldn't set dkim=1 in the user.conf.

Also, if you have dkim=0 set globally, neither the user.conf nor the domain.com.conf file will be checked. The global dkim=0 setting fully shuts off everything.

Note, if DKIM is already enabled for the User/Domain, to disable it:

Delete the files: /etc/virtual/DOMAIN.COM/dkim.public.key/etc/virtual/DOMAIN.COM/dkim.private.key
Delete the TXT records:

_domainkey
x._domainkey

Use custom headers when sending messages to users

When sending messages to users over Admin Level -> Show All Usersopen in new window or Reseller Level -> List Usersopen in new window, select the Users and click "Send Message" with the "email only" option.

Enable this functionality so that the emails can be html or have custom headers added:
http://www.directadmin.com/features.php?id=620open in new window

Note, you could already make an html email by simply adding:

<html>

as the very first line of the message, and DA would add the required headers, but now you can also add any header you want, e.g.,

|?HEADER=X-My-Header: purple-monkey|

Keep in mind that DA is fairly strict about header syntax and doesn't allow many special characters. If you're having issues with this, try with a very basic character-set first, to determine if it's the characters used, or an error elsewhere.

If you're going to combine <html> with |?HEADER=..|, just make sure that <html> remains at the very first line, or else DA won't see it.

You can use |?HEADER=..| by itself if you want.

How to prevent adding certain domains

A file /usr/local/directadmin/data/templates/forbidden_domains.list contains domains that are forbidden to be added by users in your DirectAdmin system. This can be customized by copying the file into the 'custom' directory, which will let DA know that the file has been customized:

cp -p /usr/local/directadmin/data/templates/forbidden_domains.list /usr/local/directadmin/data/templates/custom/forbidden_domains.list

If you want to add few more domains to forbidden list, the best way will be to create /usr/local/directadmin/data/templates/custom/additional_forbidden_domains.list and add only new domains into that file.

If you want to allow users the ability to add any domain that they want, just create an empty /usr/local/directadmin/data/templates/custom/forbidden_domains.list file.

# Maintaining domains, users, resellers

# How to rename a domain

# How to change a username

# How to transfer a domain from one user to another

# How to merge accounts

# User upgrade

# Restore Merge

# Moving data between accounts

# Domain already exists

# 'Show All Users' is missing some users

# How to send mail to all email accounts on the system

# How to override suspending reseller account on overlimit

# How to suspend/unsuspend user from command line

# Suspend in the background

# Unable to read the user data file

# How to run fix_da_user.sh for all the users

# How to rebuild all resellers' users.list files

# How to rebuild the reseller.list file

# How to upgrade a user to a reseller

# How to upgrade a reseller to an admin

# How to downgrade a reseller to a user

# How to change the package for all users

# How to change the package for all users under a reseller

# How to shut off mail_sni per domain

# Alternate email for high-volume messages

# How to disable DKIM per user or domain

# Use custom headers when sending messages to users

# How to prevent adding certain domains