Notification Hooks

brute_force_notify_pre.sh

This hook is called prior to the sending of BruteForce Monitor notifications and can be useful for preventing BFM notifications regarding a certain IP/User (see the accompanying example at the bottom of this guide).

Environment variables

• type(IP|User): type of value
• value: IP or User for which the brute-force notice would be created if not ignored

---

check_partitions_notice_post.sh

This hook will be called anytime the the partition notice message is sent:

• either daily with the tally
• or with the "minute" option, up to 60 seconds after the first time the dataskq notices the limit being hit, max once per 24 hour period

You can add code into this hook to check and clear up anything that needs to be done.

Environment variables

• THRESHOLD: partition threshold in percent
• PARTITIONS: list of partitions over threshold. one per line. in this format ("${partition_in_use}% - ${Partition mount path}")
• LANG: system language

---

connection_info_post.sh

This hook is used to add custom connection information to the connection notice.

The connection information script is located at:

/usr/local/directadmin/scripts/connection_info.sh

which will spit out the netstat info for:

• list top number of connected IPs, with their connection count
• the IP with the most number of connections, with all connection info (including ports)
• if /usr/sbin/ss exists, a full dump of "ss -n" for more info.

A custom copy can be used at this location:

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

to fully override the default.

Alternatively, one may choose to use the hook script to append their custom output to the connection information notification.

The following hook is called from within the script so you can include your own output to the Admin message:

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

Which means that the default output is still included, without needing you to manage it if copied (plus your own output from the connection_info_post.sh script).

---

load_spike_notice_(pre|post).sh

This script is related to the directadmin.conf settings check_load and check_load_minute.

These hooks are called before/after the load notice is sent to admins. The load_spike_notice_pre.sh script suppresses the notice on a non-zero exit status.

Also worth noting is the script /usr/local/directadmin/scripts/extra_load_info.sh, which is customizable by copying and modifying it in the /usr/local/directadmin/scripts/custom/ directory.

This script is triggered when the load of the box is above the amount specified by directadmin variables check_load and check_load_minute.

Environment variables

• ONE: one minute load average
• FIVE: five minute load average
• FIFTEEN: fifteen minute load average
• LOAD: the chosen minute load average
• LIMIT: limit set in the directadmin.conf
• LANG: language set in the directadmin.conf (lang)

---

notifyAdmins_post.sh

This script is triggered for any event that sends a message to all Admins via the Message System.

Environment variables

• priority: priority number
• subject: subject line
• message: message body
• user: constant "multiple"
• email_only(0|1): 1 means it will only trigger an email in some cases when set, like BFM message suppression, without a Message System notice

---

other_disk_usage.sh

If you have data that should be counted in the total disk usage for a User, but does not fall under the standard usage areas (e.g., data on a remote server), then you can use this option to create a hook, which lets you add extra bytes into the disk usage under "Other Usage".

Set the following in the directadmin.conf:

count_other_disk_usage=1

and create a script:

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

The script must exit with code 0. If a non-zero code is exited, the output is logged to the errortaskq.log.

The output on exit 0; must be a URL encoded. It will basically just be:

other_quota=12345

where 12345 bytes will be added to the user.usage file.

In the future, we might add more, like:

other_quota=12345&something_else=56789

but for now, it's just "other_quota". The value must be a positive integer.

---

overusage_notice_(pre|post).sh

These custom scripts are called before/after a warning/notice email is sent out.

Environment variables

• USERNAME : The name of affected user
• BANDWIDTH : percentage of bandwidth used by user
• QUOTA : percentage of quota used by user
• INODE : percentage of inode limit used by user
• BANDWIDTHLIMITGIG : bandwidth limit in MiB set for user
• BANDWIDTHUSAGEGIG : current user bandwidth in MiB
• BANDWIDTHLIMITMEG : bandwidth limit in GiB set for user
• BANDWIDTHUSAGEMEG : current user bandwidth in GiB
• QUOTALIMITGIG : Disk quota limit in MiB set for user
• QUOTAUSAGEGIG : current user disk quota in MiB
• QUOTALIMITMEG : Disk quota limit GiB set for user
• QUOTAUSAGEMEG : current user disk quota in GiB
• INODELIMIT : inode limit set for user
• INODEUSAGE : current user inode usage
• TIMELEFT : estimated time left Until limit is hit
• SUSPENDATLIMIT : user configuration variable.
• (INODES|BANDWIDTH|QUOTA)_EXCEEDED : set to yes if inodes, bandwidth and/or quota are exceeded
• CREATOR : creator of user
• LANG : Language set for user

