APPENDIX B

Migrating Mailboxes from
/var/mail to SIMS

Example 1: Converting/var/mail to the Sun Message Store--Simplest  

316  

Example 2: Converting/var/mail to the SIMS Message Store Using an SMTP Choke Router or .forward  

317  

Example 3: Converting /var/mail to SIMS Using a Proxy  

318  



This section discusses various techniques and strategies for migrating user mailboxes from /var/mail to SIMS. While there are many methods for migrating users from /var/mail to SIMS. The basic migration process is as follows:

  1. Install SIMS on a new server
  2. Populate the SIMS directory with the migrated users.
  3. Kill the sendmail daemon.
  4. Migrate the user mailboxes using imimportmbox.
  5. Start the new SIMS server.

However, between the time of killing the sendmail daemon, and starting the SIMS server, the user's account is down. Mail sent to the user will be bounced back to the recipient, and the user will not be able to send mail. The challenge arises in trying to minimize downtime.

The mailbox migration methods you choose will depend on the following:

How many users in your system?
How important is minimizing down time? That is, how significant is it if the mail system is temporarily unavailable to the user and bounces incoming mail to back to the recipient?
Are you willing to go through the extra complexity of installing SMTP Choke Routers in order to minimize the down time?

There are a number of ways to temporarily intercept and save mail sent to
/var/mail and then send it to the new SIMS server. The remainder of this appendix describes three examples of migrating users with various levels of user transparency. These examples are meant to give guidelines for migrating mailboxes, and may or may not provide the best solution for your needs. Use these examples to learn and select the methods, techniques, and strategies that work best for your situation


 

Example 1: Converting/var/mail to the Sun Message Store--Simplest

The example replaces an old sendmail server with a new SIMS server.

User transparency issues:

When the system is brought down, users can neither send nor retrieve messages.
Messages sent to the user are bounced back to the sender while the system is down.
User clients must change the name of the new server toward which they point.
  1. Install and configure the new SIMS server.
  Configure the Directory Server, IMTA, and Message Store as needed.
  2. Populate the Directory on the new SIMS server with the appropriate entries.
  See Chapter 9, Populating SIMS with Users and Groups and the SIMS Provisioning Guide for more information.
  a. Change the user's LDAP entry to include the new mailhost attribute.
  For each entry set the mailhost attribute to fully-qualified name of the new SIMS server.
  3. Run a full dirsync.
  See the imta-dirsync man page for details.
  4. Bring down the old sendmail server.
  Kill the sendmail server daemon (or whatever server daemon you are using).
  5. Migrate /var/mail mailboxes from old server to new server.
  Run imimportmbox to migrate mailboxes to the new server in the Sun Message Store format.
  6. Make sure the user's mail clients now point to the new server.
  7. Start up the new SIMS server.
  im.server start

 

Example 2: Converting/var/mail to the SIMS Message Store Using an SMTP Choke Router or .forward

This example replaces a sendmail host with a new SIMS server. Mail arriving while the system is down is sent to either an SMTP choke router or a .forward file.

User transparency issues:

