Version 1.35.0
Released: 2010-02-10
backup/restore domain pointer dns db files new
backup/restore domain pointer dns db files, since they can now be customized, it's assumed that users will want to retain this customized data for the pointer zones.
The db files for pointers are stored in:
backup/domain.com/pointer.com.db
The upon user restore, the pointer will first be created with the default zone, and then the db file will be merged with the default zone.
This merge behavior is the same as for normal domains.
domain value for action=rewrite&value=named new
Addition of:
domain=domain
eg:
echo "action=rewrite&value=named&domain=domain.com" >> /usr/local/directadmin/data/task.queue
Also optional:
update_serial=no
if update_serial is not passed, yes is assumed.
If it's set to no, then the serial number is not affected.
eg:
echo "action=rewrite&value=named&domain=domain.com&update_serial=no" >> /usr/local/directadmin/data/task.queue
echo "action=rewrite&value=named&update_serial=no" >> /usr/local/directadmin/data/task.queue
Add php version to the System Info page. new
Added the php version at the bottom of the "System Information" page in DA. Obviously, it's not a service so the "Running" or "Stopped" field will be left blank.
The API will also get the php version:
CMD_API_SYSTEM_INFO
eg:
php=%35%2E%33%2E%31
which is:
php=5.3.1
The command called for the version is:
/usr/local/bin/php -n -v 2> /dev/null
If /usr/local/bin/php does not exist, or a non-zero value is returned, the value will not show up in the System Info page, and will not show up in the API results.
Can be disabled in the directadmin.conf by adding:
show_php_version=0
The default is 1.
subdomain dns for domain pointers fixed
add A records to domain pointer dns when subdomain is created for master domain.
Security: change in process permissions for creating backups fixed
A discovered security issue was found in the backup creation process. This was caused by slight variations in the functionality of effective uid vs real uid values of processes.
Note that this fix is a far more strict form of the backup creation. If you have any apache owned directories or files, and those directories or files are chmod to 600 or 700, they will not be able to be included in the backup. They would need to be reset to be chowned to the DA user, or else chmod to 644 or 755 (whichever is appropriate)
When you update to this version of DirectAdmin, a check will be triggered that will traverse the /home/user/domains directory for all of your Users. This check will look to see if the directories and files with the domains directory are all readable by the User. If there are any files or directories which are not readable, a Message System notification will arrive to all Admin's on the box with the subject:
"A system issue requires your attention"
and the message will describe the situation and have a summary of the check for all Users. For those Users who passed the check, "Pass" will appear. For those who failed, it will list all of the files that the check flagged as unreadable.
If you see:
*** Multiple Hard Links - Security Warning ***
next to a filename, you will want to investigate what the file is, and how it got there, as it wouldn't have arrived by accident. Do not modify the chmod value or ownership of this file if you don't know what you're doing. Seek assistance from a qualified server administrator.
If you see:
Stat error on /home/user/domains/path/to/some/file: No such file or directory
It likely just means there is a dangling symbolic link, which can be ignored. That means there is a symbolic link that points nowhere, hence it's not a huge issue to resolve it.
For each file that is listed, you'll want to resolve the read problem. To do that, you'll need to check each file and directory and make adjustments to them as required to ensure they're readable by the User.
For files, one common solution would be to type:
chmod 644 /home/user/domains/path/to/file.txt
For directories, one common solution would be to type:
chmod 755 /home/user/domains/path/to/directory
However, you should understand the context of the file or directory you're changing to ensure you're not going to break things or cause security issues.
*** Do not change the chmod or ownership of a file if DirectAdmin tells you it has multiple hard links and you don't understand what that means ***
If you with to have DirectAdmin run the check again to see if you've solved all of the permission issues, type:
cd /usr/local/directadmin
echo "action=syscheck" >> data/task.queue
./dataskq d2000
and then check for the new Message in DirectAdmin.
If you do not get any new messages, they all Users have passed, and you can proceed to create backups normally.
If you have a situation where you absolutely cannot change the permissions, or feel that doing so will break your setup.. and do not wish to have tar throw errors for the files it cannot read, you can use this backup option to tell tar to ignore files it cannot read:
New backup option not available on all OSs
remote login pages to work with referer check fixed
Browsers continue to pass the remote login page as the referer, even afer posting to the CMD_LOGIN, and then receiving a location redirect. This was not anticipated during implementation of the referer check feature, where browsers continue to pass the referer from 2 requests ago.
The solution implemented is to save the login_referer in the session file. Upon the first load of /, DA will see the session has the login_referer and do a check to the currently passed referer and the value stored in the session for login_referer. If it matches, this one page load is allowed, and the login_referer variable is taken out of the session file.
Multiple forks to update cache on package change fixed
A recent change in a previous version of DA was added to update the show_all_users.cache after a change was made to a User. What was not noticed was that same function was called multiple times for all Users under a Reseller when that Reseller makes a change to one of his packages. The result of this was that the fork to update the cache file was called for each User, causing many directadmin processes to be spawn, and causing locking issues.. since not all forks could access the cache file at the same time (there is a lock file).
The fix was to add a simple flag to skip the cache update for each User, and do one efficient call for all Users at once.