I successfully switched my hosting from my real-hardware machine ‘daemon’ to my new virtual-hardware machine ‘gauss’ which is hosted by HostEurope.de. After turning off the services on ‘daemon’ and doing a final sync, I started the services on ‘gauss’ and activated the TCP-forwarding on ‘daemon’ with rinetd. I forwarded FTP, HTTP(S) and IMAP(S) such that users could connect to the old IP where those connections got forwarded to the new IP. With this, the new host only saw connections originating from the old IP although they actually belonged to strangers. Therefore I didn’t also forward the SMTP-port directly, because in that case the realtime blacklisting would have failed.
So I configured Postfix to keep doing RBL lookups and SPAM and virus scanning, and to forward mails destined for the local domains to the new host. I did it this way:
In /etc/postfix/main.cf, I first deactivated mydomain and replaced it by myhostname in the definition of mydestination. Then I added the lines
relay_domains = domain1, domain2, domain3
transport_maps = hash:/etc/postfix/transport
append_at_myorigin = no
and simply deactivated the virtual_maps. By this, I couldn’t reject unknown users anymore, but that was easier as I didn’t want to think what aliases I had. The new host could tell anyway what users did exist. However, it could’ve been done by setting
relay_recipient_maps = hash:/etc/postfix/relay_recipients
and adding lines to the mentioned file like
user1@domain1 x
user2@domain1 x
...
which then had to be postmap’ed.
After that I created entries in /etc/postfix/transport like
domain1 smtp:[IP.ADD.RE.SS]
domain2 smtp:[IP.ADD.RE.SS]
domain3 smtp:[IP.ADD.RE.SS]
what also had to be postmap’ed, of course. (Probably the syntax relay:[IP.ADD.RE.SS] works as well.)
To test Postfix with these settings before the actual migration, I wanted it to listen on another TCP-port temporarily, say, 2525. I had to add that port as allowed mailing port to /etc/services, say, as
smtptest 2525/tcp mail
after what I replaced smtp by smtptest in /etc/postfix/master.cf in the line starting with smtp and ending with smtpd. Now I could check via Telnet to port 2525 and talking plain SMTP that I didn’t provide an open relay and that all mails went where they should go to. I had to keep the relayhost active on ‘daemon’ for possible locally originating mails or SMTP AUTH.
After activating rinetd on ‘daemon’ and checking that everything worked as it should, I told my provider to switch the IPs in the DNS. Shortly after those changes were active, most of the clients were already brought to the new IP directly. 12 hours later only few connections were still coming to the old IP, most of them by crawlers. Surprisingly, this is still the case 24 hours later. The last connections came 42 hours later from some weird scanners located in Columbia, South Korea or China, and 9 hours after the last visit I turned off rinetd. ‘daemon’ is now absolved its responsibility and will play a different and yet unknown role in my network, maybe as a backup host.
The changes in the basic data of the servers are: space 20GB→15GB, CPU single@800MHz→dual@700MHz (according to /proc/cpuinfo), RAM 384MB→3GB(!), swap 1GB→8GB(!).
In short: Debian lenny’s current libc6 version 2.7 doesn’t work on kernel 2.6.9 with SMP enabled. Downgrade to libc6 2.6 if you can’t change the kernel. You might have to do this on a non-2.6.9 (or >2.6.9) system.Here’s the st
Tracked: Dec 07, 12:01
Almost three years ago I migrated to a virtual server at HostEurope.de. It was a real relief to not care for any hardware anymore, and I’m really satisfied with their service which includes monitoring and restoreable snapshots. The only major prob
Tracked: Dec 20, 13:25
Quote of myself from four years ago: I had to do the migration to a parallel machine and had only one week to accomplish this. I’ll never do it this way again, however, rather pay for two servers for a short time and decide when to finally switch. Thi
Tracked: Nov 27, 18:31