csmig

csmig 公用程式為行事曆資料庫中的每個行事曆指定一個所有者並將每個行事曆 ID (calid) 對映至一個所有者 (如果需要)。

csmig 公用程式支援託管 (虛擬) 網域和 LDAP 行事曆查找資料庫 (CLD) 外掛程式。遷移資料庫中的行事曆可使用 LDAP CLD 外掛程式進行存取。如需有關 LDAP CLD 外掛程式的資訊，請參閱第 6 章, 配置跨多台機器的行事曆資料庫分布。

本小節說明以下主題：

• csmig 功能

• csmig 需求

• csmig 語法

• csmig 遷移步驟

• csmig 提示與疑難排解

csmig 功能

csmig 遷移公用程式執行以下功能：

• 遷移行事曆

• 為行事曆指定所有者

• 更新 LDAP 屬性

遷移行事曆

csmig 可遷移 caldb.berkeleydb.homedir.path 參數所指定的目前行事曆資料庫 (*.db 檔案) 中的使用者行事曆和資源行事曆。在新的目標資料庫中，csmig 會更新行事曆特性 (calprops)、事件、待辦事項 (工作) 以及群組排程引擎 (GSE) 資料庫檔案中 LDAP CLD 外掛程式所需的項目。

csmig 僅會寫入至目標資料庫，而不會更新您的現有行事曆資料庫。

為行事曆指定所有者

csmig 可為行事曆資料庫中的每個行事曆指定一個所有者，並且可將每個行事曆 ID (calid) 對映至一個所有者 (如果需要)。所有預設 calid 均保持原樣，不進行任何變更。其他行事曆則以下列方式進行對映：

• 不具有有效所有者的使用者行事曆將由透過 -c 選項傳送至 csmig 的使用者所有。例如，如果行事曆 ID jsmith 不具有所有者，它將轉換為 orphan:jsmith，其中 orphan 被指定為 -c 選項。

• 不具有所有者的資源行事曆將由透過 -r 選項傳送至 csmig 的資源使用者所有。

• 如果資源行事曆名稱中含有冒號 (:)，這些冒號會被轉換為底線，以便遷移名稱中僅有一個冒號。

  例如，所有者為 bkamdar 的名為 football 的行事曆會被轉換為 bkamdar:football。所有者為 bkamdar 的名為 tchang:soccer 的行事曆會被轉換為 bkamdar:tchang_soccer。所有者為 admin1 的名為 auditorium:room1 的資源行事曆會被轉換為 admin1：auditorium_room1。

更新 LDAP 屬性

csmig 可更新所有相關 LDAP 項目的 LDAP 屬性，包括 icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和 uid (對於資源行事曆)。csmig 可為 LDAP 目錄伺服器資料庫中的每個行事曆建立 icsDWPHost 屬性。icsDWPHost 可指定行事曆所在的後端伺服器的主機名稱。

csmig 需求

使用 csmig 的需求包括：

• 行事曆資料庫不能損毀。使用 csdb check 指令檢查行事曆資料庫，如有必要，請執行 csdb rebuild 指令以重建資料庫。如需有關這些指令的資訊，請參閱附錄 DCalendar Server 指令行公用程式參照。

• 您必須具有足夠的磁碟空間來容納新的目標資料庫。如果適用，也應該為備份資料庫準備足夠的磁碟空間。

• 若要執行 csmig，請以 icsuser 的身份 (或以配置期間指定的 Calendar Server 執行階段使用者 ID 的身份) 登入。如果您以超級使用者 (root) 的身份執行 csmig，則可能需要重設遷移檔案的權限。

  您還必須具有管理 LDAP 目錄伺服器 (儲存使用者喜好設定) 中行事曆使用者屬性的權限。

• 必須停止 Calendar Server。

csmig 語法

csmig 公用程式的語法如下：

csmig [-t DestinationDB]
      [-b Backend-DWPHost]
      [-o OutputFile]
      [-e ErrorFile]
      [-m MappingFile]
      [-c calendarOwner]
      [-r resourceOwner]
      { migrate|dryrun }

下表列出公用程式選項，並提供對每個公用程式的說明以及預設值。

csmig 遷移步驟

安裝和配置 Calendar Server 6 之後，您必須執行 csmig 以遷移現有 Calendar Server 和 LDAP 資料。要 LDAP CLD 外掛程式正常作業，必須遷移 LDAP 資料。使用 csmig 遷移行事曆資料時，執行以下步驟：

使用 csmig 的高階步驟

步驟

1. 使用 comm_dssetup.pl 配置 Directory Server。

   如果您尚未使用 comm_dssetup.pl 為 LDAP 屬性建立索引，請在此時執行此作業。這將大大提昇 LDAP 資料遷移的效能。

