Enhancement - The control panel must always be reachable using a specific HTTPD instance

  • I'm late to the discussion...


    I hope this does not mean that the panel must now default to a different port. Everyone will then have to setup something to redirect users. No user will ever remember to put :8080 or the like, and that is ugly. This is kind of backwards. Panel should be port 80 and running on the front reverse-proxy to all sites, despite the extra server load.


    If this is a necessary step to the end goal of making i-mscp truly multi-server, in that the front-end will eventually communicate to back-end servers via CLI, then I am all for it :)


    I think it is a bad idea to have the panel on a different port. If anything, then nginx must become the reverse-proxy for everything to keep the control panel on port 80, and the rest sit behind on Apache. This will make any Varnish setup very difficult, but so be it.


    But in this case, it really should be architected like so, I believe...


    Option 1: Single-server: Control Panel + Back-end - Control Panel runs Nginx, the back-end as usual on Apache.
    Option 2: Multi-server A: Control Panel + Back-end - Control Panel runs Nginx, and can communite with local back-end and other servers on Apache.
    Option 3: Multi-server B: Control panel standalone - Control Panel runs Nginx. communicates with Back-End on other servers.

    For Option 2 & 3: Back-end standalones with Apache only, to be controled by master control panel, for option 2 and 3.


    Unless this is the eventual plan for such a move, no one will really care if the control panel is up but the websites are down : / Only to grab their files and run away.


    If the plan gets closer to multi-server, YAY! :)

  • @anarking


    Quote from anarking


    I hope this does not mean that the panel must now default to a different port. Everyone will then have to setup something to redirect users. No user will ever remember to put :8080 or the like, and that is ugly. This is kind of backwards. Panel should be port 80 and running on the front reverse-proxy to all sites, despite the extra server load.


    Exactly, this really means that in next versions, the panel will no longer be reachable on usual port (80/443) by default. This is because from now, the panel will be run on a dedicated httpd instance.


    You're claiming that your customers will not remember the URLs to access the control panel but most control panels are not reachable on the default ports (ispConfig, Plesk, Cpanel...) and this doesn't pose any problem (as long the customers are well informed). You also claim that it's ugly... How should I answer such sentence.. It's really a personal opinion here...


    However, changing those default ports will be still possible as long you are providing a dedicated IP address to the control panel. Of course, I'm talking here about true servers, not those which are under a private LAN


    For the rest, read my previous answers because it seem that you have not really understand the purpose. For instance, when you say the back-end as usual on Apache, I'm really wondering if we are using the same control panel.



    BTW: Do you ever played with plesk? In the latest Plesk versions, the control panel is also run on a dedicated httpd instance (nginx which has been recompiled with another name). Customer's sites are run through other httpd instances (nginx as frontal + Apache by default).

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

  • i meant back-end just as everything imscp controls for hosting, and panel as front to it, but okay sticking to correct nomenclature of back-end just as imscp daemon.


    okay i'm coming around, but as with plesk and like someone else mentioned, maybe best not to tie up nginx entirely with it, though sounds like you have some plans already here.


    i will either reverse proxy to the panel, or most likely have a second IP for it. I think a dedicated IP option and staying port 80 and 443 is an important option, and will be a common configuration. that and/or making it a separate server entirely (nice small, isolated central panel server). you probably already have thought of that for longer term goal though, i bet.


    either/any way, great work :)

  • Hello ;


    For those which are testing the nginx-panel branch, do not forget to run the following command each time you are updating:


    Shell-Script
    1. # rm -r /etc/imscp/nginx


    This is because some parameter values for nginx can change during development time.


    Thank you

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

  • but when this will be deleted i get this error:


    [ERROR]


    Package::FrontEnd::start: Unable to start nginx service main::setupRestartServices: Unable to restart FRONTEND service
    iMSCP::Debug::END: Exit code: 1
    root@web01 ~ #

  • @gOOvER


    Yes, this is because some parameters are wrong. Wait for my next commit please.

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

  • Lastest Branch:


    i get following error:


    [ERROR]
    Package::FrontEnd::start: Unable to start nginx service
    main::setupRestartServices: Unable to restart FRONTEND service
    iMSCP::Debug::END: Exit code: 1 root@web01 ~ #

  • @gOOvER


    According your last post, I presume that you figured out ;) As said previously, during the dev time, you must remove the /etc/imscp/nginx directory before each update because some parameter values can change. :)

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