test

Sun Java System Calendar Server 6.3 管理指南

3.5 csmig 公用程式

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

csmig 公用程式支援多個網域及 LDAP 行事曆查找資料庫 (Calendar Lookup Database, CLD) 外掛程式。遷移資料庫中的行事曆可使用 LDAP CLD 外掛程式進行存取。如需有關 LDAP CLD 外掛程式的資訊，請參閱第 5 章, 在 Calendar Server 版本 6.3 中，將行事曆資料庫配置為分布在多台機器上。

本小節說明以下主題：

3.5.1 csmig 公用程式功能

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

3.5.1.1 遷移行事曆

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

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

3.5.1.2 為行事曆指定所有者

csmig 可為行事曆資料庫中的每個行事曆指定一個所有者，並且可將每個行事曆 ID (calid) 對映至一個所有者 (如果需要)。所有預設 calids 都會保持原狀，不進行任何變更。

其他行事曆則以下列方式進行對映：

3.5.1.3 更新 LDAP 屬性

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

3.5.2 csmig 公用程式需求

使用 csmig 的需求為：

3.5.3 csmig 語法

csmig 公用程式具有以下語法：


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

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

csmig 選項 

說明和預設值 

-t DestinationDB

指定 csmig 產生的目標資料庫。預設為 MigratedDB。

-b Backend-DWPHost

指定 DWP 後端主機伺服器名稱。這個名稱必須與 ics.conf 檔案中指定的 DWP 後端主機伺服器名稱相符。

-o OutputFile

指定一個輸出檔案，該檔案會將 csmig 輸出及發生的所有錯誤擷取到螢幕。預設為 MigrateOut。

-e ErrorFile

csmig 在其中寫入所有無法解決的錯誤或資料庫項目的檔案。如果資料庫項目無法解決，則它們不會被寫入目標資料庫。預設為 MigrateError。

-m MappingFile

指定在 dryrun 模式中產生的輸出對映檔案，該檔案列出了 LDAP 模式中需要變更的項目。例如：

舊的：calid=jsmith

新的：calid=jsmith:basketball

對映檔案僅提供要對 LDAP 模式所做的變更清單。csmig 實際上不會對模式做出變更 

對映檔案不用於 migrate 模式。

-c calendarOwner

為不具有所有者的使用者行事曆指定所有者。 

-r resourceOwner

為不具有所有者的資源行事曆指定所有者。 

migrate|dryrun

指定公用程式的執行模式。使用 migrate 模式執行遷移。在實際遷移之前，使用 dryrun 模式產生輸出對映檔案。

3.5.4 csmig 公用程式遷移步驟

如果您有版本 5.1.1 之前的 Calendar Server 版本，則在安裝並配置 Calendar Server 6.3 之後，請執行 csmig，以遷移現有的 Calendar Server 及 LDAP 資料庫。要 LDAP CLD 外掛程式正常作業，必須遷移 LDAP 資料。使用 csmig 遷移行事曆資料時，執行以下步驟：

Procedure使用 csmig 的高階步驟

  1. 使用 comm_dssetup.pl 配置您的目錄伺服器。

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

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

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

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

  3. 遷移生產資料

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

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

Procedure執行模擬測試

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

  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，並驗證某些行事曆是否存在於遷移資料庫中。

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

Procedure遷移生產資料

  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) 中是否存在未解決的行事曆，並按照3.5.4 csmig 公用程式遷移步驟下3.5.4 csmig 公用程式遷移步驟中的計劃進行解決。

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

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

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

    • service.dwp.enable = "yes"

    • service.dwp.port = "59779"

    • csapi.plugin.calendarlookup = "yes"

    • 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 外掛程式的配置參數的資訊，請參閱第 5 章, 在 Calendar Server 版本 6.3 中，將行事曆資料庫配置為分布在多台機器上。

  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"

3.5.5 csmig 提示與疑難排解

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

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

問題範例

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

解決方案範例

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

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

問題範例

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

解決方案範例

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

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

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

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

問題範例

csmig 模擬測試對映檔案與輸出檔案指示存在重複的行事曆名稱。

例如，在原始資料庫中，jsmith 擁有以下行事曆：

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

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

Error modifying calendar properties, error=2

解決方案範例

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

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

問題範例

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

解決方案範例

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

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

問題範例

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

解決方案範例

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