still looking at moving from apache to nginx, once i work out the cache purging problem.. may still go for it and using normal caching plugins and work out the fastcgi caching stuff afterwards.. in the meantime.. want to move some vps's as is from aws, quickly, as they are going to become more expensive unless i commit to another full year with them.. for ispcopy, i know it needs to be the same OS on source and destination, does it also have to be the same release? ie can use it to copy from an ubuntu 22.04 source to an ubuntu 24.04 destination, or does the destination also have to be 22.04? using it to copy a slave server, does it make any changes in the master database? does it change the existing, or create new mysql logins for mysql master db access (root/ispcsrv# etc) or do i need to create those myself? if i copy the master server to a new hosting provider, do i need to change anything except the A(AAA) records in dns, and the hosts file on the slaves? anything else i've not mentioned yet that i need to be aware of?
My understanding is it must be exact same OS release. ispcopy does not adjust for differences between the source and target. I have not used ispcopy, just the migrate from Migration Toolkit.
same here.. only used the migration toolkit.. a long long time ago.. just thought, if ispcopy installs the services and then just copies the configs, rather than just copies over the /etc folder.. then in theory, it could work,
ISPCopy does not install any services; it just copies over the config files that are managed by ISPConfig, databases, and website config as it is. Therefore, the OS should be the same version or at least a similar version. It can work if you e.g. copy from debian 11 to 12, but it might be necessary to make some adjustments afterwards if e.g. a service doe snot srat with the old config.
no No. You must run the ISPConfig updater once on the new server after using ISPCopy to do this. You will have to re-create the root mysql users for the slave updates, as ISPCopy does not transfer any root MySQL users. I'm also not 100% sure if it creates the slave connection users (ispcsrv*), but you can recreate them by running an update on the slave nodes. ISPCopy doe sis that it copies the ispconfig user and the users of all web databases (but this applies to web servers only and not to a standalone master server).
ok. cool. i assume it also rsyncs over data like the contents of /var/vmail and /var/www... that can obviously take quite a while the first time.. can ispcopy be run multiple times between the same source/dest pair until it completes quickly.. the same way the migration toolkit can so that any downtime/disruption can be minimised? also, not an immediate concern with the servers i'd start with, but for a source server with multiple volumes mounted at /var/www, /var/lib/mysql etc, i take it it doesn't matter if the destination server disk configuration is different, (one single volume, or a volume is mounted at a different point) as long as there's enough space for all the data?
Yes. Yes, it uses rsync. Some people use it even in auto mode to re-sync with a hot standby server every few hours. That should be no problem. If it can be copied with rsync, then it should work. ISPCopy is basically a tool that does what you, as admin, would do during a manual migration. Lots of rsyncing of files and folders, dumping and importing databases, plus syncing Linux users, groups, etc. ISPCopy has a nice additional feature: incremental MySQL database migrations by table. It can compare the table hashes between old and new systems; only if the data has changed in that table does it get migrated. So if you have a,g, some tables with a lot of static data, these will not get copied again if you use that mode. But due to this approach, source and target OS should not be too different Or if they are, some manual modifications are needed later.
that's great.. will probably do some experimenting/testing with it over the weekend then.. at least it'll get my mind away from that bloody nginx fastcgi-cache purging .
If you run into an error like " ERROR at line 1: Unknown command '\-'." In mySQL transfers, then send me an email to info at ispconfig dot org and I send you a pre-release of the next version. This error is caused by MariaDB intentionally making dumps incompatible between versions. I've added a grep filter now to remove what they added as an import blocking mechanism.
ok.. done a isp_copy from ubuntu 22.04 to 24.04 not actually removed the old server, or done an ispconfig_update.sh yet. just checking everything over first. the servers only running dns, so pretty much the simplest copy possible to start with.. done an auto-install standalone ispconfig on the target to get all the services installed first. bit of fun and games getting the source server to ssh to the target with a password.. changing the target ssh to allow it wasn't doing anything.. i always forget about /etc/ssh/sshd_config.d/custom.conf and /etc/rkhunter.conf.local got this when starting the copy: Code: Copying system users... Group conflict: ispconfig 1001 User conflict: source(ispconfig:1001) target(ispconfig:1000) Proceed anyway? (y,n) [n]: y useradd: group '1001' does not exist WARNING: Remote command failed: useradd --non-unique -d '/usr/local/ispconfig' -g ispconfig --uid 1001 --gid 1001 -s '/bin/sh' ispconfig it didn't re-add the user/group to the target passwd/group files, and checking /usr/local/ispconfig afterwards, everything seems to have the correct permissions/ownership stil. also got this in /var/log/ispconfig/cron.log Code: Mon Oct 21 11:55:11 AM UTC 2024 Database connection failed Database connection failed Database connection failed Database connection failed Database connection failed Zugriff auf Datenbankserver fehlgeschlagen! / Database server not accessible! PHP Fatal error: Uncaught Error: Call to a member function testConnection() on false in /usr/local/ispconfig/server/server.php:64 Mon Oct 21 11:55:11 AM UTC 2024 Stack trace: Mon Oct 21 11:55:11 AM UTC 2024 #0 {main} Mon Oct 21 11:55:11 AM UTC 2024 thrown in /usr/local/ispconfig/server/server.php on line 64 which i'm assuming is the servers attempt to connect to the master database to check for any updates, which is failing because i haven't allowed root mysql access to the master db from the target servers ip's yet. so, overall, (and bound to go wrong now i say this), it looks like isp_copy from 22.04 to 24.04 worked fine with not . subject to final ispconfig_update.sh --force and reconfigure services.. to note, things like /etc/monit, /etc/rkhunter.conf /etc/rkhunter.conf.local /usr/bin/wp-cli (on webservers) etc wouldn't get copied over by default. but those files/folders should be taken care of if put into a custom-copy-paths.txt file. dedicated webservers the next test, then mailserver, then master/gui.
i've done it in a slightly different order than i said i would.. and tested a mailserver isp_copy, again from ubuntu 22.04 to 24.04 and again, only checking things for now.. not actually removed the old server and made the copy live, run ispconfig_update.sh on it, or anything like that.. but again.. everything seems to work fine.. bit of an issue trying to login to rspamd.. but got there eventually.. password in /etc/rspamd/local.d/worker-controller.inc was different to the source/live server.. did have issues logging in from the start, and did try 'rspamadm pw' at some point.. so that difference may have been that.. but setting that to match the live source server allowed login to rspamd again.. had to change CAP_DAC_READ_SEARCH to CAP_DAC_OVERRIDE in /lib/systemd/system/monit.service but that's an ubuntu 24.04 monit/php-fpm thing.. not actually isp_copy related. other than that, no issues using isp_copy to go from ubuntu 22.04 to 24.04 that i've noticed. don't have roundcube on the mailserver, but see no reason why it would have any issues. connected thunderbird to copied mailserver (using ip for imap/smtp server settings). no problems seen.. downloaded mail ok, and accepted new mail for sending to external mailserver.. sending out failed... due to ptr/spf etc settings.. but that's totally expected at this point, no ptr record on that ip, and ip isn't in live dns/spf.
tested on a dedicated webserver.. again from ubuntu 22.04 to 24.04. again, this is just checking everything before running ispconfig_update.sh, or actually replacing the old source server. everything seems fine again.. all services seem to start without problems. only issues i've noticed.. when copying from the source to the target, it doesn't copy the web##.conf files in /etc/php/#.#/fpm/pool.d www.conf is there though.. but that may have been from the standalone auto-install newly done on the target to get the services installed. also the php.ini files aren't copied over.. maybe the rsync command used is set to not overwrite newer files? which they all would be on the target server. the web##.conf files aren't an issue, the resync once actually switching the servers will create those, the php.ini files are something to take note of though... any changes to eg memory_limit, post_max_size, upload_max_filesize etc would need to be re-applied. i think i might leave test copying the server with the gui on it for now.. got other websites on there that require re-issuing licenses for when moved.. and those sites might try sending invoices / renew domains etc.. may get all the slave servers moved first and running ok for a couple of days before testing moving the master.. at least i'd know the only issue with the slaves then is updating their hosts file. on which note.. when actually removing the old source and making the new target live, obviously need to run ispconfig_update.sh and resync.. ip's will change.. some servers will keep the same hostname, some will change.. will the ispconfig_update.sh update the changes (hostnames, ip's) on the master, or will they need to be changed manually before the resync? i'm on about in system->server config (db server table)
just an update on this.. i took the plunge on removing the old ubuntu 22.04 nameserver and making the 24.04 nameserver live. was a bit nervous about doing so, due to the change of ip's on the primary nameserver itself, and thus the glue records as well. so much could potentially go wrong... i'd previously set the ttl for everything in the self-served dns zone to 600, both for all the records, and for the SOA TTL as well. but that all went well, and was very quick.. then changed the ip's (A and AAAA) in the dns zone for it on the master, and run a resync.. so far.. no problems... so again, it looks like using isp_copy to copy a slave server and upgrade the OS at the same time works. at least for ubuntu 22.04 to 24.04 just 2 things to note so far.. 1. i auto-installed ispconfig as a standalone install to get everything pre-installed, and used expert mode to only enable/configure the same services as existed on the source ispconfig server. when using isp_copy afterwards to get the source config copied over, the file /usr/local/ispconfig/server/lib/mysql_clientdb.conf now contains the mysql root password of the source ispconfig server.. so before you run ispconfig_update.sh and reconfigure the services... you need to remember to either update this file to the mysql root password of the target server, or actually change the mysql root password to that of the source server. not a biggie.. very obvious when it happens and easily fixed.. just remember to keep a note of the passwords shown at the end of the auto-install. 2. ufw. on the new server it wasn't enabled, and when i did enable it from the cli, it had no rules except the default deny all incoming.. so i got locked out.. i could get back in via a console and disable it.. then i tried disabling it, and re-enabling the firewall from the ispconfig gui.. just doing that does not re-create all the rules on the target server.. deleting the firewall rule in the gui, and recreating it from scratch does recreate all the rules on the new server and enables ufw. possibly just changing the existing rules, adding and then deleting a new rule will recreate them all, i didn't think to try that until after i'd deleted the whole entry, so i don't know if it does. definitely something to watch out for.. especially if you don't have some sort of idrac / hypervisor console that will let you get back into your server if you don't have physical access to the server.
