Version 1.29.0
Released: 2007-01-28
catch-all option added to packages (SKINS) important changes new
option to disable the catch-all menu from a user.
Setting the catch-all to anything but :fail: is generally a bad idea with the increase in spam sending to random addresses on all domains.
admin/create_customized_reseller.html
admin/modify_reseller.html
admin/show_reseller_package.html
reseller/create_customized_user.html
reseller/modify_user.html
reseller/show_user_package.html
user/show_domain.html
user/email/catch_all.html
For most of them, basically just copy all spamassassin lines/rows, and replace:
Spamassassin -> Catch-All Emails
spam -> catchall
SPAMCHECKED -> CATCHALLCHECKED
USERSPAM -> USERCATCHALL
RESELLERSPAM -> RESELLERCATCHALL
Use same key for generating a CSR if cert/key already exist new
Use same key for generating a CSR if cert/key already exist so that your current cert/key are not removed. It would mean that you wouldn't be without a cert/key while waiting for the response from the issuer.
The current method is to backup (copy/paste) your current cert/key before creating the CSR. Once created, also backup the key created for the CSR. Then paste the old cert/key back into the space until you get a response from the issuer. At that time, use the new key you had backed up.
If your key is for some reason corrupted, then create a self-signed certificate to overwrite the previous key. The self signed certficate is valid to create a request with. Pasting a pre-saved cert/key would also work.
option for restore for local NS values or bacukp NS values. (SKINS) new
when doing a restore, DA doesn't know which NS values you'll want to use.
The bakcup NS's or the local NS that the reseller has setup.
Adding an option to the "Backup / Restore Settings" in the Reseller Level (and eventually Admin Level Backup) to give the restorer the choice of which NS values they want restored.
SKINS:
reseller/backup.html
add the following to the backup/restore settings table/form:
<tr>
<td class=list align=center>
<input type=checkbox name="local_ns" value="yes" |LOCAL_NS|>
</td>
<td class=list>
Restore with Local NameServers. (unchecked: Use NS values from backup)
</td>
</tr>
Option to completely block high scoring spam (SKINS) new
Ability to add an extra spam score where the filters will completely delete the spam. This is useful if you're worried about false positives, but still want to get rid of spam that spamassassin knows for sure is spam. Example, set your spam threthold to be 4.0, but don't redirect the spam (it will still arrive), and set high scoring spam (eg, 15+) to be dropped immediately. This leaves you some breathing room "just in case", but gets rid of things that are undoubtedly spam.
SKINS:
user/email/spamassassin.html
add:
<tr><td class=listtitle colspan=2>Would you like to delete high scoring spam?</td></tr>
<tr><td class=list align=center><input type=radio name=high_score_block value="yes" |high_score_block_yes|></td><td class=list>Yes, block all spam scoring higher than: <input type=text name=high_score value="|high_score|" maxlength=2 size=2> (1-99, no decimals)</td></tr>
<tr><td class=list2 align=center><input type=radio name=high_score_block value="no" |high_score_block_no|></td><td class=list2>No, do not block high scoring spam. Use only the threshold in the previous section.</td></tr>
<tr><td colspan=2> </td></tr>
to:
/usr/local/directadmin/data/templates/filter_base
add:
|*if BLOCKLEVEL|
if
$h_X-Spam-Level: contains "|BLOCKLEVEL|"
then
seen finish
endif
|*endif|
CMD_CHANGE_FTP_PASSWORD to change their own ftp password new
CMD_CHANGE_FTP_PASSWORD is similar to CMD_CHANGE_EMAIL_PASSWORD in that a directadmin login/password is not required.
Related:
Virtual Email API for passwords and listing.
Note:
you cannot change your system ftp account with this.
you must use the full user@domain.com format, even for owned IP accounts that have a login of just "user" .. you always require the domain.
Users can access:
domain.com:2222/CMD_CHANGE_FTP_PASSWORD
to get a interface to change their password.
You can post to the command while having the form on your own web page.
action="http://domain.com:2222/CMD_CHANGE_FTP_PASSWORD"
method: POST
ftp=user@domain.com
oldpassword=theoldpass
password1=newpass
password2=newpass
You can also pass:
redirect=http://where.you/want/togo.html
to have DA redirect the browser to that page after a successful login (same as CMD_CHANGE_EMAIL_PASSWORD)
If you want to call this using the API, simply also include:
api=yes
to have the results as url encoded.
Do NOT pass
api=no
if you do not with to have results, as the value isn't checked, only the presence of "api".
new template:
/usr/local/directadmin/data/templates/ftp_pass_change/index.html
if you want to customize it, create:
/usr/local/directadmin/data/templates/ftp_pass_change/custom/index.html
new pre/post.sh scripts:
/usr/local/directadmin/scripts/custom/ftp_change_pass_pre.sh
/usr/local/directadmin/scripts/custom/ftp_change_pass_post.sh
values pass:
ftp: user
domain: domain
main_domain: 1 or 0 (is this the main IP of the user account)
is_owned_ip: 1 or 0 (is this account on an owned IP)
passwd: newpass
the main_domain and is_owned_ip are important.
If both of them are 1, the ftp login for is just "user" and not "user@domain.com" (even though the change password form requires user@domain.com in all cases)
All cases of is_owned_ip=1 means the ftp.passwd file is:
/usr/local/directadmin/data/users/username/ftp.passwd
and not /etc/proftpd.passwd.
A few more things added to Admin Level Backup new
Note this feature is still beta and not recommended for a production server.
The "modify crons" feature is not yetimplemented.
Added the ability to modify the local path when selecting the local save location option. Note that the directory specified must exist and must be writeable by the Admin that creates and restore the backups. (hence it's safer to use 1 Admin account for creating and managing your backups.
Basic beta testing is now open for this feature, if you dare 😉
Again, I still do not recommend testing on a live server (especially with restores)
Also added backup option at the bottom of the page, similar to changes in the Reseller Level Backup.
Options are:
ability to suppress success messages for backups. Emails are still send on errors. It's recommended to test with this option turned on to ensure the emails are correctly being sent out. (option not available for restores as there are no cron restores)
ability to specify a local or backup NS restore option. This means that DA will either take the NS values from your Reseller Level Settings (nameservers)
spf record IP not swapped with restores fixed
The IP in the spf TXT records are not being swapped to the new value.
All TXT record values that begin with:
"v=spf1
will be dropped (from active local, and remote), and the server spf record added in all cases.
DA has no way of knowing if the spf IP in the backup is from the previous server, or for a remote email server used to send email. If there is a remote mail server that is used to send mail (without DA on it), then this case must be manually fixed.. the spf record would have to be manually changed. DA can't predict this.
when changing IP of domain, spf record changes too fixed
When you change the IP of your domain... if you used to be on the server IP and are moving off of it, your SPF record will end up being changed as well. The spf record should always hold your server IP (the IP that exim sends to send email).
plugins system plugin.conf file empty fixed
When installing plugins, the included plugin.conf is emptied an only contains:
active=yes
installed=yes
fix will read in the new plugin.conf, merging those 2 previous values (if they exist from the same plugin), then save the file.
I'm assuming current plugin designers are re-filling the plugin.conf with the install scripts which would work fine as well.
db restore on remote system when mysql system account not present (closed) fixed
if a backup is created, and the mysql system account isn't present, DA will add a fake on with crypted password "unknown" (the crypt itself, not the password).
Reported issues with doing restore when using a remote host mysql server. (likely to do with using localhost in certain password swapping queries instead of the remote.host.com.)
UPDATE
after testing, the only way to duplicate database restore errors was to not have the system mysql account in the user_dbname.conf file at all. With the addition of the system account with the "unknown" password as of several versions ago, this cannot happen. Bug closed pending problems with current versions of DA (none known as of yet). My guess is the report made was using an older version of DA, thus the account wasn't in the database and also wasn't added to the conf file.
Update to a new version of DA to create the backups and that solves it.
Always duplicate the problem with the most recent version of DA before reporting a bug.
Multipart form data handle missing content-type from some browsers fixed
When doing a file upload through a web browser, the multipart form data format of encoding the post is used.
On most browsers, the file portion has these headers:
Content-Disposition: form-data; name="file1"; filename=""
Content-Type: application/octet-stream
But on some borwsers, the Content-Type is not passed (I've only seen about 2 browsers not pass this header)
the result is that DA ends up reading one too many lines, and the parsing gets out of sync. The result is that form data included after the file is not parsed in correctly, most notably the password in the Plugins manager section. This should fix that problem (browsers, konqueror and safari)
Count /etc/virtual/domain.com/majordmo fixed
This directory wasn't being counted. Majordomo digest/archives can use up a lot of space, thus should be counted.
email_change_pre_post.sh should be email_change_pass_pre.sh fixed
The custom script for user self password changing should be:
email_change_pass_pre.sh
and not:
email_change_pre_post.sh