Sun Java System Calendar Server 6 2005Q4 管理指南

第 4 章 資料庫遷移公用程式

如果您已安裝舊版的 Calendar Server (5.11 和更舊版本),則在安裝 Calendar Server 並執行安裝後配置之後,可能需要遷移元件資料庫和 LDAP 資料庫。

本章中提供選擇正確的公用程式小節以協助您選擇要執行的正確公用程式。

本章包含以下小節:

安裝後資料庫遷移公用程式

安裝 Sun Java System Calendar Server 之後 (如果您在安裝舊版的 Calendar Server 5.1.1 時已安裝行事曆資料庫和 LDAP 資料庫項目),請依給定順序執行以下公用程式:

  1. cs5migrate

    將行事曆資料庫從 Calendar Server 版本 5 遷移至版本 6 格式。這些公用程式可從技術支援處下載。

    如果您打算使用 Connector for Microsoft Outlook 並且具有週期性元件,則請使用為每個週期性系列建立主記錄和異常的 cs5migrate_recurring

    如果您的現有資料庫中不具有週期性元件,或者您具有週期性元件,但不打算使用 Connector for Microsoft Outlook,則請使用 cs5migrate

    cs5migratecs5migrate_recurring 均只能從技術支援部門獲得。它們不與產品封裝在一起。

  2. csmig

    可為 Calendar Server 6 資料庫中的每個行事曆指定一個所有者,並可將每個行事曆 ID (calid) 對映至一個所有者 (如果需要),這樣可以支援託管 (虛擬) 網域和 LDAP 行事曆查找資料庫 (CLD) 外掛程式。此公用程式與 Calendar Server 封裝在一起。請在執行 cs5migrate 之後,執行此公用程式,然後再執行 csvdmig

  3. csvdmig

    透過將行事曆的網域 (@domainname) 增加至每個 calid,升級 Calendar Server 6 網站以使用託管 (虛擬) 網域。例如,在網域 sesta.com 中,jdoe calid 現在將為 jdoe@sesta.com。此公用程式與 Calendar Server 封裝在一起。請在執行 cs5migratecsmig 之後再執行此公用程式。

  4. commdirmig

    – 將 LDAP 資料從 Schema 1 遷移至 Schema 2,以準備與 Access Manager 6.1 或更高版本配合使用。此公用程式與 Access Manager 封裝在一起。

選擇正確的公用程式

由於存在如此之多的潛在公用程式選擇,所以請使用以下圖形來選擇要執行的公用程式。

圖 4–1 選擇要執行的遷移公用程式

此圖形顯示用來決定要執行哪三個公用程式以及以何種順序執行的決策樹狀結構。

csmig

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

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

本小節說明以下主題:

csmig 功能

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

遷移行事曆

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

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

為行事曆指定所有者

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

更新 LDAP 屬性

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

csmig 需求

使用 csmig 的需求包括:

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 模式產生輸出對映檔案。

csmig 遷移步驟

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

Procedure使用 csmig 的高階步驟

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

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

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

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

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

  3. 遷移生產資料

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

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

Procedure執行模擬測試

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

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

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) 中是否存在未解析的行事曆,並按照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 模擬測試行事曆顯示錯誤的行事曆所有者。

問題範例

名為 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 資料手動執行兩種不同的搜尋,並比較輸出結果:

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

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

問題範例

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

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

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

Error modifying calendar properties, error=2

解決方案範例

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

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

問題範例

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

解決方案範例

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

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

問題範例

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

解決方案範例

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

csvdmig

csvdmig 公用程式可以為要使用託管 (虛擬) 網域的站點修改 Calendar Server 資料庫與 LDAP 目錄伺服器資料庫。


備註 –

如果您從非託管環境移動,請確保在使用此公用程式前執行 csmig


本小節包含以下主題:

csvdmig 功能

csvdmig 公用程式可將網域名稱增加至使用者 ID,如下所示:


注意 – 注意 –

csvdmig 公用程式會適當更新資料庫和 LDAP 目錄。也就是說,它不建立獨立的遷移資料庫,而是變更您要轉換的資料庫。因此,為安全起見,請對您的資料庫快照和 LDAP 目錄執行 csvdmig


csvdmig 語法

