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
- contents of user.conf
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
- 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:
- 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
orxfs_quota
, and 0 for some error. - exit_code: The exit code from
setquota
orxfs_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. Thepre
may differ frompost
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
- contents of reseller's user.conf file
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:
#!/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.