Version 1.55.0
Released: 2018-12-07
mail_sni=1 enabled by default for new installs new
Relating to the dovecot/exim mail_sni feature;
mail_sni for dovecot and exim sni certificates
This feature will now be enabled by default for new installs.
This will be done by having:
mail_sni=1
present by default in the data/templates/directadmin.conf.
As the internal default will still be:
mail_sni=0
If you don't have it set in your directadmin.conf, it will be still be off.
Existing installs won't be affected by the template change, since it's only used for new installs.
It can still be enabled normally via id=2019.
CMD_CHANGE_INFO: set multiple values at the same time new
New option with the:
CMD_CHANGE_INFO
call that allows you to set multiple values at the same time.
First, include this in the request:
set_multiple=yes
which then lets you set more than 1 value.
If any are no included, that's fine, it will only set what's passed.
name=<anything>
nvalue=Bob
email=<anything>
evalue=e@mail.com
language=<anything>
lvalue=en
(session=yes) optional to set it only in the session file, not user.conf
skin=<anything>
skinvalue=evolution
awstats=<anything>
awstatsvalues=0|1
zoom=<anything>
zvalue=105
If there are any errors along the way, it may abort prematurely, or may continue, depending on the error.
Basically, if you get an error, don't assume anything was done.
If any error did happen, the user_info_modify_post.sh will not be called, even if some values might have been set.
So if you get errors, ensure you inform the User clearly they it might be wise to then run it again, but on a per-item basis again,
to ensure everything is set, and the user_info_modify_post.sh is correctly called for each of those items.
Evolution: Option for Reseller config.json to not be inherited from Admin new
In the sake of branding, some Resellers might not want to see the customizations set by the Admin.
Customization in evolution are stored in a config.json file, per Reseller/Admin account.
If the current account does not have one, its "creator" is queried to see if they have one.
In this case, a Reseller's creator is often "admin", thus if the current Reseller does not have a config.json customization override (which they won't, by default), the admin's config.json is shown.
This is not always desired.
New option, internal default:
reseller_use_admin_config_json=1
which can be disabled by adding:
reseller_use_admin_config_json=0
to the directadmin.conf
OR
by adding:
reseller_use_admin_config_json=yes|no
to the Reseller's file:
/usr/local/directadmin/data/users/RESELLERNAME/reseller.conf
The reseller.conf trumps the directadmin.conf.
When DA reads it as 0, then should the current Reseller not have a config.json, the 'creator' config.json is not searched for, and all skins defaults are used.
Although it's not a standard package/account option, you can pass:
reseller_user_admin_config_json=yes|no
with Reseller creation:
CMD_ACCOUNT_RESELLER
or modification:
CMD_MODIFY_RESELLER
The yes|no reseller.conf, vs 1|0 directadmin.conf are just in case we do ever add it to packages, then it will be correctly supported.
JSON to list commands.allow/deny new
Evo needs the ability to know which commands shouldn't be allowed before they're shown/used.
If there are commands.deny or commands.allow in effect for the current login (being per-user, global or login key), the restrictions/allowances will be included in:
CMD_JSON_LANG?json=yes&domain=domain.com&request=global
You'll always see this option:
has_cmd_overrides=yes|no
and if yes, then more info will be provided in:
cmd_overrides
eg:
"cmd_overrides":
{
"commands.allow":
[
"CMD_ALL_USER_SHOW",
"CMD_JSON_LANG",
"CMD_LOGOUT",
"CMD_RESELLER_HISTORY ",
"CMD_RESELLER_STATS",
"CMD_SHOW_RESELLER",
"CMD_SHOW_USER",
"CMD_USER_HISTORY",
"CMD_USER_STATS"
],
"commands.deny":
[
]
},
"has_cmd_overrides": "yes"
Just as an example, where this would block all commands, except the listed commands.allow.
Note, only 1 of commands.allow/commands.deny might be set with has_cmd_overrides, if only one of the 2 files exists.
The commands.deny trumps commands.allow, so in your logic, check that first to decide if a command is blocked.
If it's not denied, if the commands.allow exists, then the command MUST exist in that file.
If commands.allow is set, but empty, all commands are blocked (and you wouldn't be able to view CMD_JSON_LANG anyway)
So if you have commands in command.deny, but commands.allow is not set at all, then all commands are allowed, except the values in commands.deny.
If commands.allow is set, but commands.deny is not set, then only the values in commands.allow are allowed.
If both are set, commands.deny wins over commands.allow.
Note, the bulk commands.* options:
ALL_USER
ALL_RESELLER
ALL_ADMIN
are removed and converted into the full list of values, so you don't need to worry about knowing which command belongs to which level.
These 3 ALL_* values won't be listed.
Just check the CMD_ you'r looking at against these lists, if they're set.
Use TXT DNS for current DA version new
In an attempt to be more efficient at allowing all DA boxes to know which version is the most recent, we've added a new TXT record:
version.directadmin.com. 14400 IN TXT "v=1.54.1&f=1.541000"
where DA will try that first, before attempting to connect to /ver.php.
This will be far more efficient, since a lookup has to be done anyway to determine the A record for directadmin.com, before doing the high-overhead apache connection to check it.
So we just skip that A lookup, and instead do a TXT lookup on version.directadmin.com, giving the version all in one clean hit.
This has the added benefit of caching the values in your /etc/resolv.conf name-servers, so future hits won't even touch directadmin.com.
Note for systems where DA previously connection "bind" to a proper IP (say the lan_ip value wasn't set if you're on a LAN), it used to show:
unable to connect
For the version in Admin Level -> Licenses/Updates
with this change, unless there is a DNS value, you won't be able to use the "unable to connect" version to determine if your lan_ip is setup incorrectly or not.
Prevent Reseller from customizing/branding skin new
New internal value, with default:
reseller_can_customize_config_json=1
where, if you set this to 0, Resellers will not be able to access the skin customization page, nor save customizations.
Admins are not affected by this setting.
SSH Keys Management (SKINS) new
New User command:
CMD_SSH_KEYS
CMD_API_SSH_KEYS
Ability to manage ssh keys via User Level, and by Admins/Resellers Levels.
This command is not domain dependent.
More info to come.
Benefits:
Ability to ssh to other servers without needing a password.
Ability to allow others to ssh to your account, without giving them a password (they give you their key)
Possibly cronjobs for rsync to push files to remote accounts seamlessly.
ACTIONS
CREATE:
action=create
id=id (any name you want to give it for id_rsa.pub or id=test for test_rsa.pub).
comment=somesimplecomment
(passwd=secretpass OR blank/empty for no password on the key, useful for script automation.)
(passwd2=secretpass)
type=rsa
keysize=1024|2048|4096 (default selected 2048)
Note if you use name=id, this will be what's used for outbound ssh connections.
The remote server would need the id_rsa.pub file on their end.
For the type, use rsa. The other option of dsa is dropped with OpenSSH 7.0+ so DA won't create it but will show it if exists, and rsa1 also not supported all.
GLOBAL CREATE
ability for a Reseller to add a key and apply it to all of their Users.
Option to also apply it to all future Users, when created.
May ignore the "ssh" option for Users, adding the key regardless.
The key would not work until ssh is enabled for the given account (shell needs to be set by DA, and AllowUsers set by DA in sshd_config for that User)
Similarly, Admins added to all Resellers/Users created by them... perhaps an option for every single account on the box.
The global list is stored at:
/home/reseller/.ssh/global_keys
with one key per line, eg:
id1_rsa=who=all
id2_rsa=who=selected&select0=useryes
id2_rsa=who=except&select0=userno
where "who=all" means it's added to all Users below this Reseller, and will be added to all Users when they're created.
Similarly, who=selected means only the selected Users are affected. Newly created Users would not get this key.
Lastly, who=except would mean all Users except the selected Users. Newly created Users would get this key.
to set a current id_rsa.pub file to be globa, use:
action=set_global
id=id_rsa
who=all|selected|except
(select0=fred, select1=george)
AUTHORIZE:
This will add the given pub info to the ~/.ssh/authorized_keys, either from an existing id_rsa.pub, or pasted value.
action=authorize
type=paste
text=ssh-rsa AADATAQ== test@comment.com
or:
type=id
id=id
(option0=name%3DOPTNAME%26value%3DOPTVALUE)
(option1=name%3DOPTNAME)
Regarding the option0, option1, they are optional.
They specify the key's options such as IP or command restrctions. See man sshd(8) for info on the options/values.
Note the %3D is the encoding of = and %26 is the encoding of &. The option0 entries are double-encoded in the final post string.
The options that do not have values must not have values set, and options that DO have values MUST have values set (again, 'man sshd')
eg:
json=yes&action=authorize&type=id&id=demo_rsa&option0=name%3Dfrom%26value%3d1.2.3.4
or (used by Enhanced)
action=select
authorize=<anything>
select0=e3:66:d5:37:f0:a8:35:a6:6c:55:d6:4b:56:68:0e:31
(select1=68:58:e9:08:76:91:f4:9e:28:1f:d2:39:eb:c2:bb:69)
DELETE
action=delete
type=authorized_keys|public
select0=e3:66:d5:37:f0:a8:35:a6:6c:55:d6:4b:56:68:0e:31
(select1=68:58:e9:08:76:91:f4:9e:28:1f:d2:39:eb:c2:bb:69)
where type=authorized_keys, removed the entry from the:
~/.ssh/authorized_keys
and type=public removes the 2 files:
~/.ssh/name_rsa
~/.ssh/name_rsa.pub
the type=public has an option value (check box, enabled by default):
clean=yes
it will also delete the keys with that matching fingerprint from the authorized_keys file.
Note that newer OS's will show a different SHA fingerprint format.
This doesn't change anything as it's only used as an index.
JSON
CMD_SSH_KEYS?json=yes&enabled_users=yes
with optional &fingerprint=07:af:73🇩🇪8f🆎59:d3:f7:49:50:72:c1:48:51:1d
to only show this global_keys entry.
By default, you should use enabled_users=no, for a faster main page load for Resellers+.
returns:
{
"authorized_keys":
{
"07:af:73:de:8f:ab:59:d3:f7:49:50:72:c1:48:51:1d":
{
"comment": "descriptive@comment.com",
"data": "AAAAB3NzaC1...JJw==",
"fingerprint": "07:af:73:de:8f:ab:59:d3:f7:49:50:72:c1:48:51:1d",
"keysize": "2048",
"type": "ssh-rsa"
},
"ec:b3:44:98:6e:f9:b3:23:70:7c:87:04:3f:af:30:45":
{
"comment": "all@comment.com",
"data": "AAAAB3NzaC1...fsw==",
"fingerprint": "ec:b3:44:98:6e:f9:b3:23:70:7c:87:04:3f:af:30:45",
"keysize": "2048",
"type": "ssh-rsa"
}
},
"global_keys":
{
"ec:b3:44:98:6e:f9:b3:23:70:7c:87:04:3f:af:30:45":
{
"users":
{
"sshonalready":
{
"enabled": "yes"
},
"sshuser2":
{
"enabled": "yes"
},
"sshuser3":
{
"enabled": "yes"
}
},
"who": "all"
}
},
"key_options":
{
"command": "value",
"environment": "value",
"from": "value",
"no-X11-forwarding": "checkbox",
"no-agent-forwarding": "checkbox",
"no-port-forwarding": "checkbox",
"no-pty": "checkbox",
"permitopen": "value",
"tunnel": "value"
},
"keysize":
{
"0":
{
"text": "1024",
"value": "1024"
},
"1":
{
"selected": "yes",
"text": "2048",
"value": "2048"
},
"2":
{
"text": "4096",
"value": "4096"
}
},
"public_keys":
{
"all_rsa":
{
"comment": "all@comment.com",
"data": "AAAAB3NzaC1...fsw==",
"fingerprint": "ec:b3:44:98:6e:f9:b3:23:70:7c:87:04:3f:af:30:45",
"keysize": "2048",
"timestamp": "1539761813",
"type": "ssh-rsa"
},
"allexcept_rsa":
{
"comment": "json@comment.com",
"data": "AAAAB3NzaC1...Kow==",
"fingerprint": "ab:d6:60:d3:e8:75:c0:82:de:52:91:61:aa:22:e7:c9",
"keysize": "2048",
"timestamp": "1539761558",
"type": "ssh-rsa"
},
"gui_rsa":
{
"comment": "descriptive@comment.com",
"data": "AAAAB3NzaC1...JJw==",
"fingerprint": "07:af:73:de:8f:ab:59:d3:f7:49:50:72:c1:48:51:1d",
"keysize": "2048",
"timestamp": "1540022670",
"type": "ssh-rsa"
},
"id_rsa":
{
"comment": "test@key.com",
"data": "AAAAB3NzaC1...BHw==",
"fingerprint": "59:09:0c:a1:f5:69:12:89:72:79:ed:45:11:1b:f4:3d",
"keysize": "2048",
"timestamp": "1539757117",
"type": "ssh-rsa"
}
},
"users":
[
"sshonalready",
"sshuser2",
"sshuser3"
]
}
============
If a Reseller or Admin, the json will include a top-level array global_keys, with each key that is set to be global, with info.
As well as "users", a list of all current Users under this account (just a dump of the users.list file)
{
...
"global_keys":
"users": \[ "fred", "george" \]
...
}
The call made by a normal User will not have the global_keys nor users array.
SKINS
new files:
user/ssh_keys.html
user/ssh_keys_edit.html
files_user.conf:
CMD_SSH_KEYS=user/ssh_keys.html
CMD_SSH_KEYS_EDIT=user/ssh_keys_edit.html
Edited:
user/show_domain.html
added new line:
|*if USERSSH="ON"|
<a href="/CMD_SSH_KEYS">SSH Keys</a><br>
|*endif|
CMD_CUSTOM_HTTPD: JSON to show virtual_host2.conf.pre, virtual_host2.conf.CUSTOM.pre new
On the page:
CMD_CUSTOM_HTTPD?domain=domain.com&json=yes
Within the "VH1" to "VH6" arrays, if there are custom values, a sub-array will be shown, called:
"custom_global_pre_post"
eg:
...
"VH1":
{
"custom": "1",
"custom_global_pre_post":
{
"/usr/local/directadmin/data/templates/custom/virtual_host2.conf.CUSTOM.4.pre": "#virtual_host2.conf.CUSTOM.4.pre\",
"/usr/local/directadmin/data/templates/custom/virtual_host2.conf.CUSTOM.post": "#virtual_host2.conf.CUSTOM.post\",
"/usr/local/directadmin/data/templates/custom/virtual_host2.conf.pre": "#THIS IS PRE TEXT!!\\"
},
"data":
...
Also applies to nginx template, where applicable.
Note, the cust_httpd.pre custom files are listed in json, mentioned in id=2158.
UTF-8 Encoded To/From/Reply-To in DA emails new
Should a DirectAdmin User's "name" contain UTF-8 characters, the To, From, Reply-To headres can now be encoded with UTF-8.
To enable this, add:
utf8_encode_from_to=1
to the directadmin.conf and restart directadmin.
Cron: default to MAILTO="" for new accounts new
The previous default for new accounts is to not set the MAILTO= value at all in the crontab.
This defaults to sending email to that User if the cron generates any output.
The issue with this is Users often never check their system email accounts,typically flooding it with more messages than the directory can efficiently manage, as well as causing issues with the backup, since DA/tar cannot easily read the contents of the oversized Maildir.
The solution is to default new accounts to use:
MAILTO=""
in both the crontab.conf and the actual crontab (for direct_crons=1, which is the current default).
Existing accounts will not be affected.
If you'd like, you can change the cron email to a blank value in a given User's cron page, and save, to prevent any further emails.
extra unzip command line options & max extraction file listing count new
New directadmin.conf setting, with internal default as blank:
extra_unzip_option=
The usaul way DA unzips a file is
unzip -qo '/domains/domain.com/file.zip'
In some cases, this error could show up:
path/blaÃŒÅtest.jpg: mismatching "local" filename (path/blaââ€Å“Ãωâ€Â¼Ã°test.jpg), continuing with "central" filename version
The solution is to add these options to the directadmin.conf:
extra_unzip_option=-O cp396
and restart directadmin.
The value is inserted after the -qo, so it would end up looking like this:
unzip -qo -O cp396 '/domains/domain.com/file.zip'
=========================
Also added into the default internal settings is:
extract_list_max_files=5000
where 5000 is the internal default.
You can override it by adding it and the new value to the directadmin.conf.
When extracting a tar.gz or a zip file, if the number of files within the compress file is greater than 5000, then the rest will be chopped of.
DA basically just looks for the 5000'th newline character and nulls it with , ending the string.
If this is hit, this string is added to the end of the listing:
Maximum number of files listed (5000). Suppressing further output.
This should prevent hangups if a very large zip/tar.gz is being extracted.
hook scripts for Message System new
Hook scripts that can be added to:
/usr/local/directadmin/scripts/custom/*
to be triggered anytime DA sends a notice to the Message System.
You can exit with a non-zero result for any *_pre.sh script (if they exist) to suppress the message from being sent.
The *_post.sh scripts don't check the exit status.
The output is read in, but not used, so if you need to save anything, log it from within the script,
or use the task.queue to create another message to whoever needs it.
SCRIPTS:
notifyAdmins_post.sh
Triggered for any event that sends a message to all Admins.
priority=#
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)
You can get the list of admins from
/usr/local/directadmin/data/admin/admin.list
This does make a call to "sendSystemMessage", which also has a hook, if email_only=0.
sendSystemMessage_pre.sh
sendSystemMessage_post.sh
same data is notifyAdmin_post.sh, but also:
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=user0=fred&user1=george - where the value to the right of "users" is URL encoded (the example doesn't the encoding of & and =). It's possible this value is blank if include_admins=1.
Services Monitor to use boot scripts as backup method to get parent PID new
In some cases, you might have a service in the services.status file, where there running binary does not match the boot name.
As a result, DA might not see it running, so monitoring work.
This also applies to spamsasssin (spamd) on FreeBSD, which shows "perl" as the binary.
So the behavior will be, should the normal PID retrival method return zero PIDs, this will be the fallback to figure out if the above scenario is true (only for services.status items), and whatever it could figure out, to the list.
For systemd, the Master PID is parsed right out of the "systemctl status httpd" (for example), only to get the master PID number.
For init.d systems, it call /etc/init.d/httpd status, and strips the first pid number from there. DA will look within ( ) brackets for the PID numbers, eg: "status (pid 82103) is running..."
Once the master PID is found, DA then uses it's own internal tools to find the child PIDs below it (varies per OS type)
Affects:
Services Monitor
System Information
dataskq services running check
Based on extra entries added into:
/usr/local/directadmin/data/admin/services.status
Also, the "Services Monitor" also now fetchs ram usage, but using the main pid from the status, and calling:
ps o comm,rss -C -p 12345
Packages: rename (SKINS) new
When editing a package, changing the name at the bottom is considered a "save-as" action, so you'd end up with a new package, and the old package is left unchanged.
Users with the old package are also unchanged, as they're not using the newly saved package name.
New option, a "Rename" checkbox at the bottom left of the package edit page, for both User/Reseller packages,
where, if checked, DA will fully remove the old package, and also change all users with that old package name to use the new package name and it's values/settings.
=============
SKINS:
data/skins/enhanced/reseller/show_user_package.html
data/skins/enhanced/admin/show_reseller_package.html
new checkbox in the bottom td:
|*if NEW_PACKAGE!="yes"|<input type='hidden' name='old_packagename' value='|PACKAGENAME|'><span class=float_left><input type=checkbox name='rename' value='yes'>|LANG_RENAME|</span>|*endif|
data/skins/enhanced/style.css
new class:
.float_left {
float: left;
}
named_service_override=bind9 new
On some OSs for named/bind, it's simpler to have DA use some different script name, rather than trying to force the specific boot script names.
Specifically on Debian, apt-get provides bind9.service, but DA would still be looking for named.service.
New feature, internal default is:
named_service_override=(NULL)
where it's unset.
To have DA call bind9.service, add this to the directadmin.conf file:
named_service_override=bind9
Note, if you add named_service_override to the directadmin.conf, ensure it has a value.
If it's present but blank, this means DA would call:
systemctl reload .service
instead of:
systemctl reload bind9.service
Possibility to set this as the default for new Debian 9 boxes, if that script is present.
force_ssl for easy apache/nginx redirection to https (TEMPLATES)(SKINS) new
New checkbox in both:
User Level -> Domain Setup -> domain.com
under the "private_html setup for domain.com" table, showing:
[ ] Force SSL with https redirect
and at bottom of this page:
User Level -> domain.com -> SSL Certificates
where, if checked, the port 80 VirtualHost/server{} entries for a domain/subdomains will automatically redirect to the same host and request, but with https.
DOMAIN CONFIGS
New setting will be:
force_ssl=yes
in the:
/usr/local/directadmin/data/users/username/domains/domain.com.conf
if it's turned on.
If it's off, it will be absent from the file (will not show force_ssl=no)
JSON
CMD_ADDITIONAL_DOMAINS?action=view&domain=domain.com&json=yes
will now include the:
"force_ssl": "yes",
if turned on.
If off, it will be absent from the output.
SKINS
/usr/local/directadmin/data/skins/enhanced/user/modify_domain.html
In the "private_html setup" table, below the 2 radio tr entries for the link, add a new row:
<tr><td class=list2><input type="checkbox" name="force_ssl" value="yes" |SSLDISABLED| |FORCE_SSL_CHECKED|></td><td class=list2>|LANG_FORCE_SSL_REDIRECT|</td></tr>
/usr/local/directadmin/data/skins/enhanced/user/ssl.html
<table class=mb15 cellpadding=3 cellspacing=1>
<form name=https action="/CMD_DOMAIN" method="post">
<input type=hidden name=action value="private_html">
<input type=hidden name=domain value="|DOMAIN|">
<tr><td><input type="checkbox" name="force_ssl" value="yes" |FORCE_SSL_CHECKED|></td>
<td>|LANG_FORCE_SSL_REDIRECT|</td>
<td><input type=submit value='|LANG_SAVE|'></td>
</tr>
</form>
</table>
where it uses the same action=private_html form.. but really has nothing to do with the symbolic link, since both radio buttons are excluded from the form.
TEMPLATES
Changed:
/usr/local/directadmin/data/templates/ --
virtual_host2.conf
virtual_host2_sub.conf
nginx_server.conf
nginx_server_sub.conf
added token:
|FORCE_SSL_REDIRECT|
which, if set in the Domain Setup for that domain, will be filled with either:
SetEnvIf X-Forwarded-Proto \\"https\\" HTTPS=on
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https \[NC\]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} \[L,R=301\]
OR
if ($http_x_forwarded_proto != 'https') {
eturn 301 https://$host$request_uri;
}
Crons: pad index with zeros to maintain order new
CMD_CRON_JOBS
CMD_API_CRON_JOBS
the "id" values for each cronjob are integers, but if you had 10, for example the order would be:
1
10
2
3
...
so the order could be confusing.
As there are non-integer indexes in this array (eg: MAILTO) we could not simply convert the search/sort to be an integer sort/search.
Instead, we've padded the indexes with zeros, so it would now be:
001
002
003
...
010
so that the order is maintained.
The direct_crons feature generates the IDs on the fly, so that's not an issue (nothing would change there),
and the per-User crontab.conf file will not be touched until saved.
All reads done after this change will convert 1, 2, 3 to id 001, 002, 003 on the fly.
So just be sure you're using the "id" tags from the current read before passing it to edit/delete.
The id value passed back to DA must match the padded value, so if you see id=001 you must pass id=001 for it to be seen.
But if you've coded things correctly where you're not concerned with the indexes being integers, and treat them as strings, then likely no changes should be required to your API calls.
Custom hook: dkim_create_post.sh new
New hook script, called after the dkim_create.sh has finished running, and was successful.
Create script:
/usr/local/directadmin/scripts/custom/dkim_create_post.sh
With environmental variables:
domain=domain.com
Use exit 0 for success, and exit with a non-zero for error,
Although the result will be added to the output regardless, but only shown if there is an error.
Proftpd.conf: updated TLS protocol/ciphers (TEMPLATES) new
New /etc/proftpd.conf default changes.
It now uses these ciphers/protocols:
TLSProtocol TLSv1 TLSv1.1 TLSv1.2
TLSCipherSuite HIGH:MEDIUM:+TLSv1
This is both in the file:
/usr/local/directadmin/data/templates/proftpd.conf
as well as CustomBuild 2.0 configure/proftpd.conf/proftpd.conf, if ./build proftpd is run.
optional template: plugin_iframe.html (TEMPLATES) new
Not present by default, but used with plugin feature:
iframe=yes
which current hard-codes the iframe html output around the |OUTPUT| token.
This new optional template, if created, would be used in place of the hardcoded html.
Main purposes is to make debugging easier.. shouldn't be needed for most cases.
/usr/local/directadmin/data/templates/custom/plugin_iframe.html
Sample:
<html><head><base target="_parent" />
<meta charset="utf-8" />
</head><body><div id="iframe-container">
|OUTPUT|
</div></body></html>
LetsEncrypt: max failed renewal attempts before sending failure notice new
New directadmin.conf option, internal default:
letsencrypt_renewal_failure_notice_after_attempt=5
Because the renewal attempts start at (by default) 60 days before the 90 day expiry, this is 30 days grace before the SSL certificate actually becomes invalid.
As a result, we do have time to retry renewals before we need to be concerned about a failure.
This feature allows for up to 5 renewal attempts over 5 days before actually notifying the User, should the renewal fail a 5th time.
Often times, a renewal may fail the first time but succeed later on, so this allows a few more attempts before actually notifying the User.
After 5 attempts, if there is still a renewal failure, it will only then message the User.
It will continue to notify the renewal failures until the certificate has actually expired, at which point no more renewals will happen (same behavior as before)
Custom hook script: post restore but pre-cleanup new
New custom script:
/usr/local/directadmin/scripts/custom/user_restore_post_pre_cleanup.sh
which is called after the restore of a User account, but just before the path is cleaned up.
This is called just before user_restore_post.sh, which is triggered after the temporary extracted data is cleaned up.
The same variables are passed, as to the user_restore_post.sh:
$username
$reseller (user.conf creator)
$filename
Debug mode modulus %10==7 to show timestamp new
Sometimes you want to know exactly when things happen, when using DA's debug mode.
This change adds a debug%10 == 7 check to the debug level.
Basically, if you end any debug level with a 7, then the debug output line will start with the current timestamp of the system (handy for cron debug logging, for example)
DEPRECATED: User or mail can get their dovecot quotas with directadmin suid mode new
DEPRECATED AS OF 1.62.8
Drop directadmin suid bit support
===============================================
Not likely a feature for most people (at the moment), but if you set:
echo 1 > /root/.suid_directadmin
and set permission:
./directadmin p
it will set DA to be:
-rwsr-xr-x 1 root diradmin
This is used for per-User calls.. at the moment, just two options (existing: ./directadmin --DocumentRoot) but now it also adds:
./directadmin --doveadm-quota=user@domain.com
which can be called as root, mail or a User.
If called as a User, it will ensure that domain.com belongs to the UID caller (not likely a common usage, but is an option since suid was needed anyway for 'mail')
If root or mail, it will work for any email that exists the system.
If the email is valid, dovecot quotas work, then it will output something like:
18237:102400
which would be in KB, so the above example, the account is using about 20Meg of 100Meg.
You MUST check the exit code of the directadmin call.
If it's not 0, then ignore this directadmin result.
If the account in question has unlimited dovecot quotas, then the output will be:
0:0
This feature uses the doveadm quota call to get the info, as dovecot is going to be what will accept/reject the email anyway.
The purpose of this feature is to allow exim the ability to block an inbound email at smtp-time via ACL, rather than accepting the message, and having it bounce after the dovecot lmtp delivery rejects it.
The ACL in question does not yet exist. If it will exist, it wouldn't be for a while after this version of DirectAdmin have been released.
Domain Pointers: option to not redirect to www (SKINS)(TEMPLATES) new
UPDATE with 1.57.0: Deprecated
Replaced with force_redirect:
www vs no www domain/pointer redirection (SKIN)(TEMPLATES)
======================
NOTE: This feature's implementation may change for 1.55.1, for a different design.
As this decision was made after RC1 was pushed, we'll leave this feature as-is for now.
If you're a skin designer, you may want to hold off until 1.55.1 before add the changes, since the variable names/tokens may be removed.
======================
CMD_ADDITIONAL_DOMAINS
CMD_DOMAIN_POINTER
The redirect type of domain pointed used to always redirect to the www.maindomain.com form, without any option to redirect to just maindomain.com.
Change to the CMD_ADDITIONAL_DOMAINS & CMD_DOMAIN_POINTER pages.
A new checkbox on CMD_ADDITIONAL_DOMAINS (to be posted to CMD_DOMAIN) to let the User decide if domain pointers should redirect to www.maindomain.com or just maindomain.com.
SKINS
user/modify_domain.html
user/domain_pointers.html
New JS to hide/show "www." based on the new checkbox on CMD_DOMAIN_POINTERS
The action=modify on CMD_ADDITIONAL_DOMAINS form now also had:
form_version=1.1
which is needed in order to use the:
www_pointers=yes
checkbox. If it's not passed, then with form_version=1.1, it's assumed to be off.
Without form_version>=1.1, you can pass either www_pointers=yes or www_pointers=no and DA will pick up the value, as it's explicitly specified.
TEMPLATES
redirect_virtual_host.conf
nginx_server_redirect.conf
added to top section of both:
|?WWW_PREFIX=www.|
|*if WWW_REDIRECT="no"|
|?WWW_PREFIX=|
|*endif|
and lower down (both again), changed the:
www.|DOMAIN|
redirect text to be:
|WWW_PREFIX||DOMAIN|
DATA FILES
/usr/local/directadmin/data/users/USERNAME/domains/domain.com.conf
new default:
www_pointers=yes
which can be set to no via the CMD_ADDITIONAL_DOMAINS Domain Setup page.
The domain pointers file at:
/usr/local/directadmin/data/users/USERNAME/domains/domain.com.pointers
will now have it's format changed from:
pointer.com=alias
pointer.com=redirect
to:
pointer.com=type=alias
pointer.com=type=redirect&www=no
where a late design change mean the domain.com.pointers is not actually used at all...
BUT since we will retain the conversion to:
pointer.com=type=redirect
you can add www=yes|no manually to the pointers file, if you want to override the domain.com.conf setting.
DA won't add www= to the pointer config.
Domain Pointers to have local/remote email control new
Previously, the Domain Pointers always followed the mail domain in terms of if they had local or remote email ("Local Mailserver" setting on MX Records page).
DA will still flip pointers to match whatever the main domain is set to.
However, now you can change Domain Pointers to remote/local independently after the main domain has been set however you wish.
The CMD_DOMAIN_POINTER?domain=maindomain.com lower table will now have a new column called "Local Mail"
and 2 new buttons will appear at the bottom to the left of the "Delete" button:
Local Mail
Remote Mail
The behavior of the form to control these values will be:
CMD_DOMAIN_POINTER
action=delete
domain=maindomain.com
select0=pointer1.com
(select1=pointer2.com)
To set the select# list to be local, add:
local_mail=anytext
To set the select# list to be remote, add:
remote_mail=anytext
If you forget to add local_mail or remote_mail, these pointers will be deleted 😃
So ensure you're not using a new skin with these buttons with an older version of DirectAdmin.
For Enhanced, it's not an issues because it's a hardcoded table+buttons that only shows up with this new version.
sendmail_pre.sh new
All emails generated by DirectAdmin (eg: Message System notices, etc) are pushed through:
/usr/sbin/sendmail
This custom hook:
/usr/local/directadmin/scripts/custom/sendmail_pre.sh
which can be created if you need it,
will allow you to override the sendmail call and handle the message yourself.
For example if you want to use a remote smtp-server directly, for all DA messages, you could setup some sort of wrapper in the sendmail_pre.sh to deliver them to some port 25.
RETURN CODES
If the script exists, the return code will determine how DA will handle the following actions:
0 - if exit 0 is used, it's assumed the sendmail_pre.sh has accepted the message, and there are no errors. Sendmail will not be called. You can also use this to no have DA do anything, even if the script does nothing.
1 - For exit code 1, DA assumes there was an error, and the called DA function will return with an error code (caller depends on what message is shown, etc)
2 - Exit code 2 will mean the script intends for DA to ignore that the script was there at all, and continue normally to a sendmail delivery.
ENVIRONMENT variables
full_message = all headers and message contents
message = just the body of the message
to = the "To:" header. Could be normal email, or utf-8 nencoded email if utf8_encode_from_to=1 is set in directadmin.conf.
subject = the "Subject:" header. Could be utf-8 encoded if utf8_encode_subject=1 is set in directadmin.conf.
OPTIONAL (possibly not be passed)
from = the "From:" header. Could be normal email, or utf-8 encoded email if utf8_encode_from_to=1 is set in directadmin.conf.
reply_to = the "From:" header. Could be normal email, or utf-8 encoded email if utf8_encode_from_to=1 is set in directadmin.conf.
headers = url-encoded string of possible extra headers, eg: "MIME-Version=1.0&Content-Type=text/html" (for the <html> as start of body case,, for example.
per-User/per-Reseller send_usage_message override new
Relating to feature:
option to not send warning emails for bandwidth/quotas
The value:
send_usage_message=0|1
can be added to a given User's user.conf and/or a given Reller's reseller.conf.
The value set in these files will override the directadmin.conf send_usage_message option.
This can be used to enable/disable the notices for a given account when they approach their limit.
The reseller.conf override would apply to a Reseller's limits, and the user.conf to the User's limits.
GUI
No skin changes are required for Enhanced, it's in the hardcoded token.
The setting can be changed by Users at:
User Level -> Site Summary / Statistics / Logs (CMD_USER_STATS) -> Limit Notice
where it gives 3 options in the select box:
Default (On) or Default (Off) (pending the directadmin.conf send_usage_message), with value 2.
On value 1
Off value 0
If Default (On/Off) is selected, the user.conf does not have send_usage_message.
Else, the On/Off is set based on the user.conf send_usage_message.
Same idea for Reseller, except:
CMD_RESELLER_STATS
and reseller.conf.
SAVE THE CHANGE
CMD_CHANGE_INFO | CMD_API_CHANGE_INFO
method: POST
send_usage_message=<any text>
send_usage_message_value=0|1|2
with standard dynamic output.
For Resellers, it's the same command, the only difference is the button name:
send_usage_message_reseller=<any text>
send_usage_message_value=0|1|2
JSON
CMD_USER_STATS?domain=domain.com&json=yes
the "stats" array has added entry:
"38":
{
"setting": "send_usage_message",
"usage":
{
"0":
{
"selected": "yes",
"text": "Default (On)",
"value": "2"
},
"1":
{
"text": "On",
"value": "1"
},
"2":
{
"text": "Off",
"value": "0"
}
},
"max_usage": "1"
},
where most should be self-explanitory, but the "max_usage" will be the internal/directadmin.conf setting for send_usage_message, in case you need to know it.. for some reason.
The "Default (On/Off)" already represents that value, but in translatable text, thus this is a more definitive way of knowing the value.
CMD_RESELLER_STATS?json=yes
Similar, but because the arrays for Reseller stats are different, this is a new array at the top level:
"send_usage_message":
{
"max_usage": "1",
"select":
{
"0":
{
"selected": "yes",
"text": "Default (On)",
"value": "2"
},
"1":
{
"text": "On",
"value": "1"
},
"2":
{
"text": "Off",
"value": "0"
}
}
},
Php selector to only show 1 selectbox (SKINS) new
CustomBuild 2.0 has the ability to support more than 2 php versions quite easily.
The hold-back is the internal DirectAdmin code to manage php1 and php2 versions in the configs and templates.
Also, the need for 2 php versions at the same time for one website seems very rare (we've not seen it in use).
The solution is then to simplify the Php Selector in the Domain Setup page for a given domain to only show 1 php selector, instead of 2.
This single selector will still given the User the option to select any php version that CustomBuild supports (still just 2 at the time of this writing, but more once we get it sorted out)
We'll do this in small steps in case our above assumptions are incorrect.
The internal default, which is already set it:
php_version_selector=1
this was previously intended to be an on/off switch for the selector.
This default value will remain unchanged, but it's functionality expaneded to be:
php_version_selector=0 : off
php_version_selector=1 : show only 1 php selector (.php files can be any version selected) DEFAULT
php_version_selector=2 : show the previous 2 php versions.
So by default, Users will only see 1 php selector with the php_version_selector=1 value in their Domain Setup page.
If you are using this feature where you might need .php and .php72 for one website at the same time (which we've not seen), then you can set:
php_version_selector=2
and please let us know.. as the current plan is to remove the 2nd php version instance from the templates, since it's likely not needed, and very rarely used.
If this all goes ahead, then CustomBuild 2.0 will then be changed to support php3_ php4_ etc, up to N version (any number), likely for php-fpm (mod_php can only be used once)
More DA changes will be needed for that later one, so this is more of a feeler for the proposed changes.
If may php DO need the 2nd php selector, then the other option is to leave it there, but still allow CB2 to have php3+.. and only allow a domain to use 2 different versions at the same time (we prefer to no go this route).
SKINS
token:
if directadmin.conf php_version_selector > 0
PHP_SELECTOR_COUNT=1|2
JSON
if json var "has_php_selector" == "yes", then
php_selector_count=1|2
===================
Keyword:
PHP_SELECTOR_TABLE
ftp extended=yes was not showing suspension fixed
Bug with new feature:
not correctly showing suspended=yes
Forum:
https://forum.directadmin.com/posts/291058
allow header: X-Json=yes fixed
There are cases where DA does not yet have the request parsed yet, but it needs to abort.
The usual case would be a timeout, for example, during a very large file upload.
In these cases, DA has not yet parsed the GET/POST body data yet, thus has no idea if the script wanted json=yes being set.
This optional value lets you get a more reliable output, by allowing the new header:
X-Json: yes
to be added to the request, as the headers are parsed first.
Other cases are currently if the IP is blacklisted and this header is set, it will now return a dynamic style output with error=1.
With the header set, the optional template:
/usr/local/directadmin/data/templates/blacklisted_ip.html
will NOT be used, since the output shouldn't be html.
If other scenarios are found that are not generating json when the header is set, let us know and we can include them into the correct output handling.
======
Extra headers:
In addition, if a timeout occurs, a header will be added:
X-DirectAdmin: timeout
or if a segfault occurs:
X-DirectAdmin: segfault
Sample timeout response from:
CMD_FILE_MANAGER?json=yes
Connection: close
Content-Type: application/json; charset=utf-8
Server: DirectAdmin Daemon v1.54.1 Registered to JBMC-Software.com
Set-Cookie: session=gf60qSva6eVnKmEsGfChUcKtEsTa28lQoOUmEwip1KIme40UIdesRBEpLCvLJej72; path=/; expires=Fri, 21 Sep 2018 21:38:56 GMT; HttpOnly
X-DirectAdmin: timeout
{
"error": "Your connection has timed out",
"extended": "true",
"result": "Consider disabling the <a href='http://www.directadmin.com/features.php?id=678'>Folder Usage Count</a>."
}
direct_crons and PATH= SHELL= HOME= fixed
The new direct_crons feature was not correctly handling any manually added PATH, SHELL, HOME variables in a Users crontab, thus generating:
User cron parsing error. Check crontab.conf files
or
Error Parsing Cron File
depending on which area you're viewing crons from in DA (Admin Level -> All User Crons, or User Level -> Crons)
The fix will respect the setting and will return it back into the file when it's re-saved by DA.
=====
Tested, and it also works with direct_crons=0, which does then save the PATH in the User's crontab.conf, but only if it was in the crontab, then you set direct_crons=0, and save.
Else you'd need to manually add the PATH into the Users crontab.conf, eg:
[root@test directadmin]# cat data/users/cronuser/crontab.conf
0=1 1 1 1 1 /home/cronuser/test.sh
1=2 2 2 2 2 /home/cronuser/test_two.sh
MAILTO=cronuser@othercrondomain.com
PATH=$PATH
but I doubt how many people would be using this method, as with proper support for:
direct_crons=1
there shouldn't be any reason to have the middle-man file in use.
Cluster: Remote E-Mail Account sync not working fixed
Portions of the E-Mail account sync were working (unsure when bug was introduced), but fixed now.
Accounts can be created and changed.
Deletion did not have the issue.
Dovecot was not reloaded after renewal, so new certs were not seen fixed
Bug where dovecot did not get reloaded if:
letsencrypt_renewal_success_notice=0
was used, as that setting caused the loop to "continue;" before counting that renewal.
Outside of the loop, it then sees 0 renewals, so dovecot didn't get reloaded.
LetsEncrypt: remove prompt = no from openssl request fixed
Only report is affecting Debian 8.
Creating an openssl request generated:
error, no objects specified in config file
problems making Certificate Request
solution was to remove;
prompt = no
from the san_config.
This is only done for LetsEncrypt requests/renewals.
Other DA ssl certificate requests/renewals will still have prompt = no.
Clean forwarders to delete empty forwarder during email removal fixed
Relating to this feature:
Ability to clear forwarder values when deleting emails
where it gives you the option to "Clean Forwarders" when deleting an email account to ensure it does not forward to a non-existent address,
Scenario:
E-Mail accounts:
foo@domain.com
bar@domain.com
forwarder:
foo@domain.com -> bar@domain.com
when the E-Mail address bar@domain.com is removed, with the "Clean Forwarders" option enabled,
DirectAdmin would have removed forwarder bar@domain.com from foo@domain.
Once removed, there would be 0 destination, and DirectAdmin would have set it to :fail:
The premise was "correct" should there not have been a foo@ email account, which was not considered.
Fix is to fully remove the alias if there are 0 recipients, rather than setting it to :fail:
If a forwarder is removed, the result will no longer redirect to the email listing, but instead show a result page/message notifying that the zero-recipient forwarder has been removed.
For cases without the foo@ email, this would still have the same behavior, assuming your catch-all is still set to :fail:.
json encoding double escaping newlines fixed
The DA json encoder was encoding newline characters as \\n when it should have been encoded as: \n.
The ability to control which encoding is used is now optional, and can be controlled in the file /usr/local/directadmin/data/skins/SKINNAME/skin.conf with:
jsonformat=legacy
or
jsonformat=current
If the setting is absent, it will default to "legacy", double encoding \\n
This also applies to line feed: \\r vs \r
Both the enhanced and evolution skins that are included with this release, pre-release, or downloaded will contain:
jsonformat=current
But the internal default to legacy is to still support old Evolution skins that rely on the double encoding.
Token:
SKIN_JSONFORMAT=legacy|current
but only if the setting it present in the skin.conf.
If not, it won't be set, and you can assume SKIN_JSONFORMAT=legacy is in use.
New mode is always on in DirectAdmin 1.672.
Forwarder should not forward to itself fixed
Added a check to prevent a forwarder from being created/saved if it has it's own value added to the list.
Forwarding to itself will cause an unrouteable address error.
Major optimization in table search speed fixed
When using the Admin main page search tool to find a User or Domain/Pointer via the "contains" option, the table does a pre-search on values, before deciding if it should be added to the table.
This applies to only Users or the Domains/Pointers column in this particular case.
Optimization on how the contains search is done to exponentially speed it up.
DNS domain.com.temp.12345 write race condition fixed
Although we've not had any reports, if there are 2 processes trying to write the DNS domain.com.db file at the same time, there could be a possible race condition.
DirectAdmin does first write to:
domain.com.db.temp
before doing the checks on it through named-checkzone, but it's possible while the checks are in progress, another process could in theory write to the temp, causing a possible rename of a half-written file.
We've not seen it, but as a precaution, we've change the temp file to now be;
domain.com.db.temp.12345
where 12345 is going to be the current process ID of the running process.
When the "rename" happens, the file system would only allow one at a time, so worst case it would be a theoretical rename failure and a message shown,
but the rename that succeeded would have valid file contents.
Enable login_keys for Admin accounts by default fixed
Because Admin accounts have no packages, any settings that should be on by default, must be set into the POST as it's passed through each class inheritance.
The login_keys variable was not set in this pass-through, thus it was not enabled by default.
Add it to the POST, so that it's always enabled by default (assuming the feature is enabled, which it is, by default)
Backup: create recursive path when needed fixed
When creating a backup, DA ensures the path it's being backed up to exists.
However, with the "Append to Path" feature, you could have specified dated sub-directories which would require recursive creation.
This change swaps out the single directory creation to a recursive one.
nginx_server_redirect.conf to redirec https to https (TEMPLATES) fixed
Domain pointers with nginx had a bug, where an https pointer would have redirect to the http domain, instead of the https domain.
Changed the nginx_server_redirect.conf to redirect to https main domain if it was an https pointer.
Basic locking for LetsEncrypt requests fixed
User LetsEncrypt requests run in the background.
The dataskq can take up to 60 seconds before it picks up the task.queue request to run it.
This allows more than enough time for Users to make many requests, causing issues with multiple dns settings at the same time etc..
Basic locking will now happen for background LetsEncrypt requests.
Any further attempts to do another background request will generate the error:
"Domain is already processing an SSL request. Please allow it to finish before making other changes."
Only the dataskq processing that letsencrypt request will clear the lock.
If your dataskq isn't running, the lock expiry time of 5 minutes applies, so if the dataskq failed to clear it (for whatever reason), future requests will still work after that time.
LOCK FILE
/usr/local/directadmin/data/users/USERNAME/domains/DOMAIN.COM.ssl.lock
Rename domain missing .cust_httpd.# fixed
There are other custom tokens that could exist for:
/usr/local/directadmin/data/users/USER/domains/DOMAIN.COM.cust_httpd.2
for example (also for cust_nginx.#) for any number, 1, etc..
Instead of tracking each possible filename, DA will now search for any:
domain.com.cust_*
leftover after the known renames, and if found swaps the domain.com.cust_ with newdomain.com.cust_
special password characters break backup_roundcube.php and restore_roundcube.php fixed
The new default da_admin passwords, as decided by the setup.sh, now have special characters.
This can cause issues with php's parse_ini_file function, as the password in the mysql.conf should be "quoted" for this case.
However, the mysql.conf is read by DA and cannot be used.
Simple fix is to check the loaded password after the parse_ini_file call, and if it's not long enough to be a valid password, the backup method is used.
This will read the /var/www/html/roundcube/config/config.inc.php with an include_once, making it's parsing very easy and reliable, so this fallback could almost be preferred.
Direct crons and User suspension does not restore crons on activation fixed
Bug where the un-suspension of a User does not restore their crons from the crontab.conf file.
FileManager: allow compress file with modified/missing sources fixed
Similar to an issue the DirectAdmin Backup process hit a while back:
when compressing a tar.gz file in the FileManager, if a source file changes or goes missing during that creation, tar can throw either code 1 or 256.
As long as the default directadmin.conf setting allow_backup_exit_code_one=1 is set, then these 2 tar exit codes will be allowed and will not throw an error.
Packages: Disabled text input if unlimited already set (SKINS) fixed
For Reseller and User packages, if a package is saved with "unlimited" for a given parameter, when viewing that package, the associated input should be disabled.
Previously, only the inodes entry was set to do this, mainly because it was unlimited by default already, while others are not (for new packages),
but the change now applies to all DirectAdmin package items that can be set to be unlimited.
Toggling the unlimited checkbox activates/disables the input item as usual.
SKINS:
reseller/show_user_package.html
admin/show_reseller_package.html
Added tokens:
BANDWIDTH_DISABLED, QUOTA_DISABLED, INODE_DISABLED(already there),
VDOMAINS_DISABLED, NSUBDOMAINS_DISABLED, NEMAILS_DISABLED, NEMAILF_DISABLED,
NEMAILML_DISABLED, NEMAILR_DISABLED, MYSQL_DISABLED, DOMAINPTR_DISABLED,
FTP_DISABLED
To the 2 skins, in their respective <input type=text> entries, so if a package item has unlimited set, it will be filled with 'disabled" by default, else blank: "".