newuser.history in backups/restores
Include the user.history in backups/restores. It will overwrite any previous info in the user.history that is currently present (it doesn't merge, just copies)
newadd default domain to CMD_API_ALL_USER_USAGE
For each entry in the output of CMD_API_ALL_USER_USAGE, there is now a field called "default" which will hold the default domain for that user.
newshow domain pointers in CMD_API_ADDITIONAL_DOMAINS
Another item in the output of CMD_API_ADDITIONAL_DOMAINS will be "pointers" for each domain.
This will also be enabled with this directadmin.conf value:
which is set to 1 by default.
newAbility to mark Messages as "read"
Added a button to the messages system:
Mark as Read
which will set any selected messages to be already "read".
It's the same as the button in the tickets system.. only in the message system.
Integrated awstats into DirectAdmin.
It's a global on/off swtich, and not a per domain setup.
If you wish to enable this feature for testing or use, you must install awstats.
cd /usr/local/directadmin/scripts ./awstats.sh
This will do several things.
download and install the awstats setup.
add awstats=1 to your directadmin.conf
add webalizer=0 in your directadmin.conf (webalizer will be shut off, you can override it if you want both)
Note that due to the way the log names are setup in config files, the rotation of apache logs will be slightly different during the tally.
Before the tally, all logs will not be renamed to .log.1.
Logs will be processed in place.
This has side effects in that an HUP is not going to be sent to the master httpd process right before the tally. During the rotation for each user, logs will simply be truncated instead of deleted (As they always have been for single-user tallys).
Testers should keep an eye on the effects of truncating a live log without the instant apache restart. Likely it will be fine. Also apache is restarted post tally as usual anyway.
awstats are places as static html pages into:
the config and tally data are stored in:
The advantage of having the data under /home/user, is that users can bring it with them when their accounts are moved around.
The benefit of the integrated awstats over many plugins is the security. Some awstats plugins use chmod 777 for many files and folders, meaning anyone on the system has the ability to change things around. With this setup, files are chowned to root, and chmod to a minimal setting, thus things are safe, secure, and private.
Like webalizer, with this setup, subdomains will have their own awstats page.
DirectAdmin will also parse the awstats data files to grab the bandwidth for the subdomains, so as long as the awstats are being processed for those subdomains, the bandwidth for each subdomain will show up in DA on the subdomains page (just like it did for webalizer, using the webalizer stats).
Lastly, the ../stats symbolic link on the domain stats page will point to ../awstats if the link is created. (instead of the ../stats with webalizer)
newzip and unzip to filemanager (SKINS)
Ability to create and uncompress zip files from the filemanager, similar to the tar.gz function already present.
This feature is in BETA, and is disabled by default.
If you wish to try it out, set:
in your directadmin.conf file, and restart DA.
This feature requires that you have:
and doesn't install them for you.
It's your responsibility to ensure they're present.
It's important to note that you add files to a file.zip that already exists, the zip program doesn't simply wipe the old zip file. It adds the new files to the old zip giving you an even bigger zip file with the old and new files. If you don't want this functionality, delete the old zip file before creating a new one.
The zip command used by DA is essentially the following:
cd /home/user /usr/bin/zip -ry /home/user/path/to/file.zip path/to/file path/dir
/usr/bin/unzip -qo /home/user/path/to/file.zip
|*if HAVE_ZIP="yes"| .<select name=type><option selected>tar.gz</option><option>zip</option></select> |*else| .tar.gz |*endif|
Compression of zip via API:
CMD_API_FILE_MANAGER Method: POST action=compress path=/path/youre/in file=compressedname type=zip
fixedadd failed multiserver syncs to task.queue for retry
If you're using the multiserver setup and the send fails because the other box is down, this fix will notice that it didn't make it and will add an entry to the task.queue to try again later for "x" number of attempts until it succeeds or runs out of attempts.
the default will be 0.
If you want it to do retries, set this to a higher value and restart DA.
Just be careful with this. Failed syncs will attempt to resend the data every minute until the retry counter hits zero. If, in that time, you decide to delete the domain, then the next retry will be told to sync a domain that doesn't exist (basic checks do exist for this), but don't set the retry count too high, only a value for the expected maximum duration of downtime the other box has. For example if it's a reboot, then at most, set it to 10.
Also, if you have multiple IPs in the multiserver setup and one fails, but the other works fine, this retry will resend for both IPs, so the functional dns server will get as many copies as retries.
The related task.queue command will be:
echo "action=sync&type=cluster&value=domain.com&count=10" >> /usr/local/directadmin/data/task.queue
fixedForce lowercase in pop account edit
If any uppercase letters are used in the username field when changing a password, ensure that it's lower case. Force to lower if it's not.
fixedSelect button to enable checkbox on CMD_DB broken
fixedexecuteCommand: can't figure out what to tally for action=tally&value=username
executeCommand: can't figure out what to tally for action=tally&value=username
happened if a manual reset for one specific user was issued.
This bug didn't affect the user reset itself, the reset does happen.
The error was the tally command the dataskq re-added to the task.queue for re-counting the "leftovers" from the reset. Esentially numbers just higher than 0, so the bug was quite minor, but a bug no less.
The fix was to add the missing &type=user to the end of the string.
fixedStrange characters while creating tar.gz files in the filemanager
If you get an "error while compressing file.tar.gz" type error, with a chdir error and escaped characters, it was due to two calls to getpwnam in the same string generation. What this did was wiped the result for the first one when the 2nd call was generated. Once both calls were completed, then the calling string function tried to assemble the string with a non-existent memory space. Fix is to call getpwnam once to it's own string, and use the new string twice in the assembly of the setup. The error happened randomly depending on the length and charcters of the name of the tar.gz file.
fixedchanging the default ~username public_html link back to old default
Due to confusion relating to this recent change:
We are going to be changing the default setting for the:
to the value of 1.
The option is still going to be present if you like this feature, if you don't override it you will have the previous linked method for the /home/username/public_html links.
The directory method, although more logical, caused confusion due to the name of the public_html directory, which implies "place for your files" which only applied when accessing http://188.8.131.52/~username. Users were confused when the places their files into this folder and couldn't see their files when accessing their domain (which would have been http://184.108.40.206/~username/domain.com).
If you anticipate that you will want to use this feature with the directory method (~username/domain.com) then add the old_public_html_link=1 value to your directadmin.conf now, so you won't see any changes when you update to this version of DA.
New function to reset all public_html link to whatever your old_public_html_link value is set to.
For all users:
echo "action=rewrite&value=links" >> /usr/local/directadmin/data/task.queue
For one specific user (eg: bob):
echo "action=rewrite&value=links&user=bob" >> /usr/local/directadmin/data/task.queue