Planned changes regarding DNS managements

    The proposed change will be a benefit for all and I actually handle it exactly like this, so I can provide SSL access for each user through one SSL file.


    However, such a change should not be in a bug fix release like 1.3.9 but in 1.4.x, because it changes the behavior of the system.

    Quote from Starlight

    However, such a change should not be in a bug fix release like 1.3.9 but in 1.4.x, because it changes the behavior of the system.

    You're right. I've edited my post.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    Hello everybody,


    I hope it is okay to add my thoughts on this here.
    I am running two instances of i-MSCP on two different servers - they are named <panel1>.<domain.tld> and <panel2>.<domain.tld> for hostnames as well as for panel. Both are DNS slaves for each other and also BackupMX (automatically configured using scripts installed by listeners). The glue records are done in the customer <domain.tld> on the primary server.


    Generally I like suggestion because it will end up in a clean and lean configuration but I guess my idea of having two servers on the same domain would not work anymore except using <sub1>.<domain.tld> and <sub2>.<domain.tld> instead of <domain.tld> which would result in longer names for the panel (<panel>.<sub1>.<domain.tld>).


    Perhaps I missed something but I guess similar thoughts might come up when heading a planed multi server deployment.


    Regards Jörg

    (Ubuntu 16.04, i-MSCP 1.5.1, php-Fpm, Plugins: ClamAV, CronJobs, InstantSSH, LetsEncrypt, Mailgraph, Monitorix, OpenDKIM, PhpSwitcher, PolicydSPF, Postscreen, RecaptchaPMA, RoundcubePlugins, ServerDefaultPage, SpamAssassin, YubiKeyAuth)

    @UncleJ


    No, with the planned changes, you'll be able to have something like:

    • srv1.domain.tld (server1), that, for the server hostname
    • srv2.domain.tld (server2), that, for the server hostname
    • panel1.domain.tld (server1), that, for the control panel
    • panel2.domain.tld (server2), that, for the control panel

    But here, you'll have to decide which one of your two servers is the master DNS. For instance, srv1 could be master while srv2 could be slave.


    BTW: Where is your master DNS actually?


    Final notice: It is normally planned to be multi-servers in 1.4.0, meaning that you'll be able to manage your two servers through same i-MSCP control panel instance (only one).

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    @Nuxwin


    This would be pefect the way you explained.
    Currrently the master for domain.tld is on server1 where it is configued as client with glue records and synced to server2. The zones for panel1 and panel2 are on their own server and then synced to the other one. Same for the customers defined on each server. So each server is master for its own customers and slave for the customers of the other server.

    (Ubuntu 16.04, i-MSCP 1.5.1, php-Fpm, Plugins: ClamAV, CronJobs, InstantSSH, LetsEncrypt, Mailgraph, Monitorix, OpenDKIM, PhpSwitcher, PolicydSPF, Postscreen, RecaptchaPMA, RoundcubePlugins, ServerDefaultPage, SpamAssassin, YubiKeyAuth)

    You're welcome. Your current setup is a bit complicated but with current implementation, you have not the choice.


    In 1.4.0 there will be a domain.tld zone and no longer a panel.domain.tld zone. To resume, on imscp setup you'll be asked in order for:

    • The domain name to use with the server. For instance: domain.tld
    • The hostname to use for the server. For instance: srv1.domain.tld
    • The hostname to use for the control panel. For instance: panel.domain.tld
    • Whether or not (if Bind9 is installed on the server), the server must be act as primary DNS server or slave DNS server for the domain.tld zone.

    Now about usage of domain.tld as customer client, this will be of course possible. i-MSCP will be simply smart enought to update the existent domain.tld zone instead of creating a new one.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support