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:

CMD_API_ADDITIONAL_DOMAINS

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&quota=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:

Allow tar exit code 1

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.

Last Updated: