Version 1.53.1
Released: 2018-06-26
Ability to hide LetsEncrypt messages from Admins new
New option, internal default;
letsencrypt_renewal_notice_to_admins=1
which will email all Admins if there is an error (or if there is success when letsencrypt_renewal_success_notice=1 is set too)
If you don't want to be annoyed with clients that manage their SSL correctly and have their certificates expire, then set:
letsencrypt_renewal_notice_to_admins=0
in the directadmin.conf, and restart directadmin.
This will suppress all LetsEncrypt messages for the Admins.
Daily email limit in Show All Users (LANG) new
The cache file at:
/usr/local/directadmin/data/admin/show_all_users.cache
will now have an extra field for each User:
email_daily_limit=##
where it's set the limit for that User (/etc/virtual/limit or /etc/virtual/limit_fred)
Any errors in figuring out the limit, it will be set to -1, but this should be rare/never.
With that, the CMD_ALL_USER_SHOW page will add an extra value to the "Send E-Mail" column,
where if an email was sent today, then that column will look like this:
1 (Today: 1 / 100)
if not emails were sent today, then the column will look like
5
where "5" would be the sum of all emails sent this month, before today.
The limit is not shown if no email was sent today.
JSON
The previous format options were:
"sent_emails": "1:1",
or
"sent_emails": "5",
but the new format options will add a 3rd colon opiton:
"sent_emails": "1:1:100",
matching up with the above examples.
LANG
/usr/local/directadmin/data/skins/enhanced/lang/en/internal/command.txt
old:
498= (Today: %lld)
new:
498= (Today: %lld%s%s)
failure to update this file will result in it showing the hardcoded english version of the text because the number and order of % sequences must match, else it will be ignored.
API
as the call to CMD_API_ALL_USER_USAGE is a direct dump of the show_all_users.cache, this will just add the email_daily_limit=## for each User, as mentioned.
LAN Licensing system to do external checks to prevent need for eth0:0 new
As per the directadmin.com/lan.php guide, it can be tricky and annoying to get DirectAdmin install within a private network.
This change clears the biggest confusion with regards to that by doing an outbound check to confirm what your server IP is, should the standard eth0:0 style check fail.
This will allow DA to run even if step #2 from lan.php was missed.
However this affect DA's ability to do a local lookup of the server IP used for various things, like the |SERVER_IP| token in the templates, binding for updates, or any other area that DA needs to know the server IP.
In the event that the eth0:0 check fails, but the new remote check passes,
DA will internally set an IP override for the global function that does an IP lookup on the main ethernet_dev device, using the external lookup value instead.
(Just means that if you change your main server IP, DA should be restarted to figure out the new IP), since it's no longer a dynamic/live value.
Also, this check is ONLY done if the lan_ip value is set, most likely to your internal IP address, like 192.168.0.2, for example.
The main reason for adding this check is to allow some systems (eg: jail in FreeBSD) where only 1 IP is allowed, and it's the internal IP, preventing adding the external IP to eth0:0.
Note, if you have a proxy for outbound connections, then this tool won't work correctly, and you will need to ensure the licensed IP is added to eth0:0.
To clarify, I used eth0:0 as an example. the eth0 device name on your box may differ, so adjust as needed.
PhpMyAdmin 4.8.0 AuthLog support new
With the release of phpMyAdmin 4.8.0, the AuthLog feature has been added:
https://docs.phpmyadmin.net/en/latest/config.html#cfg_AuthLog
However, the logging format has been changed from ours via patch:
Apr 15 18:20:11:: pma auth user='adsf' status='mysql-denied' ip='192.168.1.2'
to the AuthLog format:
Apr 15 18:19:17 phpmyadmin: user denied: asdf (mysql-denied) from 192.168.1.2
The brute_filter.list does not support an option for ip_until= value of (end of string), so a NULL was added as an exception.
The new phpMyAdmin entry in the:
/usr/local/directadmin/data/templates/brute_filter.list
is:
phpmyadmin3=ip_after=%20from%20'&ip_until='&text=phpmyadmin:%20user%20denied:%20&user_after=user%20denied:%20'&user_until='%20(mysql-denied)
phpmyadmin4=ip_after=%20from%20&ip_until=NULL&text=phpmyadmin:%20user%20denied:%20&user_after=user%20denied:%20&user_until=%20(mysql-denied)
where ip_until=NULL lets DA use the IP until the end of the line, instead of needing to look for a character.
The phpmyadmin3 is used as a workaround so we can push 4.8.0 via CB2, until DA 1.53.1 is released.
CB2 will automatically add the phpmyadmin3 line to your brute_filter.list file, and will patch the file:
/var/www/html/phpMyAdmin-4.8.0/libraries/classes/Logging.php
so log entries look like this:
Apr 15 18:19:17 phpmyadmin: user denied: 'asdf' (mysql-denied) from '192.168.1.2'
simply adding single 'quotes' around the User and IP, so the ip_until option can look for ', since it's unable to look for the end of the line (until 1.53.1) using ip_until=NULL.
As a result, if you want to use phpMyAdmin 4.8.0, you should upgrade to DirectAdmin 1.53.1, so that phpMyAdmin brute force attacks can be scanned by DA.
The extra line in the brute_filter.list is not sufficient to allow brute force scanning.
dovecot_proxy for Multi-Server Setup email sync new
With the introduction of the E-Mail clustering option a while back:
Cluster: Remote E-Mail Account sync
This new feature allows you to add:
dovecot_proxy=1
to the directadmin.conf on both the local and remote servers that are involved in the email clustering.
When this is enabled, anytime a value is changed on the master server, it will locally save a dovecot proxy line to the local /etc/virtual/domain.com/passwd file.
With regards to the sync,
<a target=_blank href='[Cluster: Remote E-Mail Account sync](/changelog/version-1.48.0.html#cluster-remote-e-mail-account-sync)'>
this will push the info to the remote box</a>, as before, but with dovecot_proxy=1 enabled remotely,
it will also add the proxy into to the remote passwd file on the slave box, pointing to the master server's IP.
This has the effect, such that you can in theory have the remote slave box as mail.domain.com, with all emails arriving there with smtp.
On that slave box, when exim tries to save the email with lmtp, it will be redirected back to the master server to be saved, so email is saved locally.
Clients can connect to either the master or slave box to check their imap.
This task.queue option has been updated to rewrite the master data on the master box:
echo "action=rewrite&value=email_passwd" >> /usr/local/directadmin/data/task.queue
or:
echo "action=rewrite&value=email_passwd&user=fred" >> /usr/local/directadmin/data/task.queue
which makes one API per domain, pushing all master email accounts to the slave box.
On the slave, for each account, it will either add the account, or update the password, just as if a client had done it through a browser (except the master proxy IP is set).
This means all of the hook scripts are used, so the remote box can still use email_create_pre.sh, or email_change_pass_pre.sh normally (and post scripts)
NOTE: the "passwd" field will be the crypted value, and not the plaintext password.
If you rely on this, only the master will know the plaintext.
But you'll know it's crypted because passwd_is_crypted=1 will be set in your .sh scripts.
service "kill" new
CMD_SERVICE and CMD_API_SERVICE will now support a -9 SIGKILL signal, by passing action=kill in the given command.
It will still only be allowed on standard services listed in services.status.
The option will NOT show up in the GUI, but you can run it manually via GET, eg:
CMD_SERVICE?action=kill&service=httpd
or
CMD_API_SERVICE?action=kill&service=httpd
The command will use:
/usr/bin/killall -9 'httpd'
Should only be used in cases where you know what you're doing and actually need this functionality.
Do not affect php-fpm after installing a certificate new
As more websites are being encrypted, this means more regular certificate creation and changes.
This request more regular restart of apache, which by default, also includes php-fpm.
An exception has been added for any certificate change made (Normal, LetsEncrypt, Pasted, etc..) such that if you're running php-fpm, it will not be affected.
Only httpd/nginx will be restarted/reloaded/graceful (as applicable to your OS/setup), but php-fpm will be left alone.
As apache on systemd setups use graceful restarts, this means that without the php-fpm reload, it should make the restarts/reloads/graceful changes to apache nearly seamless (again, depending on your OS/setup)
The change to the task.queue goes from:
echo "action=httpd&value=restart&affect_php_fpm=no" >> /usr/local/directadmin/data/task.queue
(where restart might be something else, depending on your setup),
but the important part is the affect_php_fpm=no, which means any action done to httpd (or nginx or litespeed) , will no longer touch php-fpm along with it.
This only applies to the CMD_SSL and CMD_API_SSL changes.
The nightly tally will still do whatever it's going to do (php-fpm is not skipped), as suspensions or other changes as part of the tally may need it.
NOTE: the task.queue automatically removes duplicate entries.. so if you had this twice:
action=httpd&value=restart
action=httpd&value=restart
it would only be called once.
However, with it possibly being like this now:
action=httpd&value=restart
action=httpd&value=restart&affect_php_fpm=no
there might be some rare cases where httpd is restarted/reloaded twice in the same run (we may add extra code to address that... we'll see if it's needed).
There is logic to check for the "hardest" "stop > restart > reload", where the biggest> takes priority...
We'll continue to monitor if this case actually ever shows up.
Backup encryption (SKINS) new
Ability to encrypt backups from all Levels.
Disabled by default (0).
To enable, add:
allow_backup_encryption=1
to the directadmin.conf and restart directadmin.
Implemented to be GDPR compliant.
SCRIPTS
new files:
/usr/local/directadmin/scripts/encrypt_file.sh
/usr/local/directadmin/scripts/decrypt_file.sh
the custom folder can be used if you want to make alterations, just copy the script to the custom directory, and DA will use it instead.
API / JSON
The API cron output will include encryption_password=0|1 depending on the value, and will not include encryption_password if allow_backup_encrypt=1 is not enabled.
json cron output has an important change where the "where" value, which used to be:
"where": "ftp://127.0.0.1:21/May"
is now:
"where":
{
"encryption_password": "0",
"path": "ftp://127.0.0.1:21/May"
},
The "where" is now always an array, and longer just a string.
This gives us more options should we need to make changes later.
Like the API, if allow_backup_encrypt=1 is not enabled. then the encryption_password won't be generated at all.
Applies to both CMD_ADMIN_BACKUP and CMD_USER_BACKUP
If enabled, the settings array will have:
allow_backup_encryption=1
and encryption_password will store the current password, used for auto-fill of encryption/decryption fields.
SKINS:
admin/admin_backup.html
reseller/backups.html
admin/admin_backup_modify.html
reseller/backup_modify.html
Added this below the append path tr:
|*if ALLOW_BACKUP_ENCRYPTION="1"|
<tr>
<td class=listtitle></td>
<td class=listtitle>
|LANG_BACKUP_ENCRYPTION|
</td>
</tr>
<tr>
<td></td>
<td>
<table cellpadding=0 cellspacing=1 width=100%>
<tr>
<td class=list align=right>|LANG_PASSWORD|:</td>
<td class=list>
<input type=password name='encryption_password' value="|encryption_password|" placeholder='|LANG_OMIT_NO_ENC|' autocomplete="new-password">
</td>
</tr>
</table>
</td>
</tr>
|*endif|
and farther down for the restore, after |FILES|</div>, add:
|*if ALLOW_BACKUP_ENCRYPTION="1"|
<table width=100% cellspacing=1 cellpadding=0>
<tr>
<td class=listtitle>
|LANG_BACKUP_DECRYPTION|
</td>
</tr>
<tr>
<td>
<table cellpadding=0 cellspacing=1 width=100%>
<tr>
<td class=list align=right>|LANG_PASSWORD|:</td>
<td class=list>
<input type=password name='encryption_password' value="|encryption_password|" autocomplete="new-password">
</td>
</tr>
</table>
</td>
</tr>
</table>
|*endif|
style.css
add class:
.green_lock {
FONT-SIZE: 12pt;
color: transparent;
text-shadow: 0 0 0 #009900;
}
as there "Where" column in the backup cron list will include the actual lock character.
However, it's a special unicode character, thus cannot have it's color changed in the normal way, so we make it transparent, then shadow it with the color we want.
Per-record TTL changes (SKINS) new
BETA
TODO: power_user/default skins.
For now, internal default is off:
dns_ttl=0
so to enable it, add;
dns_ttl=1
to the directadmin.conf and restart directadmin.
If a domain as a ttl_override enabled, the override will do just that.. override any per-record settings.
This could be a quick way to reset all ttl values to a given value, if needed (then switch it back to the default ttl)
SKINS
admin/dns_admin_control.html
user/dns_control.html
user/dns_mx_control.html
The DNS_ROWS value will have a 2nd column being the current TTL value of that record.
As a result, the table needs to 'grow' wider (things like colspan)
Also set a BLANK_TD, but padding it to <td></td> when dns_ttl=1.
Top area after the Name td, but before the Value td.
|?TTL_INPUT=|
|?COLSPAN=4|
|?BLANK_TD=|
|*if DNS_TTL="yes"|
|?COLSPAN=5|
|?TTL_INPUT=<td class=list align=center><input type=text name=ttl size=6 value="\`TTL_VALUE\`" placeholder="\`LANG_TTL_BLANK_FOR_DEFAULT\`" title="\`LANG_TTL_BLANK_FOR_DEFAULT\`"></td>|
|?BLANK_TD=<td class=list></td>|
<td class=listtitle align=center >|LANG_TTL|</td >
|*endif|
Pad tables with |BLANK_TD| as needed.
Insert |TTL_INPUT| into each record "Add" form, between the name and value. It will be blank if dns_ttl=0, but filled with the input field if enabled.
Ability to add/delete dns records from the task.queue new
Very raw feature with limited user validation. Use very carefully.
Samples, add/delete:
echo 'action=dns&do=add&domain=domain.com&type=A&name=mail&value=1.2.3.4&ttl=500' >> /usr/local/directadmin/data/task.queue
echo 'action=dns&do=delete&domain=domain.com&type=A&name=mail&value=1.2.3.4' >> /usr/local/directadmin/data/task.queue
echo 'action=dns&do=delete&domain=domain.com&type=TXT&name=_acme-challenge&value=*' >> /usr/local/directadmin/data/task.queue
Note, that the do=delete does require you pass the "value" as most record types allow duplicate names, thus the value is used to differentiate the records.
The ttl can optionally be passed during do=add, but is not required. If dns_ttl=1 is not enabled, the ttl value will have no effect.
For do=delete, if value=* then it will delete all records of that type, with the given name=.
So in the example, it will delete all TXT records from domain.com, that have a left-side name of _acme-challenge.
This will not catch any full records, like "_acme-challenge.domain.com." as the tool is quite basic.
This method saves needing an API call, and supports all of the clustering pushes.
Note the type must be an upper case character, one of:
A, NS, MX, CNAME, PTR, TXT, AAAA, SRV, SPF, TLSA, CAA, DS
Note: if some features are not enabled, that given type might not get added to the db file, eg:
dns_tlsa=1
dns_caa=1
dns_spf=1
NOTE for NS records:
Due to very old backwards compatibility, the NS record name and values are swapped.
Use the left-side name (domain.com) as the "value" and the right side value as the "name" (ns2.domain.com.)
DNSSEC: dnssec_sign_post.sh new
Custom script, which you can create here:
/usr/local/directadmin/scripts/custom/dnssec_sign_post.sh
If it exists, this script is called after a zone is signed, but before any clustering sends it off to the slave dns servers.
Variables are:
domain=domain.com
return_code=0|1
do_cluster=0|1
The return_code is the success/failure of the actual signing. 1 is good, 0 means there was an error.
The do_cluster is set to 1 if directadmin.conf cluster=1 AND it's a local trigger.
Remote slaves get the raw copy anyway, so do_cluster=0 might only be seen if directadmin.conf cluster=0..
The only remote case would be remote per-record changes.. which I cannot recall ever doing.
Possibly in the future, so just be sure you handle it if you need to do different actions based on this value. (eg: dns-01 wildcard LetsEncrypt requests)
Exit status:
If all is well, and you want the clustering (if enabled) to proceed, use exit code 0
If there is an error and you need it to abort the clustering push, then use any non-zero value, and the signing function call will abort after the local file is signed, but before the clustering push happens.
LetsEncrypt wildcards for free *.domain.com SSL certificates (SKINS) new
BETA
The LetsEncrypt team has added support for free wildcard domain certificates.
We've updated the letsencrypt.sh script to version 1.1.0-beta, as well as updated the binaries/GUI to support the new option.
The wildcard version uses dns-01 checks, unlike the old method which uses http-01 checks.
So to use wildcards, the dns must be reactive quickly, as specific records need to be added, named restarted, all in one sequence to make it work.
This requires the latest DA binaries, and the new letsencrypt.sh script, as well as a skin that supports the wildcard options.
REQUIREMENT - PLEASE ENABLE:
dns_ttl=1
If dns_ttl=1 is not set, then wildcards will be disabled.
At the time of this writing, dns_ttl=0 is the default so must be added to the directadmin.conf
It's plausible that we enable dns_ttl=1 by default for the next release pending testing.
SKINS
user/ssl.html
The main change in regards as to what to pass to DA is a new checkbox:
wildcard=yes
if it's not passed (or not 'yes') then it uses the old le_select0 options.
If wildcard=yes is passed, then the options to pass are now called:
le_wc_select0=*.domain.com
The reset of the changes are all javascrip to show/hide the settings to try and keep confusion to a minimum.
NOTE: with wildcard=yes, the common "name" should still be set to "www.domain.com".
Only the checkboxes in the table below (le_wc_select#) will control which wildcard domain values are added.
You must select *.domain.com for the main www.domain.com value. You cannot select only a *.pointer.com, and leave the main *.domain.com un-checked, as the naming on disk uses:
domain.com.san_config
and the settings inside wouldn't make much sense if the main domain was not part of it.
So it's the same as before, just clarifies that the rule still applies to wildcards.
Also add:
<input type=hidden name=background value="auto">
to the CMD_SSL form, relating to running it in the background for tasks that can take longer to run:
LetsEncrypt ability to process User requests in the background (LANG)(SKIN)
GUI option for per-User awstats new
Relating to this feature:
Ability to disable awstats on a per-User account basis
where the User can have their awstats disabled by user.conf, this option will allow the User to disable it themselves via the GUI in their account settings.
To save the data, it's similar to the other per-item options:
CMD_CHANGE_INFO
awstats=anytext
awstatsvalue=0|1
For json, just include json=yes.
NOTE:
Awstats must be globally enabled in order for this to work.
You cannot have awstats=0 globally, and awstats=1 in the user.conf, that won't trigger any parsing.
Option to not delete domain web data with domain (LANG) new
When a User deletes one of their domains, the confirmation screen will now have a checkbox at the bottom, checked by default, asking to delete the web data.
If checked, the directory:
/home/user/domains/domain.com
is deleted, just as before.
If un-checked, the directory:
/home/user/domains/domain.com
will not be removed along with domain.com
However, all other areas, like email data, will still be removed.
LANG
lang/en/internal/command.txt
597=Delete web data
598=Preserving the web data only applies to /domains/domain.com. Other areas like E-Mail data will not be preserved.
Functionality
Because a checkbox is not passed if unchecked, and to maintain backwards compatibility, the form will pass:
delete_data_aware=yes
for all domain deletions.
The you can either pass:
delete_data=yes
or not pass it at all to save the data (or delete_data=no is also fine.. as it explicitly checks for 'yes').
If delete_data_aware=yes is not included, then the checkbox will have no effect, and the data will be removed as before.
LetsEncrypt ability to process User requests in the background (LANG)(SKIN) new
Include:
background=yes
with the LetsEncrypt requests, and DA will attempt to run them in the background, or include:
background=auto
and it only sends the requests that can go to the background (at this time, just the LetsEncrypt cert requests), in case you just want to blindly attach the variable to your form for all 'Save's.
Newer wildcard requests take longer due to changes to the dns system, which could cause confusion or timeouts if run in the foreground.
If there are any immediate errors, they'll still be send to the browser, as before, else the usual success message will be sent but with info about sending the request to the background.
Any result will end up in the Message System.. good or bad.
LANG:
lang/en/internal/ssl.txt
60=Your request will run in the background. Once completed, you'll be notified in the Message System.
61=LetsEncrypt request successful
62=Error with LetsEncrypt request
Where 61 and 62 will be the subject lines, good or bad, for the Message System notice.
SKIN:
user/ssl.html
added:
<input type=hidden name=background value="auto">
to the CMD_SSL form.
named_action_post.sh & taskq_dns_post.sh new
Custom scripts which can be created:
/usr/local/directadmin/scripts/custom/named_action_post.sh
/usr/local/directadmin/scripts/custom/taskq_dns_post.sh
named_action_post.sh
If it exists, it will be called anytime DA makes any call to the named service.
This applies to start, stop, restart, reload, etc..
Varisble passed will be:
action=X
immediate=0|1
where X is the given action that was just performed.
The immediate variable indicates if it's a task.queue action 0, or 1 for immediate reloads, mainly for LetsEncrypt wildcards.
This can be used in case you need to trigger something anytime a local change is done on the DA side where named is altered.
Usually, you'd just want to do it for the reload action, eg:
#!/bin/sh
if [ "$action" = "reload" ]; then
#do your action.
#if error, echo what went wrong and exit non-zero
fi
exit 0;
The exit code does not current affect any code logic, but if you exit with a non-zero result, the output will be saved to:
/var/log/directadmin/errortaskq.log
if the exist code is 0 AND there is something output, then DA will log it to system.log.
So if everything went well, do not output anything, as that would just add more code to the system.log
taskq_dns_post.sh
If the taskq_dns_post.sh exists, it will be called, and all data that was passed to the task.queue for the:
action=dns&do=add...
action=dns&do=delete...
style calls, will also be passed to this script.
The exit code behavior is the same as named_action_post.sh.
If all goes well, exit 0. Any issue echo some text and exit non-zero.
password placeholder in admin/reseller backups new
New internal directadmin.conf option:
password_placeholder=XXXXXXXXXX
where you can change the value to something else.
The value will be put into the
<input type=password name=ftp_password value="XXXXXX">
instead of the plaintext ftp_password or plaintext encryption_password.
Anytime the form is saved, either creation of a new cron, ftp listing update.. or modification of a cron,
the existing back-end password will be loaded into DA internally, decrypted, and will replace the XXXX string with the actual value.
This should improve security, as the password are no longer saved in the html as plaintext.
The reason for making a password_placeholder variable, is in case someone actually wants to use a password value of XXXXXXXXX..
They could then set password_placeholder=YYYYYYYYY for example.
Of course, using XXXXXXXXX for a password is a terrible idea anyway, so don't do it 😉
No skin changes should be needed, as DA figures things out internally.
The calls to the task.queue will still use the base64 password, as it's translated internally in DA before it gets to the task.queue.
If this is buggy or you like having the plaintext in the form, the add the empty value to the directadmin.conf:
password_placeholder=
and DA will set it internally as (null), and things should work as before.
New option: letsencrypt_renewal_error_to_users=1 new
New internal default setting:
letsencrypt_renewal_error_to_users=1
used to continue sending LetsEncrypt error messages to Users.
However, the Admin be fully in control of User LetsEncrypt certificates, in which case sending the message to the User might be confusing.
To send errors only to the Admin, add these values in the directadmin.conf:
letsencrypt_renewal_error_to_users=0
letsencrypt_renewal_notice_to_admins=1
The letsencrypt_renewal_notice_to_admins=1 should be set internally already, but change it to 1 if it's set to 0 in the directadmin.conf.
If both options are set to 0, DA will add it to the errortaskq.log.
php_home_tmp_session_save_path (TEMPLATE) new
For systemd boxes, their php-fpm70.service file (for example) will have:
PrivateTmp=true
Anytime php-fpm70 is restarted, this virtual tmp directory could be purged (not 100% sure on the conditions for this).
Instead of setting PrivateTmp=false, we opted for a more User oriented solution to use:
php_admin_value[session.save_path] = /home/username/tmp
set in the per-User:
/usr/local/directadmin/data/users/USER/php/php-fpm70.conf
via the template change in:
/usr/local/directadmin/data/templates/php-fpm.conf
using:
|*if PHP_SESSION_SAVE_PATH!=""|
php_admin_value\[session.save_path\] = |PHP_SESSION_SAVE_PATH|
|*endif|
The internal default will depend entirely if the box supports systemd by default.
For CentOS 7 or newer Debian versions, the default will be:
php_home_tmp_session_save_path=1
for older init.d OSs the default will be:
php_home_tmp_session_save_path=0
At the moment, this only applies to php-fpm instances, as we've not had other reports of mod_php (for example) losing it's sessions when httpd uses PrivateTmp=true.
Not sure of the difference there, but if we encounter any such reports, we can expand the setting to mod_php, etc..
At any time, you can disable the feature by adding:
php_home_tmp_session_save_path=0
to the directadmin.conf, restart DA, and also issue a config rewrite:
cd /usr/local/directadmin/custombuild
./build rewrite_confs
User Level License Verification: CMD_LICENSE_VERIFY new
Users can now verify that their provider's license is valid, by going to:
User Level -> Site Summary / Statistics / Logs -> DirectAdmin License: Verify
button will be at the bottom, hardcoded into the table, to intentionally make it difficult to remove.
This is a real-time check and is rate-limited per-User.
If a User wants to validate their provider's license without using the software, they can instead go directly to our website:
https://license.directadmin.com/
type in the server's IP and check it there.
Note, the IP entered should be the server's main/licensed IP, typically whatever the server's hostname resolves to.
Another way to find it (if you're using the default local dns settings) is to take it from the spf TXT record, as DA enters the ip4:1.2.3.4 value there for the server IP.
The license.directadmin.com is rate limited.
JSON
will have extra variables in the standard dynamic output, including:
serverip=1.2.3.4
url=https://license.directadmin.com/?action=check&ip=1.2.3.4
a_href=Confirm results on the <a href="https://license.directadmin.com/?action=check&ip=1.2.3.4">DirectAdmin Website</a>
task.queue for deleting a zone new
You can now delete a zone via the task.queue:
echo "action=dns&do=delete_zone&domain=domain.com" >> /usr/local/directadmin/data/task.queue
The custom hook taskq_dns_post.sh will be called, similar to other action=dns calls.
nginx 1.15.0: remove "ssl on;" (TEMPLATES) new
Changes in the nginx 1.15.0 release remove support for the "ssl on;" and rely on "ssl" being part of the "listen" line.
https://nginx.org/en/CHANGES
===========
Changes with nginx 1.15.0 05 Jun 2018
- Change: the "ssl" directive is deprecated; the "ssl" parameter of the
- "listen" directive should be used instead.
===========
Older versions of nginx still work without the "ssl on;" option, assuming "listen .... ssl..." is set.
Confirmed/tested on 1.13.12, but in theory should go back as far as "0.7.14", when support for ssl in listen was added.
TEMPLATES
/data/templates/nginx_server_secure.conf
/data/templates/nginx_ips.conf
/data/templates/nginx_server_secure_sub.conf
/data/templates/nginx_server_redirect.conf
and CustomBuild 2.0 rev 1878:
/configure/nginx/conf/nginx-vhosts.conf
/configure/nginx_reverse/conf/nginx-vhosts.conf
custom Blacklisted IP page (TEMPLATE) new
Optional custom template file:
/usr/local/directadmin/data/templates/custom/blacklisted_ip.html
if that file exists and the client IP is blacklisted, this content type text/html page will be sent to the client, instead of the hard-coded:
Your IP is blacklisted
http://help.directadmin.com/item.php?id=306
No token options at this time.
Add connection info into the high load notice (SCRIPTS)(TEMPLATES) new
Add connection info into the connection notice.
SCRIPT
new script 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 cust copy can be used at:
/usr/local/directadmin/scripts/custom/connection_info.sh
to fully override the default.
OR
a hook is called from within the script, which can be created here, so you can include your own output to the Admin message:
/usr/local/directadmin/scripts/custom/connection_info_post.sh
so 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.
TEMPLATE
/usr/local/directadmin/data/templates/load_check_message.txt
has new token;
|CONN_INFO|
just below the |TOP|, to be filled with the output from the connection_info.sh script.
T11709
Plugins can add "vue" files new
A new folder can now be created to provide vue files, for the evolution skin.
The path would be:
/usr/local/directadmin/plugins/YOURPLUGINNAME/vue/
where you can put any .js file you want.
This /vue/ is very similar to the current /images/, as it uses the same code to send, so it only sends static files, they won't be parsed.
check_partitions_notice_post.sh.sh new
Custom hook script which can be created here:
/usr/local/directadmin/scripts/custom/check_partitions_notice_post.sh.sh
and 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.
dynamic output for APIs to use URL encoding fixed
The encoding of characters for API output in dynamic errors was previous html encoding, eg:
-
when it should have been:
%2D
for the example dash character, but applies to all encoding.
This means all dynamic type output for API calls will have the encoding changed to the proper format.
This bug was found while adding extra code to any CMD_API call where the two-factor auth or security questions were in play.
The previous result would be the html form being sent to ask for the code or question.
The new result for this case will look more like:
error=1&text=Two%2DStep%20auth%20failure&details=two%2Dstep%20auth%20required%3A%20use%20a%20Login%20Key
with http status:
401 Unauthorized
this is useful for the Multi-Server Setup, for cases like a call to CMD_API_LOGIN_TEST (or any CMD_API call),
where instead of getting a proper login error, it was getting the html page.
This will also give you a clearer result/output when using the "Test Connection(s)" button on the Multi-Server Setup page.
Restore with direct_crons=1 does not restore crons fixed
If you have direct_crons=1 during a restore, the backed up crontab.conf will not be saved.
Fix was to force the re-write of the copied crontab.conf into the "crontab -u fred /usr/local/directadmin/data/users/fred/crontab.conf.tmp" command.
Only restart php-fpm once with nginx proxy setup. fixed
Anytime httpd is restarted, php-fpm is restarted.
Anytime nginx is restarted, php-fpm is restarted.
With the proxy setup, both httpd and nginx are restarted, so php-fpm was restarted twice in very short succession.
The 2nd issue of the graceful restart happened during it's first (re)startup which broke it.
The dataskq removes duplicates from the task.queue file, so we'll know that httpd and nginx restarts only happen once,
but new code has been added to only restart php-fpm once within a 5 second span.
Remove system accounts from da_roundcube fixed
When a system account is removed from DirectAdmin, this will also remove it from the da_roundcube.users table.
Other da_roundcube tables use a cascade feature, so they are automatically cleaned.
Virtual Email accounts were already cleared from the da_roundcube.users table when delete from DA.
Prevent duplicate forwarder values fixed
When creating or modifying a forwarder, if the list of forwarded emails/pipes/etc have any duplicates, they'll be removed.
This is done with a contain class with sorting, so this has the side-effect of the values always being in alphabetical order (shouldn't affect anything)
local_data and local_mail values in CMD_DNS_ADMIN?json=yes removed font tag fixed
Bug where the yes/no values in the json output had <font> tags wrapped around them, and also were translated, meaning the value might not be in english.
Fixed by removing the tags for json=yes, and using hardcoded yes or no values, eg:
"205":
{
"domain": "testing.com",
"local_data": "yes",
"local_mail": "yes"
},
eg:
CMD_DNS_ADMIN?sort1=1&page=5&json=yes
move_domain.sh: update user.conf default domain= value fixed
The move_domain.sh will move a domain from one User to another.
If the moved domain was the "default" domain for the old User, the user.conf was not previously being updated.
This caused issues in the old User's httpd.conf, as the ~username php_admin_value sendmail_path was still showing the old domain value for the email.
Also the /home/olduser/publc_html link would need to be updated as well.
The new default domain for the old User will be the first domain in their list, if there is one.
Else the domain= value will be blank (which is fine) and the public_html link will be left alone until a new domain is added to set it to the new default.
Restore of per-domain cust_httpd.1 with nginx_proxy=1 fixed
If you're using nginx_proxy=1 and have custom tokens set in the:
Admin Level -> Custom Httpd Config
the restore did not handle all cases.
The case in question was where the names were mixed up, so (for example) if you had both:
cust_httpd.1
cust_nginx.1
only the cust_nginx.1 was restored.