This is not a good solution and would break the modular design of Sentora. As well as needing extra SSL entries/certificates if you use SSL. The best practice, and easiest, is to use a folder alias added to each domain like /webmail or /mysql for example: domain.com/webmail or domain.com/mysql
These do not require additional DNS configurations and will work under the main domain's SSL certificate if in use.
This is the method I have been using and is described here: [How-To] Set up /webmail or /mysql for all domains
Note about breaking the modular design:
Sentora modules are meant to rely on themselves only. For example, you can completely remove the DNS manager and bind9 and use external DNS withou affecting any other panel functions.
I do suppose adding a check to see if DNS Manager=Enabled>Add webmail.customerdomain.com / mysql.customerdomain.com entries. (You can not use mail.customerdomain.com since the 'mail' sub domain is reserved for the email server's mx records.)
Creating panel.domain.com for all domains is a great idea but the panel is currently designed to work off one main domain like panel.yourhostingdomain.com
Past tests of using just IP, domain.com/panel, panel.customerdomain.com, etc. have shown random issues with functionality such as module failures. (Incorrect paths and URLs)
From a security standpoint as server owner, panel.yourhostingdomain.com is literally the best practice since the server owner can put SSL on to it to ensure encrypted access to the panel, unlike if a customer uses panel.customerdomain.com and does not add SSL their connection to the panel will not be as secure. (Same with webmail.domain.com and mysql.domain.com)
I'll see if I can make some time this week for testing some of the above functionality.
These do not require additional DNS configurations and will work under the main domain's SSL certificate if in use.
This is the method I have been using and is described here: [How-To] Set up /webmail or /mysql for all domains
Note about breaking the modular design:
Sentora modules are meant to rely on themselves only. For example, you can completely remove the DNS manager and bind9 and use external DNS withou affecting any other panel functions.
I do suppose adding a check to see if DNS Manager=Enabled>Add webmail.customerdomain.com / mysql.customerdomain.com entries. (You can not use mail.customerdomain.com since the 'mail' sub domain is reserved for the email server's mx records.)
Creating panel.domain.com for all domains is a great idea but the panel is currently designed to work off one main domain like panel.yourhostingdomain.com
Past tests of using just IP, domain.com/panel, panel.customerdomain.com, etc. have shown random issues with functionality such as module failures. (Incorrect paths and URLs)
From a security standpoint as server owner, panel.yourhostingdomain.com is literally the best practice since the server owner can put SSL on to it to ensure encrypted access to the panel, unlike if a customer uses panel.customerdomain.com and does not add SSL their connection to the panel will not be as secure. (Same with webmail.domain.com and mysql.domain.com)
I'll see if I can make some time this week for testing some of the above functionality.
