Directadmin Docs

User/Reseller Management Hooks

reseller_destroy_pre.sh

This script is called before a reseller is deleted.

The reason for having this script is that if you delete a Reseller, adding the reseller and users to the user_destroy_pre.sh won't be sufficient, in that a lot of deletion cleanup is done prior to the reseller's user portion actually being removed (which is when the user_destroy_pre.sh is finally run)... so the user_destroy_pre.sh isn't sufficient to cover some cases.

This script will be handy if you want to prevent the deletion of an account, or a specific account (Reseller or User) below it.

Environment variables

reseller_modify_(pre|post).sh

These hook scripts are called before/after a reseller config file is modified.

Environment variables

  • contents of user's reseller.conf and, during the pre script, the data from the request body.
  • modified_by: reseller who makes the modifications

user_create_(pre|post).sh

These scripts are called before/after a user/reseller/admin is created.

Environment variables

  • passwd: password set for user
  • contents of user.conf

user_create_post_confirmed.sh

This hook is called after the user.conf is written (for user creation).

Note, this feature request was initially made with the domain_create_post.sh in mind (for domain_create_post_confirmed.sh).

However, after looking at the code, it was found that the write for the domain confs are done quite early on in the creation, so the domain_create_post.sh is in fact called at the correct time, thus there is no need for the domain_create_post_confirmed.sh.

It was also found that there was a follow-up write of the domain.com.conf, which is why the domain_create_post.sh script wasn't able to make any changes.

Environment variables

  • passwd: password set for user
  • contents of user.conf

user_destroy_(pre|post).sh

These scripts are called before/after a user/reseller/admin is deleted.

Environment variables

user_httpd_write_(pre|post).sh

These custom scripts are called before/after a user httpd.conf is written.

Environment variables

  • username: owner of httpd.conf file
  • creator: (on domain creation only) reseller who created the user

user_info_modify_post.sh

This script is used for changing the following User info:

  • Name
  • Email
  • language
  • skin

Note that the user.conf may or may not have already been written when this is called, so don't rely on it being written already.

Environment variables

One of the following variables will be set with value of their respective button value:

  • email
  • name
  • language
  • skin

These values are always passed, from the form:

  • nvalue: username
  • evalue: user contact email
  • lvalue: language set
  • skinvalue: name of set skin

user_modify_(pre|post).sh

These scripts are called before/after the user config file is modified.

Environment variables

  • contents of the user's user.conf...during the pre script, variables may include the same data from the request body.
  • modified_by: reseller who will make/made modifications

user_password_change_(pre|post).sh

These scripts run before/after the DA user's password is changed.

Environment variables

  • contents of user.conf
  • passwd: new password
  • home: user's home directory
  • username: DA name
  • called_by_self(0|1): whether the password change was called by the user themselves
  • options: set to yes if additional settings are passed, which includes:
    • system(no|yes): update user's system (directadmin) password
    • ftp(no|yes): update password used for main ftp account
    • database(no|yes): update password used for main database account

user_(suspend|activate)_(pre|post).sh

This script is called before/after a user is suspended or unsuspended (activated).

Environment variables

  • contents of user.conf
  • bandwidth_used: network bandwidth used by user
  • quota_used: disk quota used by user
  • choice (0|1): describes the way user was suspended
    • 1 - admin or reseller manually suspended the user The account will not be unsuspended upon the monthly reset.
    • 0 - user was suspended during dataskq tally for bandwidth overuse. account will be unsuspended at the beginning of the month
  • caller_type: type of caller. possible values:
    • 0: N\A
    • 2: reseller
    • 3: admin
  • caller_name: name of admin or reseller who suspended the user

Examples

Customizing the php mail log location for your users

This example makes use of the following internal value:

php_mail_log_dir=NULL

which is unset/missing.

If you add any string, even an empty value like "php_mail_log_dir=", this will be used (don't add an empty value).

This feature allows you to override the /home/user/.php folder to use some other location, in the event your clients have a habit of deleting their logs.

So if you wanted to store them elsewhere, like:

/var/log/php-mail-logs/fred/php-mail.log

You could use:

php_mail_log_dir=/var/log/php-mail-logs/|USERNAME|

Note that DirectAdmin assumes the directory has permission to be created while running as the User.

As such, the parent folder must exist and be controllable by the User ahead of time.

In the above example, this would not be true, so using a hook like:

/usr/local/directadmin/scripts/custom/user_create_post/php_mail_log.sh

with the following code:

#!/bin/sh
D=/var/log/php-mail-logs/$username
mkdir -p $D
chown $username:apache $D
chmod 770 $D
exit 0;

would be needed.

Post-cleanup might be required too via this hook:

/usr/local/directadmin/scripts/custom/user_destroy_post/php_mail_log.sh

with this code:

#!/bin/sh
D=/var/log/php-mail-logs/$username
rm -f $D
exit 0;

Make sure to chmod your scripts to 700 and set the ownership to diradmin.

Prevent Users from changing their own DirectAdmin password

There are some cases where you do not want to allow Users to change their passwords, but still allow the passwords to be changed via their creator. I believe WHMCS might be one of these cases, where they'd change their passwords from there.

In DA there are a few ways you could block their access to CMD_PASSWD, but assuming you have 1.51.4+, the simplest would be to create the custom script:

/usr/local/directadmin/scripts/custom/user_password_change_pre.sh

with code:

#!/bin/sh
if [ "$called_by_self" = "1" ]; then
       echo "You cannot change your own password.";
       exit 1;
fi
exit 0;

and chmod the script to 755 and chown to diradmin.

Last Updated: