1

I have a centos 6 VPS running ispconfig that isn't in good shape at the moment. Yum is broken beyond repair and it looks like my best option for fixing is a reinstall.

I'm planning to backup, install centos 7 and all my server software, recreate accounts, and restore files on the same machine. Getting a 2nd machine might be an option since this one runs out next month, but I'm not sure I will get the same setup because I got an extra IP address in my plan that I need.

My issues are the postfix mail accounts - I've used imapsync to migrate before, but that's not going to work in this case because I won't have two servers up at the same time. It looks like I can copy maildir files and system user files but this seems fragile to me.

Also I'm considering moving from ispconfig to vestacp. (Edit: I'm sticking with ispconfig)

Any suggestions that will make this easier would be appreciated. If I'm going about this all wrong please let me know.

Edit: Clarifications

  • I have 32 email accounts under 12 domains
  • My IMAP server is dovecot
  • My Server Control Panel is ispconfig (I'm sticking with it)
  • Maildir files are not under /home/ they're under /var/mail/exampledomain.com/exampleuser/Maildir/

3 Answers 3

4

The first answer from jornane is correct so far as it goes, however I do not believe it addresses what the OP is really trying to get at - which is how best to handle migration of email and accounts, rather than how to handle DNS.

Ordinarily there are many ways to handle this task, but because we are dealing with only one server which will be going through an OS reinstall. I will take for granted OP's assertion that yum has somehow become irreparable, or so damaged that repair would be more complex or time-consuming than reinstalling OS. I will also take for granted that this is your only available server, and that you are familiar with imapsync. I am also going to assume that you are using dovecot-imapd as your IMAP server, because postfix is an SMTP server and not an IMAP server (but dovecot I find is one of the more widely used IMAP systems with postfix).

One option in this scenario is to use imapsync to backup your accounts to a series of free gmail accounts. Backup each account to gmail (you could do several simultaneously, depending on how much muscle your current server has and what kind of anti-spam tactics Google is using for IMAP lately). You can use this script:

imapsync \
   --host1 your.oldserver.ext --port1 993 --user1 [email protected] \
   --passfile1 /path/to/gmail_mirror.passfile1 --ssl1 \
   --host2 imap.gmail.com --port2 993 --user2 [email protected] \
   --passfile2 /path/to/gmail_mirror.passfile2 --ssl2 \
   --useheader 'Message-Id' --skipsize \
   --syncinternaldates --noauthmd5 -nofoldersizes \
   --split1 100 --split2 100 \

Note that this relies on the default IMAPS TCP port 993. If you are using plaintext IMAP on your server, you should consider not doing that as soon as possible, and in the time being you can change your port to 143 or whatever you are using. You can probably also use localhost for host1 in the first script and host2 in the second script, again depending on your settings. You will also need to use a passfile. More info on the correct flags to use and how to use them is available here: http://imapsync.lamiral.info/OPTIONS

To dump the emails from Google to the new server you can do this, which will work for your All Mail and Sent Mail folders:

 imapsync \
      --host1 imap.gmail.com --port1 993 --user1 [email protected]
      --passfile1 /path/to/gmail_mirror.passfile1 --ssl1 \
      --host2 your.newserver.ext --port2 993 --user2 [email protected]
      --passfile2 /path/to/gmail_mirror.passfile2 --ssl2 \
      --useheader 'Message-Id' --skipsize --allowsizemismatch \
      --syncinternaldates --noauthmd5 -nofoldersizes\
      --split1 100 --split2 100 \
      --regextrans2 's/\[Gmail\]/username\@somedomain/' \
      --include "All Mail|Sent Mail" --delete2 --expunge2

The advantages to this approach is that the likelihood of it breaking something is very small. Because I am working from the assumption that yum is irreparably damaged, and because I am unfamiliar with this server, it is very possible that other components are also broken or corrupted. This method is very simple and leaves little room for subtle failures.

There are other options that have additional benefits: most notably, other backup and restore options would be much faster as they would not depend on internet connections. However, exploring those options would require more detailed information about your environment, for example: does your server in fact use Dovecot to provide IMAP or another program? Does your server use some CMS like cpanel or Plesk? Does your IMAP daemon have a MySQL backend? Do you use system or virtual users?

Keep in mind that there are a variety of ways that a mail server migration can be complicated. There are a variety of different authentication schemes for example that could complicate the migration of users and their mailboxes as opposed to simply transferring their email as I have laid out here. If you want to recreate users that can send using SMTP using the same architecture as your prior server, we would need to get a look at the relevant portions of your main.cf and IMAP configuration files (for dovecot those would be dovecot.conf).

3
  • Your assumptions are correct. I'm using dovecot, my control panel is ISPconfig, and imapsync was fairly painless last time I used it. I had considered the imapsync>gmail method but thought 32 accounts might be too many for that to be practical. I will still consider it though. What about a local (windows) imap server instead of gmail? Or actually I have a linux box running xbmc that maybe I could get postfix/dovecot running on there. Jul 29, 2015 at 22:07
  • Ah ok - since you have somewhere to backup the data temporarily, why not copy the backend files? This would include: /etc/dovecot.conf file, the contents of /var/mail/spool and/or /home/ ? With 30 users you can recreate passwords manually on the new server or move those as well (method depending on whether SQL, passwd/shadow file, LDAP, etc). Aug 2, 2015 at 14:12
  • I ended up finding another server to move to so my initial problem wasn't an issue anymore - I was able to use imapsync directly to the new machine which made the whole process much easier. While tedious, using the throwaway gmail accounts feels like it would have been a pretty safe option. Accepting this answer because it answered my main question most directly. Sep 1, 2015 at 16:19
6

There are other good answers to this, but they're fairly theoretical. I thought it might be useful for you to know that I've done this, on a number of occasions, and it's fine, but on CentOS servers using dovecot and sendmail, and I use mbox as a storage format. I know you're using postfix and Maildir, and I'm sorry I can't shed specific light on that; I hope this is still useful.

Stored email will be under people's home directories, usually under ~/mail, but they may have configured things otherwise. As long as you're taking all the home directories, and restoring them with matching UID/GIDs, stored email should be fine.

Unread/unfiled email is under /var/spool/mail. Again, take the whole of that directory, restore as above, and everything just works.

If I have any concrete advice, it's

  1. Dump everything. Don't get selective. Take a backup of everything, check that it's readable, and keep it safe. VPSes are small, so keep several copies (ie, don't be trying to restore from your one and only tarfile, so that when you accidentally type tar c instead of tar t and you overwrite the backup, it's a disaster). You never know what odd file you will find you need to restore, to make things work after the move.

  2. Now is not the time to start changing things. You may have dreamt of rationalising your UIDs, or changing the mail storage format (or changing your control panel, but we won't talk about that, because it would make your question off-topic for SF) but this is not a good time to change anything. Because you're doing this in situ, you have no safety net. That is not a good time to get clever.

  3. Perfect practice makes perfect. It's a VPS. They cost next to nothing. Amazon will literally let you have one for free. Try a test migrate, hone your skills when the bullets aren't flying. It's good that people on the internet tell you this is a no-brainer, but it's your files, your users, your data. It's great to be sure!

1
  • All very good advice. I upvoted you so hard for #2 I almost broke my mouse. Thank you for helping me decide to stick with ispconfig for now. Also I'll update my question with the location of my maildir files because they're not under /home/ Jul 30, 2015 at 15:48
2

TL;DR E-mail servers will keep messages in their queue a few days if they can't be delivered. Normally during a migration, you'd have to change DNS records, but since you're staying with the same server (same IP) there's no need for that. You can simply shutdown the server, install the new one, and you're good to go. The only important thing is that you should not accept incoming mail during the migration.

This is what you should do:

  1. Disable customer access to the old server (shutdown Postfix/Dovecot/what have you).
  2. Take a backup. You can just copy Maildir and user folders like you proposed, nothing fragile about that.
  3. Format the server and reinstall.
  4. Set up the mailserver again, do NOT configure the firewall yet! Keep mail ports blocked.
  5. Restore all mail. Remember to create accounts and run chown accordingly. Remember that some mailservers require the Maildir to be owned by the mail group (use chgrp).
  6. Now everything is in place. Open the ports and make the new server listen for incoming mail.

When someone tries to deliver e-mail while you're working, they'll be stopped by the firewall and try again at a later time. Because of this, it will take a while before all delayed e-mail will be delivered, up to a couple of days. So warn your customers that their mail could be delayed.

5
  • Thanks, that helps me feel better and yes, DNS will be easy. I guess I'm most concerned about step 5 - the only things I've read concerning accounts have been to do surgery on password, group, shadow and gshadow where it seems like a mistake might add unwanted accounts to the new machine. Is this part necessary if I just create the email accounts manually and move the mail files into the newly created directories? I assume I would still need to chown for appropriate users. In your explanation it seems like that's what you're saying. Jul 29, 2015 at 22:17
  • That's correct, you should add users first (do that in the way you're most comfortable with), restore the directories and chown them. Also remember that your mailserver may require the mail directory to be owned by the mail group.
    – jornane
    Jul 30, 2015 at 6:32
  • That helps. So, just to be clear - If I create the email accounts manually in my control panel then I can just overwrite the files and set permissions and I don't have to worry about messing with the password, group, shadow and gshadow files? chown will be enough as long as I get the owner and group permissions right? Jul 30, 2015 at 15:56
  • Just check what the permissions look like now, if you can re-create that afterwards, you should probably be fine. Specifics about control panels aren't answered here, see meta.serverfault.com/questions/8055/… for more details.
    – jornane
    Jul 30, 2015 at 17:15
  • Also: messing around in passwd, group, shadow and gshadow should not be necessary, and is generally a bad idea in combination with web hosting control panels.
    – jornane
    Jul 30, 2015 at 17:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .