Version 1.51.3

Released: 2017-02-25

Ability to disable awstats on a per-User account basis new

With the recent change to awstats processing where saved data is now owned by the User, this uses up more space.

Some Users might not want this, so this override allows you to shut off awstats 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:

awstats=0

to override the global setting.

This will hide the ability to select Awstats in:

CMD_USER_STATS

and will also fully disable:

CMD_AWSTATS

Most importantly, the awstats_process.sh will not be run for this User account.

Ability to disable DKIM on a per-User account or per-Domain basis new

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 (eg: 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:

  1. Delete the files:

/etc/virtual/DOMAIN.COM/dkim.public.key

/etc/virtual/DOMAIN.COM/dkim.private.key

  1. Delete the TXT records:

_domainkey

x._domainkey

Ensure da-popb4smtp gets restarted after update fixed

The update.sh script was previously calling the olders direct init.d/service method of restarting the da-popb4smtp binary.

This worked for many cases, but not all (eg: systemd might not have been handled for all cases)

That caused da-popb4smtp to possibly stop working with a new binary in place, but the old instance still running, resulting in lack of bandwidth logging for imap/pop.

Changed the dataskq to allow da-popb4smtp restarts via task.queue, and the update.sh will be changed accordingly, so the dataskq will ensure the da-popb4smtp gets restarted after an update.

awstats_process.sh + cagefs fixed

With the change to run awstats_process.sh, the security of cagefs caused a few issues:

  1. Couldn't access /usr/local/awstats/ to run the perl scripts to compute the stats.

  2. Couldn't access the user_logs to view the given User log for reading.

Numerous changes required in the awstats_process.sh.

A) Determine if the given User has cagefs enabled:

/usr/sbin/cagefsctl --list-enabled | grep username

B) Append /usr/local/awstats/ to the paths in:

/etc/cagefs/conf.d/directadmin.cfg

and run:

cagefsctl --update

run as the User, and check for:

/usr/local/awstats/tools/awstats_buildstaticpages.pl

if not readable, run:

cagefsctl --force-update

C) if the awstats.user folder is in the way, instead of aborting, remove it (as the User) and continue normally.

This should clean up any of the aborted run scenarios.

D) Delete the symbolic links in "awstats" before the copy to awstats.user, because cagefs doesn't like the User creating links pointing to root files. (so that cp makes a matching diff)

E) Add:

%/var/log/user_logs

to:

/etc/cagefs/cagefs.mp

and run:

cagefsctl --remount username

so that the log:

/var/log/user_logs/username/domain.com.log

is readable by the User, using the "split username" method:

https://docs.cloudlinux.com/index.html?split_by_username.html


WORKAROUND

If you'd like this fix now, you can either grab the pre-release binaries, or just grab the updated script:

wget -O /usr/local/directadmin/scripts/awstats_process.sh http://files1.directadmin.com/services/all/awstats/awstats_process.sh

and you can run it manually for any User if you want to update things now:

/usr/local/directadmin/scripts/awstats_process.sh USERNAME DOMAIN.COM

DNS: Reset Defaults: re-add DKIM records for hostname fixed

Fix for hitting the "Reset Defaults" button on the hostname.

Adds extra checks in DA to allow addking the DKIM records despite not being able to figure out which User it's for.

Because the /etc/virtual/zonename.com must still exist, it's still only going to be valid for local domains or the hostname.

Extra zone resets will not have their DKIM zones re-added because there are no ketys in /etc/virtual/zonname.com/* to work with.

Segfault relating to commands.allow fixed

If a User did not have commands.allow, but did have commands.deny, a segfault could occur.

BFM: WordPress Scanning: return code 302 (TEMPLATES) fixed

Update to brute_filter.list file, to add filter items wordpress3 and wordpress4.

Basically exact dupcliates of wordpress1/wordpress2, except they catch return code 302, instead of just 200.

Last Updated: