Version 1.33.7
Released: 2009-06-26
tally_user_post.sh new
custom script:
tally_user_post.sh
called after the tally for a user is completely done.
Environmental variables passed are the contents of the users user.conf file.
Purge button for email accounts based on days new
For system with dovecot install (Maildir) the "Empty" button on the CMD_EMAIL_POP page has been replaced with a "Purge From" button.
The 3 radio boxes have been replaced with a selectbox for the inbox/imapfolders/spambox... and another selectbox has been added to contain: "All E-Mail", as well as "Older than x days" for multiple selections for different numbered days.
What this will do is allow Users to keep their inboxes cleaner by being able to delete all emails older than x days, in addition to being able to empty them entirely. They can chose the inbox, the imap folders or the spambox.
The default options for the selectboxes are "spambox" and "All Email", just as they were before, so it will still be a 1 click to delete all emails from the spambox, just as before.
The previous "empty" button will still be valid (for APIs too if used), but this new version can be used as well, so it's backwards compatible.
API: CMD_API_EMAIL_POP
Note, the CMD_API_POP does NOT support this function.
However, you can use the API version of CMD_EMAIL_POP, which is:
CMD_API_EMAIL_POP
method: POST
action=delete
purge=<any text>
file=inbox|imap|spambox|attachments
(what=all|<positive integer>)
Option to give Users ability to change skins on their own new
Skins have typically been chosen by Reseller/Admins, but this option gives a simple dropdown on the Acccount/Stats/Logs page in their User Level, allowing them to chose any skins visible to their creator. To enable this feature, add:
user_can_select_skin=1
to the directadmin.conf, and restart DA.
The internal default is set to 0, so this option is not enabled by default.
Possible reasons why you wouldn't want to enable this:
If you've got some custom skins with specialized code you don't want your users to see. Note this feature give Users visibility of All skins on the system in the global location:
/usr/local/directadmin/data/skins/*
as well as in their creators home directory (permissions permitting)
/home/creator/skins/*
If you are a skin designer and don't want Users seeing the skins you're working on, keep the skins under a test Reseller and not globally.
Note, if a Reseller has custom skins in /home/reseller/skins, those skins will not show up with this feature, as it would be checking his creators path for skins, eg: /home/admin/skins/*. He can still change his skins via Reseller Level -> Skins, so he's not losing any functionality.
user_backup_pre.sh new
user_backup_pre.sh
will be called before anything is done for user backup creation.
non-zero return value will abort user backup creation.
variables:
username=joe
reseller=resellername
file=/path/to/the/user.tar.gz
uid counter for new users new
This is a security feature where DirectAdmin manages 2 files:
/usr/local/directadmin/data/admin/high_uid.number
/usr/local/directadmin/data/admin/high_gid.number
these files contain the last highest uid/gid values created through DA.
Upon creating new Users, DA will check these 2 files, as well as the /etc/passwd and /etc/group, and check to see what the current high uid/gid values are, and use that value+1 for the next User (followed by saving the high_uid.number and high_gid.number with these new values).
The benefit of this, regarding security, is that the same uid/gid values are never used again after a User is deleted. All new Users get a new, never before used id value. This ensures that no lingering files on the system can have any effect on their new account.
High values in the /etc/passwd and /etc/group files greater or equal to 40000 are ignored. This is because by default there are some system accounts (eg: nobody:65534) that exist there already, and we don't want to create users higher than that.
For any systems that do a lot of adding/removing of users, or that simply have a very high number of users, these 2 counter files may grow very quickly.
If you need to disable this feature, simply add:
use_uid_counting=0
to your directadmin.conf file, and restart DA, then the old method of letting the useradd/pw commands decide ids, is used.
The internal default is 1, so this feature is enabled by default.
Option for graceful restart for apache new
Graceful restarts will not disconnect any current client connections.
All idle child processes are killed, and new ones started with any config changes.
The existing connections are left to finish, and once completed, they die, and new child processes with the new config changes will replace them.
It's considered more "polite" and you don't notice any downtime while apache fully stops then starts.
This feature is still in testing, considered BETA at this time.
It assumes that the graceful command is setup in your /etc/init.d/httpd boot script.
Most scripts will simply have something like:
graceful|help|configtest)
$apachectl $@
which is fine.
To enable this feature, add:
graceful_restarts=1
to your directadmin.conf, then restart DA.
Any call to add action=httpd&value=restart to the task.queue file will have it replaced with action=httpd&value=graceful.
Note that the full extent of not doing full retarts is not yet known, hence testing is required. Preliminary test show no issues when adding and removing new virtualhost with SSL certificates in apache 2.2.
Note that restarts issued in the service monitor will still do full restarts.
CentOS 7+ will have this option enabled by default with systemd.
This is because systemd doesn't know what "graceful" is.. it only knows reload.
The httpd.service has "ExecReload" trigger a graceful restart.
With CentOS 7+, this option will call a reload command.
allow leading plus in email names new
https://forum.directadmin.com/showthread.php?p=159577#post159577
Encode sort options in table advanced searches new
Issue where crafted variables passed to the advaned search pages get inserted into the html form on the next page without checks. Solution was to encode the passed data so that it cannot do any harm.
clear webmail attachments folder on empty fixed
https://forum.directadmin.com/showthread.php?p=155169#post155169
Added "Webmail Attachments" to purge/empty dropdown.
The "All E-Mail" and "older than x days" also works on this choice, so you can chose to do all attachements (which would really be the only one that makes sense) or selectively using a specific date.. which doesn't make sense, but since the option is there for other inboxes, may as well avoid the confusion and be consistent.
Addition: included the webmail's inbox cache to be cleared with the attachments. This is just a cache, and has no other means of being cleared. The main storage location of the inbox is through pop, so clearing the cache will not remove anything important.
freebsd to only use dmesg.boot for cpu info fixed
Change freebsd cpuinfo for "system information" to only grab cpuinfo from dmesg.boot, and not load up the compat procfs.
plugin index.raw to send in chunks fixed
The index.raw method for controlling all session output used to send 1 byte at a time. For many systems this is fine, because the network would buffer up a few bytes, then send them in larger chunks. However it was reported that some systems don't do this buffering which greatly slowed down the sending of index.raw data due to the overhead of sending packets with only 1 byte in them.
Solution was simple, to buffer up the data within DA and sending that buffer in larger chunks, thus giving the transfer of the same data fewer packets, hence faster transfers.
Bandwidth details off by a day fixed
The bandwidth details page was off by a day because the date logged was the date that it processed the data. However, the tally always runs the day after the data was actually logged, hence it was off by one. This resulted in the day 1 stats being essentially nil bandwidth, and each day's stats totals were showing up before that day was actually finish.
One result of this change is that the last day of the month will never been seen, which is logically correct, since it's stats are not know until the very end of the month.. however, the reset will happen at that time, so the details would be wiped out anyway.
ftp accounts not renamed upon domain name change fixed
https://forum.directadmin.com/showthread.php?p=159425#post159425