csvdmig 公用程式的語法如下:


csvdmig [-t DestinationDB]
         [-c ConfigFile]
         [-e ErrorFile]
         [-m MappingFile]
         migrate [DB|LDAP]

下表列出 csvdmig 所使用的選項,並提供對每個選項的說明。

選項 

說明和預設值 

-m MappingFile

指定對映檔案的輸入參數。如需有關對映檔案的更多資訊,請參閱對映檔案。預設為 MigrateMapping

-c ConfigFile

指定 Calendar Server 配置檔案的輸入參數。預設為 ics.conf 檔案。

-t DestinationDB

指定資料庫位置的輸出參數。預設為 MigratedDB


提示 –

始終使用 -t 選項。嘗試遷移工作目錄中的資料庫產生不可預期的結果。請參閱目標 DB


-e ErrorFile

用於為無法解決的錯誤指定錯誤檔案名稱的輸出參數。預設為 MigrateError

DB | LDAP

指定要修改哪個資料庫: 

DB – 行事曆資料庫

LDAP – LDAP 目錄

預設為行事曆資料庫 (DB)。

表 4–1 csvdmig 的選項

選項 

說明和預設值 

-m MappingFile

指定對映檔案的輸入參數。如需有關對映檔案的更多資訊,請參閱對映檔案。預設為 MigrateMapping

-c ConfigFile

指定 Calendar Server 配置檔案的輸入參數。預設為 ics.conf 檔案。

-t DestinationDB

指定資料庫位置的輸出參數。預設為 MigratedDB。請參閱目標 DB

-e ErrorFile

用於為無法解決的錯誤指定錯誤檔案名稱的輸出參數。預設為 MigrateError

DB | LDAP

指定要修改哪個資料庫: 

DB – Calendar Server 資料庫 LDAP – LDAP 目錄

預設為行事曆資料庫 (DB)。

對映檔案

對映檔案是輸入文字檔案它將現有使用者對映至他們各自的網域。執行 csvdmig 之前,必須先建立對映檔案。每一行指定一個項目,新舊值之間用空格分隔。例如:

user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
 ...
usern usern@siroe.com

目標 DB

此公用程式不會將遷移檔案移至新的 DestinationDB。如果您指定 -t 選項,則必須在執行 csvdmig 之前將要遷移的資料庫檔案複製到該目錄。

如果您未使用 -t 選項,公用程式會將這些檔案遷移至工作目錄,並產生不可預期的結果 。

csvdmig 範例

commdirmig

commdirmig 公用程式將您的 LDAP 資料從 Sun LDAP Schema 1 遷移至 Schema 2,以準備使用 Access Manager 來進行認證服務。

本小節包含以下主題:

誰應執行公用程式

如果您先前使用的是 Messaging Server 5 的一個版本或 Calendar Server 5,您的 LDAP 項目為 Schema 1 格式。在新的 Calendar Server 6 2005Q4 環境中,如果您要使用 Access Manager 進行認證,則必須執行此公用程式將 LDAP 項目轉換為 Schema 2 格式。

如果您未使用 Access Manager,仍應考量遷移 LDAP 資料,因為 Schema 2 是適用於所有使用 LDAP 的 Java Enterprise System 產品的更好的 LDAP 模式。將來新版本的 communications 產品 (Calendar, Messaging 和 Instant Messaging) 很可能無法支援 Schema 1。但是,如果您此時不打算使用 Access Manage,則可以推遲遷移,以在稍後更方便的時間遷移。


備註 –

如果您具有用於喜好設定的獨立 LDAP 目錄,則必須在該 LDAP 和用於認證的 LDAP 上執行 commdirmig


何時執行公用程式

如果您要從 Calendar Server 的 Java Enterprise System 之前的版本遷移,請在執行 cs5migratecsmig csvdmig 之後再執行此公用程式。

文件的位置

commdirmig 遷移公用程式需要特殊的準備和規劃。這在獨立的指南中有說明,請參閱「Sun Java System Communications Services 6 2005Q4 Schema Migration Guide」

公用程式的位置

commdirmig 公用程式隨附於您使用 Java Enterprise System 安裝程式安裝的 Delegated Administrator。

還可從技術支援部門獲得用於該公用程式的修補程式。