Version 1.57.2
Released: 2019-06-23
Ability to create DKIM records through DirectAdmin (SKINS) new
DKIM keys are only created with a domain autoimatically when dkim=1 is set, or by manually running a script.
This change will allow a 1 click-adding or removal of the keys and dns through DirectAdmin's interface.
TOKENS
DKIM=0|1 if dkim is enabled for this User (based on directadmin.conf and user.conf override)
DKIM_ENABLED=0|1 dkim is fully on for this domain, based on the presence of the dkim.private.key, used by exim for dkim headers.
If token DKIM=0 is set, DKIM_ENABLED will not be present.
FORMs
CMD_EMAIL_POP || CMD_API_EMAIL_POP
method: POST
action=set_dkim
domain=domain.com
disable=<anytext>
or
enable=<anytext>
Which will enable/disable DKIM both through the /etc/virtual/domain.com/dkim.*.key files, but also with adding/removing values from the DNS.
Output is the standard dynamic output for success/error.
NOTE: enabling DKIM here, if you had just disabled it will create all new keys.
Remote DNS servers would need to be updated to the new key values (copy them from your local zone if automatic dns clustering is not enabled)
SKINS
data/skins/enhanced/user/email/pop.html
<form action='?' method='POST'>
<input type='hidden' name='domain' value='|DOMAIN|'>
<input type='hidden' name='action' value='set_dkim'>
|*if DKIM_ENABLED="1"|
DKIM is enabled
<input class='mt20' type='submit' name='disable' value='Disable DKIM'>
|*endif|
|*if DKIM_ENABLED="0"|
DKIM is disabled
<input class='mt20' type='submit' name='enable' value='Enable DKIM'>
|*endif|
</form>
Restore: Allow restore of account if creator does not exist, as long a creator also being restored new
Previously, DA required a Reseller/Admin exist before you restore an account to it.
This change ensures that:
The restore files are sorted Admin, Resellers, Users, so they're restored in that order
The "creator exists" check has been modified to also check the current list, and allow a Restore of an account to a missing creator, as long as that creator is also in the current restore list.
force_ssl: global directadmin.conf option new
Currently, the force_ssl option is per-domain, off by default, and only set when a User enables it.
This change (off by default),lets you set:
force_ssl=1
into the directadmin.conf, so anytime the file:
/usr/local/directadmin/data/users/domains/domain.com.conf
is read by the Domain class, it will first put force_ssl=yes into the contain before reading it.
Any absence of the force_ssl setting in the domain.com.conf will force it to be enabled.
Design change when directadmin.conf force_ssl=1 is set, such that when disabling force_ssl, it will now instead set:
force_ssl=no
Previously (or with da.conf force_ssl=0), disabling force_ssl in the GUI would simply delete the force_ssl option entirely, as it defaulted to 0.
DKIM: Off by default, but allow User to enable DKIM on a domain new
After just adding this feature:
Ability to create DKIM records through DirectAdmin (SKINS)
a request came in to allow User DKIM control without it being on by default.
dkim=2
will be the setting for "off for new domains", so when adding a domain with dkim=2, DKIM will not be enabled.
The id=2046 can then be used to enable DKIM via the E-Mail Accounts page, below the email accounts table.
state-change require POST (SKINS)(SECURITY) new
Skins can now set this in their skin.conf:
state-change-require=POST
which is recommended.
When set, DA will only allow state-change operations though POST commands.
As some 3rd party skins may not be doing this already, it's off by default.
Only applies to session-based connections.
CMD_API calls that authenticate with each call are not affected.
Some custom skins may require a few changes to forms below to ensure setting the variable doesn't break current forms.
Some of the changes below are set in the table tokens, not skin html, so not all entries need addressing (if your skin uses table tokens)
===============
Internal code change areas, only enforced if skin has it enabled.
Confirmed User deletion: changed to POST
CMD_ALL_USER_SHOW: POST
CMD_USER_SHOW: POST
CMD_SHOW_SERVICES: changed table to use POST forms
CMD_SERVICE: requires POST
reseller/show_user.html: delete/suspend/unsuspend forms, POST
CMD_API_GET_SESSION: requires POST
===============
June 19: Update: Saving "Admin Settings" action=conf ended with a CMD_SERVICES GET redirect to restart directadmin. Changed to internally push the reload to the task.queue without the redirect.
iframe restrictions new
New default setting:
x_frame_options=sameorigin
which adds header to all requests:
X-Frame-Options: sameorigin
Plugin Translation: CMD_JSON_LANG new
New commands for CMD_JSON_LANG:
List all languages available for this plugin:
CMD_JSON_LANG?plugin=hello_world
Get that json language:
CMD_JSON_LANG?plugin=hello_world&lang=nl
============================
LANGUAGE FILES
They'll live here, for example, any of:
/usr/local/directadmin/plugins/hello_world/lang/en.po
/usr/local/directadmin/plugins/hello_world/lang/en.json
/usr/local/directadmin/plugins/hello_world/lang/en/lang.po
etc..
See the similar lang priority list for custom overrides
Priority order: lang.po, lang.json, custom/lang.po, custom/lang.json, etc
Ability to set directadmin.conf with: "./directadmin set name value" new
To simplify many things, including knowing you've actually set something correctly, instead of editing or adding a value in the directadmin.conf, you can very simply type:
cd /usr/local/directadmin
./directadmin set name value restart
for example:
./directadmin set dns_ttl 1 restart
The 4th restart option is optional.
You can omit it if you wish to restart yourself after setting other things.
directadmin will exit code 0, with:
name=value
if it succeeds.
Any errors will be non-zero, and output to stdout.
Added June 21th 2019.
letsencrypt=1 enabled by default for new installs new
All new installs of DirectAdmin will have LetsEncrypt enabled by default.
Existing installs can still enable it manually with this guide;
https://help.directadmin.com/item.php?id=648
Widgets: per-User/Reseller on/off for widgets new
The user.conf and reseller.conf now support the ability to control which widgets are allowed to be shown.
Options:
widgets=ON - blank/missing is the same default value
widgetes=OFF - all widgets disabled, not likely to get much use
widgets=ON:WGT_DB|WGT_PLUGINS_HELLO_WORLD - only allows these 2 widgets
widgets=OFF:WGT_DB - disables only WGT_DB, all other widgets are still allowed
At this time, it's not an interface/package item, but you can control it with the custom package items:
Ability to add your own package items (SKINS)
User Level Restore: SSL Certs, Domain Pointers not restored fixed
When a User restores their own backup via their User Level -> Create/Restore Backups, the SSL Certificates and Domain Pointers are not being restored.
These items are being restored if done via the Reseller Level restore, or Admin Level restore.
The backup/restore system has levels of restore code, and these items should be in the base-level, not a privileged restore.
As this changed the restore order for some things, extensive testing will be needed.
FileManager: saving protected directory: 404 fixed
The FileManager in DirectAdmin is chrooted, so any files needed at the time of data sending must be pre-loaded.
There are various checks to do this, and the logic was wrong when deciding to not pre-load data for json_dirs/json_files:
CMD_FILE_MANAGER action=json_dirs action=json_files action=json_all
which is likely where the bug was introduced.
The actual functionality was fine, the directory in question would still be protected (likely why it wasn't reported until now)
Debug mode would have given you:
fynamic(api=0, error=0):
text='Directory Protection Settings have been saved.'
result=''
Command::doCommand(/CMD_FILE_MANAGER) : finished
Command::run: finished /CMD_FILE_MANAGER
2019:06:01-03:16:53: *** Unable to read ./data/skins/enhanced/files_user.conf
Send::sendFail((null), (null))
Where the lookup of the files_user.conf should have happened in the preLoad, before anything was 'run', not after the run.
Based on the error, I'm actually surprised no other Filemanager functions were affected (this was the geneic global pre-load, while other functions make the preload call explicitly.
If other areas were affected but not reported (with same 404), then this fix would likely apply to them too (not aware of any).
One report came in that creating a zip is also affected.
Skip User redirect / to CMD_SHOW_DOMAIN if blank referer fixed
With regards to the blank referer check, it was reported that with either Firefox or Edge, when a User logs in from :2222/ (and not :2222/CMD_LOGIN),
and when the account only has 1 domain, the redirect from / to CMD_SHOW_DOMAIN?domain=domain.com can have a blank referer, thus triggering:
"The request was made without a referer header and will not be immediately followed."
Chrome (possibly others too), or other login paths don't seem to trigger it.
Solution is, that should there be no referer when the / request comes in, and if the redirection t CMD_SHOW_DOMAIN is going to happen, instead show the User domain listing page "/"
(usually only visible with more than 1 domain), except it will now show up for this one scenario.
Other browsers that correctly pass the referer header (as they should) will be redirected to CMD_SHOW_DOMAIN as usual.
T15882
Rspamd settings can break email filter fixed
Rspamd settings stored in /etc/virtual/domain.com/filter.conf can cause the word-filter to break if there are no blocked words, thus causing:
if
then
seen finish
endif
Work-around:
Add any ~long random word to be filtered which won't get caught, eg:
Block all e-mail containing the word: NotLikelyEverGoingToHappen
blank referer to window.location.href to desired page. fixed
Relating to the blank referer check for GET requests which show this error:
The request was made without a referer header and will not be immediately followed.
If you wish to follow this URL anyway, click the link to continue with the missing header
Although is protects you from remote pages that might not pass a referer, it was fairly annoying if you were just pasting a URL into the browser,
or if you were using a bookmark to try and load a page after you were already logged into your session.
This change is simple in that, if:
It's a GET request
there is no referer
You're logged in with a session
a redirect has not already happened
DA will then show you the same error page as before, but a very simple:
window.location.href = url
will be set, with the &redirect=yes added in, so-as to prevent loops.
The redirect will add the missing referer, and you'll see the page you're expecting to see, without needing to click anything. (Confirmed on Chrome anyway).
As XSS/ajax attacks are getting the page content, and not running them from the correct URL bar in your browser, if they try to run that redirect on the remote page,
the referer passed would then be that of the remote page, and would reject the request, immediately logging you out.
users_can_add_remove_domains: Admin or Reseller exemption fixed
Related to this feature:
Domains: user.conf to block domain adding/deleting
which lets you block the deletion (and removal) of a domain.
The issue is that this applies to everyone on the User Level, including Admins and Resellers.
This change allows you to add a mask to the directadmin.conf users_can_add_remove_domains value, to specify if these rules should exempt Admin and/or Resellers.
Current options:
0 - allow everyone to add/delete
1 - block everyone to delete
2 - block everyone to add and delete
for the mask, those will cover the first 3 bits (even though they could be done in 2, we'll use 3 for backwards compatibility)
Bits 4 and 5 will control the Reseller exemption, and Admin exemptions, respectively.
To exempt a Reseller, add 16 to your value.
To exempt an Admin, add 32 to your value.
(To exempt both, add 16+32 to your value)
For example, say you like use 2 to block both creation and deletion.
You want to allow Admins to create/delete, so you'd add 32, giving you 34:
users_can_add_remove_domains=34
meaning, Resellers are still blocked from creating/deleting the values.
ftp_list.php, ftp_upload.php: change --ftp-ssl to --ftp-ssl-reqd (SECURITY) fixed
Updated the two scripts at:
/usr/local/directadmin/scripts/ftp_list.php
/usr/local/directadmin/scripts/ftp_upload.php
to replace:
--ftp-ssl
to be:
--ftp-ssl-reqd
Reported case where the remote server didn't support TLS, thus the ftps backups were working through non-ftps connection.
This change will let the client know that FTPS is not actually working on the remote box, instead of silently succeeding with ftp.
The ftp_download.php script uses curl through php scripting, vs the other 2 which use command line curl with #!/bin/sh.
The ftp_download.php correctly failed when FTPS was selected, and how the issue was discovered.
FreeBSD DnsSec: remove randomdev option fixed
Reported bug:
https://forum.directadmin.com/showthread.php?t=57891
where new versions of dnssec-signzone no longer support the -r option.
Changed so that all FreeBSD boxes do not use it.
Tested on older versions to confirm it does not request user input.
PHP1_RELEASE and PHP2_RELEASE to always be the true value. (TEMPLATES) fixed
The templates use, for example:
PHP1_RELEASE=70
PHP2_RELEASE=73
To store the 1st and 2nd selected php versions for a given user. (although the 2nd is off by default in current DA versions).
So Users can decide any of the 4 php enabled versions to set in their 1st PHP1_RELEASE token.
The reason for this change is when the nginx_proxy option is used, nginx itself doesn't need php, since apache runs it.
So for the proxy templates, DA just set the version at 0, and the container ended up loading the token as 0.00000.
This change will instead also fill the nginx template's with the php version x10, so 56, 70, 73, etc.. instead of 0.0000.
There are other checks at the top which set OBD=, which were checking for 0.00000, but now check for 0... but should always be true with the version.
===================
TEMPLATES
data/templates/virtual_host2.conf
data/templates/user_virtual_host.conf
data/templates/openlitespeed_vhost.conf
data/templates/virtual_host2_secure.conf
data/templates/virtual_host2_sub.conf
data/templates/nginx_server.conf
data/templates/virtual_host2_secure_sub.conf
mail_sni: without secure_access_group, ensure mail can read the certificates fixed
Previously, only with secure_access_group enabled, would the cert/key files be chowned to diradmin:mail 640.
Without that, they were 600.
For apache, this is fine, but with mail_sni enabled, "exim" cannot read them correctly.
So if mail_sni is enabled, the diradmin:mail 640 will still be set.
Both internal DA code and the set_permissions.sh have been updated to ensure this is set.