It is actually
/etc/postfix
files (postgrey_whitelist_clients, postgrey_whitelist_clients.local, postgrey_whitelist_recipients)
Thank you Eric!
I’d just like to thank everybody who contributed to this discussion. This has been really insightful and truly helpful.
Eventually, it’d be great if VirtualMin could provide some more support for such migrations, i.e. using some sort of wizard to streamline the entire workflow (many of the steps involved are largely identical).
In the meantime, it’d be great if some of the info mentioned in this thread, could be added to the mentioned “migration tutorial” here: http://www.virtualmin.com/documentation/system/migrate
Alternatively, I’d suggest to at least add a link to this thread.
I feel it’d be great if VirtualMin/CloudMin could further work towards this goal, i.e. of facilitating migrations between installations (virtual or dedicated). I went through a lot of trouble doing such things with other management panels, and it seems VirtualMin is almost half way there.
With some more automation and customization options, many of these steps could be done in an automated/scripted fashion.
Just think in terms of setting up additional name server entries, preparing migrations etc.
What could be done a little better on the VirtualMin side of things is providing explicit support for migration-related features. This includes for example remote database replication/synchronization, in the case of mySQL this is fairly simple to set up (found instructions on your forum!) and then there are other things that are currently not yet backed up as part of a virtual domain server, such as for example domain-specific cron jobs.
The potential issue related to migrating virtual domains and eMail addresses were already mentioned.
Some scripted method to compare/validate a migrated server would also be great.
It would be great to see a little more consistency eventually, so that migrating a “virtual domain” from one virtualmin installation to another one, could be largely automated using a handful of custom steps.
Thanks again
- wocul
Hello all,
Just to send a final word, the migration was successful and downtime was only about 40 minutes, using the IP from the old server on the new server. Very good! I just did one thing differently from the steps above, I’ve changed the old server’s IP to another IP instead of turning it off, then updated the new server with the old server’s IP and I could still access the old server to check and copy some configurations.
A few things to be aware of when migrating like I did from a Centos 5.8 32 bits, PHP 5.2.17, MySQL 5.0 to Centos 6.2 64 Bits, PHP 5.3.12, MySQL 5.5.32.
- If you don’t have SELinux enabled on old server, disabled it on the new server before the first restore test. You can have permission problems if after restoring the backup you decide to disable SeLinux.
- php.ini modules directory was restored as (extension_dir = “/usr/lib/php/modules”) but on the new server the correct path is (extension_dir = “/usr/lib64/php/modules”), so I had to do search/replace text on all php.ini files. Also had to set the timezone on all php.ini files.
- Mysql 5.5 does not accept long usernames as 5.0 does. So I had to change some long usernames that used to work on my PHP applications, updating them to the short name showed on Virtualmin->Edit Virtual Server (For MySQL database : username). Virtualmin shows this when the Administration username is longer than MySQL accepts.
- Dovecot mail_location was different on the new server, so I had to update it to match the old server’s location.
- Also, postfix, spamassassin, Postgrey, ProFTPd FTP Server and SSH server custom configurations were copied manually.
Other than that, it was all good, I’m pretty happy with the server up and running.
Congratulations for the Virtualmin guys, it is a great product.
And thanks for everyone that helped on this thread.
Cheers,
- Rogerio
The postfix/dovecot related issues seem familiar, it would be great if VirtualMin could recognize such mismatches and suggest a modified config for review, so that the corresponding settings and folders can be rsync’ed
And yes, it would be also great if VirtualMin could recognize that a VHOST has matching cron jobs under the same user name, so that these could be also saved/restored accordingly.
Also, postfix, spamassassin, Postgrey, ProFTPd FTP Server and SSH server custom configurations were copied manually.
Are those settings (usually found in Webmin, also e.g. Apache’s general configuration) not backed up and restored by Virtualmin’s backup with the –all-features option?
Regards,
fuggi
Custom config for Postfix, and Postgrey whitelists are copied in the Virtualmin backup, the rest is not.
Are they at least copied by Webmin’s “Backup configurations files” functionality?
Never tried that, but I suppose they should. What’s the problem exactly? You could always just archive /etc and extract what you need from it on the new server.
The problem is that it is neither an easy nor robust procedure if some parts are done automatically but others have do be done manually and the admin has to keep it all in mind.
Yes, I have to agree there.
Problem though is that Linux installations are very versatile and can differ greatly. Many different distros, a patchwork of software put together, and everybody sets stuff up their own way. So, coming up with a migration procedure that works for all of them is non-trivial to say the least. 
So, some manual work is probably always required when doing such a migration.
this isn’t mentioned on the website ( http://www.virtualmin.com/documentation/system/migrate ) - so just for future reference:
to reduce downtime, dynamic webbsites using mySQL (phpBB, wordpress, drupal etc) will be typically set up to do mySQL replication during the migration to a new server, i.e. remote DB mirroring onto the new server - that’s when the old server can stop using its own local DB and use the new DB as its master DB, so that regardless of the DNS propagation delay, both servers (old + new) will use the new DB on the new server.
http://www.virtualmin.com/node/18141
Thanks for this thread. I’m probably going to have to go through this somewhat aggravating sounding manual/automatic migration of virtualmin from one machine to another, since the VPS OS is debian 6 squeeze which will reach end of support in about 5 months, May 2014 probably, requiring a move to debian 7 wheezy, but that’ll require moving from the current hardware node which is centos 5 kernel 2.6.18, to a new hardware node since debian 7 wheezy requires the hardware node to be running kernel 2.6.32+ aka centos 6. Argh.
I just went through the same thing and ended up messing up my whole installation, there are some folks in the “jobs” forum offering support with these sorts of things - if you cannot afford any downtime, I suggest to get in touch with them …
BTW: I used this tutorial to set up mySQL replication in order to migrate the whole thing with zero downtime: http://techblog.procurios.nl/k/n618/news/view/56429/14863/how-to-migrate-mysql-databases-without-downtime.html
And this for validating the replicated DB: http://www.tutorialsolve.com/2009/07/23/tutorial-for-mysql-data-validation/
http://www.alexwilliams.ca/blog/2009/10/01/scripted-mysql-replication-consistency-checks/
Once everything was in place,I only had to change the DB credentials on the old server to use the new/replicated DB instead.