Version 1.42.0
Released: 2012-11-04
change user passwords for CMD_API_DATABASES new
change user passwords for CMD_API_DATABASES
Similar to CMD_DB, options are:
CMD_API_DATABASES
Method: POST
action=modifyuser
domain=domain.com
name=user_dbname
user=user_dbuser
passwd=password
passwd2=password
Allow blank Division with SSL Certificate Requests new
New rules with regards to ssl certificates require that if a field is specific in a certificate, it must be accurate.
The "OU" field in a certificate describes the "Division" of a company, however in many companies, they don't have divisions.
In this case, the division should be blank, else the certificate authority may deny your certificate request.
This change in DA is to allow the Division field to be blank when creating an SSL certificate and SSL Certificate request.
The result is the the OU field wil not be present in the request, so it won't be checked by the certificate authority.
If you do have a division in your company, then you must still set it accordingly.
Related (note how there is no OU field):
http://help.directadmin.com/item.php?id=443
load_spike_notice_pre.sh and load_spike_notice_post.sh new
Related to feature:
Pre/post scripts for the load notice.
If DA notices a load spike, these scripts will be called, if they exist:
/usr/local/directadmin/scripts/custom/load_spike_notice_pre.sh
/usr/local/directadmin/scripts/custom/load_spike_notice_post.sh
This would give an Admin the ability to automatically restart a service (or any other desired action), should it be known to be problematic with regards to causing high load.
With load_spike_notice_pre.sh, if a non-zero result is generated, the notice to the Admin's is aborted.
This is called before the message is sent.
The load_spike_notice_post.sh is called after the message has been sent.
The return value of load_spike_notice_pre.sh will not affect the code.
Both scripts will log the output to the errortaskq.log if a non-zero value is produced.
CMD_API_MULTI_SERVER new
API version of CMD_MULTI_SERVER.
It should already work, just need to add documentation here.
For now, run DA in debug mode with the "| grep string" option, to see what your browser is passing.
Use the same commands and options for your script.
CMD_API_PROCESS_MONITOR new
API of CMD_PROCESS_MONITOR
Output will be url encoded array.
boxinfo= text of the top section of the "top" output. Includes newline characters (all encoded, of course)
headers=0=PID&1=USER&2=etc.. each header, text access from the numbers (text is direct from the top output)
0=0=716&1=root&10=0:00.01&11=/usr/bin/top -c -b -n 1 &2=15&3=0&4=2552&5=876&6=660&7=R&8=2.0&9=0.4
1=...
2=...
3=0=26158&1=apache&10=0:00.00&11=/usr/sbin/httpd -k start -DSSL &2=18&3=0&4=13248&5=7544&6=2712&7=S&8=0.0&9=3.4
each PID on the system is shown.
The index (left value) is just a counter from 0, and not the actual PID number.
the PID number itself is usually going to be header number 0, in the data to the right of the index (Eg: 0=716 and 0=16158)
However, the output is determined 100% by how top displays it.. so if it's different on some system, then the output order may also be different (although, I don't recall ever seeing it in a different order)
Because the API does not use sessions, the root authentication is not possible at this time, hence signals cannot be sent through the API (cannot kill processes, or send HUPs, etc.)
The "admin" password is not sufficient authentication to kill processes.
netmask for IPv6 IPs eg: /64 (SKINS) new
The netmask field in the IP Manager now supports /mask values, eg:
IP: <anyipv6>
netmask: /64
All existing IPv6 IPs will use /64 as a default, unless otherwise stated.
If you want to change existing IPs, edit their configs:
/usr/local/directadmin/data/admin/ips/<value>
and set /<value> as desired.
Debug mode for checking netmask validity is only exactly at level 2150.
Also added a new global token:
HAVE_IPV6=yes|no
depending if it's enabled or not.
minor changes added to the scripts/addip script to accept the netmask (ensures only /# format is used, 255.255.255.0 format is ignored for IPv6)
SKINS:
admin/ip_manager.html
|*if HAVE_IPV6="yes"| For IPv6 IPs, use a /mask, eg: /64|*endif|
or for enhanced and language files:
|*if HAVE_IPV6="yes"| |LANG_IPV6_MASK||*endif|
Added TTL to Admin Level DNS Admin (SKINS) new
Added a TTL field to the zone edit feature:
Admin Level -> DNS Admin -> domain.com
only works on local domains, which are owned by a User, and not a domain pointer.
SKINS:
admin/dns_admin_control.html
add this, before the </form> entry:
|*if ALLOW_TTL_OVERRIDE="yes"|
<form action='/CMD_DNS_ADMIN' method='POST'>
<input type=hidden name=action value=ttl>
<input type=hidden name=domain value="|domain|">
<input type=hidden name=user value="|ZONE_USER|">
<tr>
<td class=list2>Override TTL Value</td>
<td class=list2 align=center>TTL</td>
<td class=list2><input type=radio name=ttl_select value="custom" |TTL_CUSTOM_SELECTED|><input type=text name=ttl size=6 value="|TTL_VALUE|"> <input type=radio name=ttl_select value="default" |TTL_DEFAULT_SELECTED|>Use Default</td>
<td class=list2 align=center><input type=submit value="Save"></td>
</tr>
</form>
|*endif|
CMD_API_DNS_ADMIN?info=yes new
Extra option for CMD_API_DNS_ADMIN, where you can add info=yes as a variable, and DA will generate a double url encoded list with a zone name, and:
is_local=yes|no
is_local_mail=yes|no
Changed MB to scalable size for Usage (SKINS) new
Admin Level -> Complete Usage Stats
Reseller Level -> Reseller Stats
Changed the text:
Bandwidth (MB) 12345
Disk Usage (MB) 12345
to be
Bandwidth 12.34 GB
Disk Usage 12.34 GB
Where the units used change depending on the scale of the number.
All the way from B to TB.
CMD_API_SHOW_USER_CONFIG to show additional IPs new
Extra value "ips" added to output, eg:
ips=1.2.3.4|5.6.7.8|1:2:0:0:0:0:0:8
Note that "ip=1.2.3.4" is still in the output, which is the "main" IP for the User (DA highlights this IP in green)
Also added:
email_limit=
which is the number from /etc/virtual/limit, or /etc/virtual/limit_username, whichever applies.
Add backup id to backup results new
When a backup finishes, include the backup ID with the message, eg:
Your backups are now ready (id=4)
or:
An error occurred during the backup (id=4)
where id=4 would imply that backup cron id 4 was the cron backup that was just run.
The "Modify" button on both Admin and Reseller Level backup pages will now include the ID beside them, eg:
Modify 4
Also include a timestamp next to each User being backed up.
User user1 has been backed up. <12:39:25>
User user2 has been backed up. <12:41:34>
such that the completion time of the creation of each tar.gz User backup is logged.
Note that this time is before the ftp transfer (if used).
If there is an ftp upload error, a timestamp will be included along with the ftp error output, eg:
User test has been backed up. <1:27:30>
ncftpput: cannot open 1.2.3.4: username and/or password was not accepted for login.
<1:27:30>
which could be useful for debugging logs.
Hide domain disk usage when simple_disk_usage is enabled (API)(SKINS) new
When the simple_disk_usage option is enabled:
This will rely 100% on the system quotas for disk usage.
This means that DA will not manually count data for more detailed stats.
As such, showing a "quota" column for domains in CMD_USER_STATS and CMD_ADDITIONAL_DOMAINS would be confusing.
When simple_disk_usage=1 is set, DA will hide the Disk Usage columns for the "Domain Setup" and "Stats/Logs" pages.
It will also hide the Email Usage row, on the Stats page.
This has also been changed with:
CMD_SHOW_USER and CMD_API_SHOW_USER
the Disk Usage column is hidden, and the Email Usage row is hidden.
API:
This also applies to API calls:
CMD_API_ADDITIONAL_DOMAINS: disk usage will be returned as: quota=simple_disk_usage, instead of a number.
For CMD_API_SHOW_USER, the number for the disk usage is returned as "simple_disk_usage".
SKINS:
Although no html files were changed, it's important to note the changes to the tables.
Some skin designers may be parsing the tables, so the missing columns could throw off their code.
Per-DA-User email send limit in interface (SKINS) new
Related to feature: Per-Email send limit
Requires exim.pl version 10 or higher (active check in DA is done)
Feature disabled by default. See below to enable it.
Admin Level -> Show All Users -> user
or
Reseller Level -> List Users -> user
Adds a text input and "Save Limit" button, eg:
[200] / Day [Save Limit]
The default value is from:
/etc/virtual/limit
When you add a number it creates:
/etc/virtual/limit_username
where username is the DA username.
To delete the limit_username and revert to the default, simply set a blank value and click "Save Limit".
0 is unlimited.
Note that a Reseller does not have access to this feature by default because of the internal option:
reseller_can_set_email_limit=0
Only Admins have access to this form.
To enabe it for Resellers, add this to the directadmin.conf with:
reseller_can_set_email_limit=1
and restart DA to override the option.
The upper limit that can be set by a Reseller is controlled by this variable (default):
max_user_send_limit=-1
where -1 implies that the upper limit is taken from /etc/virtual/limit.
max_user_send_limit=0 implies no limit (unlimited)
If max_user_send_limit is set to a number higher than 0, then the number which is set it the limit.
SKINS:
no html changes are needed.
Only the hardcoded tables are changed.
Language files also changed:
internal/command.txt
internal/email.txt
Per-Email send limit (SKINS) new
Relates to:
Per-DA-User email send limit in interface (SKINS)
Users can set a per-email send limit via the interface.
Requires exim.pl version 10.
By default (for now) this option is disabled:
user_can_set_email_limit=0
To enable it, set:
user_can_set_email_limit=1
Note that regardless of the limit set, all email account sends are still limited by the DA-User limit, one of:
/etc/virtual/limit
/etc/virtual/limit_username
For example, the DA user has a limit of 50 in:
/etc/virtual/limit_username.
so 10 email accounts, each with a per-email limit of 10 can still only send 50 emails total among all of them, not 100.
example: /etc/virtual/limit_fred
This also only applies to smtp sends.
If emails are sent via command line, the per-email limit will not be used, but the per-DA limit will be used.
If user_can_set_email_limit=1 is set, then on the "E-Mail Accounts" page, you'll see a new column called:
Sent
which will show the number of emails sent today.
If a limit is set for that User, the limit is then displayed, eg:
2 / 5
if no per-email limit is set, but a global per-email is set in (exact name... perhaps email_limit would have been less confusing, too late now):
/etc/virtual/user_limit
then that limit will be shown, eg:
2 / 50
If no limit is set... and no user_limit is set, then no limit will be shown, eg:
2
This is because it's not "unlimited" since the cap of
/etc/virtual/limit
/etc/virtual/limit_username
will still apply, so saying it's "unlimited" would be confusing.. and the limit in these per-DA User limit files are the total for all Users, so saying that the email-limit is the DA-User limit is not usually true, and would be confusing.
If /etc/virtual/user_limit is missing, then DA will fallback to use /etc/virtual/limit instead.
Feature will save send/limit into the usage.cache, if that feature is enabled.
Related option (default):
max_per_email_send_limit=-1
The -1 implies that the max value that can be set by a User reverts to the global default in:
/etc/virtual/user_limit
If you set max_per_email_send_limit=0, this overrides the global default and allows unlimited messages to be sent (not recommended)
Any number for max_per_email_send_limit above 0 will be the number of sends allowed.
Remember that local deliveries do not count in the send count.
Only remote deliveries are counted, since only they use any bandwidth.
SKINS
user/email/pop.html
New "create email" link:
user/email/pop_create.html
new form item:
|*if USER_CAN_SET_SEND_LIMIT="yes"|
<tr><td class=list>Send Limit</td><td class=list><input type=text name=limit size=16 value=""> Zero is unlimited. Blank will default to |GLOBAL_PER_EMAIL_LIMIT|</td></tr>
|*endif|
user/email/pop_modify.html
new form item:
|?SEND_LIMIT_VALUE=|
|*if SEND_LIMIT!="no"||?SEND_LIMIT_VALUE=\`SEND_LIMIT\`||*endif|
|*if USER_CAN_SET_SEND_LIMIT="yes"|
<tr><td class=list>Send Limit</td><td class=list><input type=text name=limit size=16 value="|SEND_LIMIT_VALUE|"> Zero is unlimited. Blank will default to |GLOBAL_PER_EMAIL_LIMIT|</td></tr>
|*endif|
New template custombuild 2.0 new
New template:
/usr/local/directadmin/data/templates/user_virtual_host.conf
which is added into a User's httpd.conf file before any VirtualHosts.
It's used to setup <Directory /home/user> settings for suPhp, mod_ruid, and php-fpm for the even that /~username is used.
With php-fpm, this allows the /~username method to still use all php.ini settings (open_basedir), and runs the scripts as the user, instead of apache.
Mod_ruid2 should also run everything as the user, if it's under /home/user.
Like all templates, you can create data/templates/custo/user_virtual_host.conf, and it will override the main template, and will be safe from overwrites.
PACKAGE token added to all dns_*.conf templates new
As the need for flexibility in the default dns settings grows, I've added a new token:
PACKAGE
will will be available in all dns_*.conf templates, as well as the named.db template.
The PACKAGE value will not be present if the zone does not have an associated User on this box...
However, for any domains that are created on this box under a DA User, the token should be there.
For example, you may want to set your MX records differently, based on package.
To do this, type:
cd /usr/local/directadmin/data/templates/custom
cp ../dns_mx.conf .
Edit the custom/dns_mx.conf file, and set this in the file:
|*if PACKAGE="remotemail"|
mail.remoteserver.com.=10
|*else|
mail=10
|*endif|
where "remotemail" is the name of the User package set that is to use:
mail.remoteserver.com.
as the mail server.
Related, if the final destination is not on this box:
http://help.directadmin.com/item.php?id=8
BFM automated unblock (SKINS) new
Ability to unblock an IP based on time.
Only works if the reported IPs from ./show_blocked_ips.sh returns the dateblocked value, eg:
1.2.3.4=dateblocked=1346259183
specific directadmin.conf settings to be determined.
Will likely be:
unblock_brute_ip_time=0
in minutes, where 0 is never.
0 will be the default.
Related:
BFM: show_blocked_ips.sh and unblock_ip.sh (SKINS)
Note that the HAVE_BF_UNBLOCK_AFTER_TIME token is only set to 1 if both scripts/custom files exist:
unblock_ip.sh
show_blocked_ips.sh
as both of these scripts must be installed and working in order for this feature to work.
SKINS:
admin/admin_settings.html
|*if HAVE_BF_UNBLOCK_AFTER_TIME="1"|
<tr>
<td class=list>
Remove an IP from the BF blacklist after
</td>
<td class=list>
<input type=text name=unblock_brute_ip_time value="|UNBLOCK_BRUTE_IP_TIME|" size=4> minutes (0 = never)
</td>
</tr>
|*endif|
Save the bandwidth breakdown for previous months (User History). new
Since we already have the bandwidth.tally.cache file, just before the monthly reset, save a copy of this file for future viewing.
This will allow comparisons between past months.
Will have a new folder:
/usr/local/directadmin/data/users/username/history
and each file would be called:
2012-09.log
for example.
Note that the creation of this log is not merely a file copy.
Instead it's a smart merge, in case the reset is run many times.
Only the last months data will be set there.
For the current month, use the normal "Details" button on your stats page.
To view these history files, they'll be under the "User History" button, which already exists.
If more than 0 files exist in the "history" directory, a new "Details" column will be added to the User History page, where a JS popup will show the previous months.
No skin changes are needed, as it uses existing code.
CMD_API_BANDWIDTH_BREAKDOWN will be able to use this as well.
Just add year=2012&month=9 to the end of your call (either the ?user=user method, or the "self" method with no "user")
CB2: hide items from php safemode page new
Linked:
Admin Level -> Php Safemode Config
into CustomBuild 2.0 php-fpm, where it now changes the open_basedir on/off switch in the data/users/user/php/php-fpmXX.conf file.
Also for CB 2.0, hide safemode, since it's depreciated and removed from 5.3/5.4.
Note that the open_basedir settings in the php-fpmXX.conf (since it's per user and not per-domain) will be controlled by the open_basedir setting for the main domain of the account.
So the on/off switches for all non-main-domains under a User account will not have any effect on the open_basedir setting for this entire user.
Optimization of search for Show All Users new
Added a table optimization on the Show All Users page.
If the "User" is searched for, a pre-filter is done on the value before it's added to the table.
If it doesn't match, it won't be added to the table.
Same is done for the domains, although, the cache still needs to be loaded in before DA can see the domains list anyway, so the improvement won't be as significant.
However, this will save the adding then removal of data from the table based on the filter, speeding up the process.
per-service memory usage on Services Monitor (SKINS) new
A new column has been added to the Services Monitor page.
This new column will show how much memory this service is using.
This info is grabbed from a new script:
/usr/local/directadmin/scripts/service_memory_usage.sh
which uses ps, awk and grep to figure out the values.
SKINS:
admin/show_services.html
Since the old method had a table hard-coded, the old |SERVICES| token will remain, for backwards compatibility.
New skins, or skins that that want to update (recommended) should completely remove the entire old <table>..</table>, and |SERVICES| token.
Replace that remove code with:
|SERVICES_TABLE|
which provides a standard dynamic table (searching), along with the memory usage column.
Lastly, since this table is getting somewhat wider, we've changed to use:
|HTM_HEADER_FULL|
|HTM_FOOTER_FULL|
as the side-bar is not needed on this page.
The reboot row is added to the bottom of the table using a listtitle class.
Backup/Restore /etc/virtual/limit_username new
Add the files:
/etc/virtual/limit_username
to the User backup/restores.
Backup FTP pre-check new
When creating a DA backup that uses FTP, a new option has been added which will test the listing of the ftp information before the backups are created.
This will save time in that the Admin/Reseller will know wrong information has been generated before waiting for all backups to be created.
The internal default will be set to:
backup_ftp_pre_test=1
and can be added to the directadmin.conf with a value of 0 if you wish to disable this feature.
This feature relies 100% on the exit value of the script:
/usr/local/directadmin/scripts/ftp_list.php
/usr/local/directadmin/scripts/custom/ftp_list.php (if this exists, it will have priority)
An exit value of 0 must be returned, else DA will throw an error when the backup job is created, before any Users are backed up.
Note that during the implementation of this feature, a few bugs were found in the ftp_list.php and fixed (regarding exit codes).
Also, more output is generated by the script in the event of non-zero return codes from ncftpls (eg: wrong path would be blank, so script now checks for code 3 and adds text)
If you've customized your ftp_list.php, you must ensure that the exit codes are working properly.
A value of 0 is required to pass the check.
A non-zero value will abort the backup creation, and the output from the script will be immediately displayed to the Admin/Reseller in DA.
forwarder_create_pre.sh, forwarder_create_post.sh, forwarder_delete_post.sh new
Custom scripts for creating, setting, and deleting forwarders:
forwarder_create_pre.sh
forwarder_create_post.sh
Environmental variables passed:
username=fred
file=/etc/virtual/domain.com/aliases
user=forwadername
value=email.com
domain=domain.com
If you exit with a non-zero value, the action is aborted.
Aborting with a post.sh script wouldn't abort the action (it's already done) but will throw an error.
All text generated will be displayed in the DA interface.
Note that this will also be called when the catch-all is set.
There is already a forwarder_delete_pre.sh:
autoresponder_delete_pre.sh and forwarder_delete_pre.sh
so I've just added a forwarder_delete_post.sh.
The "value" is not passed when deleting.
manually created task.queue cronjobs need database_data fixed
Relating to:
Ability to exclude DB data from backup, but include DB Settings (SKINS)
If you have manually created a backup cronjob which echos to the task.queue, and have used the what=select option to pick and chose which options you want to backup, DA will now notice that database_data_aware=yes is not present, and if option123=database is present, DA will automatically add option99=database_data, to ensure databases are included.
Please update your cronjobs to have database_aware=yes&option99=database_data to your manual cronjobs.
Note that this does not affect anything if you've setup all of your cronjobs through DA, as DA should have already updated them with the database_aware=yes option, and enabled database_data, if database was on.
This also does not affect any cronjobs that use what=all. Only the what=select where the checkboxes are used to select which data to backup.
Forum thread:
https://forum.directadmin.com/showthread.php?t=43913
usernames ending in bytes end up with large bandwidth usage fixed
If you have a username, say mybytes, the script:
/usr/local/directadmin/scripts/rotate_email_usage.sh
would find:
/etc/virtual/usage/mybytes
/etc/virtual/usage/mybytes.bytes
instead of just:
/etc/virtual/usage/mybytes.bytes
for rotation into the bandwidth.tally.
This caused 11111 characters to be added to the bandwidth.tally file for that User (without a newline character), thus adding that many characters to the leading count of bytes for that tally line.
Basically, it would add something like:
111111645534=type=tally.. etc..
to the bandwidth.tally making the bandwidth many orders of magnitude higher than it should be.
Fix was to change the rotate_email_usage.sh not to do that.
Reset Zone button not including additional IPs fixed
Reset Zone button not including additional IPs
It's only including the ip=1.2.3.4 from the domain.com.conf, but needs to include the domain.com.ip_list instead.
Change pointers when changing User nameservers fixed
When chaning the ns1/ns2 values for a User, previously only the domain's zone was updated with the new NS records.
Now, both the domains and the pointers of those domains will be updated.
https://forum.directadmin.com/showthread.php?t=44453
Added Login Keys to backup/restore fixed
The Login Keys will now be backed up from all Backup Levels.
However the restore of the keys will only take place if the backup is restored at the Reseller Level or Admin Level.
HAVE_SAFE_MODE token not being set fixed
If safemode was turned on for a domain, and you're using CLI, the HAVE_SAFE_MODE option wasn't being correctly set, so the option wasn't being set in the user httpd.conf files.
Note that safemode is depreciated in php 5.3 and removed in 5.4, in favor of other security measures (suphp, mod_ruid2, php-fpm, disable_functions, secure_access_group, etc..)
http://php.net/manual/en/features.safe-mode.php
BFM support alternate syslogd date format fixed
On some systems, syslogd uses a different time format, eg:
2012-10-25T14:17:06.554268-05:00 hostname sshd: etc
instead of the more common method:
Jun 9 08:14:19 hostname sshd: etc
DA will check the first character of the line.
If it's a number, the alternate format will be used instead.
DKIM keys to be 2048-bit and multi-line TXT records fixed
DKIM Keys were 768 bits.
Change to script/dkim_create.sh to use 2048 bit keys instead, during creation.
This change will not affect existing keys.
If you want to redo the keys for existing domains, you'll need to type:
cd /usr/local/directadmin/scripts
rm -f /etc/virtual/domain.com/dkim.*.key
./dkim_create.sh domain.com
This will give you new keys, and also update the zone (within 1 minute)
Related thread:
https://forum.directadmin.com/showthread.php?t=44891
The extra long TXT zones exceed named's max record length, so steps are added to store and read long zone values in chunks.
eg:
instead of this, which will break the zone:
value TXT "reallylongrecord"
it becomes:
value TXT ( "really"
"long"
"record" )
DA will handle the chunks for you... hence you need the new DA binaries to use 2048 bit keys.
When viewing a record in DA, the assembled value is displayed (no chunks), even if the db files has chunked values.
Some other URLs describing multi-line TXT records:
http://www.zytrax.com/books/dns/ch8/txt.html
http://razzed.com/2009/03/05/dkim-txt-records-in-dns-exceeding-255-characters/
http://superuser.com/questions/657789/format-of-txt-data-in-dns-record