Version 1.41.1
Released: 2012-06-19
improved tokenizing on dns_*.conf files new
The dns_*.conf files now support the full capabilities of the tokenizer.
- Token replacement now works correctly (was disabled in some cases, where variable already existed)
eg dns_a.conf can now use:
|?IP=1.2.3.4|
value=|IP|
to make all IPs 1.2.3.4, regardless of what value the IP token was set to before.
Previously, you could set a value, but only if it didn't exist. Since IP already existed, the |?IP=...| value was ignored.
NOTE that the list of tokens will be changed when you set them in a conf file.
This means if you change |IP| in the dns_a.conf, all dns_*.conf files that are loaded after it will see this new IP value.
The order of dns_*.conf files is:
dns_ns.conf
dns_a.conf
dns_mx.conf
dns_cname.conf
dns_txt.conf
dns_aaaa.conf
dns_srv.conf
- Full embedded root access scripting in the dns_*.conf files, eg:
eg dns_a.conf:
|$/usr/local/bin/php
<?php echo "php=1.2.3.4" ?>
DONE|
localhost=127.0.0.1
|*if IS_IPV6!="yes"|
|DOMAIN|.=|IP|
mail=|IP|
pop=|IP|
www=|IP|
ftp=|IP|
smtp=|IP|
|*endif|
which will add an A record called:
php 14400 IN A 1.2.3.4
where you can add anything you'd like into the script, including database acccess...
This will allow you to create the new dns databases on the fly based on database entries.
Note that this only applies to new dns zones for new domains.
The dns_*.conf files are not used for existing domains (unless you use the "reset zone" button in DNS Admin, which wipes it clean and starts over)
Credits to Roel Beun from www.acceleratic.nl for this request.
SSLCACertificateFile in VH's in ips.conf new
A new directadmin.conf option (internal by default):
apacheca=/etc/httpd/conf/ssl.crt/server.ca
to work with the other 2 existing options:
apachecert=/etc/httpd/conf/ssl.crt/server.crt
apachekey=/etc/httpd/conf/ssl.key/server.key
The above server.ca path is the default internal value.
If apacheca is not in the directadmin.conf, the above server.ca path will be used.
If the path that apacheca is set to exists and is more than 0 bytes, the ips.conf will then be written with:
SSLCACertificateFile /etc/httpd/conf/ssl.crt/server.ca
to allow shared IPs to have a CA certifaite/chain.
The template has changed:
/usr/local/directadmin/data/templates/ips_virtual_host.conf
at the top:
|?CACERT_LINE=|
|*if CACERT!=""|
|?CACERT_LINE=SSLCACertificateFile \`CACERT\`|
|*endif|
and in the SSL VH:
SSLEngine on
SSLCertificateFile |CERT|
SSLCertificateKeyFile |KEY|
|CACERT_LINE|
To rewrite your ips.conf, type:
cd /usr/local/directadmin
echo "action=rewrite&value=ips" >> data/task.queue && ./dataskq d200
Add Host header to connections in mutli server setup new
If you're using a hostname for a connection in:
Admin Level -> Multi Server Setup
instead of an IP address, DA will now pass that Host header in the API request to the remote box.
User Restore options need unique identifier (SKINS) fixed
With the addition of this feature:
Ability to exclude DB data from backup, but include DB Settings (SKINS)
a bug for the User Level restore was introduced in that the newly added "database_data" option was indentified by select11, but "dns" was already using select11.
This caused the database_data from being skipped if dns is also selected for the restore.
Fix was to change "dns" to select12.
This is a low priority fix, as another line was missing from this file anyway:
<input type=hidden name="form_version" value="2">
which tells DA to look for the "database_data" value.
Since it ends up being form_version=1, the restore automatically adds the database_data internally, if "database" is present.
So a restore will not be missing any data, but instead, one will simply not be able to de-select the database_restore option.
Brute force reporting values in encoded form fixed
Sample report:
Subject: Brute-Force Attack detected in service log from IP(s) 127.0.0.1 on User(s) test%40email%2Ecom
where we'd want to see this instead:
Subject: Brute-Force Attack detected in service log from IP(s) 127.0.0.1 on User(s) test@email.com
This is related to this change:
encode usernames brute_user.data
This shouldn't affect functionality too much, except for the values passed to the pre/post.sh scripts may also be encoded.. as well as the values in the skip list.
Workaround: do checks on the encoded values until fixed, eg:
test%40email%2Ecom (may require manual changing of /usr/local/directadmin/data/admin/brute_skip.list)
Ensure difficult password is used with \"Reset Password\" option fixed
Reseller Level -> List Users -> username
Resend Welcome Email -> Checkbox for [reset password] -> Send
If difficult passwords are enabled, the internally generated password does not always produce a password that passes the tests.
If the difficult password checking (DPC) is enabled, pass it through the DPC script to ensure it passes.
Try up to 20 times until it does.