Hello, yeah, some topic as Issue #2368. In a multiserver setup I'm trying to found a way to move some website to other servers to balance the load without breaking the website realpath. The goal is to do a transparent migration without search and replace /var/www/clients/clientX/webXX/ in files and db (eg like in wordpress). Creating a new website with same domain in an different server create a new (autoincrement) website_id and there is no way to override it. Reading the manual I see also that "Linux User and Linux Group cannot be changed" "Connect Linux userid to webid" is on since setup in every servers. I think that the wanted logic is similar to mirror setup. Any suggestions? Thanks
Wish someone would write a utility to allow moving around websites or mail boxes around within a single multi-server ISPconfig system. Would be willing to pay a reasonable amount for such a tool and I'm sure others would as well Probably have to do something like On a form get a list of clients, websites, & databases to move from server A to server B Using remote API create a new website and database on new server for client move via rsync the data from old server/website to new server/website Move database from old server to new server delete website and database on old server update DNS for correct IP
Ok after going through various forum posts along similar lines, I need to bring up this topic again. I know it is technically not a problem to create a service of the same name (website, email, whatever) on a different node in a multiserver setup, but as of now that results in new system internal user ids getting assigned, and the need to manually sync over the associated contents. It is, however, entirely possible to change the servers for an ISPconfig user account - the change only takes effect once the associated services are recreated, potentially resulting in loss of data if nothing is done about it beforehand. I am fairly proficient at creating sync scripts & stuff - so my question and amendment to this feature request would be: Can there be a hook which would call an external script upon updating the server in an ISPconfig user's account that would pass old and new server ID, allowing for an appropriate sync script to be called, following by a resync of the respective service so it will become active on the target server? Does this seem feasible at all or are there internals to ISPconfig forbidding such an approach? I've had to move about plenty of websites already and repeatedly wondered if there was an easier way to accomplish this. I am certainly willing to invest some of my own time in getting this to work - if it is at all possible, that is Thanks, Jerry
I'm sure such a tool is possible, and I remember there was feature request about that. Now searching I found this: https://git.ispconfig.org/ispconfig/ispconfig3/issues/4778 I do not want to code PHP, so count me out from implementing this. In my experience, reasonable amount of pay for coding work is very different from the perspective of byuer and seller. My opinion is reasonable amount is what sloccount shows. https://dwheeler.com/sloccount/ Just for kicks, I tried sloccount on Linux source version 5.4-rc4: Code: Total Physical Source Lines of Code (SLOC) = 18,505,185 Development Effort Estimate, Person-Years (Person-Months) = 6,049.06 (72,588.75) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 14.65 (175.82) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 412.86 Total Estimated Cost to Develop = $ 817,146,127 (average salary = $56,286/year, overhead = 2.40).
There was discussion about this before the migration tool and ispcopy saw the light of day and Till said he was working on something like that, but not sure if what he was talking about ispcopy which moves entire servers. I think if Till and his team wrote something like this, a service move tool within a single multiuser setup and priced it like they do the current addon tools it could be well worth their time and make ISPConfig even more desireable. Since the cpanel price increase there has been more talk about ISPConfig as a potential worthy successor to cPanel on Webhostingtalk and others especially since cpanel migration has been added.
Yeah I found ISPcopy immensely helpful when I had to replace some old iron in my multiserver setup - but that was just a true 1:1 copy to a new physical node replacing the old one. Being able to actually shift websites (and associated DBs) to other servers in the setup as suggested in the issue linked above would just add a lot of value to ISPconfig. Given that the last mention of this being in development appears to be two years old, it's probably less trivial (or simply less prioritized) than it seemed at the time. Just for the sake of argument: I wouldn't mind investing some of my own time to help with this, and I generally don't count in terms of hourly wages if I find such effort worthwhile - but as with everything else, YMMV
you can just edit the dbispconfig master database, change the website server_id, the database server_id, ftp server_id etc to the id of the server you want to move the site to. then resync on the new server, it'll create all the user accounts, folders etc in place on the new server. it'll still leave the site/database as it is on the existing server, so you'll then need to copy the files/database over. assuming you have the Linux user_id linked to the web_id then the user_id's and paths will be unchanged. that just leave's cleaning up the dbispconfig database and site/database files/configs on the old server after you've finished moving the site.
As the client # and web # are unique across the entire ISPConfig installation (I'm 99% sure they are, as they are stored in the master database), there is no need to change them. Ie. don't "create a new website" but implement a proper "move service(s) to another server" which would leave those the same. Presuming the file paths (eg. 'Website path' under Server Config) are the same on source and destination, no changes would be needed to databases/htaccess/etc. It's sounds simple enough, but there will need to be a lot more involved in a "push button" approach which doesn't break things. Some state would need to be maintained that the service move is in, along the lines of: checking everything is good (fail with specific info if not) -> adding service to new server (same effect as "resync on the new server" -> initial copying data (rsync, multiple passes) -> disable service on old server for final sync -> enable service on new server -> remove service on old server. In the "checking everything" stage you'll have to find non-standard files/directories (eg. laravel installations) and either offer what to do with those or simply say it's not supported. For jailkit files, at the moment it'd be safe to sync all the old files over and they should run on the new server, though down the line I believe ISPConfig will be more involved in jailkit (at least updating jails, if not better support for what services/binaries to include in the jail itself, possibly including php version management), so might just plan to do a reinit on the new server after data has been copied. Websites with a static ip address will be problematic/need further consideration. Checks should be done for php versions (though what do you check, just that the version name is the same? same init script for fpm? just print a list of available versions on the new server and select one as part of the migration?). Likely nginx/apache differences wouldn't be much, though any specific apache/nginx directives would differ, and perhaps a way to supply converted directives manually should be made? Or just let the site not work right on the other end until that would be cleaned up. Any idea how to cleanly export certbot certificates and import on the new server? Just request (manually via checking the letsencrypt checkbox again?) a new certificate once migrated (and DNS changes completed)? For database dump/load, do database collations need checked, or is an sql dump complete enough to safely load on the remote end even when server versions differ, etc.? Definitely catch any errors in loading the dump on the new server and report the failure. For DNS, it'd be easy enough to offer IP address substitution, and possibly a few name substitutions. Maybe have a little screen/step to offer checkboxes for common substitutions to be done? Eg. IP of new webserver changed for ip of old webserver, hostname of old mail server changed to hostname of new, eg. For mail, most things should be straightforward, but one thing that comes to mind is amavis/rspamd filters, if the old and new server differed in the filtering system, those would need converted. You could (should?) offer the option to manually confirm the last "remove service" step, or to automate it if everything else went fine.
It always sounds simple enough, at least to managers. An oft-heard specification runs something like: "just slap a quick script together to do this, it just needs to work so there's no need for tests and docs etc."
oh, it is simple enough, at least for successfully (manually) moving a site to another server. i've done 20+ sites using this method without any problems. the clean up afterwards is a bitch though . the sites files/databases are easy. but in the ispconfig interface, if you filter it to show sites on eg 'web1', getting it to not think the site you just moved from web1 to 'web6' is still on web1 requires quite a bit of effort and mysql meddling in dbispconfig. getting it done automatically, as jesse envisages, encompasses a whole lot more sanity/error checking, failback planning and coding. fortunately, i'm not a programmer, so that, as slartibartfast would say, is an SEP. (somebody else's problem)
