DirectAdmin Docs
Search K

Appearance

User/Reseller Management Hooks ​

user_create_pre.sh user_create_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.sh user_destroy_post.sh ​

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

Environment variables ​

user_httpd_write_pre.sh user_httpd_write_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.sh user_modify_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.sh user_password_change_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_pre.sh user_suspend_post.sh user_activate_pre.sh user_activate_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

setquota_post.sh ​

The setquota_post.sh hook is called after any call by DirectAdmin to the setquota or xfq_quota binaries, when setting User quotas or inode limits. It will be called once per related partition. Once for the da config-get quota_partition value, and one for each of da config-get ext_quota_partitions values, if applicable. Exit code of this script will not have any effect on DA's success return code to the User, but a non-zero will add "Script output: setquota_post.sh". Output from the script will not always be shown to the User. This script may be useful if other actions are needed to be done anytime quota limits are set. For example, altering the grace time to something than the default 7 days. This script was added in DirectAdmin 1.676

Environment variables ​

  • username: Username for the quotas being set.
  • partition: name of the parition where the quotas are being seg, eg: /home
  • success: 1 for successful call to setquota or xfs_quota, and 0 for some error.
  • exit_code: The exit code from setquota or xfs_quota (0 for success, non-zero for issue which can be checked via related man pages)
  • xfs: 1 if the given partition is an xfs partition, else 0.
  • bs: quota soft limit KB
  • bh: quota hard limit KB
  • is: inodes soft limit
  • ih: inodes hard limit

reseller_create_pre.sh reseller_create_post.sh ​

Hooks triggered before and after Reseller creation. For success, both should return 0, else return a non-negative exit code. A non-zero exit code for the reseller_create_pre.sh will abort the Reseller creation, while the reseller_create_post.sh will not abort anything, as it's too late at that point.

Any output will be returned in the results regardless of exit code. Non-zero return codes will also include the Script output text with the script name (See show_custom_script_path=1)

Environment variables ​

For both, the environmental variables will be:

  • Full contents of the internal reseller.conf values, at the time of the call. The pre may differ from post as changes are done based on settings (eg; use_this_ip,)
  • username: accout being created
  • passwd: plaintext password for the new account

Sample locations:

  • /usr/local/directadmin/scripts/custom/reseller_create_pre/YOURACTION.sh
  • /usr/local/directadmin/scripts/custom/reseller_create_post.sh
  • /usr/local/directadmin/plugins/PLUGINNAME/hooks/reseller_create_pre.sh

Note: We recommend using the new directory method custom/reseller_create_pre/YOURACTION.sh over the older custom/reseller_create_pre.sh file method.

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.sh reseller_modify_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

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:

bash
#!/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:

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

with this code:

bash
#!/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:

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

with code:

bash
#!/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.