Version 1.45.1
Released: 2014-04-29
Add x-use-https header on http to https redirect new
If you connect to http when DA is using https, DA will redirect you to https automatically.
This change simply adds an extra header, so scripts/APIs can check to see if this header is set:
x-use-https: yes
and if it does, then they'll know that DA is using https, and they can notify the Admin to change the API settings accordingly.
CMD_API versions of CMD_CHANGE_EMAIL_PASSWORD, CMD_CHANGE_FTP_PASSWORD, CMD_EMAIL_ACCOUNT_QUOTA, CMD_EMAIL_ACCOUNT_VACATION new
Added these new CMD_API calls:
CMD_API_CHANGE_EMAIL_PASSWORD
CMD_API_CHANGE_FTP_PASSWORD
CMD_API_EMAIL_ACCOUNT_QUOTA
CMD_API_EMAIL_ACCOUNT_VACATION
which are 100% aliases of:
CMD_CHANGE_EMAIL_PASSWORD
CMD_CHANGE_FTP_PASSWORD
CMD_EMAIL_ACCOUNT_QUOTA
CMD_EMAIL_ACCOUNT_VACATION
So, if "api=1" is required, even if you're using CMD_API, you must still pass the GET/POST values "api=1"
The purpose of adding the CMD_API versions of these commands is when the:
force_hostname=
option is used in DA... a CMD_API is exempt.
The non-API versions would be given the forced redirect instead of the desired results.
Allow tokenizer to handle shebang scripts new
Previously, scripts passed to the Tokenizer neede to have the file started with the binary to run, eg:
/bin/sh
this was fine, but made debugging tricky and annoying.
The Tokernizer class can now accept either:
/bin/sh
#!/bin/sh
where #!/bin/sh will be far easier to debug with, saving the need for custom copies when debugging.
(/bin/sh can be replaced with any binary, that's nothing new, eg: #!/usr/local/bin/php)
Apache 2.4.9 and php-fpm HAVE_PHP1_FPM change (TEMPLATES) new
Update: Aug 6, 2014: With Apache 2.4.10, these tokens have been removed from the templates:
Removed HAVE_PHP1_FPM_OLD from templates (TEMPLATES)
This applies to CustomBuild 2.0 running Apache and php-fpm.
For the virtual_host2.conf, and related files:
virtual_host2.conf
virtual_host2_secure.conf
virtual_host2_secure_sub.conf
virtual_host2_sub.conf
user_virtual_host.conf
The token value for:
HAVE_PHP1_FPM
will be affected by the version of apache.
If apache is 2.4.7 or older:
HAVE_PHP1_FPM_OLD=1
HAVE_PHP2_FPM_OLD=1
If apache is 2.4.9 or newer:
HAVE_PHP1_FPM=1
HAVE_PHP2_FPM=1
which will provide different httpd syntax.
logs_to_keep max hardcoded to 400 fixed
The "Apache Logs to Keep" setting (aka directadmin.conf = logs_to_keep) will now have a hardcoded 400 rotation limit.
The default is 5.. so 400 is going to be rather high anyway.
The bug was that there was a silent-fail rotation limit of 200, but some clients were setting 365 rotations which caused the rotation to fail.
In this one case, the /var/log/httpd/domains/domain.com.bytes files were not being rotated at all.. and just kept growing.
This made the apache bytes grow much larger than it actually was.
Current workaround, don't use anything larger than 199.
breadcrumb when showing a User to point back to correct list (SKINS) fixed
Both:
CMD_ALL_USER_SHOW
CMD_USER_SHOW
list Users, and when you click them, you'll be viewing the User page, eg:
CMD_SHOW_USER?user=crumb
The fix is to check the referer on the CMD_SHOW_USER page.
If there is a referer, and CMD_ALL_USER_SHOW exists in the referer, then the breadcrumb will point back to CMD_ALL_USER_SHOW
SKINS:
reseller/show_user.html
change the TREE:
<a class=tree href="/CMD_USER_SHOW">Show Users</a>
to:
```html
<a class=tree href="/`USER_REFERER`">Show Users</a>
Where DA will fill the USER_REFERER token with the relevant value.
Admin/Reseller creation to set correct "skin" based on "docroots" fixed
Both Admins and Reseller don't have a "Skin" selection option in their packages or during their creation.
The skin choice only applies to Users.
The logic is that both Admins and Reseller can change their own skin, and as such will get whatever the "docsroot" is set to, in the directadmin.conf.
They can change it later if they wish.
The bug was that, although the docsroot was correctly set in the user.conf file, the "skin" variable was hardcoded to "enhanced", which wouldn't match the skin if the docsroot was changed.
Fix was to simply figure out the skin name based on the docsroot path, and set accordingly.
Ftp backup errors not showing what the error is fixed
Bug introduced in 1.45.0 with this change:
Ability to specify a dynamic dated append value in backup paths (SKINS)
If there are error with the ftp_upload.php script, the backups system will report that there was an error in the backup, and will tell you:
Although a backup error has occurred, the upload of valid backups would have still been attempted to
but the bug was that the actual error message output from the ftp_upload.php wasn't properly added to the result string.
So, until this fix is released.. either grab the pre-release binaries to debug your ftp upload issues.. or else manually test the upload of files through ftp.
You can also manually test the ftp_upload.php to get the exact output that DA should be showing you:
http://help.directadmin.com/item.php?id=502
Combine certificate and ca bundle for nginx fixed
If nginx is being used (or the nginx proxy), a bundle needs to be saved directly into the certificate file to work.
This change will create a new file:
domain.com.cert.combined
anytime a User nginx.conf rewrite is done for a domain with a domain.com.cert and domain.com.ca file, an the certificate will be set accordingly.
If a User is pointing to use the shared server certificate, and
/etc/nginx/ssl.cert/server.crt.combined
is missing, the user ssl "save" will create the file.
If server.crt.combined exists, it won't be touched.
If an Admin on the shared server IP is saving an SSL cert or ca bundle, it will rewrite the server.crt.combined each time.
CB2.0: Add SSLCACertificateFile to User VirtualHosts is shared cert is used fixed
This is a bug, introduced when Apache 2.4.9 was released.
The issue only happened on CentOS 5. CentOS 6 (newer openssl?) was unaffected.
The related error generated by Apache was:
[Wed Apr 02 03:28:02.003967 2014] [ssl:emerg] [pid 1048] AH02562: Failed to configure certificate www.example.com:443:0 (with chain), check /etc/httpd/conf/ssl.crt/server.crt
[Wed Apr 02 03:28:02.004032 2014] [ssl:emerg] [pid 1048] SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line (Expecting: DH PARAMETERS) -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile?
AH00016: Configuration Failed
After hours of trying many different combinations, it was discovered that we were able to get apache running by adding this line:
SSLCACertificateFile /etc/httpd/conf/ssl.crt/server.ca
to ALL VirtualHost entires that used the shared server certificate, mentioned in the error.
Before we added the entry to all relevant 443 VHs, the state was such that:
/etc/httpd/conf/extra/httpd-vhosts.conf did have the server.ca (default VirtualHost for server IP)
/etc/httpd/conf/extra/httpd-ssl.conf did not have the server.ca in:
<VirtualHost _default_:443>
- All User httpd.conf VirtualHosts that used the server.crt didn't have the server.ca either.
Adding the server.ca to files #2 and #3, Apache started up.
==============
It was also noticed (for custombuild 1.2) that the same applied:
All VirtualHosts that mention the server.crt MUST load the server.ca.
When NO SSLCACertificateFile lines were used at all, apache generated the error and refused to start.
I'm not sure if the contents of the server.ca are relevant... we provide a generic file with many of the common authorities.
As the server.crt is self-signed.. (but also tested with signed, same effect)
Optimize suspension/unsuspension for show_all_users.cache fixed
Upon suspension/unsuspension, the entire show_all_users.cache is recomputed.
The reasoning at the time was that if you trigger it on a Reseller, it's quicker just to recompute the info for all accounts.
When there are more accounts, say 5000, it will not be very efficient, so the fix will be to optimize which accounts are re-computed, rather than all.
Basically, just include all selected accounts, plus any Users they may control, if they are a Reseller or Admin.
Secondary bug found where the forked process to rebuild the cache also held the client socket, so the client connection didn't close until the cache was built.
Fix was to close the client connection (without ssl disconnect) in the cache fork process.
MX name only shows a dot (SKINS) fixed
Relating to:
Subdomain MX records (SKINS) (API)
The name on the left side was only showing a single dot.
The code to fix looks like this:
|?FULL_MX_NAME=|
|?FULL_MX_VALUE=|
|*if HAVE_FULL_MX_RECORDS="1"|
|?FULL_MX_NAME=\`DOMAINFIELD\`.|
|?FULL_MX_VALUE=<input type=text name=mx_value size=18>|
|*endif|
where the change is in this line:
|?FULL_MX_NAME=`DOMAINFIELD`.|
it was previously:
|?FULL_MX_NAME=`ptr_val`.|
making it just a dot if the main domain was being edited.
Custom dns IPs for domain.com and www get duplicate merge on restore fixed
If you've got custom IPs for the 2 A records:
domain.com.
www
during the restore, when DA tries to add the linked IPs for the value the domain is set to... the domain's value gets re-added to the zone.. when that was not the intended result.
The result should have been the custom domain.com. and www A records remain the only A records, instead of duplicates for domain.com. and www being added with the domains IP.
for, example, before:
domain.com. A 1.2.3.4
www A 1.2.3.4
where the domain true IP as set in DA is set to 192.168.1.2
The 1.2.3.4 would be a manual change where the website might be on some other server.
After a restore, DA would have added:
domain.com. A 1.2.3.4
domain.com. A 192.168.1.2
www A 1.2.3.4
www A 192.168.1.2
which would not be the intended result
This fix required somewhat extensive changes to the "add IP" code for linked IPs, so testing in RC phase will be important.
8-bit base64 encode and decode fixed
Previously, the base64 encode/decode ensured that all chracters were only 7-bit (leading bit was 0)
However, password and text can contain characters with values 256 and greater (special characters), so the b64 encode/decode functions were changed to support 8-bits.
Lower max session_minutes to 35791 fixed
The setTimeout javascript for the DA auto-logout has maximum value, so the session_minutes maximum is now changed to be:
35791
which is 35791 * 60 * 1000 = 2147483648, the maximum signed number that can fit into 32-bits.
Else it flips to negative in javascript, and you get logged out instantly.