2. 使用展示伺服器 (非生產伺服器) 執行模擬測試。

   模擬測試會報告 csmig 在實際遷移期間將執行的作業，但不會遷移任何資料。在模擬測試之後，實際遷移之前，請修正所有錯誤，並決定處理任何未解決的行事曆的計劃。

   如需有關如何執行模擬測試的說明，請參閱csmig 遷移步驟。

3. 遷移生產資料

   生產執行期間，csmig 會遷移行事曆資料庫 (.db 檔案) 和 LDAP 資料 (使用者和群組喜好設定資料)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和 uid (對於資源行事曆)。遷移之後，所有行事曆資源都會建立一個 LDAP 項目。

   如需有關如何遷移生產資料的說明，請參閱csmig 遷移步驟。

執行模擬測試

步驟

1. 在展示伺服器上安裝 Calendar Server 6 (如有必要)。

2. 將行事曆資料庫的快照複製到展示伺服器中。

3. 透過執行以下工作在展示伺服器上模仿生產 LDAP 環境：

   • 安裝 Directory Server。

   • 在此伺服器上安裝 LDAP 資料庫的快照。

4. 執行 comm_dssetup.pl 以配置展示 Directory Server。

5. 執行 csconfigurator.sh 以配置展示 Calendar Server。

6. 以 icsuser 的身份登入 (或者，如果不同，以配置期間指定的 Calendar Server 執行階段使用者 ID 的身份登入)。如果您以超級使用者 (root) 的身份執行 csmig，則可能需要重設遷移檔案的權限。

7. 變更至 cal_svr_base/SUNWics5/cal/sbin 目錄。

8. 執行 csdb check 指令以檢查資料庫是否有損毀。如果指示資料庫已毀壞，請執行 csdb rebuild 指令以重建資料庫。

9. 考量為不具有所有者的使用者行事曆建立 catchall calid。例如，以下指令將建立 calid 為 orphan 的使用者：

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

10. 使用 stop-cal 指令停止 Calendar Server (如有必要)。

    cal_svr_base/SUNWics5/cal/sbin/stop-cal

11. 使用 dryrun 選項執行 csmig。例如，您可以輸入︰

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

    此指令將不具有所有者的使用者行事曆 (無主行事曆) 指定給所有者 orphan，將不具有所有者的資源行事曆指定給所有者 calmaster。

12. 檢查輸出對映檔案 (csmig.map)。對映檔案列出 LDAP 模式中需要更新的項目。

13. 檢查輸出檔案、對映檔案與錯誤檔案。解決您發現的所有 LDAP 問題或錯誤。在實際遷移之前，決定如何處理所有未解決的行事曆。有以下選項可供選擇：

    • 在遷移之前，刪除所有不需要的行事曆。

    • 為所有未解決的行事曆指定所有者。

    • 在遷移期間，允許 csmig 使用 -c 與 -r 選項為行事曆指定所有者。

14. 執行 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

15. 完成測試遷移後，請執行以下步驟以檢查新遷移的行事曆資料庫。

    1. 將遷移資料庫複製到 caldb.berkeleydb.homedir.path 參數指定的 /csdb 目錄中。或者，編輯此參數以指向遷移資料庫的新位置。

    2. 對新的行事曆資料庫執行 csdb check。遷移資料庫中的事件數與待辦事項數應該與遷移前資料庫中的總數相符。

    3. 搜尋 icsCalendarOwned 項目，並確定這些項目與遷移前的行事曆數目相符。

    4. 登入 Communications Express，並驗證某些行事曆是否存在於遷移資料庫中。

       如果測試遷移成功，您便可以遷移生產資料庫。

遷移生產資料

步驟

1. 以 icsuser 的身份 (或以配置期間指定的 Calendar Server 執行階段使用者 ID 的身份) 登入。如果您以超級使用者 (root) 的身份執行 csmig，則可能需要重設遷移檔案的權限。

2. 變更至 cal_svr_base/SUNWics5/cal/sbin 目錄。

3. 使用 stop-cal 指令停止 Calendar Server (如有必要)。

   cal_svr_base/SUNWics5/cal/sbin/stop-cal

4. 備份下列資料：

   • 行事曆資料庫 (.db 檔案)。

   • LDAP 資料：slapd 資料庫目錄與 LDAP 資料庫。

   • ics.conf 檔案。實際上不需要此步驟，但如果要復原至原始配置，該步驟會很有用。

5. 使用 migrate 選項執行 csmig。

   例如，以下指令可將行事曆資料庫遷移至 /var/opt/SUNWics5/newcsdb/ 目錄中：

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

6. 檢查錯誤檔案 (csmig.errors) 中是否存在未解析的行事曆，並按照csmig 遷移步驟下csmig 遷移步驟中的計劃進行解析。

7. 執行 csdb check 指令以檢查遷移資料庫。如果指示任何資料庫已毀壞，請執行 csdb rebuild 以重建資料庫。