Users being migrated will temporarily prevented from accessing their mailbox or sending mail.
Messages sent to the user are saved in either a SMTP choke router or .forward file. No messages are bounced.
User clients must change the name of the new server toward which they point.
Mail sent before the /var/mail messages are migrated will be dated and queued in the mail store with a delivery date earlier than the messages to be migrated. That is, your message delivery queue will look out of order.
  1. Install and configure the new SIMS server.
  Configure the Directory Server, IMTA, and Message Store as needed.
  2. Save incoming mail to an SMTP choke router or a .forward file.
  The SMTP choke router intercepts and temporarily saves incoming mail. After the mailboxes are migrated and the new server is set up, you can send the saved messages to the new message store.
  A .forward file forwards mail addressed to a specific user to specified file. After the mailboxes are migrated and the new server is set up, you can run a imimportmbox to migrate the .forward mail to the new server in the SIMS message store format.
  3. Populate the Directory on the new SIMS server with the migrated entries.
  See Chapter 9, Populating SIMS with Users and Groups and the SIMS Provisioning Guide for more information.
  a. Change the user's LDAP entry to include the new mailhost attribute.
  For each entry set the mailhost attribute to the fully-qualified name of the new SIMS server.
  4. Start up the new SIMS server.
  /etc/init.d/im.server start
  Users can now send and retrieve new mail, but these mailboxes will not contain the old mail that has yet to be migrated.
  5. Temporarily disable a batch of user to migrate.
  We recommend ~1,000. Set the emailPersonStatus attribute to inactive for each user entry. These users will not be able to access their mailboxes, or send mail. Incoming mail will be temporarily stored in the SMTP choke router of the .forward file.
  6. Migrate disabled /var/mail mailboxes from the old server to new server.
  Run imimportmbox to migrate mailboxes to the new server in the Sun Message Store format.
  7. Make sure the user's mail clients now point to the new server.
  8. Enable the migrated inactive users.
  Set the emailPersonStatus attribute to active for each user entry.
  9. Send messages temporarily stored in SMTP choke router or to the .forward file to the new mailboxes.
Note - New mail delivered either before or while imimportmbox is being run will appear in the mail store as having been delivered before migrated mail.

 

Example 3: Converting /var/mail to SIMS Using a Proxy

This example installs SIMS on the current sendmail host and configures it to be a proxy. Another SIMS host is installed on the backend and configured as a message store host.

User transparency issues:

Users being migrated will temporarily prevented from accessing their mailbox, however, they can still send mail.
Messages sent to the user are saved in a temporary hold channel. No messages are bounced.
User clients do not have to change the name of the server toward which they point, since they will still be accessing mail from the same machine, which is not a proxy.
  1. Install the new SIMS server.
  Configure the Directory Server, IMTA, and Message Store as needed.
  2. Install SIMS on the current sendmail server and convert it to a SIMS pure proxy.
  See "To Configure a Pure Proxy" on page 308.
  3. Populate the directories on the new SIMS servers with the new entries.
  See Chapter 9, Populating SIMS with Users and Groups and the SIMS Provisioning Guide for more information. Note that the new servers will need to get updated directory information either as directory masters or slaves. (You can also specify another machine to serve as the directory server for either of the proxy or non-proxy machine. See the imadmin-modify-currentldap man page.)
  4. Change the Mailhost attribute in the entries of the migrated users and groups to the name of the new server.
  You can do this from the Admin Console (see "To Modify a User Entry" on page 41 and "To Modify a Group Entry" on page 49). You can also use the ldapmodify command if you prefer to do this in a UNIX script. See ldapmodify man page for details.
  5. Temporarily disable mailbox accounts of users who are to be migrated so that mail sent to these users will be put on hold until the accounts are restarted.
  For each user and group LDAP entry to be migrated, set the mailDeliveryOption to hold. Execute the command hold_slave to send incoming mail to the hold channel. (See the section on the hold channel in the SIMS Reference Manual and the
hold_slave man page). During this time, users will not be able to access their mailboxes.
  6. Start up the new SIMS server and SIMS proxy, and kill the sendmail daemon.
  Start up command: im.server start.
  Incoming and outgoing mail will now be handled by the new SIMS machines. However, incoming mail will go to the Hold channel instead of to the message store.
  7. Migrate /var/mail Mailboxes from old server to new SIMS server.
  Use imimportmbox to migrate mailboxes to the new server in the Sun Message Store format. See the man page.
  8. Enable the disabled mailbox accounts so that they can receive mail.
  For each user and group LDAP entry migrated, change the mailDeliveryOption setting from hold to mailbox. Execute the command hold_master to deliver message in the Hold Channel to the migrated mailboxes. (See the section on the Hold Channel in the SIMS Reference Manual and the hold_master man page).

Proxy/mail server should be running as planned.

  9. If the system is working, delete all the migrated accounts from the old machine.
  Use imdeluser.



Copyright© 1999 Sun Microsystems, Inc. All Rights Reserved.