Version 1.41.0
Released: 2012-06-10
MAILTO for cronjobs (SKINS) new
New field in cronjobs area allowing Users to set MAILTO=user@domain.com option for cron output.
https://forum.directadmin.com/showthread.php?t=30152
Valid values would be:
user@domain.com
username (DA login)
and a blank value (no spaces, no characters), where DA will set:
MAILTO=""
so no email is generated for any crons.
SKINS:
user/cronjobs.html
add new table/form:
<br>
<table class=list cellpadding=3 cellspacing=1>
<form action='/CMD_CRON_JOBS' method='POST'>
<input type=hidden name="action" value="saveemail">
<tr><td class=listtitle colspan=2>Send all Cron output to E-Mail</td></tr>
<tr><td class=list align=left>E-Mail</td><td class=list><input type=text name=email size=48 value="|MAILTO|"></td></tr>
<tr><td class=listtitle colspan=2 align=right><input type=submit value="Save"></td></tr>
</form>
</table>
CMD_LOGIN_KEYS to Reseller/User Packages (SKINS) ** Manditory Skin Changes ** new
Option CMD_LOGIN_KEYS in the skins.
https://forum.directadmin.com/showthread.php?t=42746&p=216907#post216907
During the DA update, the update.sh will automatically run:
echo "action=addoptions" >> /usr/local/directadmin/data/task.queue
This task will go through all user.conf, reseller.conf and package files.
If the directadmin.conf has login_keys=1, then all of the above files will receive:
login_keys=ON
else, if login_keys=0 is in the directadmin.conf, then all files will receive:
login_keys=OFF
Note that the internal default in DA is:
login_keys=1
even if no value for login_keys is present in the directadmin.conf
Failure to use update skins will result in login_keys being turned off in a package or user.conf/reseller.conf file.
This would disable login_keys for that User.
SKINS:
admin/create_customized_reseller.html
admin/show_reseller_package.html
admin/modify_reseller.html
reseller/create_custom_user.html
reseller/show_user_package.html
reseller/modify_user.html
user/show_domain.html
All files essentially have this 1 line addition after System Info:
<tr><td class=list>Login Keys</td><td class=list align=center><input type=checkbox name=login_keys value="ON" |LOGINKEYSCHECKED|></td><td class=list></td></tr>
user/show_domain.html will have something like:
|*if LOGIN_KEYS_ENABLED="0"|
|?USERLOGINKEYS=OFF|
|*endif|
|*if USERLOGINKEYS="ON"|
<a href="/CMD_LOGIN_KEYS">Login Keys</a>
|*endif|
CMD_ADDITIONAL_DOMAINS to list multi-ips new
Related to:
If API is used, add "ips=yes" to the list, to get the IPs, eg:
CMD_API_ADDITIONAL_DOMAINS?action=view&domain=testdomain.com&ips=yes
has_multiple_ips=yes|no
will be set.
If "no" value is present, then no other values will be available.
If "yes", then you'll see IPs in a double encoded list, eg:
current_ips
assigned_ips
so you'll need to decode the above variables again to list the IPs.
Sample output:
SSLCertificateFile=%2Fusr%2Flocal%2Fdirectadmin%2Fdata%2Fusers%2Fiptest%2Fdomains%2Fipblahdomain%2Ecom%2Ecert&SSLCertificateKeyFile=%2Fusr%2Flocal%2Fdirectadmin%2Fdata%2Fusers%2Fiptest%2Fdomains%2Fipblahdomain%2Ecom%2Ekey&UseCanonicalName=OFF&active=yes&assigned%5Fips=assigned%5Fips%30%3D%31%3A%32%3A%30%3A%30%3A%30%3A%30%3A%30%3A%38%26assigned%5Fips%31%3D%31%39%32%2E%31%36%38%2E%31%2E%38%30%26assigned%5Fips%32%3D%31%39%32%2E%31%36%38%2E%31%2E%38%32%26assigned%5Fips%33%3D%31%39%32%2E%31%36%38%2E%31%2E%38%33&available%5Fips=available%5Fips%30%3D%31%3A%32%3A%30%3A%30%3A%30%3A%30%3A%30%3A%39&bandwidth=unlimited&cgi=ON&defaultdomain=yes&domain=ipblahdomain%2Ecom&free%5Fips=&has%5Fmultiple%5Fips=yes&ip=%31%3A%32%3A%30%3A%30%3A%30%3A%30%3A%30%3A%38&open%5Fbasedir=ON&owned%5Fips=owned%5Fips%30%3D%31%39%32%2E%31%36%38%2E%31%2E%38%33%26owned%5Fips%31%3D%31%3A%32%3A%30%3A%30%3A%30%3A%30%3A%30%3A%38&php=ON&private%5Fhtml=directory"a=unlimited&safemode=OFF&shared%5Fips=shared%5Fips%30%3D%31%39%32%2E%31%36%38%2E%31%2E%38%30%26shared%5Fips%31%3D%31%3A%32%3A%30%3A%30%3A%30%3A%30%3A%30%3A%39&ssl=ON&suspended=no&user%5Fips=user%5Fips%30%3D%31%3A%32%3A%30%3A%30%3A%30%3A%30%3A%30%3A%38%26user%5Fips%31%3D%31%3A%32%3A%30%3A%30%3A%30%3A%30%3A%30%3A%39%26user%5Fips%32%3D%31%39%32%2E%31%36%38%2E%31%2E%38%30%26user%5Fips%33%3D%31%39%32%2E%31%36%38%2E%31%2E%38%33&username=iptest
Where, decoded once, it will give you these variables (some of the above output is ignored for the description below):
assigned_ips = assigned_ips0=1:2:0:0:0:0:0:8&assigned_ips1=192.168.1.80&assigned_ips2=192.168.1.82&assigned_ips3=192.168.1.83
available_ips = available_ips0=1:2:0:0:0:0:0:9&available_ips1=192.168.34.123
user_ips = user_ips0=1:2:0:0:0:0:0:8&user_ips1=1:2:0:0:0:0:0:9&user_ips2=192.168.1.80&user_ips3=192.168.1.83
shared_ips = shared_ips0=1.2.3.4&...
owned_ips = shared_ips0=1.2.3.4&...
free_ips = shared_ips0=1.2.3.4&...
ignore the example values, as they may not be accurate.
Note that the shared_ips list will also include the server IP, should it be available.
assigned_ips is the list of IPs current assigned to the domain.
available_ips is the list of IPs which can be assigned to the domain.
DEPRECATED: ssl_ignore_when_local new
DEPRECATED: as of 1.62.0
Instead, use a 2nd port for ssl (2222), and main port for non-ssl (2223), eg:
cd /usr/local/directadmin
./directadmin set port 2223
./directadmin set ssl 0
./directadmin set ssl_port 2222
service directadmin restart
and use 2223 for non-ssl, and 2222 for ssl connections.
==============
https://forum.directadmin.com/showthread.php?t=42871&pagenumber=
Option which lets you tell DA to disable ssl if a connection is made on localhost.
The logic is somewhat backwards in that it currently only checks the connecting IP, which will be 127.0.0.1, if you're connecting to 127.0.0.1, so ensure you're using that, and not ::1...
as it's been found that the "from" IP, when connecting to ::1 is not ::1 or 127.0.0.1, but rather the main server IP, which is not considered "local", so this feature doesn't work if your API script is connecting to ::1.
The correct method for this would be to check the sockets themselves to figure out which IP was being connected to, instead of from.
That way we could check if 127.0.0.1 was connected to, or ::1 was connected to, however that code does not currently exist in DA, so DA (At this time) only check the "from" address.. which is going to be 127.0.0.1 anyway, so as long as people are aware of this, it should be ok the way it is.
DNS Admin column for local mail new
Similar to Local Data, a new column will be added to:
Admin Level -> DNS Admin
to determine if the domain is present in the file:
/etc/virtual/domains
this will help determine quickly if the MX records should be pointing to an external location or not.. or if a User has made an error by unchecking the option.
The column will be labeled:
Local Mail
Related:
http://help.directadmin.com/item.php?id=8
AJAX (SKINS) (BETA) new
Some text fields will support AJAX autofill.
At the moment, it's only setup on:
Admin/Reeller Level -> Change Passwords
The internal default for the directadmin.conf is:
ajax=0
If you want to test this new feature, turn it on with:
ajax=1
and restart DA.
IMPORTANT For skin designers:
Please don't start development with these functions yet, as there is a high likelihood of them changing for a future release of DA.
I'm not 100% satisfied with the static output from CMD_AJAX_USERS quite yet.
It may change to be just the usernames, and the javascript/html bits added at the browser level, instead of in DA.
Removed NameVirtualHost from ips.conf if Apache 2.4 is used new
When the file:
/etc/httpd/conf/ips.conf
is rewritten, DA will now check the contents of:
/usr/local/directadmin/conf/options.conf
If the following is found:
apache_ver=2.4
(2.4 or higher), then DA will not add the NameVirtualHost entires to the ips.conf file.
Ability to exclude DB data from backup, but include DB Settings (SKINS) new
New option for backups allowing Admin Backup/Transfer and User Site Backup to chose if they want the database data included in the backup.
The old option "Databases" is renamed "Database Settings". All variable names remain the same for this checkbox.
New option called "Database Data" specifies the inclusion of the actual sql data.
DB Settings includes Users, passwords, access hosts, etc..
The "DB Data" is the sql data.
If the DB Data is selected, the DB Settings must be selected (javascript is used to enforce this)
The settings can be selected, and the data not selected, giving the backup the skeleton of the database setup, without any tables or data.
This is useful if you need to transfer a User account to a different server with a large database, and need to transfer the sql data manually (bypassing the DA backup system)
During the update, the old dataskq command:
action=convert&value=cronbackups
is run to update the:
/usr/local/directadmin/data/admin/backup_crons.list
to add:
database_data_aware=yes
to each cron.. and if the option10=database was present, DA will add option11=database_data.
The database_data_aware option is needed to ensure that when the update is run a 2nd time, if the database_data is missing, it stays missing, as it would be the desired state at that point.
Backup files also change slightly.
The file:
backup/backup_options.list
will also have a new option:
database_data_aware
if created by this version of DA.
It's needed to tell DA if the backup was created before or after this feature was added.
If database_data_aware does not exist in the backup_options.list, then if database exists, database_data is added internally.
If database_data_aware does exist, and backup, and database exist, but database_data does not, then the sql files will not be restored.
The user_db.conf files will be restored.
SkINS:
admin/admin_backup.html
admin/admin_backup_modify.html
user/site_backup.html
user/site_restore.html
The forms to create a backup need the following added:
<input type=hidden name="form_version" value="2">
as well as:
<input type=checkbox name=option11 value="database_data" |DATABASEDATAON| onClick='setSelectedData(); if (this.checked == true) { document.tableform1.option10.checked = true; }'>
A change is needed for the existing "database" checkbox:
<input type=checkbox name=option10 value="database" checked onClick='setSelectedData(); document.tableform1.option11.checked = this.checked;'>
The form_version=2 tells DA that these options exist in the form.
Without form_version=2, DA will assume the skin is old, and if "database" is passed, then database_data is internally turned on.
Ability to reset today's email usage count to allow more sends new
Feature to allow the reset of the current day's email sends, to allow more emails to be sent out.
The file:
/etc/virtual/usage/username
exists if the:
/etc/virtual/limit
file is set to something other than 0, and email has been sent.
Once the usage file becomes the size of the limit, then emails can no longer be sent out.
A new button, located at:
CMD_SHOW_USER?user=username
will appear next to:
Sent Emails
if the usage file exists, and the currently logged in user is an Admin (only Admins can use this feature)
The button will read:
Reset Today
For both Resellers and Admins, the "Current Usage" column for "Sent Emails", to the right of the number, it will show:
(Today: 25)
where 25 is showing the size of the usage file.
When you click the "Reset Today" button, the usage file is deleted.
The (Today: 25) text will then disappear, indicating that the count is reset.
Once the User starts to send emails again, this number will show up again in realtime (for each page load)
FileManager icons upgraded and set to transparent png (SKINS) new
Minor changes to the images in the 3 DA skins.
The 4 new files for folder and files have been upgraded to png files, as png's allow for transparency.
This lets us change the background color while having the matching background in the icon (since each line has a different bg color)
While I was at it, I made them look much nicer, including the alpha channel for the shadows (bg color can go through the shadow).
The changes are quite minor, but make it look much more polished, and is far more flexible for different colors/skins.
There are 4 new files:
images/file.png
images/file_link.png
images/folder.png
images/folder_link.png
These will replace the gif versions in the files_user.conf:
IMG_FOLDER=images/folder.png
IMG_FOLDER_LINK=images/folder_link.png
IMG_FILE=images/file.png
IMG_FILE_LINK=images/file_link.png
I've left the gif files, in case they're being linked to by other language packs, or skins.
Also, the icon column in the FileManager also has align=center in it's <td> tag, to line up the icons in the center of the column.
Added |?HEADER| support to lost_password_email.txt new
Similar to many other email txt files, I've added support to the template file:
lost_password_email.txt
such that the top of the file can have:
|?HEADER=Content-Type: text/plain; charset=iso-8859-2|
Related:
ability to add your own email headers in welcome messages
Ability to suppress BFM messages new
As brute force attacks are fairly common, and the tools to prevent those attacks are fairly reliable, some admins do not wish to be told about every case of attacks.
Since the trigger of the brute_force_notice_ip.sh only happens with notices, I've added an option to prevent the sending of the notices, but still call the scripts normally to block the IP.
The directadmin.conf option will be:
hide_brute_force_notifications=0
which is the internal default (option disabled, notifications shown)
If you wish to prevent notices from being sent out, but still have the IPs blocked, then set this in your directadmin.conf:
hide_brute_force_notifications=1
user_restore_fail_post.sh new
Custom script which is called after a DirectAdmin tar.gz backup restore fails.
Script will be at:
/usr/local/directadmin/scripts/custom/user_restore_fail_post.sh
Variables to be passed to the script:
username=bob
usertype=user|reseller|admin
reseller=creatorsname
file=something.tar.gz|user.creatore.user.tar.gz
source_path=/restored/from
owner=personwhotriggeredbackup
reason=current<br>ext<br>\withreason
Note that owner and source_path will be empty strings if the restore is triggered by the User (User Level -> Create/Restore Backups)
So be sure to check if owner is blank before trying to use the source_path (check it too).
If they are blank, then it's likely going to be:
/home/username/backups/file.tar.gz
Note that the reason will include the <br>\ characters in it, as inserted into DA's message.
Display time of last DA restart (SKINS) new
Admin Level -> Admin Settings
will now display the time when DA was last restarted.
This can help determine if DA was restarted after a DA update, or license update.
SKINS:
admin/license.html
add this to bottom table:
<tr><td class=list>Last Restart</td><td class=list>|startup_time|</td></tr>
public_html_link_set_pre.sh and public_html_link_set_post.sh new
Pre/post hook scripts, triggered when the lnk:
/home/user/public_html
is create or set (happens fairly often).
scripts:
/usr/local/directadmin/scripts/custom/public_html_link_set_pre.sh
/usr/local/directadmin/scripts/custom/public_html_link_set_post.sh
Variables:
username=bob
domain=domain.com #value link is being set to.
main_domain=maindomain.com #value which is set in the user.conf
old_public_html_link=1|0 #value from the directadmin.conf, will usually be set to 1. The 0 method is a directory.
apache_public_html=1|0 #Usually will be 0. Old value of 1 was from when the public_html was chgrp to apache.
If you exit with a non-zero value from public_html_link_set_pre.sh, then the entire process will be skipped.
Note that you'd be on your own for handing any issues that may arise from not having the link set. (untested, unknown)
Suspend date new
When a User is suspended, the reason will now be shown on the page:
CMD_SHOW_USER?user=user
and only if the User is suspended.
This will add the variable:
suspend_date=12345
to the user.conf when the User is suspended, and the format of the number will be a unix timestamp (seconds since 1970)
Upon unsuspension, the row won't show up on CMD_SHOW_USER, and suspend_date will be deleted from the user.conf.
MD5sum on services.tar.gz new
the install.sh will now do an md5sum (or md5 on FreeBSD) on the services.tar.gz after download.
There will be an associated file.tar.gz.md5 file for each services tar.gz file on files*.directadmin.com.
If the md5sum match fails, a warning it shown, and a 5 second pause is given.
Instruction to delete the services.tar.gz and the md5 file and run the setup.sh again, will follow.
DA will not automatically delete the tar.gz file, as functionality exists to allow the services.tar.gz to already be present.
If it is, and no md5 file exists, then the install will not do an MD5 check.
If the tar.gz exists, and the md5 file exists, the check will be done.
the md5 file is downloaded first, before the tar.gz.
The reason for this check is that some people abort the DA install, at the moment the services_os.tar.gz file is being downloaded.
This leave the box with an incomplete tar.gz file, and because of the functionality which skips the download if the services.tar.gz exists, this causes the install to be incomplete.
The addition of the feature won't change the functionality, but will throw a warning of a broken services.tar.gz, if the md5 match fails.
This should be sufficient information to prevent much confusion and save time if there is a broken services.tar.gz file.
encode usernames brute_user.data fixed
encode usernames in brute_user.data and brute_log_entries.list to make all characters safe.
The usernames are now hex hencoded, eg %12 where characters need to be.
They're decoded during viewing, then converted to html safe characters for the html page.
remove IP with IPv6 fixed
/sbin/ifconfig reports IPv6 IPs in condensed form, but the removeip script was looking for the expanded form.
Updated the removeip script to have a 2nd command (the condensed form IP), so it has a matching value to look for.
dovecot 2.1.0 logging change for BFM fixed
Updated the brute_filter.list to accommodate the slightly changed logging entry for dovecot.
Essentially renamed dovecot1 to dovecot2, and added a new dovecot1 with a more restricted match to handle the 2.1.0 case.
Note that the BFM will still find the entries in 2.1.0, but the attempts per entry will be off. The fix addresses the attempts count.
internal mimtypes.txt wasn't being used fixed
The mimetypes.txt internal text wasn't being used because the "Send" class was loading up before the Config was, so the "en" language wasn't yet set.
Since Send doesn't need any of the texts in the mimetypes class, a flag was added to the Send init to skip the internaltext loading (which was failing), so it's left to later on, when all language settings are properly loaded (eg: "en")
ssl_port is ignored when running in debug mode fixed
https://forum.directadmin.com/showthread.php?t=42993&p=217996#post217996
Fix, was to consolidate the forking into a new function.
Call it from setAsDaemon, but also call it in debug mode.
change_username.sh to check max_username_length fixed
The change_username.sh did not respect the directadmin.conf setting:
max_username_length
so if you change a username to a value longer than this setting, you'd run into issues within DA where the User wouldn't show up or work correctly.
Fix runs "./directadmin c" to check the current limit and compares the length of the new user string.
Changing password when quotas are full can break ~/.shadow fixed
On some systems (proven on a simfs quota system), the system will prevent root from chowning a file to a User, if that User is over quota. (not observed on CentOS).
The solution is, when saving a password when quotas are full, to save to:
~/.shadow.temp
as root.
Attempt a chown on the temp. If the file is not owned by the user after the chown, set the quotas to 0 (off), chown the file, rename the file to ~/.shadow and turn quotas back on.
If the chown worked, then the .temp file is renamed normally.
Note that all systems will use the temp file & rename method now.
The disabling of quotas only happens if the chown didn't stick.
SIGTERM not killing all child processes if numservers>20 fixed
If you've got something like numservers=30 and restart DA by only sending a SIGTERM to the parent DA process, the child processes over 20 didn't get the message, so kept on running.
New code uses the newer container class for pids instead of an old pid array.
anonymous ftp doesn't work with secure_access_group fixed
It appears as though proftpd is running as "ftp" when doing the chdir/chroot, prior to dropping the privileges to that of the user.
This caused an error for the anonymous ftp account, as mentioned below.
The fix is to add "ftp" to the "access" group, eg:
usermod -G access ftp
and then restart proftpd.
For any new systems where the access group does not yet exist, the ftp value will be added to the access group autmatically.
Error:
Apr 2 23:29:43 server proftpd\[12843\]: 192.168.0.2 (127.0.0.1\[127.0.0.1\]) - FTP session opened.
Apr 2 23:29:47 server proftpd\[12843\]: 192.168.0.2 (127.0.0.1\[127.0.0.1\]) - notice: unable to use '~/' \[resolved to '/home/testuser/domains/testdomain.com/public_ftp/'\]: Permission denied
Apr 2 22:29:47 server proftpd\[12843\]: 192.168.0.2 (127.0.0.1\[127.0.0.1\]) - Preparing to chroot to directory '~/'
Apr 2 22:29:47 server proftpd\[12843\]: 192.168.0.2 (127.0.0.1\[127.0.0.1\]) - chroot to '~/' failed for user 'anonymous@testdomain.com': Operation not permitted
Apr 2 22:29:47 server proftpd\[12843\]: 192.168.0.2 (127.0.0.1\[127.0.0.1\]) - error: unable to set default root directory
Apr 2 22:29:47 server proftpd\[12843\]: 192.168.0.2 (127.0.0.1\[127.0.0.1\]) - FTP session closed.
Add timestamp hour offset for FileManager fixed
Related thread:
https://forum.directadmin.com/showthread.php?t=42248
We've added a simple workaround to the timezone issue by adding the following new directadmin.conf opiton:
fm_hour_offset=0
This will be the internal default.
If your timestamps are off by a few hours, you can simply add a positive or negative integer into this variable to change the displayed timestamp on the files in the FileManager.
Example, if your files are showing a time 2 hours into the future, you can set the value to:
fm_hour_offset=-2
and restart DA, and DA will display the a_time, m_time and c_time values as -2*3600 (human readable, of course).
This should also affect the values returned in the API.
pureftpd not in brute_filter.list fixed
pureftpd is not in the brute_filter.list.
New brute_filter.list entry:
pure-ftpd1=binary=pure-ftpd&text=[WARNING] Authentication failed for user&ip_after=(?@&ip_until=)&user_after=user%20[&user_until=]
Also, new directadmin.conf entry (internal default):
brute_force_messages_log=/var/log/messages
Where it's assumed the pure-ftpd entries are made there.
If they're made elsewhere, then set the brute_force_messages_log entry in the directadmin.conf with the correct path.
Sample log entry used:
May 1 02:37:23 hostname pure-ftpd: (?@127.0.0.1) [WARNING] Authentication failed for user [admin]
login-as to support more than 1 level down (SKINS) fixed
If you're logged in as an Admin, then login as a Reseller, and then try to login as a User (below Reseller), it would previously just stay at the Reseller login.
This is because the session holds the admin password, not the reseller password, so when reseller|user is used in the form, the password match fails.
The simple solution is to change the form from using:
reseller|user
(when logged in as the reseller) to show:
admin|user
instead, even though we're logged in as "reseller" (via the login-as from admin).
This forces a password lookup on admin, which is the value in the session file, so it then works correctly.
Note that when "Logout" is clicked, it will drop straight to admin, and not reseller.
SKINS:
reseller/show_user.html
admin/show_reseller.html
change:
<input type=hidden name=username value="|USERNAME|||user|">
to be:
<input type=hidden name=username value="|LOGIN_AS_MASTER_NAME|||user|">
Backup to allow tar exit code 256 (--ignore-failed-read) fixed
Similar to this change:
We've added exit code 256 as a valid tar return code, which is commonly generated when:
--ignore-failed-read
is used but the file is still fine.
security: encoding of domain output on CMD_DOMAIN fixed
In response to this report:
http://packetstormsecurity.org/files/112225/DirectAdmin-1.403-Cross-Site-Scripting.html
the domain output on the 2 mentioned pages will now be html encoded.
Regarding the security level of this bug, it's low to non-existent.
The report makes this reported statement, which is false:
The vulnerability allows an attacker with privileged user account to hijack customer/moderator/admin sessions with high required user inter
action. Successful exploitation can result in account steal or client side context manipulation when processing affected module
application requests.
Because of this feature which was added in 1.34.5:
Security check on Referer header
which prevents the "cross-site" aspect of the cross-site-scripting report.
We could say then, than all versions older than 1.34.5 would be affected.
Reset count on IP in BFM during unblock fixed
https://forum.directadmin.com/showthread.php?t=43460&p=220801#post220801
The IP values from the file:
/usr/local/directadmin/data/admin/brute_ip.data
will be removed when an unblock is done.
The unblock button only shows up if the scripts are present, eg:
http://help.directadmin.com/item.php?id=380
subdomain_owner_check: Allow sub.sub.domain.com if sub.domain.com is already in list fixed
Assume:
1 - domain.com is owned by user2
2 - sub.domain.com is already created under user1
3 - user1 is trying to create sub.sub.domain.com
Previously, point 3 would fail because the subdomain_owner_check only found domain.com, and noted that it didn't belong to user1.
With this change, an additional check is done with sub.sub.domain.com, starting with sub.domain.com.. to see if it exists in the domains.list file of user1.
If a subdomain exists in the domains.list of user1 (sub.domain.com), then a double-subdomain (sub.sub.domain.com) is now allowed to be created by user1.
This change is not affected with the check, when a new User is being created... which makes sense, since a new User won't yet have any domains anyway.