ISPConfig installation into multiple OpenVZ containers

Discussion in 'Installation/Configuration' started by letezo, Mar 3, 2009.

  1. letezo

    letezo New Member

    I've installation problems with ISPConfig 3.0.0.9 RC2 in a "multiserver" setup. I had to tweak ISPConfig's installer to overcome difficulties and I need to know whether it is a bug in ISPConfig or I did something wrong.

    Installation details:

    I tried to install ISPConfig 3.0.0.9 RC2 on Ubuntu Linux 8.04 LTS Server in a way, that each service have its own OpenVZ container for scalability and online migration.

    I've set up "virtual environments" (so called VEs) for each service first: mysql, mail, www, ftp, dns. We can treat them as separate machines, basically. I used the same Ubuntu version in all of them.

    I've forwarded the ports for each service into the corresponding VEs using firewall DNAT rules, including 8080 for the ISPConfig Web UI. I've set up the required name=>IP mappings in the hosts files as well and enabled access for the root MySQL user from all the VEs.

    A single /var/clients directory has been "bind mounted" into both the www and ftp VEs using <veid>.mount scripts in order to allow uploading content. All the required packages are installed into each VM (only the ones required for the service implemented by each VE). Finally all the VEs are saved in order something goes wrong with the ISPConfig installation. I was careful enough to do this, fortunately...

    Then I tried ISPConfig's "multiserver" installation process: Installed a "master" ISPConfig into the mysql VE with all the other components disabled. It created a master dbispconfig DB and added a single server record as usual, but the Web UI was disabled in this installation (no Apache2 in the mysql VE).

    Please note: I do have only one MySQL server in the mysql VE and I don't want the overhead of installing a MySQL server into each VE. So it is not a real replicated multiserver installation, only a "split by service" one.

    The problem

    Then I installed ISPConfig as a multiserver slave on the www VM with Web server and ISPConfig UI support enabled, all the others disabled. I had to repeat this installation step (after restoring the VEs each time) due to severe confusion caused by ISPConfig's multiserver setup. I also couldn't find usable documentation or relevant forum posts on the subject helping me out, so writing here.

    First try:

    I installed ISPConfig into the www VE as a regular slave by specifying a new database (like dbispconfig_www) first, then the master second as requested by the installer.

    (You will get a "Database already contains some tables" error if you try to reuse the existing ispconfig master DB as "the database" of the slave.)

    Repeating this for each service resulted in a set of working, but completely disjunct ISPConfig installations without central management. The Web UI showed only the www VE.

    I tried to figure out why it did not work. Finally I managed to tweak the config.inc.php database configuration files and fixed the MySQL access rights manually to overcome this and join it into a centrally managed system, but I guess that's not a standard way of installation, which would prevent future upgrade to the final version of ISPConfig 3.

    So I reverted this.

    Second try:

    I've realized, that it needs to use a single database on my mysql VE instead of using many replicated ones, but reusing that single master database for all the slaves was prohibited by the ISPConfig installer.

    So I searched for "Database already contains some tables" in the installer and - after analyzing the source code - simply commented out the following line in the ispconfig3_install/install/lib/installer_base.lib.php file:

    $this->error('Stopped: Database already contains some tables.');

    (Just entered a // before the line to comment it out.)

    Commenting out the above line disables the error message and simply prevents the ISPConfig installer from trying to overwrite the master database, which would result in an error message otherwise.

    Then I installed ISPConfig in the default "master" mode to each service VEs (www, ftp, etc.) specifying the single master dbispconfig database served by the mysql VE. It entered the server records into that single database.

    This setup seems to work without further tweaking or manually editing the configuration. (Make soure that the VE names are resolved to IP addresses by the mysql VE's /etc/hosts file, otherwise MySQL doesn't allow connections from the service VEs.)

    Questions:

    * Is it a bug in the ISPConfig installer preventing to install multiple ISPConfig instances reusing a single MySQL database?

    * Would it be a new "mode" of ISPConfig installation not officially supported?

    * Will such an installation sharing a single database supported during upgrades to the final ISPConfig 3 release?

    Suggestions:

    The ISPConfig installer and documentation should clarify the "mode" of installation: E.g.: single server, shared database multiserver or replicated multiserver.

    Clear examples should be provided for each possible installation mode.

    Thanks in advance and sorry for the very long post. - Viktor
     
  2. letezo

    letezo New Member

    It seems to not work at all

    It seems to not work. :(

    For example the FTP service cannot be separated easily:

    * ISPConfig creates the users (like web1) and groups (like client1) in the Web server's VE (www) as normal system users (/etc/passwd and /etc/group), so they can't be used by pure-ftpd in the ftp VE easily. There are tricks, certainly, but we would get an unsupported configuration then. (ISPConfig does not use PAM for the actual system users.)

    * ISPConfig stores the server_id of the Web server into the ftp_user record, so it cannot login through FTP without hacking the pure-ftpd configuration files or ISPConfig.

    I've failed to separate the services while preserving ISPConfig's central management. :(
     
  3. Justin Albstmeijer

    Justin Albstmeijer New Member

  4. letezo

    letezo New Member

    Thanks for your note

    Thanks for your note about the reported bug. :)

    Please note, that the setup I described above is not a regular multiserver installation, but a group of ISPConfig managed virtual machines with a single shared MySQL database and server.
     
  5. till

    till Super Moderator

    There is no such bug.

    No.

    no.

    no.

    This works all perfectly and is used already by several providers on production systems. It does not work for you because you entered wrong mysql details. The setup is really simple:

    1) Install the first server in standard mode.
    2) Install the second server in expert mode, enter the mysql root login details for the local mysql server and then the details of the master server.
     
  6. Justin Albstmeijer

    Justin Albstmeijer New Member

    Well that was exactly how my setup was till now..
    Multiple openvz servers sharing one master sql/panel server for dbispconfig.
    But looking at the replies on my bugreport.. somekind of mysql replication has been inplemented in later ipsconfig3 versions.. whereby the local database server gets it's own replicated dbispconfig database.

    I wonder if there is a global design overview somewhere....
     
  7. till

    till Super Moderator

    Such a setup is not supported. For performance reasons ISPConfig requires a local mysql databse on every server. What you did is basically to install serveral instances of ispconfig on the same server which will not result in a services separation of course.
     
  8. till

    till Super Moderator

    No. But the setup is really simple. One master database and a unlimited number of slave databases which replicates only the data needed for a psecific server.

    The reasons for this setup are:

    1) The access to the local DB is much faster and can also use sockets.
    2) You would reach a max. connection limit very fast if you had just one central db.
    3) Security: the slave databases contain only the data for the local node.

    we started with a central Db setup in the first betas of ISPConfig 3 and the approach was not scalable enough. The current setup has been implemented by several providers already in production systems and it works very well.
     
  9. Justin Albstmeijer

    Justin Albstmeijer New Member

    Thanks for your reply.
    Is there a way I can get my servers without their own mysql server, using the central now, in line with this change?
    Just install a local mysql server and run an upgrade will get all OLD mysql data currently in the central mysql server synced to the local mysql servers?
     
  10. till

    till Super Moderator

    No, this will not work as the data is synced from the datalog and most likely your datalog does not contain all needed data.

    What you can try is that you install a exact copy of master database on every slave. Then use a config.inc.php file from the latest version (not your old version) and replace your config.inc.php file with it. Then you will have to set the correct login details for local and remote database in this file.

    But I never tested this so it might be that it does not work.
     
  11. Justin Albstmeijer

    Justin Albstmeijer New Member

    sounds scary,,
    Any idea what could go wrong with the approach you propose? besides that fact that these slaves will contain unnecessary data from the master.
    I can imagine some queries could figure out which data you actually need to get to the slave, starting with server_id en tables related.

    - will the master in the at all time contain all data (users/aliases/sites) for all slaves?
    - will there be somekind of check if master and slave are inconsistant?
     
  12. till

    till Super Moderator

    Yes, at the master runs the interface and the interface must be able to show all data. the master itself is not able to connect to the slave databases. The replication works the other way, the slaves are connection to the master and replicate data if there are new records. this has the benefit that you can shutdown a slave for maintenance and no data gets lost when someone edits data on the master server in the meantime.

     

Share This Page