---

sendSystemMessage_(pre|post).sh

These hook scripts are triggered anytime DA sends a notice to the Message System.

Environment variables

• priority: priority number
• subject: subject line
• message: message body
• user: multiple
• email_only (0|1): (1 means it will only trigger an email in some cases when set, like BFM message suppression, without a Message System notice)
• include_admins (0|1): where 1 means the Admins will also be notified, but won't be in the "users" list variable. See the admins.list for the list of Admins.
• alternate_email (0|1): usually 0, but some cases like BFM message suppression means the user.conf alternate_email is used, so main inbox isn't flooded for common messages. This is always 1 for those cases, but only matters if the user.conf actually has alternate_email set. If it's not in the user.conf, it makes no difference. Refers to the emails used for notification of the message in the Message System.
• users: List of users in query string format ("user1=${username1}&user2=${username1}..." where ${usernameX} URL encoded username). It's possible this value is blank if include_admins=1.

---

service_down_notice.sh

This hook is called in the event that a reload and restart both fail to bring a service to be up.

This will give you the opportunity to add extra checks/fixes if you know of common issues with the given service.

If your script thinks it might have fixed the issue, then exit with a return code 0, which tells the dataskq to wait 5 seconds to let that service start up before checking if it's running.

For all other cases, the script should return a non-zero status, e.g., "exit 1;" which disables the 5 second wait for the final process check.

If the service is not running for the final process check, then the dataskq sends the standard notice to all Admins, e.g.,

The service '${service}' on server your.host.com is currently down

In the event your script is called, all relevant logs will be loaded with the result:

try_to_fix_process(${service}): error: ${Script_Output}

or

try_to_fix_process(${service}): success: ${Script_Output}

Environment variables

• service : service name which is down

---

Examples

Prevent the Brute Force Monitor from reporting a specific email address

If you have an email address that is repeatedly attempting to access your server via invalid credentials and triggering BFM notifications, and you know that the person doing it is not malicious, then you can tell the BFM to skip that email address from being checked.

To do this, create the following custom script:

nano /usr/local/directadmin/scripts/custom/brute_force_notify_pre.sh

and in that script, add the following code:

#!/bin/sh
if [ "$type" = "User" ]; then
   if [ "$value" = "your@email.com" ]; then
       echo "exempt your@email.com";
       exit 1;
   fi
fi
exit 0;

Then chmod the script to 755 and correct the ownership:

chmod 755 /usr/local/directadmin/scripts/custom/brute_force_notify_pre.sh
chown diradmin. /usr/local/directadmin/scripts/custom/brute_force_notify_pre.sh

Note that this will only prevent reports for users/emails and will not prevent the blocking of the associated IPs (as the IP could be "attacking" some other account as well).

---

Automating the removal of Apache semaphores with ipcs/ipcrm via /usr/local/directadmin/scripts/custom/service_down_notice.sh

Full article here

If you routinely need to remove Apache semaphores with the ipcs/ipcrm tool, and if you cannot sort out why they keep building up, you may use the following code in the script /usr/local/directadmin/scripts/custom/service_down_notice.sh:

#!/bin/sh                                                
if [ "$service" != "httpd" ]; then

    EMAIL=your@email.com
    MAX_SEMAPHORES=15

    IPCS=/usr/bin/ipcs
    IPCRM=/usr/bin/ipcrm
    MAIL=/bin/mail

    COUNT=`${IPCS} | grep apache | wc -l`

    if [ "$COUNT" -le $MAX_SEMAPHORES ]; then
        #all is well, there are no semaphore build-ups.
        exit 0;
    fi

    #we have more than MAX_SEMAPHORES, so clear them out and restart Apache.

    LIST=/root/sem.txt

    ${IPCS} | grep apache | awk '{print $2}' > ${LIST}
    for i in `cat ${LIST}`; do
    {
        ${IPCRM} -s $i;
    };
    done;

    /etc/init.d/httpd restart

    TXT="${COUNT} semaphores cleared for apache for `hostname`"
    echo "${TXT}" | ${MAIL} -s "${TXT}" ${EMAIL}
    exit 1;

Fix the ownership and permissions:

chmod 700 /usr/local/directadmin/scripts/custom/service_down_notice.sh
chown diradmin. /usr/local/directadmin/scripts/custom/service_down_notice.sh