Hi to everyone I'm trying to add a mirror node to a running ispconfig3 installation. I installed Ispconfig 3 in expert mode on a new server (Debian Squeeze 6) and patched and aligned to the running production server. Set up MySQL (5.5) Master/slave and it seems to work. Aligned client* groups and web* users from /etc/passwd /etc/groups /etc/shadow /etc/gshadow on the original server. Replicated nginx configuration from primary server to mirror (just opened each site configuration on ispconfig control panel on the original server and saving it... There is a better way to do this?) Forced pureftp user creation on mirror opening and saving each ftp user (again: is there a better way to force sync between primary and mirror servers?) TODO: postfix replication (what about mail folder? Do someone have experience in mirroring a postfix installation between two nodes?) ISSUE with rsync: /var/www folder is replicated with rsync, and I am experiencing the following issue: rsync: chown "/var/www/clients/client1/web13" failed: Operation not permitted (1) rsync: failed to set times on "/var/www/clients/client1/web6": Operation not permitted (1) ........ rsync: chown "/var/www/clients/client6/web43" failed: Operation not permitted (1) rsync: failed to set times on "/var/www/clients/client6/web81": Operation not permitted (1) ........ rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1060) [sender=3.0.7] I tried to set permissions and just touch a file with root privileges and I receive the same error (permission denied). I think the problem is that log folders are mounted in fstab: /var/log/ispconfig/httpd/######### /var/www/clients/client1/web77/log none bind,nobootwait 0 0 Is there a way to not having these permission denied errors? (they're filling root mailbox, since rsync is running in a cron job...)
I think, a master-master replication with mysql is better. When you change a "web-database" on the mirror, thoses changes are not present on the master. Instead of syncing /var/www you can sync /var/www/clients. ISPConfig creates the needed symlinks on the mirror when a web-site is changed or added. You can also use rsync to keep your mails in sync ( /var/vmail ). Maybe you can use unison (a little bit easier to setup and uses rsync also) or use raid1 over network (drbd). BTW: to get the web-sites written on a later added mirror-server, you can also use the resync-tool.
The webfolder is protected, while changing the permissions you can use Further after your task completion you can retain the original permissions by
Many thanks for the answer. it is in roadmap, after validating the configuration I will configure MySQL in master/master replication. Until then "slave" websites are not visible, so no writes in DB (hopefully). a couple of notes: I replicate all the databases (including "mysql" DB) but don't replicate dbispconfig and phpmyadmin databases, instead I created a new dbispconfig2 on the mirror server. Should I replicate them? I noticed that if I grant some access to database through the web ui (for example adding a new IP address in Sites -> Databases -> Remote Access IPs), it correctly sets the grants on "master" mysql.user table, but the changes are not replicated... I tried both configuring mysql in row based replication and statement based replication. Tryed through CLI (mysql) and the grants are replicated only if I issue a "use mysql" before grant statement. Good to know, thanks. But the issue here is that it seems that mounting logs folders makes them unaccessible by root at all... Is this expected behavior? I used rsync because I never used unison, but reading your documentation I am very interested in trying it. Used DRBD for a long time (apache clustering, NFS HA, syslog repository...) and I found it a little hard to set-up but very stable and useful (had some performance issues, but if you don't too much writes it is very good choice)... Is it still limited to 2 or 3 nodes? I'll try unison for sure. Do you think it will resolve permissions issues? Could you explain exactly what I am expected to see replicated from the master to the slave and what should I care to replicate by hand? Thanks
You should not replicate the mysql-database to avoid overwriting user-accounts like the ispconfig-user. Otherwise you must use the same password on both servers. I`ve no problems in a mirror-setup with the permissions for the database. Maybe you should debug server.sh on the second server. If you replicate the mysql-db, your password for the second server are overwritten. You must use a differente db on the mirror as described in the setup. You can replicate the ispconfig-databases. I´m not sure if makes any difference. What do you mean with this? I can access all log-files. As long as you use only two servers i would use DRBD with OCFS2 or GFS2 instead of rsync or Unison. I use Unison to sync the clients-folder and it works without any problems. Setup the slave-setup as described. You must not alter anything by hand.
Yes, I paid attention to use two different users and databases for ispconfig (ispconfig/dbispconfig and ispconfig2/dbispconfig2) and to copy debian sys-admin user password on the slave servers, and I use the same root password... BTW, if I don't replicate mysql db, who takes care to replicate grants and create database statements onto the mirror server when creating or modifying databases? If you say that ispconfig replicates that I will change my master-slave configuration (I don't like replicate mysql db actually)... I mean the original issue that I posted: rsync: chown "/var/www/clients/client1/web13" failed: Operation not permitted (1) rsync: failed to set times on "/var/www/clients/client1/web6": Operation not permitted (1)
ISPConfig creates the databases on the mirror-server and sets-up the permission and adds the user. You can´t use a master-slave-replication if you would like to use the mirror-server. With a master-slave-setup your mirror is just a "poor-backup-solution"
Thank Florian for your suggestions. Too bad drbd is not an option, because I have no spare partitions to set it up... So I would stop those permission error during rsync copy, if it is possible... I encountered another little issue: I changed php-fpm settings on the "master" ispconfig console (Sites -> <site> -> Options -> PHP-FPM pm.*) for all sites. I see that values are update on the "master" dbispconfig.web_domain table and in pool.d/*.conf configuration files, but not on the mirror database dbispconfig2 or mirror configuration files... Is this expected behavour? Is there a way to force configuration propagation? BTW: Is there a way to change default values for new nginx php5-fpm pools?
Which version do you use? In the latest release there is no "Options -> PHP-FPM pm.*" under websites. As long as the services for the master and slave are the same every change on the master will be replicated to the slave. Checkt the jobqueue and debug your mirror.
Version 3.0.5.3. I mean properties that are replicated in these colums of the web_domain table. pm_max_children: 50 pm_start_servers: 20 pm_min_spare_servers: 5 pm_max_spare_servers: 35 pm_process_idle_timeout: 10 pm_max_requests: 0 Anyway putting slave in debug mode it turned out that there was a server.php process runnng since monday morning 19th. On monday we had to restart "master" server due to a problem with a disk. server.php is stuck since that reboot... Shouldn't it have a watchdog or something like that to prevent these issues? I killed the process, deleted lock file /usr/local/ispconfig/server/temp/.ispconfig_lock and now nginx configurations are replicated correctly. Is this the correct way to solve this?
