|
| |
| Sun Java System Calendar Server 管理指南 | |
第 4 章
遷移公用程式安裝 Calendar Server 並進行配置之後，您可能需要遷移元件資料庫和 LDAP 資料庫。提供了數個遷移公用程式，可將低版本的資料庫升級至目前版本。本章提供遷移公用程式示意圖，以協助您選擇要執行的正確公用程式。
本章包含以下小節：
Calendar Server 遷移公用程式簡介Calendar Server 6 2004Q2 提供兩種類型的資料庫遷移公用程式：
元件資料庫遷移公用程式
元件資料庫包含所有行事曆使用者和資源的事件和待辦事項。以下公用程式可遷移元件資料庫：
如果您已安裝 Calendar Server 6.0 (2003Q4) 並要升級至 Calendar Server 6 2004Q2，則無需執行此公用程式。首次存取該資料庫時，從 Berkeley 3.2.9 至 4.2 的更新將自動完成。
請在執行 csmig、csvdmig 和 commdirmig 之前先執行此程式。
此公用程式在遷移網站上提供。請參閱「遷移網站」。
您無需首先執行此公用程式的基本版，因為週期性版本也可執行與基本版相同的功能。也就是說，它可將 Calendar Server 5.x 資料庫遷移至 Calendar Server 6.x，並將行事曆資料庫從 Berkeley DB 2.6 版升級至 4.2 版。此外，為了能夠在 Outlook 中查看，此公用程式將現有週期性事件轉換為具有異常的主記錄。
此公用程式在遷移網站上提供。請參閱「遷移網站」。
- ics2migrate 將資料從 iPlanet Calendar Server 2.x 遷移至 5.x。此公用程式隨附於 Calendar Server 5.1.1。
- ncs4migrate 將資料從 Netscape Calendar Server 4.x 遷移至 5.x。此公用程式在遷移網站上提供。請參閱「遷移網站」。
LDAP 資料庫遷移和升級公用程式
LDAP 資料庫包含認證 (使用者和資源項目) 和行事曆喜好設定資訊。以下公用程式可升級或遷移 LDAP 資料：
- csmig 可為 Calendar Server 6.x 資料庫中的每個行事曆指定一個所有者，並可將每個行事曆 ID (calid) 對映至一個所有者 (如果需要)，這樣可以支援託管 (虛擬) 網域和 LDAP 行事曆查找資料庫 (CLD) Plug-in。此公用程式與 Calendar Server 封裝在一起。執行 cs5migrate 之後，請執行此公用程式然後再執行 csvdmig。
- csvdmig 透過增加行事曆的網域 (@domainname) 至每個 calid，升級 Calendar Server 6.x 站點以使用託管 (虛擬) 網域。例如，在網域 sesta.com 中，jdoe 的 calid 現在將為 jdoe@sesta.com。此公用程式與 Calendar Server 封裝在一起。執行 cs5migrate 和 csmig 之後再執行此公用程式。
- commdirmig 公用程式 將 LDAP 資料從模式 1 遷移至模式 2，以準備用於 Identity Server 6.1 或更高版本。此遷移公用程式在單獨的指南中提供，請參閱位於以下網站上的「Sun Java System Communications Services Schema Migration Guide」：
http://docs.sun.com/coll/CalendarServer_04q2 和
http://docs.sun.com/coll/CalendarServer_04q2_zh_TW如果您先前使用的是 Messaging Server 5.x 或 Calendar Server 5.x，您的 LDAP 項目為 Sun LDAP 模式 1 格式。在新的 Calendar Server 6 2004Q2 環境中，如果您要使用 Identity Server 進行認證，則必須執行此公用程式將 LDAP 項目轉換為模式 2 格式。
如果您要從 Calendar Server 的 Java Enterprise System 之前的版本遷移，請在執行 cs5migrate、csmig 和 csvdmig 之後再執行此公用程式。
對於 Sun Java Enterprise System 2004Q2，此公用程式與佈建公用程式 commadmin 同時隨附於 Identity Server 6.2 (2004Q2)。
如果您不希望更新 Identity Server，則只需要 Calendar Server 6.0 (2003Q4) 的遷移公用程式，技術支援部門可提供僅用於此公用程式的修補程式。
遷移公用程式示意圖由於有很多可供選擇的公用程式，圖 4-1 顯示了可協助您決定使用這些公用程式的順序的示意圖。
圖 4-1 執行 Calendar Server 遷移公用程式的示意圖
在您安裝 Calendar Server 6.x 並執行 cs5migrate 之後，決定您需要執行哪個遷移公用程式 (如果有其他遷移公用程式)。圖 4-2 圖 4-2 顯示了其他配置方案以及針對每個配置方案要執行的遷移公用程式。
圖 4-2 配置方案
遷移網站為進一步協助您針對特定站點作出適當的選擇，技術支援人員 (將您引導至某網站) 可向您提供其他資訊和公用程式下載。
在該網站上，您需要完成一份簡短的問卷，該問卷可協助您決定使用哪個公用程式，並可協助您計算遷移程序所需的當機時間。
小心 如果您的站點被配置用於有限虛擬網域模式或 Calendar Server 的多個實例，請聯絡您的 Sun Microsystems Inc. 銷售客戶代表，以評估您的遷移需求，並確保您具有支援那些需求的特定遷移公用程式。
在某些情況下，建議您向 Sun Microsystems 技術支援人員或專業服務人員尋求援助。
註
雖然 cs5migrate 看來是隨附於 Calendar Server 產品，但是如果您嘗試執行此公用程式，則會顯示以下訊息：
!!!!!!!!!!請注意!!!!!!!!!!
若要遷移至 Calendar Server 6.0，請聯絡您的 Sun Microsystems 技術支援代表或銷售客戶代表，以取得此公用程式的最新版本。
ics2migrateics2migrate 公用程式可將 iPlanet Calendar Server 2.x 行事曆資料和 LDAP 使用者喜好設定遷移至 Sun ONE Calendar Server 5.x。
本小節說明以下內容：
遷移需求
從 Calendar Server 2.x 遷移至 6.x 需要以下硬體和軟體：
來源機器與目標機器可以是不同的伺服器，也可以是同一台伺服器。如需支援平台的清單，請參閱「Sun Java System Calendar Server 版本說明」。
遷移的內容？
下表列出 Calendar Server 2.x 資料，並說明 ics2migrate 如何將資料遷移至 Calendar Server 6.x。
下表列出 Calendar Server 2.x LDAP 屬性，並說明 ics2migrate 如何將屬性遷移至 Calendar Server 6.x。
遷移程序
若要從 2.x 遷移至 5.x：
小心 執行 ics2migrate 之前，先使用一個公用程式 (例如 csbackup、Sun StorEdge Enterprise Backup[TM] 軟體或 Legato Networker[R]) 備份您的行事曆資料庫。
備份行事曆資料庫非常重要，因為 db_upgrade 會適當地升級該資料庫。如果升級期間發生問題，您的資料庫可能會無法回復。
在您的 2.x Berkeley 資料庫中執行 db_recover
執行 Berkeley DB db_recover 公用程式，以在您轉換日誌檔異動之前將其合併到該資料庫中。如果您不使用此公用程式，將會遺失未合併的異動。
下載並安裝 Calendar Server 5.1.1
請參閱位於以下網站上的「iPlanet Calendar Server 5.1 Installation Guide」：
http://docs.sun.com/db/doc/816-5516-10
升級 2.x 行事曆資料庫
Calendar Server 5.1.1 需要 Sleepycat Software 的 Berkeley DB 3.2.9 版。執行 ics2migrate 之前，您必須使用 Berkeley DB db_upgrade 公用程式將您的行事曆資料庫升級至 3.2.9 版。Calendar Server 5.x 在以下目錄中包括 Berkeley DB 公用程式：
cal_svr_base/opt/SUNWics5/cal/tools/unsupported/bin
如需有關 Berkeley DB 公用程式的更多資訊，請參閱以下網站：
http://www.sleepycat.com/docs/utility/index.html
若要將您的資料庫升級至 3.2.9 版，請：
- 在 Solaris 與其他 UNIX 系統上，以執行 Calendar Server 的使用者與群組身份登入，例如 icsgroup 與 icsuser。
- 如有必要，停止 2.x Calendar Server。
- 如果您尚未備份行事曆 2.x 資料庫，請進行備份。
- 從下列目錄中移除 (刪除) 所有舊的共用檔案 (_db_name.share) 或日誌檔 (log.*)：
cal_svr_base/opt/SUNWics5/cal/lib/http
cal_svr_base/var/opt/SUNWics5/csdb
- 執行 db_upgrade 公用程式，將您的 2.x 行事曆資料庫升級至 3.2.9 版。如果您不在 2.x 行事曆資料庫所在的目錄中，請使用 -h 選項指向這些資料庫檔案。
注意您必須對所有的 2.x 資料庫檔案 (alarms.db、calprops.db、events.db 和 todos.db) 執行 db_upgrade。還必須在 Calendar Server 配置中的所有前端與後端伺服器上執行 db_upgrade，即使對沒有直接連線至行事曆資料庫的伺服器亦如此。
- 在包含資料庫檔案的 csdb 目錄中找到 Calendar Server 2.x caldb.conf 檔案，並變更檔案中的第一行，如下所示：
舊值：caldb.version "1.0.0 [BerkeleyDB]"
新值：caldb.version= "1.0.0 [BerkeleyDB]"
注意如果此檔案不在 csdb 目錄中，請使用文字編輯器建立該檔案，然後將第一行設定為新值。
遷移資料 (執行 ics2migrate)
請遵循以下步驟執行 ics2migrate：
- 移至 ics2migrate 所在的目錄。
- 使用「ics2migrate 語法」中的語法執行 ics2migrate。
- 遷移後，請確定 ics.conf 檔案中的 caldb.berkeleydb.homedir.path 參數指向遷移資料庫。
- 執行 csdb check 指令，如有必要，執行 csdb rebuild 指令，重建行事曆資料庫。
ics2migrate 語法
遷移 Calendar Server 2.x 資料庫與 LDAP 使用者喜好設定
僅遷移 Calendar Server 2.x 資料庫
僅遷移 LDAP 使用者喜好設定
表格 4-3 列出 ics2migrate 選項以及各選項的說明。
檢查遷移結果
完成遷移之後，請檢查以下結果：
遷移範例
本小節包含以下主題的範例：
在無訊息模式下遷移
執行與上個範例相同的遷移動作，但是在無訊息模式下執行。ics2migrate 不會在主控台上顯示遷移統計資料或產生日誌檔。
ics2migrate -q /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db
僅遷移行事曆資料庫
僅遷移儲存在 2x_db 目錄 (相對於目前目錄) 中的 2.x 行事曆資料庫，並且在 /var/opt/SUNWics5/50_db 目錄中建立一個 6.0 資料庫。
ics2migrate -m db 2x_db /var/opt/SUNWics5/50_db
僅遷移 LDAP 使用者資訊
僅將 Calendar Server 2.x LDAP 使用者資訊遷移為 6.0 版格式。
ics2migrate -m ldap
同時遷移行事曆資料庫與 LDAP 使用者資訊
同時遷移 LDAP 使用者資訊與 Calendar Server 2.x 資料庫。Calendar Server 2.x 資料庫儲存在 /var/opt/SUNWicsrv/2x_db 中，6.0 資料庫儲存在 /var/opt/SUNWics5/50_db 目錄中。
可存取所有行事曆的排程與空閒/忙碌情形，並將最少的遷移統計資料記錄在名為 ics2migrate.log 的日誌檔中。
ics2migrate /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db -l min
csmigcsmig 公用程式可為行事曆資料庫中的每個行事曆指定一個所有者，並可將每個行事曆 ID (calid) 對映至一個所有者 (如果需要)。
csmig 公用程式支援託管 (虛擬) 網域和 LDAP 行事曆查找資料庫 (CLD) Plug-in。可使用該 Plug-in 存取遷移資料庫中的行事曆。LDAP CLD Plug-in 允許行事曆分布在多台後端伺服器上，從而提供了行事曆資料庫的水平可延伸性。如需有關 LDAP CLD Plug-in 的資訊，請參閱「Sun Java System Calendar Server 6 2004Q2 管理指南」。
本小節說明以下主題：
csmig 功能
csmig 遷移公用程式執行以下功能：
csmig 需求
使用 csmig 的需求為：
csmig 語法
csmig 公用程式的語法如下：
csmig [ -t DestinationDB ] [ -b Backend-DWPHost ]
[ -o OutputFile ] [ -e ErrorFile ] [ -m MappingFile ]
-c calendarOwner -r resourceOwner { migrate|dryrun }
-t DestinationDB 指定 csmig 所產生的目標資料庫。預設為 MigratedDB。
-b Backend-DWPHost 指定 DWP 後端主機伺服器的名稱。此名稱必須與 ics.conf 檔案中指定的 DWP 後端主機伺服器名稱相符。
-o OutputFile 指定一個輸出檔案，該檔案會將 csmig 輸出及發生的所有錯誤擷取到螢幕。預設為 MigrateOut。
-e ErrorFile 是 csmig 寫入所有錯誤或無法解決的資料庫項目的檔案。如果資料庫項目無法解決，則它們不會被寫入目標資料庫。預設為 MigrateError。
-m MappingFile 是在 dryrun 模式中產生的輸出對映檔案，它列出了 LDAP 模式中需要變更的項目。例如：
Old calid = jsmith New calid = jsmith:basketball
對映檔案僅提供對 LDAP 模式的變更清單，csmig 並不實際變更此模式。
在 migrate 模式中，不使用 MappingFile。
-c calendarOwner 為沒有所有者的使用者行事曆指定所有者。
-r resourceOwner 為沒有所有者的資源行事曆指定所有者。
csmig 遷移步驟
在您配置中的所有伺服器上安裝了 Calendar Server 6.0 之後，必須執行 csmig 以將現有的 Calendar Server 與 LDAP 資料遷移至新的 Calendar Server 6.0 與 LDAP 資料 (這是 LDAP CLD Plug-in 正常作業所必需的)。使用 csmig 遷移行事曆資料時，執行以下步驟：
- 配置您的 LDAP 目錄伺服器 - 增加索引可以大幅提昇對 LDAP 資料的遷移和行事曆搜尋效能。
- 進行虛擬執行測試 - 虛擬執行會報告 csmig 在遷移期間將執行的作業，但不會實際遷移任何資料。虛擬執行之後，您可以修正所有錯誤，並決定處理任何未解決行事曆的計劃。
- 遷移您的生產資料 - 在執行生產資料遷移期間，csmig 會遷移行事曆資料庫 (.db 檔案) 與 LDAP 資料 (使用者與群組喜好設定資料)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 以及 uid (用於資源行事曆)。遷移之後，所有行事曆資源都會建立一個 LDAP 項目。
配置您的 LDAP 目錄伺服器
若要提昇效能，請考量將以下兩個新索引增加到 slapd.ldbm.conf 檔案中：
如需有關在 slapd.ldbm.conf 檔案中建立索引的資訊，請參閱您的目錄伺服器文件。
進行虛擬執行測試
在展示伺服器上進行的虛擬執行測試會報告將要遷移的內容，但不會實際遷移生產資料庫。虛擬執行可讓您決定遷移生產資料庫的計劃。例如，您可以決定處理「無主」行事曆 (沒有所有者的行事曆) 的方式。
若要使用 csmig 進行虛擬執行測試，請遵循下列步驟：
- 以 icsuser 的身份 (或以配置期間指定的 Calendar Server 運行時間使用者 ID 的身份) 登入。如果您以超級使用者 (root) 的身份執行 csmig，則可能需要重設遷移檔案的權限。
- 在展示伺服器上安裝 Calendar Server 6.0 (如有必要)。
- 將行事曆資料庫的快照複製到展示伺服器中。
- 安裝 LDAP 伺服器以模擬生產 LDAP 環境。使用 slapd.ldbm.conf 檔案中的新索引在此伺服器上安裝 LDAP 資料庫的快照。
- 移至 cal_svr_base/opt/SUNWics5/cal/sbin 目錄。
- 考量為沒有所有者的使用者行事曆建立一個 catchall calid。例如，在 Solaris 系統上，以下指令將建立一個 calid 為 orphan 的使用者：
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan
- 使用 stop-cal 指令停止 Calendar Server (如有必要)。
- 執行 csdb check 指令以檢查您的資料庫是否損毀。如果指示資料庫已損毀，請執行 csdb rebuild 指令以重建資料庫。
- 使用 dryrun 選項執行 csmig。例如，在 Solaris 系統上，輸入：
./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun
該指令將沒有所有者的使用者行事曆指定給 orphan，將沒有所有者的資源行事曆指定給 calmaster。
檢查輸出對映檔案 (csmig.map)。對映檔案列出 LDAP 模式中需要更新的項目。
- 檢查輸出檔案、對映檔案與錯誤檔案。解決您發現的所有 LDAP 問題或錯誤。在實際遷移之前，決定如何處理所有未解決的行事曆。有以下選項可供選擇：
- 在實際遷移生產行事曆資料庫之前，先在展示伺服器上遷移您的行事曆資料庫。此步驟可使您準確查看資料的遷移方式，並可讓您在遷移生產資料庫之前修正所有問題。
例如，在 Solaris 系統上，以下指令可將行事曆資料庫遷移至 /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 目錄中。或者，編輯此參數以指向遷移資料庫的新位置。然後執行以下檢查：
如果測試遷移成功，您便可以遷移生產資料庫。
遷移您的生產資料
若要使用 csmig 遷移您的生產資料庫，請遵循以下步驟：
- 以 icsuser 的身份 (或以配置期間指定的 Calendar Server 運行時間使用者 ID 的身份) 登入。如果您以超級使用者 (root) 的身份執行 csmig，則可能需要重設遷移檔案的權限。
- 移至 cal_svr_base/opt/SUNWics5/cal/sbin 目錄。
- 使用 stop-cal 指令停止 Calendar Server (如有必要)。
- 備份下列資料：
- 使用 migrate 選項執行 csmig。例如，在 Solaris 系統上，以下指令可將行事曆資料庫遷移至 /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
- 將新遷移的資料庫複製到 caldb.berkeleydb.homedir.path 參數指定的 /csdb 目錄中。或者，編輯此參數以指向遷移資料庫的新位置。
- 執行 csdb check 指令以檢查遷移的資料庫。如果指示資料庫已損毀，請執行 csdb rebuild 指令以重建資料庫。
- 啟用 LDAP CLD Plug-in，方法為對 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 快取記憶體目錄的位置。預設為 cal_svr_base/var/opt/SUNWics5/csdb/cld_cache。
- 使用 start-cal 指令重新啟動 Calendar Server。
- 登入 Calendar Server，檢查數個遷移的行事曆，以驗證您的配置是否起作用。若要在進行檢查時停用警示，請將 ics.conf 檔案中的以下每個參數均設定為 "no"：
csmig 提示與疑難排解
本小節說明以下提示與疑難排解解決方案：
csmig 虛擬執行行事曆所有者並非我想要的行事曆所有者
例如，名為 tchang:myCalendar 的行事曆在行事曆資料庫中的所有者名為 jsmith，而 csmig 虛擬執行將該對映顯示為 jsmith:tchang_myCalendar。我希望將該行事曆名稱保留為 tchang:myCalendar，並將所有者指定為 tchang。
解決方案
在遷移之前，使用 cscal 公用程式將行事曆的所有者 tchang:myCalendar 變更為 tchang。一旦完成該項作業，遷移便會將此行事曆對映至 tchang:myCalendar，並將 icsCalendarowned 增加至 tchang 的 LDAP 項目中。
LDAP 行事曆搜尋無法正常工作
遷移之後，將啟用 LDAP 行事曆搜尋，但是行事曆搜尋對話方塊不會傳回任何結果，或僅傳回部分結果。
解決方案
啟用 LDAP 行事曆搜尋可讓 Calendar Server 搜尋 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))。
使用以下過濾器對 LDAP 資料手動執行兩種不同的搜尋，並比較輸出結果：
由於伺服器使用包含 icsCalendaruser 物件類別的過濾器，因此在模式檢查停用的情況下可能已部署了 LDAP 伺服器，並可能已佈建了某些不具有 icsCalendaruser 物件類別的行事曆項目。
csmig 虛擬執行指示重複的行事曆名稱
csmig 虛擬執行對映檔案與輸出檔案指示存在重複的行事曆名稱。例如，在原始資料庫中，jsmith 擁有下列行事曆：
虛擬執行指示在遷移期間將合併這兩個行事曆，最後生成的行事曆將為：
輸出檔案將包含下列警告訊息：
修改行事曆屬性時發生錯誤，錯誤 = 2
解決方案
如果您不想合併這兩個行事曆，請在遷移之前將 basketball 的所有者變更為 jsmith 之外的其他所有者。這樣做會保留兩個獨立行事曆的資料完整性。
我如何將無主行事曆指定給不同的所有者？
依預設，csmig 會將所有無主行事曆指定給單一所有者，但是我想為某些無主行事曆指定不同的所有者。
解決方案
csmig 不接受指令行上的對映檔案。但是，您可以在遷移之前，將所有者指定給原始資料庫中的無主行事曆。檢查所有無主行事曆的虛擬執行對映檔案。然後在遷移之前，使用 cscal 公用程式將所有者指定給無主行事曆。以 dryrun 模式再次執行 csmig，以驗證新的所有者。
我如何將行事曆使用者移至另一台後端伺服器？
我如何將使用者從一台後端伺服器移至另一台後端伺服器？
解決方案
若要移動行事曆使用者，請匯出原始伺服器上的每個使用者行事曆，然後將這些行事曆匯入另一台伺服器。移動行事曆之後，您可以刪除原始伺服器上的行事曆。如需有關移動使用者的詳細步驟，請參閱「Sun Java System Calendar Server 6 2004Q2 管理指南」。
csvdmigcsvdmig 公用程式可以為將要使用託管 (虛擬) 網域的站點修改 Calendar Server 資料庫與 LDAP 目錄伺服器資料庫。csvdmig 公用程式將網域名稱增加至使用者 ID，如下所示：
csvdmig 語法
csvdmig 公用程式的語法如下：
-m MappingFile 為輸入參數，用於指定對映檔案。預設為 MigrateMapping。
對映檔案是輸入文字檔案，它將現有使用者對映至他們各自的網域。執行 csvdmig 之前，必須先建立對映檔案。每一行指定一個項目，新舊值之間用空格分隔。例如：
user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
...
user-n user-n@siroe.com-c ConfigFile 為輸入參數，用於指定 Calendar Server 配置檔案。預設為 ics.conf 檔案。
-t DestinationDB 為輸出參數，用於指定遷移資料庫的位置。預設為 MigratedDB。
-e ErrorFile 為輸出參數，用於為無法解決的錯誤指定錯誤檔案的名稱。預設為 MigrateError。
DB | LDAP 用於指定是修改 Calendar Server 資料庫 (DB) 還是修改 LDAP 目錄伺服器 (LDAP)。預設為行事曆資料庫 (DB)。
csvdmig 範例
