We were running our domains at a vServer of
Vollmar.net, a very reliable hoster. They decided to change their virtualization environment from CTX to XEN – which is fine. The drawback: There is no automatical «migration» for the images. Since I would like to have a XEN-based server due to more power for the same money, we need to reinstall our vServer.
So, this is about how to migrate a Linux system from one server to another. Of course, this is limited to the software I run on the vServer. Also pathes might be Debian specific.
For transfering data from the old to the new server I use ssh this way:
cd DIR && tar -cf - . | ssh newServerIP "cd DIR && tar -xpvf -"
This has the benfit of preserving the permission and ownership of the files.
Testing of most applications is quite easy by putting the new IP adresse into
/etc/hosts on a local machine. This uses the server prior to the changes within the DNS.
On the old server we retrieve the package list:
dpkg --get-selections > PKGLIST
We transfer this PKGLIST to the new server and:
dpkg --set-selections < PKGLIST
Finally we tell apt-get to install the packages:
apt-get dselect-upgrade
If we have installed apt-file, we need to retrieve its filelists:
apt-file update
Depeding on package selection, this is now a very unsecure situation: Services are up and running, but are unconfigured! Thus we shut them down. For me these are:
/etc/init.d/apach2 stop
/etc/init.d/exim4 stop
/etc/init.d/courier-imap-ssl stop
/etc/init.d/mysql-server stop
Next steps are related to the MySQL database supporting my Etomite.
Preparing a dump of all databases:
mysqldump --password=ZZZ --all-databases > /root/MYSQL_DUMP
…and after transfering, this could be
mysql -p < /root/MYSQL_DUMP
The logrotate script (and some other maintainance stuff) of mysql uses a special account – which has an (during package installation) autogenerated password. We need to look the new one up in
/etc/mysql/debian.cnf
(replace xxxxx belog with this) and finally we need to flush priviledges, thus all the permissions are correct and active:
mysql -p
Welcome to the MySQL monitor.
....
mysql> GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES,\
SUPER, LOCK TABLES ON *.* TO \
'debian-sys-maint'@'localhost' IDENTIFIED BY PASSWORD 'xxxxxx'
mysql> FLUSH PRIVILEGES;
Since we just have a couple of users, we manually created them on the new server, but took care about the uid, thus they correlate:
adduser NAME --uid UIDofOldSERVER
Afterwards, I transfered the
/etc/shadow
. While updateing
/etc/groups
take care about changed GID of gorups like www-data!
Next steps are related to the uncritical http stuff. First transfer the basic config
/etc/apache2
and the normal www stuff from
/var/www
, which includes gallery pix for me. and finally, dokuwiki’s data needs to be transfered from
/usr/share/dokuwiki/
We should now start the apache and test all its websites.
First transfer the basic config
/etc/courier
We should now start the courier-authdeamon and imapd-ssl. But test might fail since the Maildir folders are required to be transfered to the user homes before.
First transfer the basic config
/etc/exim4
, maybe also
/etc/exim
, if aliases are defined there. Afterwards
/etc/spamassassin
needs to be transfered and checked if the deamon must be enabled in
/etc/default/spamassassin
. If you run mailinglists by mailman, transfer
/etc/mailman
as well as
/var/lib/mailman
, which includes the old archives.
We should now start the exim4 and spamd but testing is required to make sure we dont have a misconfigured exim4 as open-relay.
Okay, now for some minor, but important things. We first transfer the root and user crontab entries.
Afterwards have a look, if
/usr/local/
contains software, which might need to have special maintainance, if CPU architecture is different.
We could now transfer the root’s HOME as well as user’s ones.
Okay, the server is now ready to serve our requests, thus we could change the DNS entries of the domain.
Take care and monitor logs in old and new server since the old server just retrieves spam.
From now on, mails might get temp. lost from user point of view!
So after a couple of days, we could manually transfer the newly arrived mails from the old server to the new one.
..and finally edit
/etc/ssh/sshd_config
for not allowing root login any longer.
If something is unclear, wrong or misunderstandable – just drop me a note!