Hi, I've used the search function repeatedly but have not quite been able to find what I'm looking for: We have an ISPconfig setup with a master (incl. GUI) server and several client (either web&DB or email) machines, that do not run the ISPconfig GUI. Now I am looking to replace some of the clients (due to old hardware) with new machines. The hosting data center cannot reassign the IP addresses of the old machines (no use to argue), so the new machines will come with different IPv4 addresses for a start. The idea is: - set up the new machine with latest Debian 9 + ISPconfig setup - copy over _all_ client files and directories as well as all databases (including DB users, passwords, etc.pp.) - change DNS name for the new IP to the name of the previous machine What else do I need to change in ISPconfig to make it accept the replacement server? Where do I need to update the IPv4 address of the server I am replacing? Bonus question: If I ever get into the situation that I want to replace the _master_ server - how & where do I need to update the clients so they will find the new master? Is repointing the DNS all there is to it? Thanks a lot in advance, Jerry
The easy way to do this is to use the ISPCopy application which is part of the ISPConfig Migration Toolkit 2. But the manual approach will work too of course. Edit the /etc/hosts file on master and slave so they both have the new IP. Then use the mysql user editor from phpmyadmin on the master to change the IP of the ispcsrv* mysql user of that slave. I recommend to using phpmyadmin here as the user permissions are split into many records in most tables of the mysql.mysql database, using the user editor is the best choice so you don't have to edit all records one after another. Move the ispconfig master installation incl. all mysql users to the new server and then edit the hosts files on all systems to reflect that change.
Thanks for your prompt reply, Till - I didn't have the migration toolkit on the radar for this purpose - however me being the "better safe than sorry" person, I'll probably give the toolkit a chance then as it may come in handy repeatedly in the near future. I take it I should either upgrade the old box to a more recent level of Debian then or install the target box with the same (old) version as the source server, or am I going to run into serious issues if using ISPcopy from a Debian 8 to Debian 9 box? (Upgrading the source machine _is_ an option, so I'm not too concerned if you say that's needed) I still hope messing with the master won't be needed as it is already on a high-availability cluster. Thanks, Jerry
Using ISPCopy to move an installation from Debian 8 to 9 should be ok. The worst thing that might happen is that one of the services complains about an outdated config option which needs to be altered then. So the 'old config' problem probably not better nor worse than what would happen with the 'manual' approach. I did copy ISPConfig installation manually in the past as well until I wrote that tool to automate the process, it's just a big time saver. The note about 'use the same Linux distribution and version' is mainly meant for users that are not aware that copying e.g. a postfix config from server a to a newer server b might cause postfix to spit out some errors about depreceted settings. What should be done after using ISPCopy is that you do an ispconfig update afterwards, this will already adjust most of the old vs. new config issues. Also Tools > Resync in ISPConfig run on the websites might useful when the apache major version differs (2.2 to 2.4) as apache changed it's syntax. What ISPCopy can't do yet is altering of the ispcsrv' user in the master database, so this step still needs to be done manually in phpmyadmin.
I have to get back to this once more - thank you very much for the ISPcopy tool, which has been incredibly helpful in moving my server installation - I will certainly make use of it some more. However I found three - hopefully minor - things: - ispconfig links in /usr/local/bin are not getting copied automatically which makes it slightly inconvenient to locate the ispconfig_update script that you (rightfully) recommend to run after the copy is complete. Also, when launched from ispconfig_update.sh it refuses to update if the installation is already up-to-date - you have to use update_stable.sh instead. - the IP address migration does not seem to have worked - I created a replace-ip-address.txt as described and added the parameter but it complained about no IP address replacement given. I'm doing another copy in the next few days and will check if it was just my fault but thought I'd mention it just in case. - third item isn't really a bug but maybe a worthwhile feature to consider: The copy tool clearly says, source and target OS and services should be the same - I deliberately used ISPcopy between a Debian 8 and a Debian 9 box and it worked like a charm - except that it happily refused to realize, that the PHP settings on the new box needed to be adjusted to reflect PHP 7 instead of 5. After some digging I was able to figure it out myself in the server config section of the control panel, but if there is a chance to make this auto-detecting in a future version, it's going to be a great help for others. Thanks again, you indeed saved me a lot of time - well worth the price you charge for this tool. Regards, Gereon
Thank you for your feedback and bug report. In regard to the IP address replacement, try to put the file replace-ip-address.txt in the vXX subfolder that matches your PHP version, e.g. v56 for PHP 5.6 and 7.0, v71 for PHP 7.1. I guess the code reads the file location from a wrong location at the moment, I'll check and correct that.
Ok thanks - I may not have thought of that, in particular since I was even moving between PHP versions (next move I am going to do will not have that issue as there will be so many old-fashioned web sites that I have to retain PHP 5.6 for that box) - I'll give it a try then.
Sorry, have to follow up on this again. Last night I did another run of ISPcopy, this time I had observed to bring both machines to an (almost) identical software level, the only notable difference being that the target box had mariadb instead of mysql installed (this worked well the other night from Debian 8 to 9 even, so I thought it wasn't that much of a risk) - unfortunately things failed miserably. It may have been my fault, but I still want to explain what I did - maybe there is an underlying issue in the copy tool? At first run, ISPcopy hit the wall after synchronizing the databases and a certain somebody had missed to install rsync on the target box (like I said, my fault) - so I fixed that and re-ran things, being under the impression that I could safely use --incremental-db as the databases seemed to have gone through fine on first run. It does look like the DBs got transferred again (even though nothing should have changed as apache was down and crontab entries disabled when I started both runs) - well I didn't mind much and let it continue. Transfer went w/o error messages, and even the replace-ip-address.txt triggered as I had placed it in the php5.6 folder. After everything was transferred, it first proved difficult to get ISPconfig updated (master server was refusing connections - turned out a mysqladmin flush_hosts did the trick), then running a resync was both painfully slow and did not seem to return the desired results. I eventually checked MySQL (well, mariadb) and it was in some sort of an undefined state. It appears something has messed up the mysql config big time and I can't tell what it is. Maybe it is to blame on the initial (failed) run, maybe it is because incremental-db parameter did not quite what I thought it should do, maybe I should step away from trying to use mariadb on Debian 8 altogether. I appreciate some qualified advice I'll try to clean up the target machine today and give it another try - I don't trust the state of things at the moment, so simply rerunning the copy tool may make things even worse. Two lessons learned before I retry: 1) make sure rsync is available on both machines (obviously) and 2) run a mysqladmin flush_hosts on the master server to avoid major hiccups with the resync. Thanks, Gereon
I don't think that the issue you describe is directly related to ISPCopy, the same issue would have occurred when you copied the databases over manually. For example I copied a server with 500+ databases with ISPCopy yesterday (Debian 7 to debian 9) without issues, or at least without issues that ISPCopy was to blame for like some incompatible lines in postfix main.cf and some websites which did not like that the default PHP changed from 5.3 to 7.0. A few things to note which might help you to understand ISPCopy better and to diagnose your problem: ISPCopy does not alter or change the MySQL configuration in any way on the target server. ISPCopy copies the databases over like this: The database get's dumped with mysqldump on the old server, the dump is gzipped, the dump is copied over to the new server, the database is loaded by piping the SQL dump to the 'mysql' command. So as you can see, this procedure just uses the standard tools provided by MySQL and MariaDB and it resembles the procedure that one would use for a manual transfer as well. There are no binary database files copied nor is any config file touched. The missing rsync has no influence on the database copy part, the databases are copied with the scp command which should exist on any server that has ssh. How the incremental copying works: This function uses the table hashes of a database from 'SHOW TABLE STATUS' and compares them with the hashes from the last run. If the hash has changed, then the table is copied again. Back to the underlying problem: maybe you have run into this problem? I've seen this on various systems, it starts to occur when you load databases into MariaDB, I guess MariaDB or Debian, has set some very low file limits lately which you might hit when just importing a few databases.
Thanks Till, you might have just hit the spot. Since I'm not going to be able to make another attempt on the switchover in the next 4-5 days, I may as well just run another copy after adjusting the settings you advised. Upon inspection of the systemctl output and some other logs after the attempt to switch, mariadb may just have grounded to a halt because of the open files limit indeed. If it was just that, then I must have been lucky that the other server was carrying too few databases to run into this problem. Thanks for your advice, very much appreciated.
Okay, couldn't stand the suspense, I did the changes and relaunched the isp_copy tool. Turns out it did happily migrate all the databases (which it did last night as well) and this time apparently also all the users - but only 19 out of 66 records in the mysql "db" table, resulting in the majority of DBs being inaccessible. I have patched that manually for the time being, but it does seem awkward as this ran perfectly well with the other migration the other day. With all the DBs already being created from yesterday's run, it may be due to fall-out from the initial run or whatever - impossible for me to determine now. Anyway, it _does_ look like it's on a better path now but I will only know for certain when I dare trying the DNS switch marathon again. Thanks, Gereon
Did you use the incremental option? If yes, this option skips the users. Sorry that I did not mention that.
No this time I deliberately did not use the incremental option - it did say it migrated all the users (although I think it claimed the same last night but didn't actually copy them all) but it didn't care too much about the DB table which was only partially migrated from a previous run. Anyway, it looks like by all I can tell the two boxes are in sync now - if I can motivate myself I may try another switchover after 10pm tonight - otherwise it'll be Sunday night and I'll know more by Monday morning. Thanks for your continued support and anyway for a great environment that is much appreciated by my users as well.
Just wanted to issue thanks again - two subsequent differential copies of my server worked just fine - I believe my original issue was the combination of a failed transfer (due to missing rsync) and weak mariadb defaults causing contention on the receiving end. Server has been moved to new hardware now and works like a charm. Can't wait to migrate our last old box. I absolutely recommend getting this tool.
