ISPConfig installation into multiple OpenVZ containers

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

 

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.

 

separation of services has work fine up till now using ispconfig3.
There seems to be an installer issue.
I reported a bug similar to your report

http://bugtracker.ispconfig.org/index.php?do=details&task_id=574&project=3

 

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.

 

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....

 

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?

 

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?