必要に応じて、Calendar Server 6 を中継サーバーにインストールします。
カレンダデータベースのスナップショットを中継サーバーにコピーします。
次の作業を実行して、中継サーバー上に本稼働 LDAP 環境を再現します。
Directory Server をインストールします。
このサーバーに LDAP データベースのスナップショットをインストールします。
comm_dssetup.pl を実行して、中継 Directory Server を設定します。
csconfigurator.sh を実行して、中継 Calendar Server を設定します。
icsuser としてログインします。これが異なる場合は、設定中に指定した Calendar Server のランタイムユーザー ID としてログインします。スーパーユーザー (root) として csmig を実行する場合は、移行されたファイルに対するアクセス権のリセットが必要になることがあります。
cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。
csdb check コマンドを実行して、データベースに破損が生じていないかどうかを確認します。破損が見つかった場合は、csdb rebuild を実行してデータベースを再構築します。
所有者がいないユーザーカレンダにすべてを割り当てるための calid を作成することを考慮します。たとえば、次のコマンドを実行すると、orphan という calid を持ったユーザーが作成されます。
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan |
必要に応じて、stop-cal コマンドを使用して Calendar Server を停止します。
cal_svr_base/SUNWics5/cal/sbin/stop-cal
dryrun オプションを指定して csmig を実行します。たとえば、次のように入力します。
./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun
このコマンドを実行すると、所有者のいないユーザーカレンダ (orphan カレンダ) が所有者 orphan に割り当てられ、所有者のいないリソースカレンダが所有者 calmaster に割り当てられます。
出力マッピングファイル (csmig.map) を確認します。マッピングファイルに、LDAP スキーマ内で更新する必要のあるエントリが一覧表示されます。
出力ファイル、マッピングファイル、およびエラーファイルを確認します。検出された LDAP の問題やエラーを解決します。実際の移行の前に、未解決のカレンダを処理する方法を決定します。選択肢は以下のとおりです。
移行する前に、不要なカレンダを削除します。
未解決のカレンダに所有者を割り当てます。
-c オプションと -r オプションを使用して csmig を実行し、移行中にカレンダに所有者を割り当てます。
csmig を実行して、中継カレンダデータベースを移行します。
たとえば、次のコマンドを実行すると、カレンダデータベースが /var/opt/SUNWics5/testcsdb/ ディレクトリに移行されます。
./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster migrate
テスト移行が完了したら、次の手順を実行して、新しく移行されたカレンダデータベースを確認します。
移行されたデータベースを、caldb.berkeleydb.homedir.path パラメータで指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して、移行されたデータベースの新しい格納場所を指定します。
新しいカレンダデータベースで csdb check を実行します。移行されたデータベースの予定や仕事の数は、移行前の合計数と一致している必要があります。
icsCalendarOwned エントリを検索し、エントリが移行前のカレンダ数と一致していることを確認します。
Communications Express にログインし、移行されたデータベース内のいくつかのカレンダを検証します。
テスト移行が正常に行われたら、運用データベースの移行準備は完了です。