Hi there Is there any standard way or howto replacing the live server in the cluster. I have a cluster running 3.2.1 on CentOS 8 and one of the servers running web and mysql roles should now be replaced due mistakes in initial configuration and unrecoverable damaged RPM database with the almost the same way configured web/mysql server with CentOS 7. Thanks.
In the tutorial written that the tool will copy data from another panel, but in my case I have an ISPConfig 3.2 with the following servers 1. Panel and NS1 2. NS2 3. mail 4. web and database I would like to replace only 4th server now but there are already a live sites and databases
The Migration Toolkit consists of 2 different tools, the Migration Tool and ISPCopy. The Migration Tool is more versatile as it can migrate servers but also merge them and other fancy things like migration servers partially by client etc, but the drawback of this importing approach is that you can't use it for servers that are connected to the same master. So if you have tow server nodes in a multiserver that are connected to the same master server, then you can't use the Migration Tool in this case. But, the Toolkit consists of 2 tools, and the second tool is made for this exact case. The second tool is named ISPCopy, it copies an ISPConfig installation as it is to a new server, this means you can use it to transfer a slave system to new hardware while keeping it connected to the master. The steps are: 1) Install the new system in that way that it runs the same services as the old system, the OS version can be newer though. You can install ISPConfig (e.g. in single server mode) but you don't have to. 2) Disable server.sh and cron.sh root cronjobs on the old server to prevent that ISPconfig communicates with the master node. 3) Run ISPCopy on the old server and let it move the ispconfig installation to the new system. 4) Run a forced update of ispconfig on the new server, let it update permissions in master database to connect the new node to the master and let it reconfigure services to update and write the config files.
I thought about ISPCopy aswell, but due to the note on misconfigurations, I think the migration tool would be better, because it leaves out the config - or am I missing something?
The Migration Tool should indeed be used in cases of config issues. But as far as I understand the setup of the original poster the old and new system are connected to the same master? If that's the case, then the Migration Tool can not be used. using teh Migration Tool would be as if you try to copy a file onto itself, it would try to import data into the same master that exists in the master already.
well i can think of a third use case scenario where neither a straight migration or ispcopy appear suitable. moving an existing multiserver member server (non-master) from one multi-server setup into another multi-server setup. eg, two companies in using the same datacentre merge. both use ispconfig multi-server, and want to merge the two separate ispconfig setups into one system. so maybe now they want to remove one physical webserver from ispconfig system a, and add it to ispconfig system b, whilst not losing the websites already configured and running on this webserver. obviously they could setup another webserver on system b, use the migration tool to migrate everything from the old webserver to the new server ( and migrate dns data ). but for this argument, let's assume they don't have another physical server, or the spare time/cash to buy/rent one, or use a vm/vps as an intermediary migration server to temporarily run the sites whilst the old server is re-installed/reconfigured. they now need some way to have all the user data migrated from ispconfig system a to ispconfig system b. have the webserver remove itself from system a, join system b, update all the system ids, user ids, etc in it's own dbispconfig database with the id's from its new master. then rebuild it's /etc/passwd /etc/group files, and update all the owner/group settings on all the websites it hosts. not saying you need to rush out and develop a new migration option, it's a scenario that will likely only occur very rarely, so may be something to consider for the future.
Hello again. Excuse me for pumping such old topic, but I still have same question. I would like to replace an OS inside 2 servers in my setup (one is a mailserver and second is a web / mysql server, not master). I would like to leave as is everything including server names and numbers, but replace an OS (I have broken an RPM database in 2 servers running CentOS 8 that can not being repaired). I would like to install the same configuration server and just move all ISPConfig and client's stuff to that server. Could someone advice me what exactly I have to copy from damaged server in that case? I will first try with same OS version, CentOS 8, later would like to go to CentOS 7 or maybe some Debian/Ubuntu, but now I have to get an OS back to fully working and supported state. Thanks
I was advised to use the migration tool, but this tool will move the stuff to another server while I'm looking for the way just to replace an OS and leave everything as it was including server names, aliases and IDs
There is a utility named something like "ispcopy" in the migration toolkit which does this; the source and destination server must be the same OS version/configuration.
Hi Georgy, have you tried this? Maybe this will help: https://www.tecmint.com/rebuild-corrupted-rpm-database-in-centos/ I would exhaust all avenues before going nuclear, if you have tried this then consider migrating the important things off the server to a temporary server, reinstall the server and migrating back to the server. Another option might be to use rsync to pull all the critical files from the server, user data, configs etc etc and sync them back. in this way you could migrate the hosts file, cloud.cfg hostname etc etc etc. Migration has the benefit of being somewhat easier The rsync pull will require a lot digging in the first place to find all the files but the sync back will be a breeze. Warning though it also has the biggest chance of failure because you could miss something important.