8. 將新的遷移資料庫複製到 caldb.berkeleydb.homedir.path 參數指定的 /csdb 目錄中。或者，編輯此參數以指向遷移資料庫的新位置。

9. 啟用 LDAP CLD 外掛程式，方法為對 ics.conf 檔案中的以下配置參數進行任何必要的變更：

   • 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 " (適用於包括本機伺服器的每台後端伺服器)

   • caldb.cld.cache.enable = "yes" (如果您要使用 CLD 快取記憶體選項)

   • caldb.cld.cache.homedir.path 指定 CLD 快取記憶體目錄的位置。預設為 /var/opt/SUNWics5/csdb/cld_cache。

     如需有關設定 LDAP CLD 外掛程式的配置參數的資訊，請參閱第 6 章, 配置跨多台機器的行事曆資料庫分布。

10. 使用 start-cal 指令重新啟動 Calendar Server。

11. 登入 Communications Express，並透過檢查一些遷移行事曆來驗證您的配置是否正常工作。

    若要在進行檢查時停用警示，請將 ics.conf 檔案中的以下每個參數均設定為 “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"

csmig 提示與疑難排解

本小節說明以下提示與疑難排解範例：

• csmig 模擬測試行事曆顯示錯誤的行事曆所有者。

• 無法正常搜尋 LDAP 行事曆。

• csmig 模擬測試指出存在重複的行事曆名稱。

• 我如何將無主行事曆指定給不同的所有者？

• 我如何將行事曆使用者移至另一台後端伺服器？

csmig 模擬測試行事曆顯示錯誤的行事曆所有者。

問題範例

名為 tchang:myCalendar 的行事曆在行事曆資料庫中的所有者為 jsmith，而 csmig 模擬測試將對映顯示為 jsmith:tchang_myCalendar。但是，您希望將此行事曆命名為 tchang:myCalendar，並將所有者指定為 tchang。

解決方案範例

在遷移之前，使用 cscal 公用程式將行事曆的所有者 tchang:myCalendar 變更為 tchang。完成此項作業後，遷移便會將此行事曆對映至 tchang:myCalendar，並將 icsCalendarowned 增加至使用者 ID tchang 的 LDAP 項目。

無法正常搜尋 LDAP 行事曆。

問題範例

遷移之後，將啟用 LDAP 行事曆搜尋，但是行事曆搜尋對話方塊不會傳回任何結果，或僅傳回部分結果。

解決方案範例

啟用 LDAP 行事曆搜尋使得 Calendar Server 可以搜尋 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))。

使用以下篩選器對 LDAP 資料手動執行兩種不同的搜尋，並比較輸出結果：

• LDAP 搜尋，篩選器為 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))

• LDAP 搜尋，篩選器為 (icscalendarowned=*substr*)

由於伺服器使用包含 icsCalendarUser 物件類別的篩選器，因此在模式檢查停用的情況下可能已部署 LDAP 伺服器，並且可能已佈建某些不具有 icsCalendarUser 物件類別的行事曆項目。

csmig 模擬測試指出存在重複的行事曆名稱。

問題範例

csmig 模擬測試對映檔案與輸出檔案指示存在重複的行事曆名稱。例如，在原始資料庫中，jsmith 擁有以下行事曆：

• 包含 5 個事件的 basketball

• 包含 10 個事件的 jsmith:basketball

模擬測試指示在遷移期間將合併這兩個行事曆，最後生成的行事曆將為 jsmith:basketball，其所有者為 jsmith，共包含 15 個事件

輸出檔案將包含下列警告訊息：

Error modifying calendar properties, error=2

解決方案範例

如果您不想合併這兩個行事曆，請在遷移之前將 basketball 的所有者變更為 jsmith 之外的其他所有者。這樣做會保留兩個獨立行事曆的資料完整性。

我如何將無主行事曆指定給不同的所有者？

問題範例

依預設，csmig 會將所有無主行事曆指定給單一所有者，但是我想為某些無主行事曆指定不同的所有者。

解決方案範例

csmig 不接受指令行上的對映檔案。但是，您可以在遷移之前，將所有者指定給原始資料庫中的無主行事曆。檢查所有無主行事曆的模擬測試對映檔案。然後在遷移之前，使用 cscal 公用程式將所有者指定給無主行事曆。以 dryrun 模式再次執行 csmig，以驗證新的所有者。

我如何將行事曆使用者移至另一台後端伺服器？

問題範例

我如何將使用者從一台後端伺服器移至另一台後端伺服器

解決方案範例

若要移動行事曆使用者，請 export 原始伺服器上的每個使用者行事曆，然後將這些行事曆 import 另一台伺服器。移動行事曆之後，您可以刪除原始伺服器上的行事曆。如需有關如何移動行事曆的說明，請參閱管理使用者行事曆。