Migrating to CommuniGate Pro |
|||||||||||||||||||||||||||||||||||||
|
The CommuniGate Pro Server keeps all user accounts and mailboxes inside its "base directory". On a properly configured system direct user access to the base directory is prohibited to ensure that account mailboxes and other Server files stay intact.
When you create a CommuniGate Pro account for a local user who needs mail access via legacy mailers, select the External INBOX option. In this case, the account INBOX will not be created inside the CommuniGate Pro base directory. Instead, the mailbox location will be taken from the user domain settings. Usually, you specify /var/mail/* or /var/spool/mail/* - the "standard" location where legacy mailers expect to see user mailboxes.
When the Server accesses these external mailboxes, it uses the OS file-locking mechanism to synchronize its activity with legacy mailers.
Note: legacy mailers were not designed to support simultaneous access to mailboxes. They can destroy data in your mailbox if you open two legacy mailer sessions with the same mailbox and delete messages in one of the sessions. CommuniGate Pro cannot fix this, since these mailers bypass the server, it can only guarantee (using file locks) that legacy mailers do not destroy a mailbox while CommuniGate Pro is working with it.
For more details, see the Sharing section.
Since most legacy mail systems use this format, the existing mailbox files can be used when migrating to CommuniGate Pro. You should either copy the old mailbox files into the proper places in the CommuniGate Pro account directories, or you can specify that some accounts have external INBOXes (see above), and the old mailbox files will be used "in place".
Note: when CommuniGate Pro stores a message in a BSD-type mailbox, it adds additional fields to the separator (From) line. These fields are ignored by legacy mailers and mail servers, but they allow the CommuniGate Pro Server to keep the message status and unique message ID information. When you make your CommuniGate Pro Server use a BSD-type mailbox composed with an old mail system, it issues warnings (Log records) about missing fields in the message separators. The Server still opens such mailboxes: it creates empty status flag sets for such messages, and it generates unique IDs on-fly. As users read, move, and/or delete old mail from their mailboxes, messages stored with the old mail system disappear, and the Server stops complaining when opening these mailbox files.
Since the OS Passwords are one-way encrypted, they cannot be used for secure SASL authentication methods. The following procedure can be used to allow migrated users to employ the secure SASL methods:
Users can connect to the newly created accounts using their old OS Passwords - i.e. the same passwords they used with the legacy mail system. When users try to modify their account passwords, the new passwords will be stored as CommuniGate Passwords. All users that have updated their passwords will be able to use the secure SASL authentication methods.
Sometimes you cannot use this method. For example, you migrate users from a different server, and you do not register them all with the Unix OS on the new server, but you do have the passwd file from the old server. In this case, you may want to enter the Unix-style (crypt-encrypted) passwords as the CommuniGate (internal) Passwords.
To make the CommuniGate Pro server process its internal password string as a
U-crpt (crypt-encrypted) or other support encrypted password (see below),
store the password in the Account Settings
with one-byte binary 002 prefix. If you want to create a user test using the
CLI interface, and the Unix (crypt-encrypted) password
for that user is AslUzT1JkPsocc, then use the following CLI command:
createaccount "test" {Password="\002AslUzT1JkPsocc";}
If you create users by importing an account list from a text file, place the Unix passwords strings into the UnixPassword column, not into the Password column. In this case, the Loader will automatically add the binary 002 prefix to all password strings. If you create users using the LDAP Provisioning feature, specify the encrypted password as the unixPassword attribute.
Account Settings of the new accounts should specify one of the CommuniGate Pro password encryption methods (clear text or A-crpt). Users will be able to log in using their old Unix/encrypted passwords. When they update their passwords, new CommuniGate Password strings will be stored using the specified CommuniGate Pro password encryption method. All users that have updated their passwords will be able to use the secure SASL authentication methods.
Some servers produced by the Netscape and Software.com companies store user passwords
using several encryption methods. When passwords are retrieved from those servers, they
have the following form:
{method}eNcoDeD
or
$method$eNcoDeD
where method specifies one of the standard encryption methods, and the eNcoDeD string
is an encrypted password (sometime - Base64-encoded).
CommuniGate Pro can use these passwords in the same way it uses the Unix-encrypted passwords, and they should be entered in the same way: you should use the binary 002 prefix in the CLI commands and/or your should place those passwords into the UnixPassword field of the Account Import file.
The following encryption methods are supported:
Sample Import file:
|
|
You can use a CommuniGate Pro CLI script to automatically import all users and their passwords from the OS /etc/passwd file. See the CommuniGate Perl Interface site for a sample script.
The List Migration script allows you to copy mailing lists and their subscriber sets from Post.Office to CommuniGate Pro.
If you want to move your users from a CommuniGate for MacOS server, you can build the account list file using the CommuniGate/MacOS extractor utility.
If you want to move your users from a Stalker Internet Mail Server (SIMS), you can build the account list file using the SIMS extractor utility.
The utility also extracts the Exchange Global Address Book and converts it into an LDIF file that can be imported into the CommuniGate Pro Directory.
The utility requires an MS Windows workstation to run.
The CommuniGate Pro software package includes the MovePOPMail program. This program connects to the old POP server, logs in, retrieves all messages, and submits it to the new SMTP server:
MovePOPMail [--verbose] [--delete] [--notimeout] POPserver POPname POPpassword SMTPserver SMTPrecipient
Sample:
MovePOPMail --verbose 192.0.0.4 john "jps#dhj" 192.0.1.5 john
The CommuniGate Pro software package includes the MoveIMAPMail program. This program connects to the old and new IMAP servers, logs into both, retrieves the list of mailboxes in the old account, creates all missing mailboxes in the new account, and copies all messages from mailboxes in the old account to the mailboxes in the new account. The program also copies the list of "subscribed mailboxes", and the mailbox ACLs (if supported).
MoveIMAPMail [flags] OldServer oldName oldPassword NewServer newName newPassword
Flags is zero, one or several optional parameters:
Sample:
MoveIMAPMail --list "Mail/*" 192.0.0.4 john "jps#dhj" 192.0.1.5 johnNew dummy
Note: if a mailbox name in the source account ends with symbols .mbox or .mdir, the mailbox name in the target account will end with the -mbox or -mdir symbols.
The CommuniGate Pro software package includes the MoveAccounts program. This program uses a tab-delimited text file that contains account names and passwords. It can be the same file you have used to Import Accounts to a CommuniGate domain.
The program scans the file and uses either the MovePOPMail or the MoveIMAPMail program to move messages for each account. These programs should be located in your current directory.
MoveAccounts [--POP | --IMAP] file sourceServer targetServer [suppl_parameters]
The first line of the file should contain the data field names. The fields with names Name and Password must be present.
If the field NewName exists, it is used as the SMTPrecipient parameter when the MovePOPMail program is started, or as the newName parameter for the MoveIMAPMail program. Otherwise the same Name field data is used.
If the --IMAP parameter is specified, the program checks if the NewPassword field exists. If it does, the data in that field is passed as the newPassword parameter to the MoveIMAPMail program. Otherwise, the same Password field data is used.
All fields with other names are ignored.
Sample:
|
MoveAccounts --POP AccountList 192.0.0.3 192.0.1.5
If you cannot obtain the clear-text passwords for all accounts you want to copy, and the old server is using the Unix /etc/passwd or /etc/shadow file, follow these steps:
When CommuniGate Pro Accounts are created for the old server users, the CommuniGate Pro passwords should not be specified at all (they can be left empty). Before creating those accounts, open the Account Template for the target Domain. Disable the Use CommuniGate Password option and enable the Use External Password option in the Account Template. -------------------
When a user connects to the server, the user mailer sends the user name and the user password in the plain text form. Because the CommuniGate Pro Account has the Use CommuniGate Password option disabled, and the Use External Password option enabled, the External Authentication script is called. The script connects to the old server using the POP or IMAP protocol and checks if it can log into the old server with the provided (user login) credentials.
The method is based on the External Authentication feature of the CommuniGate Pro server.
Download, install, and tailor the migration script, and configure CommuniGate Pro to use this script as the CommuniGate Pro External Authentication program.
Create the target CommuniGate Domain, and in the Domain settings enable the Consult External Authenticator option. Disable the Use CommuniGate Password option and enable the Use External Password option in the Account Template.
When a user attempts to connect to a non-existent Account, or when CommuniGate Pro receives a message for non-existent Account, the External Authentication script is called. The script connects to the old server using the SMTP protocol and checks if the account with the same name (same address) exists on the old server. If the old server does not reject the address, the script creates the Account with this name in the CommuniGate Pro Domain. Then the CommuniGate Pro Server delivers the message to this newly created Account.
When a user connects to the CommuniGate Pro Server, the user mailer sends the user name and the user password in the plain text form. Because the CommuniGate Pro Account has the Use CommuniGate Password option disabled, and the Use External Password option enabled, the External Authentication script is called. The script connects to the old server using the POP or IMAP protocol and checks if it can log into the old server with the provided user credentials.
If the old server accepts the specified password:
After the first successful login, the correct password will be set as the new CommuniGate Password, and all Account mail will be copied from the old server.
After all old server users have successfully connected to the CommuniGate Pro server at least once, all their Accounts will be created and have the correct CommuniGate Passwords set. Then you can disable the External Authentication script and retire the old server.
Very often it is essential to switch to the new server without any interruption in the services you provide.
If you install the new CommuniGatePro server on the same system as the old mail server, you should:
All this can be done while your old server is still active.
Now, you should stop your old server activity by either changing its port numbers to non-standard values, or by disconnecting it from the external network.
Use the AccountMove program to copy all messages from your old server to CommuniGate Pro.
When all messages are copied, change the CommuniGate Pro SMTP port number back to 25, POP port number - to 110, and IMAP port number to 143. Now CommuniGate Pro will operate as your mail server, without any interruption in the services you provide.
You may want to keep the old server running for several hours - in case its queue contained some delayed outgoing messages. Just check that the old server does not try to use the standard ports.
If you create several Secondary domains in CommuniGate Pro, you may want to move accounts from your old server(s) to a Secondary CommuniGate Pro domain, not to its Main Domain.
In this case, you should add the NewName field to your account list file, and copy all names into that column, adding the @domainname string to each name.
If you use the IMAP protocol to move messages between the servers, you may use a simpler method: