Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] (Semi) Automatic Migration To A New Server #1232

Open
realrellek opened this issue Jan 27, 2024 · 0 comments
Open

[FR] (Semi) Automatic Migration To A New Server #1232

realrellek opened this issue Jan 27, 2024 · 0 comments

Comments

@realrellek
Copy link

realrellek commented Jan 27, 2024

As already discussed on discord, here is a concept of how an automatic migration to a new server could work. I want to propose a two-fold solution. One is completely automated and it rsyncs everything over to where it was. Let's call this magic-migrate. The other one is a more clean solution but requires more involvement from the admin because one would have to mysqldump and re-import all databases. Let's call that clean-migrate. I would propose to make the latter the default way because it seems cleaner and would not carry over any residue from updates over the years. Also if you are using Froxlor for a long time, say with MySQL, you are likely to have legacy passwords which would become a problem later (if we believe MySQL's warning in the logs).

Both options would be available using the CLI.

Both options relate to the automation of the guides I am writing for the docs: froxlor/Documentation#18

magic-migrate

You call magic-migrate and Froxlor-CLI would ask a few questions, such as, new IP, SSH port, SSH credentials (password or key), or maybe ask if keys are already registered in the system (~/.ssh/config already configured).

Hm and that's about it, I would say? Like the rest would be to rsync data over.

However, I think froxlor-cli would have to create a script because you really should stop all services that are affected, such as web server, database, mails, ftp.

These services would have to be stopped as well on the target server.

So it feels safer to just put a script somewhere, tell the admin to stop everything on both machines, and run the script.

On the new server, you would start all the services and run another CLI script, like I dunno, finish-migration. This would call the IP switcher, maybe ask if you wish to change the hostname, configure the system and run the cronjob.

clean-migrate

clean-migrate should ask the user if you intend to switch your DBMS. Because mysql_native_password is deprecated on MySQL 8 and caching_sha2_password is not supported on MariaDB.

So Froxlor could check what hashes are in use. If it detects something has to be done, it should ask for the password first (and make the admin go look for them, e.g. in wp-config.php) and update the user to an appropriate password hash.

Froxlor now exports all the users and their hashes into a file (a json file, I guess). That would be a file we need over at the new server.

Also Froxlor could mysqldump all customer databases and its own. All of these and customers' htdocs are now transferred over to the new server. And the admin is asked to run the CLI with clean-migrate-target or whatever. This function would ask for (or just find) the json file and the dumps from earlier and import it. It would do it as if you tell Froxlor to create a new database (only that we don't give it a plain password but a hash).

And then it calls finish-migration and does the same as described above because these are jobs that need to be run anyway.

Final thoughts

I give you, this document is somewhat long and verbose, but I think it really isn't all that much that Froxlor would actually have to do.

I mean the finish-migration - or rather what it would actually do - is already implemented for the most part. The IP switching thing exists and the question if you would like to change the hostname is just one setting. And so is the configuration thing.
It might just need a little adjustment if you were using clean-migrate before because in that case, it would have to make sure if configs need to be changed (due to distro for example).

We should also leave a really manual migration guide (well maybe even both versions) in the docs, in case you for some reason have to do it manually. Kind of how you could also configure your system manually if you want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant