csmig Migration Steps

After you have installed and configured Calendar Server 6, you must run csmig to migrate your existing Calendar Server and LDAP data. Migration of the LDAP data is required for the LDAP CLD plug-in to work properly. Use these steps to migrate calendar data using csmig:

High Level Steps for Using csmig

1. Configure your Directory Server using comm_dssetup.pl.

   If you have not already indexed LDAP attributes using comm_dssetup.pl, do so at this time. This will greatly help performance of the LDAP data migration.

2. Using a staging server (not your production server), perform a test dry run.

   A dry run reports what csmig would do during an actual migration but does not migrate any data. After the dry run, and before you actually migrate, correct any errors and determine a plan to handle any unresolved calendars.

   For instructions on how to perform a test dry run, see csmig Migration Steps.

3. Migrate Your Production Data

   During a production run, csmig migrates the calendar database (.db files) and LDAP data (user and group preferences data), icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet, and uid (for resource calendars). After the migration, all calendar resources will have an LDAP entry created.

   For instructions on how to migrate your production data, see csmig Migration Steps.

To Perform a Test Dry Run

1. Install Calendar Server 6 (if necessary) on the staging server.

2. Copy a snapshot of your calendar database to the staging server.

3. Mimic your production LDAP environment on the staging server by performing the following tasks:

   • Install Directory Server.

   • Install a snapshot of the LDAP database on this server.

4. Run comm_dssetup.pl to configure the staging Directory Server.

5. Run csconfigurator.sh to configure the staging Calendar Server.

6. Log in as icsuser (or, if its different, log in as the Calendar Server runtime user ID specified during configuration). If you run csmig as superuser (root), you might need to reset the permissions for the migrated files.

7. Change to the cal_svr_base/SUNWics5/cal/sbin directory.

8. Run the csdb check command to check your database for corruption. If corruption is indicated, run csdb rebuild to rebuild the database.

9. Consider creating a catchall calid for user calendars that don’t have an owner. For example, the following command creates a user with the calid of orphan:

   ./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan

10. Stop the Calendar Server using the stop-cal command (if necessary).

    cal_svr_base/SUNWics5/cal/sbin/stop-cal

11. Run csmig with the dryrun option. For example, you might enter:

    ./csmig -b sesta.com -o csmig.out -e csmig.errors
     -m csmig.map -c orphan -r calmaster dryrun

    This command assigns user calendars without an owner (orphan calendars) to the owner orphan and resource calendars without an owner to the owner calmaster.

12. Check the output mapping file (csmig.map). The mapping file lists entries that need to be updated in the LDAP schema.

13. Check the output, mapping, and error files. Resolve any LDAP issues or errors that you find. Determine how you will handle any unresolved calendars before the actual migration. Several options are:

    • Delete any unneeded calendars before you migrate.

    • Assign owners to any unresolved calendars.

    • Allow csmig to assign owners to the calendars during migration using the -c and -r options.

14. Run csmig to migrate your staging calendar database.

    For example, the following command migrates the calendar database to the /var/opt/SUNWics5/testcsdb/ directory:

    ./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com 
    -o csmig.out -e csmig.errors -m csmig.map -c orphan 
    -r calmaster migrate

15. After the test migration is finished, perform these steps to check out the newly migrated calendar database.

    1. Copy the migrated database to the /csdb directory specified by the caldb.berkeleydb.homedir.path parameter. Or, edit this parameter to point to the new location of the migrated database.

    2. Run csdb check on the new calendar database. The number of events and todos in the migrated database should match the pre-migration totals.

    3. Search for icsCalendarOwned entries and make sure that the entries match the pre-migration number of calendars.

    4. Log in to Communications Express and verify some of the calendars in the migrated database.

       If the test migration is successful, you are ready to migrate your production database.

To Migrate Your Production Data

1. Log in as icsuser (or as the Calendar Server runtime user ID specified during configuration). If you run csmig as superuser (root), you might need to reset the permissions for the migrated files.

2. Change to the cal_svr_base/SUNWics5/cal/sbin directory.

3. Stop the Calendar Server using the stop-cal command (if necessary).

   cal_svr_base/SUNWics5/cal/sbin/stop-cal

4. Backup the following data:

   • Calendar database (.db files).

   • LDAP data: slapd database directory and LDAP database.

   • ics.conf file. This step is not actually required, but it can be useful if you need to revert to your original configuration.

5. Run csmig with the migrate option.

   For example, the following command migrates the calendar database to the /var/opt/SUNWics5/newcsdb/ directory:

   ./csmig -t /var/opt/SUNWics5/newcsdb/ -b sesta.com 
   -o csmig.out -e csmig.errors -m csmig.log -c orphan 
   -r calmaster migrate

6. Check for any unresolved calendars in the error file (csmig.errors) and resolve them according to your plan from csmig Migration Steps under csmig Migration Steps.

7. Run the csdb check command to check your migrated database. If any corruption is indicated, run csdb rebuild to rebuild the database.

8. Copy the new migrated database to the /csdb directory specified by the caldb.berkeleydb.homedir.path parameter. Or, edit this parameter to point to the new location of the migrated database.

9. Enable the LDAP CLD plug-in by making any necessary changes to the following configuration parameters in the ics.conf file:

   • service.dwp.enable = "yes"

   • service.dwp.port = "9779"

   • csapi.plugin.calendarlookup = "y"

   • csapi.plugin.calendarlookup.name = "*"

   • caldb.cld.type = "directory"

   • caldb.dwp.server.default = "default-server-name"

   • caldb.dwp.server.server-hostname.ip = "server-hostname" (for each back-end server including the local server)

   • caldb.cld.cache.enable = "yes" (if you want to use the CLD cache option)

   • caldb.cld.cache.homedir.path specifies the location of the CLD cache directory. The default is /var/opt/SUNWics5/csdb/cld_cache.

     For information about setting configuration parameters for the LDAP CLD plug-in, see Chapter 6, Configuring Calendar Database Distribution Across Multiple Machines.

10. Restart Calendar Server using the start-cal command.

11. Log in to Communications Express and verify that your configuration is working by checking several of the migrated calendars.

    To disable alarms while you are making your checks, set each of the following parameters in the ics.conf file to “no”:

    • caldb.serveralarms = "no"

    • caldb.serveralarms.dispatch = "no"

    • service.ens.enable = "no"

    • service.notify.enable = "no"

    • ine.cancellation.enable = "no"

    • ine.invitation.enable = "no"

    • service.admin.alarm = "no"