第 3 章
移轉 Calendar Server 資料

Sun™ ONE Calendar Server 6.0 提供以下移轉公用程式：

cs5migrate 公用程式 – 將 Calendar Server 5.x 資料庫移轉至 Calendar Server 6.0，並將行事曆資料庫從 Berkeley DB 2.6 版升級至 3.2.9 版。
csmig 公用程式 – 可為行事曆資料庫中的每個行事曆指定一個所有者，並可將每個行事曆 ID (calid) 對映至一個所有者 (如果需要)，這樣可以支援託管 (虛擬) 網域和 LDAP 行事曆查找資料庫 (CLD) 外掛程式。
csvdmig 公用程式 – 升級 Calendar Server 6.0 的站台以使用託管 (虛擬) 網域。
ics2migrate 公用程式 – 從 iPlanet Calendar Server 2.x 中移轉資料。
ncs4migrate 公用程式 – 從 Netscape Calendar Server 4.x 中移轉資料。
csrename 公用程式 – 重新命名行事曆資料庫和 LDAP 目錄伺服器中的行事曆使用者 (帶「ics」字首的 Calendar Server 屬性)。

圖 3-1 顯示執行 Calendar Server 移轉公用程式的示意圖。

小心	在執行移轉公用程式之前，請首先洽詢您的 Sun Microsystems 技術支援代表或銷售帳號代表，以確保您使用的為最新版本的公用程式，這一點非常重要。 如果您的站台已配置為有限虛擬網域模式或 Calendar Server 的多個實例，請聯絡您的 Sun Microsystems 銷售帳號代表，以評估您的移轉需求，並確保您具有支援那些需求的特定移轉公用程式。

圖 3-1 執行 Calendar Server 移轉公用程式的示意圖

---

cs5migrate 公用程式

如果您要從 Calendar Server 5.x 升級到 Calendar Server 6.0，則必須先執行 cs5migrate 公用程式，然後才能執行 Calendar Server 6.0。cs5migrate 公用程式執行以下功能：

將下列 Calendar Server 5.x 檔案移轉至 Calendar Server 6.0：
行事曆資料庫檔案 (ics50calprops.db、ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db 和 ics50gse.db)
階段作業資料庫 (session.db)
將行事曆資料庫從 Berkeley DB 2.6 版升級至 3.2.9 版。
將移轉狀態寫入 cs5migrate.log 中，並將所有錯誤寫入 cs5migrateError.log 和 cs5migrateException.log 中。

移轉時間

cs5migrate 移轉時間可隨數種因素而改變。首先，cs5migrate 必須存取 LDAP 目錄伺服器以更新綱目屬性，因此連至 LDAP 伺服器的網路連線會極大地影響移轉時間。如果可能，請使用高速網路連線連至 LDAP 伺服器，並在網路流量最小時執行 cs5migrate。

移轉案例 – 在一個執行具有 20 GB 交換檔案空間的 Solaris 8 作業系統、具有 UltraSPARC™ III Cu、12 個 CPU、750 MHz、12 GB 記憶體和浮點處理器的 Sun Fire™ 上，cs5migrate 移轉以下 Calendar Server 5.x 行事曆資料庫大約需要 1 小時 15 分鐘：

行事曆資料庫大小：大約 600 MB
行事曆數：8726
事件數：272412
工作數：4490
警示數：13583
群組排程引擎 (GSE) 項目數：0

cs5migrate 語法

cs5migrate 公用程式的語法如下：

cs5migrate [-q] [-d] [-r] [-l min|max] source-directory target-directory

-q 指定靜音模式。如果移轉成功，cs5migrate 不會顯示資訊。但如果發生任何錯誤，則會顯示錯誤資訊。

-d 指定虛擬執行模式。虛擬執行會報告在實際移轉過程中 cs5migrate 將執行的作業，但是 cs5migrate 不會移轉任何資料或升級資料庫。

-r 指定建立週期性事件的主元件。

-l min|max 指定移轉日誌 (ics5migrate.log) 的日誌模式與詳細資訊層級。

註 -t 選項未在目前版次中實施。

source-directory 是一個必備參數，它指定包含 Calendar Server 5.x 資料庫檔案的目錄。

target-directory 是一個必備參數，它指定 cs5migrate 建立新 Calendar Server 6.0 資料庫檔案所在的現有目錄。

重要事項 執行 cs5migrate 之前，必須先建立 target-directory。

移轉程序

執行 cs5migrate 之前，請執行下列步驟：

使用一個公用程式 (例如 csbackup、Sun StorEdge Enterprise Backup™ 軟體或 Legato Networker®) 備份 Calendar Server 5.x 資料庫。
還建議您在移轉之前，使用 csbd rebuild 指令重建行事曆資料庫。如需相關資訊，請參閱「Sun ONE Calendar Server 管理員指南」中的第 5 章「管理 Calendar Server 資料庫」。
如有必要，可以透過將 ics.conf 檔案中的 caldb.serveralarms 參數設定為「yes」來啟用警示。
需要將 Calendar Server 5.x 資料庫移至其他伺服器時，如果資料庫 (*.db) 檔案不太大，則只需將這些檔案複製到新的伺服器即可。否則，請建立這些資料庫檔案的 tar 檔案，將 tar 檔案複製到新的伺服器，然後將其解包。

若要執行 cs5migrate，請執行下列步驟：

在 Solaris 與其他 UNIX 系統上，以執行 Calendar Server 的使用者與群組身份登入，例如 icsgroup 與 icsuser。
如有必要，使用 stop-cal 指令停止 Calendar Server。
如有必要，建立 target-directory。在執行 cs5migrate 之前，target-directory 必須存在。
執行 cs5migrate。如需有關語法，請參閱 cs5migrate 語法。

例如，在 Solaris 系統上：

./cs5migrate -q -l max /var/opt/SUNWics5/csdb511
  /var/opt/SUNWics5/csdb60


在此範例中，在您移轉之前，/var/opt/SUNWics5/csdb60 目錄必須存在。

如需瞭解移轉狀態，請檢視 cs5migrate.log 檔案。如果在移轉期間發生錯誤，或無法移轉行事曆資料庫項目，cs5migrate 會將它們寫入 cs5migrateerror.log。

cs5migrate 完成後，ics.conf 檔案中的 caldb.berkeleydb.homedir.path 參數必須指向移轉的資料庫，因為 cs5migrate 並不修改 ics.conf 檔案。

可以重設此參數以指向移轉的資料庫目錄，也可以將移轉的資料庫檔案移至此參數所指定的目錄。

如果您要使用 LDAP 資料快取記憶體選項 (local.ldap.cache.enable = "yes") 或 CLD 快取記憶體選項 (caldb.cld.cache.enable = "yes")，請在執行 cs5migrate 後於目標目錄中建立 ldap_cache 和 cld_cache 目錄。
檢查移轉資料庫檔案的權限。如果您以 icsuser 的身份執行 cs5migrate，則不應存在任何存取問題。如果您以超級使用者 (root) 的身份 (不建議使用) 執行，則可能需要重設權限。
使用 start-cal 指令重新啟動 Calendar Server。

---

csmig 公用程式

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

csmig 公用程式支援託管 (虛擬) 網域和 LDAP 行事曆查找資料庫 (CLD) 外掛程式。可使用該外掛程式存取移轉資料庫中的行事曆。LDAP CLD 外掛程式允許行事曆分散在多個後端伺服器上，從而提供了行事曆資料庫的水平可延伸性。如需有關 LDAP CLD 外掛程式的資訊，請參閱「Sun ONE Calendar Server 管理員指南」。

本文件說明下列主題：

csmig 功能
csmig 需求
csmig 語法
csmig 移轉步驟
csmig 提示與疑難排解

csmig 功能

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

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

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

csmig 會更新所有相關 LDAP 項目的 LDAP 屬性，包括 icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 以及 uid (用於資源行事曆)。csmig 會為 LDAP 目錄伺服器資料庫中的每個行事曆建立 icsDWPHost 屬性。icsDWPHost 會指定行事曆所在的後端伺服器的主機名稱。
csmig 可為行事曆資料庫中的每個行事曆指定一個所有者，並且可將每個行事曆 ID (calid) 對映至一個所有者 (如果需要)。所有預設的 calid 都保持原樣，不進行任何變更。其他行事曆則以下列方式進行對映：
沒有有效所有者的使用者行事曆將由透過 -c 選項發送至 csmig 的使用者所擁有。例如，如果 jsmith 沒有所有者，而且 orphan 被指定為 -c 選項，則 jsmith 將轉換為 orphan:jsmith。
沒有所有者的資源行事曆將由透過 -r 選項發送至 csmig 的資源使用者所擁有。
如果資源行事曆的名稱中含有冒號，這些冒號會轉換為底線。

例如，所有者為 bkamdar 的行事曆 football 會轉換為 bkamdar:football。所有者為 bkamdar 的行事曆 tchang:soccer 會轉換為 bkamdar:tchang_soccer。(calid 中只能有一個冒號。)名為 auditorium:room1 的資源行事曆將轉換為 auditorium_room1。

csmig 需求

使用 csmig 的需求為：

行事曆資料庫不能損毀。使用 csdb check 指令檢查行事曆資料庫，如有必要，請執行 csdb rebuild 指令以重建資料庫。如需有關這些指令的資訊，請參閱「Sun ONE Calendar 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 }

-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 外掛程式正常作業所必需的)。以下為使用 csmig 移轉行事曆資料時建議執行的步驟：

配置您的 LDAP 目錄伺服器 – 加入索引可以大幅提昇對 LDAP 資料的移轉和行事曆搜尋效能。
進行虛擬執行測試 – 虛擬執行會報告 csmig 在移轉期間將執行的作業，但不會實際移轉任何資料。虛擬執行之後，您可以修正所有錯誤，並決定處理任何未解決行事曆的計劃。
移轉您的生產資料 – 在執行生產資料移轉期間，csmig 會移轉行事曆資料庫 (.db 檔案) 與 LDAP 資料 (使用者與群組偏好設定資料)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 以及 uid (用於資源行事曆)。移轉之後，所有行事曆資源都會建立一個 LDAP 項目。

配置您的 LDAP 目錄伺服器

若要提昇效能，請考量將以下兩個新索引加入到 slapd.ldbm.conf 檔案中：

index icscalendar pres,eq,sub – 由移轉程序用來搜尋 icsCalendar 屬性。
index icscalendarowned pres,eq,sub – 移轉程序不需要，但在啟用 LDAP CLD 外掛程式之後，於 LDAP 資料上執行行事曆搜尋 (用於訂閱作業) 時使用。

如需有關在 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 問題或錯誤。在實際移轉之前，決定如何處理所有未解決的行事曆。有下列選項可供選擇：
在移轉之前，刪除所有不需要的行事曆。
為所有未解決的行事曆指定所有者。
在移轉期間，允許 csmig 使用選項 -c 與 -r 為行事曆指定所有者。
極力建議您在實際移轉生產行事曆資料庫之前，先在展示伺服器上移轉您的行事曆資料庫。此步驟可使您準確查看資料的移轉方式，並可讓您在移轉生產資料庫之前修正所有問題。

例如，在 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 目錄中。或者，編輯此參數以指向移轉資料庫的新位置。然後執行以下檢查：
對新的行事曆資料庫執行 csdb check。移轉資料庫中的事件數與待辦事項數應該與移轉前資料庫中的總數相符。
搜尋 icsCalendarOwned 項目，並確定這些項目與移轉前的行事曆數目相符。
登入 Calendar Express，並檢驗移轉資料庫中某些行事曆是否存在。

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

移轉您的生產資料

若要使用 csmig 移轉您的生產資料庫，請遵循下列步驟：

以 icsuser 的身份 (或以配置期間指定的 Calendar Server 運行時間使用者 ID 的身份) 登入。如果您以超級使用者 (root) 的身份執行 csmig，則可能需要重設移轉檔案的權限。
移至 cal_svr_base/opt/SUNWics5/cal/sbin 目錄。
使用 stop-cal 指令停止 Calendar Server (如有必要)。
備份下列資料：
行事曆資料庫 (.db 檔案)。
LDAP 資料：slapd 資料庫目錄與 LDAP 資料庫。
ics.conf 檔案。實際上不需要此步驟，但如果要復原至原始配置，該步驟會很有用。
使用 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

檢查錯誤檔案中是否有未解決的行事曆，並根據進行虛擬執行測試下步驟 10 中的計劃解決它們。
將新移轉的資料庫複製到 caldb.berkeleydb.homedir.path 參數指定的 /csdb 目錄中。或者，編輯此參數以指向移轉資料庫的新位置。
執行 csdb check 指令以檢查移轉的資料庫。如果指示資料庫已損毀，請執行 csdb rebuild 指令以重建資料庫。
啟用 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 快取記憶體目錄的位置。預設值為 cal_svr_base/var/opt/SUNWics5/csdb/cld_cache。

檢查該目錄是否正確，如果要將此 CLD 快取記憶體放在其他位置，請修改此參數。

如需有關為 LDAP CLD 外掛程式設定配置參數的資訊，請參閱「Sun ONE Calendar Server 管理員指南」。

使用 start-cal 指令重新啟動 Calendar Server。
登入 Calendar Server，檢查數個移轉的行事曆，以檢驗您的配置是否起作用。若要在進行檢查時停用警示，請將 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，並在 tchang 的 LDAP 項目內加入 icsCalendarowned。

LDAP 行事曆搜尋無法正常工作

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

解決方案

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

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

使用過濾器 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) 的 LDAP 搜尋
使用過濾器 (icscalendarowned=*substr*) 的 LDAP 搜尋

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

csmig 虛擬執行指示重複的行事曆名稱

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

包含 5 個事件的 basketball
包含 10 個事件的 jsmith:basketball

虛擬執行指示在移轉期間將合併這兩個行事曆，最後生成的行事曆將為：

jsmith:basketball，其所有者為 jsmith，共包含 15 個事件

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

修改行事曆屬性時發生錯誤，錯誤 = 2

解決方案

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

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

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

解決方案

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

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

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

解決方案

若要移動行事曆使用者，請匯出原始伺服器上的每個使用者行事曆，然後將這些行事曆匯入另一台伺服器。移動行事曆之後，您可以刪除原始伺服器上的行事曆。如需有關移動使用者的詳細步驟，請參閱「Sun ONE Calendar Server 管理員指南」。

---

csvdmig 公用程式

csvdmig 公用程式可以為將要使用託管 (虛擬) 網域的站台修改 Calendar Server 資料庫與 LDAP 目錄伺服器資料庫。csvdmig 公用程式將網域名稱加至使用者 ID，如下所示：

行事曆 ID (calids) 的格式變更如下：

userid[:calendar-name] 變更為 userid@domain[:calendar-name]

存取控制清單 (ACL) 存取規則變更如下：

userid 變更為 userid@domain

Calendar Server 屬性的 LDAP 目錄伺服器使用者項目修改如下：

userid[:calendar-name] 修改為 userid@domain[:calendar-name]

小心	csvdmig 公用程式並不會將資料從一個位置實際移轉至另一個位置。它會在行事曆資料庫與 LDAP 目錄伺服器的目前位置上對二者進行修改。 因此，執行 csvdmig 之前，請備份您的 Calendar Server 資料庫與 LDAP 目錄伺服器資料庫。

csvdmig 語法

csvdmig 公用程式的語法如下：

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

-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 範例

使用預設值移轉 LDAP 目錄伺服器：

csvdmig migrate LDAP

移轉 Calendar Server 資料庫：

csvdmig -t targetDB -e errorFile -m mappingFile migrate

---

ics2migrate 公用程式

ics2migrate 移轉公用程式可以將 iPlanet Calendar Server 2.x 行事曆資料與 LDAP 使用者偏好設定移轉至 Calendar Server 6.0。

本節說明以下內容：

移轉需求
移轉的內容
移轉程序

1. 升級 2.x 行事曆資料庫

2. 移轉資料

3. 檢查移轉結果

移轉範例

移轉需求

從 Calendar Server 2.x 移轉至 6.0 需要以下硬體和軟體：

來源機器具有要移轉的 Calendar Server 2.x 資料。
目標機器是將要建立移轉資料的機器。該機器必須安裝有 Calendar Server 6.0 (或更高版本)。
ics2migrate 公用程式 - 在移轉之前，請首先洽詢您的 Sun 技術支援代表或帳號管理員，以確保您使用的為最新版本的公用程式。

來源機器與目標機器可以是不同的伺服器，也可以是同一台伺服器。如需支援平台的清單，請參閱「Sun ONE Calendar Server 版次注意事項」。

移轉的內容

下表列出了 Calendar Server 2.x 資料，並說明了 ics2migrate 如何將資料移轉至 Calendar Server 6.0。

表格 3-1 移轉 Calendar Server 2.x 資料

Calendar Server 2.x 資料	Calendar Server 6.0 的移轉結果
行事曆屬性 (calprops)	更新了 Calendar Server calprops 資料庫。
事件	更新了 Calendar Server events 資料庫。
待辦事項	更新了 Calendar Server todos 資料庫。
警示	寫入事件與待辦事項的同時，更新了 alarms 資料庫。

下表列出了 Calendar Server 2.x LDAP 屬性，並說明了 ics2migrate 如何將屬性移轉至 Calendar Server 6.0。

表格 3-2 移轉 LDAP 屬性 

Calendar Server 2.x LDAP 屬性	Calendar Server 6.0 LDAP 屬性
nswcalUser *	icsCalendarUser *
nswcalCalID	icsCalendar
nswcalExtendedUserPrefs	icsExtendedUserPrefs
ceCalList **	icsSubscribed
ceAgendaList **	icsSet
ceDefaultAgenda **	icsDefaultSet
ceDefaultTZID **	icsTimeZone
ceFirstDayWeek **	icsFirstDay
* 物件類別 ** nswcalExtendedUserPrefs 的原始部分

移轉程序

ics2migrate 步驟如下：

升級 2.x 行事曆資料庫
移轉資料
檢查移轉結果

小心	執行 ics2migrate 之前，先使用一個公用程式 (例如 csbackup、Sun StorEdge Enterprise Backup™ 軟體或 Legato Networker®) 備份您的行事曆資料庫。 備份行事曆資料庫非常重要，因為 db_upgrade 會在目前目錄中升級該資料庫。如果升級期間發生問題，您的資料庫可能會無法回復。

升級 2.x 行事曆資料庫

Calendar Server 6.0 需要 Sleepycat Software 的 Berkeley DB 3.2.9 版。執行 ics2migrate 之前，必須使用 Berkeley DB db_recover 和 db_upgrade 公用程式將您的行事曆資料庫升級至 3.2.9 版。Calendar Server 6.0 在以下目錄中包括 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。
移轉後，請確定 ics.conf 檔案中的 caldb.berkeleydb.homedir.path 參數指向移轉資料庫。
執行 csdb check 指令，如有必要，執行 csdb rebuild 指令，重建行事曆資料庫。

ics2migrate 語法

移轉 Calendar Server 2.x 資料庫與 LDAP 使用者偏好設定

ics2migrate [-q] [-s def|none] [-f def|none] [-l min|max] source target

僅移轉 Calendar Server 2.x 資料庫

ics2migrate [-q] [-m db] [-s def|none] [-f def|none] [-l min|max] source target

僅移轉 LDAP 使用者偏好設定

ics2migrate [-q] [-m ldap]

註	若要顯示語法，請鍵入 ics2migrate (不帶任何選項)。

表格 3-3 列出了 ics2migrate 選項以及各選項的說明。

表格 3-3 ics2migrate 選項 

ics2migrate 選項	說明
[-q]	在靜音模式下執行。如果移轉成功，則 ics2migrate 不會在主控台上顯示資訊。如果移轉失敗，則 ics2migrate 僅顯示錯誤。 預設為冗長模式。
[-m db|ldap]	db – 僅移轉行事曆資料庫。 ldap – 僅移轉 LDAP 使用者偏好設定。 預設為同時移轉行事曆資料庫與 LDAP 使用者個人偏好。
[-s def|none]	def – 僅可存取使用者預設行事曆的排程。 none – 不可存取任何使用者行事曆的排程。 預設為可以存取所有行事曆的排程。
[-f def|none]	def – 僅可存取使用者預設行事曆的空閒/忙碌情形。 none – 不可存取任何使用者行事曆的空閒/忙碌情形。 預設為可以存取所有行事曆的空閒/忙碌情形。
[-l min|max]	min – 記錄最少的資料移轉統計資料：每個行事曆的行事曆 ID、主要所有者、事件數與待辦事項數。 max – 記錄最多的資料移轉統計資料：最少的統計資料加上每個事件和待辦事項的與會人員數以及警示數。 ics2migrate 將統計資料記錄至 cal_svr_base/opt/SUNWics5/cal/sbin 目錄下的 ics2migrate.log 中。 依預設，ics2migrate 在主控台顯示移轉統計資料，並且不產生日誌檔。
source	Calendar Server 2.x 資料庫檔案所在的目錄。 如果指定了 -m db 選項，或者忽略了 -m 選項，則需要有 source 才能進行資料庫移轉。
target	Calendar Server 6.0 資料庫檔案所在的目錄。 如果指定了 -m db 選項，或者忽略了 -m 選項，則需要有 target 才能進行資料庫移轉。

檢查移轉結果

完成移轉之後，請檢查下列結果：

檢查 ics2migrate.log 檔案，查找下列訊息 (依您的移轉選擇而定)：

Database migration successfully completed
LDAP user preference migration successfully completed

如果您懷疑資料庫可能損毀，請執行 csdb 公用程式的 check 指令。

check 指令會掃描行事曆資料庫，以檢查資料庫是否已損毀。如果 check 指令找到無法解決的不一致情況，它會在輸出中報告該情況。如有必要，您隨即可執行 csdb 公用程式的 rebuild 指令以重建行事曆資料庫 (caldb)。

如需有關 csdb 公用程式的 check 與 rebuild 指令的說明文件，請參閱說明文件網站上的「Sun ONE Calendar Server 管理員指南」。

移轉範例

同時移轉行事曆資料庫與 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

在靜音模式下移轉

執行與上個範例相同的移轉動作，但是在靜音模式下執行。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 與行事曆資料庫資訊。僅可存取每個使用者預設行事曆的排程，不能存取伺服器上所有行事曆的空閒/忙碌情形，並且不會在日誌檔中產生統計資料資訊。

ics2migrate -s def -f none 2x_db 50_db

---

ncs4migrate 公用程式

本節描述了如何使用 ncs4migrate 移轉公用程式將 Netscape Calendar Server 4.x 行事曆資料移轉至 Sun ONE Calendar Server。

對於開發者 Corporate Software & Technologies Int. Inc. 而言，Netscape Calendar Server 4.x 行事曆也稱為 CS&T 行事曆。

如果您需要 ncs4migrate 公用程式的複本，請與您的 Sun 技術支援代表或帳號管理員聯絡。取得 ncs4migrate 之後，請將它複製到 cal_svr_base/opt/SUNWics5/cal/sbin 目錄中。

本節包含下列資訊：

移轉需求
移轉的內容
移轉步驟

1. 備份 Calendar Server 5.0 資料庫

2. 準備移轉

3. 移轉資料

從多重節點上移轉資料

檢查移轉日誌檔

4. 檢查移轉資料

移轉需求

移轉需要下列硬體與軟體：

來源機器 — 機器上有您要移轉的 Netscape Calendar Server 4.0 (或更高版本) 資料。
目標機器 — 該機器上有您要移轉到的 Calendar Server 5.0 資料庫。它應該執行的是 Calendar Server 5.0 修補程式 4 (或更高版本)。

來源機器與目標機器可以是不同的伺服器，也可以是同一台伺服器。如需支援平台的清單，請參閱「Sun ONE Calendar Server 版次注意事項」。

移轉的內容

下表說明了 ncs4migrate 如何將 Netscape Calendar Server 4.0 資料移轉至 Calendar Server 6.0。

表格 3-4 移轉 Netscape Calendar Server 4.0 資料 

Netscape Calendar Server 4.0 資料項目	Calendar Server 5.0 移轉結果
會議、事件以及資源與使用者注意事項	作為事件移轉。
工作	作為待辦事項 (工作) 移轉。
存取 (安全性) 權限	在移轉的過程中忽略。不移轉指定內容與指定權限。 針對使用者的行事曆與資源行事曆，ncs4migrate 會使用 ics.conf 檔案中的存取控制字串，如下所示： 針對使用者的行事曆，ncs4migrate 會使用 calstore.calendar.default.acl，並將 Calendar Server 5.0 行事曆中的私密性設定設定為： 行事曆所有者：空閒時間、排程、讀取、刪除與修改 所有其他使用者：空閒時間與排程 針對資源行事曆，ncs4migrate 使用 resource.default.acl，並將 Calendar Server 5.0 行事曆中的私密性設定設定為： 資源所有者：空閒時間、排程、讀取、刪除與修改 所有其他使用者：空閒時間、排程與讀取 如需有關私密性設定及其變更方式的說明，請參閱 Calendar Express 線上說明。 註 移轉之前，請檢查 ics.conf 檔案中的字串，以確定其正確，如下所示： 對於 calstore.calendar.default.acl，正確的字串為： @@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g;@^c^^g 對於 resource.default.acl，正確的字串為： @@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g;@^c^^g
檔案附件	在移轉過程中忽略；在日誌檔中產生警告。
群組	未移轉。

移轉步驟

備份 Calendar Server 5.0 資料庫

建議您在移轉之前執行下列步驟，以確保行事曆資料庫的完整性：

使用一個公用程式 (例如 csbackup、Sun StorEdge Enterprise Backup™ 軟體或 Legato Networker®) 備份行事曆資料庫。

如需有關資訊，請參閱「Sun ONE Calendar Server 管理員指南」。

對您的行事曆資料庫執行 csdb 公用程式的 check 指令，以檢查資料庫是否損毀。如果 check 指令偵測到任何損毀，請執行 csdb 公用程式的 rebuild 指令以重建資料庫。

如需有關 csdb 與 csbackup 公用程式的說明文件，請參閱「Sun ONE Calendar Server 管理員指南」。

準備移轉

在執行 ncs4migrate 公用程式之前，請在目標機器上執行下列步驟：

以超級使用者 (root) 的身份登入 (或成為超級使用者)，或以具有系統管理員權限的使用者身份登入。
移至 cal_svr_base/opt/SUNWics5/cal/sbin 目錄。
建立名為 ncs4dirpaths.dat 的文字檔案，並指定 Netscape Calendar Server 4.0 資料庫的完全合格的目錄路徑。例如：

/apps/ncs/calendar/unison/db/nodes/N0/perm

若要尋找包含 Netscape Calendar Server 4.0 資料庫的目錄，請搜尋 unison.dbd 檔案。

如有必要，請滿足任何需求以使 ncs4migrate 能存取節點並讀取 Netscape Calendar Server 4.0 資料庫所在的目錄。

註	請勿在路徑名稱中使用諸如 $CAL_HOME 的變數。在移轉期間不會解析變數。

如需有關為多重節點上的資料建立 ncs4dirpaths.dat 檔案的資訊，請參閱從多重節點上移轉資料。

如果要移轉選取的使用者，請在 cal_svr_base/opt/SUNWics5/cal/sbin 目錄中建立一個名為 ncs4userfilter.dat 的使用者過濾檔案。ncs4userfilter.dat 是一個文字檔案，用於指定要移轉的使用者。每一行都用以下一種格式識別一個使用者：
Netscape Calendar Server 行事曆系統中的 node-number:user id (nscalxitemid 屬性)
使用者的 UID 屬性

例如，ncs4userfilter.dat 檔案中的數個項目可能為：

caluser1
caluser2
10000:00256
10000:00257

您可以在同一個 ncs4userfilter.dat 檔案中使用這兩種格式。

確定 LDAP 伺服器正在執行。
若要避免移轉期間更新行事曆資料庫，請停止 Calendar Server。但是，Netscape Calendar Server 可以執行，也可以停止。

現在，您可以移轉 Netscape Calendar Server 4.0 資料了。

移轉資料

在目標機器上，執行下列步驟：

以超級使用者 (root) 或具有系統管理員權限的使用者身份登入，同時移至 cal_svr_base/opt/SUNWics5/cal/sbin 目錄 (如有必要)。
在指令行上鍵入 ncs4migrate。

ncs4migrate 公用程式即會顯示其歡迎功能表，其中包含表格 3-5 中顯示的選項。

註：儘管 ncs4migrate 會顯示 (E)xport 與 (I)mport 選項，但是它們不受支援，也不應該使用。

表格 3-5 ncs4migrate 公用程式選項 

ncs4migrate 選項	說明
(E)xport	將 Netscape Calendar Server 4.0 行事曆資料庫匯出到中間檔案。
(I)mport	將資料從中間檔案匯入行事曆資料庫。
(S)kip	略過中間檔案。一次僅將一條記錄從 Netscape Calendar Server 4.0 移轉至 Calendar Server 5.0。
(L)ogging = ON|OFF	設定記錄。記錄檔案名稱為 ncs4migrate_yyyymmdd-hhmmss.log。 預設值為 ON。
(V)erbose = ON|OFF	設定冗長日誌。預設值為 OFF。 為了節省磁碟空間，建議保留為 OFF。
(D)ebug = ON|OFF	設定除錯日誌。預設值為 OFF。
(Q)uiet = ON|OFF	設定螢幕輸出。預設值為 OFF。
(T)erminate = TRUE|FALSE	如果 Netscape Calendar Server 4.0 資料庫中的使用者不在 LDAP 中，便終止。預設值為 FALSE。
(O)nly = TRUE|FALSE	僅移轉使用者過濾檔案 ncs4userfilter.dat 中的使用者。 預設值為 FALSE。 如果 O 與 M 為 TRUE，則 ncs4migrate 會移轉過濾檔案中具有任何參與者 (作為所有者或與會人員) 的所有事件。所有與會人員均會使事件移轉至其各自的行事曆中。
(M)igrate = TRUE|FALSE	移轉使用者過濾檔案中的使用者。預設值為 FALSE。
(B)ypass = TRUE|FALSE	繞過移轉使用者過濾檔案中的使用者。預設值為 FALSE。
(A)ny = TRUE|FALSE	Netscape Calendar Server 安全性存取層級的任何組合都會在 Calendar Server 中產生一項授權。預設值為 TRUE。FALSE 意味著需要提供所有三個存取層級；請參閱 (H)elp。
(U)ser	顯示使用者過濾檔案 ncs4userfilter.dat。 使用選項 O 開啟或關閉 (ON|OFF) 過濾。預設值為 OFF。
路徑(P)	Netscape Calendar Server 4.0 資料庫的路徑檔案。檔案名稱為 ncs4dirpaths.dat。
(H)elp	顯示 [說明] 畫面。
(E)xit	結束程式。

從 ncs4migrate 功能表，指定 S 選項以移轉所有使用者。或者，如果您要移轉使用者過濾檔案 (ncs4userfilter.dat) 中的特定使用者，請指定 O 選項。
監視移轉日誌檔以檢查移轉狀態。請參閱檢查移轉日誌檔，以取得更多資訊。
移轉完成之後，請依照檢查移轉資料所述檢查移轉行事曆資料庫。

從多重節點上移轉資料

若要從多重節點上移轉 Netscape Calendar Server 4.0 資料，請在目標機器上執行下列步驟：

以超級使用者 (root) 的身份或以具有系統管理員權限的使用者身份登入後，將 Netscape Calendar Server 4.0 資料庫目錄從各個節點複製到您要執行 ncs4migrate 的機器上。(每個 Netscape Calendar Server 4.0 目錄均應包含一個 unison.dbd 檔案。)

您也可以直接從各個節點移轉 Netscape Calendar Server 4.0 資料；但是，必須首先滿足所有需求以使 ncs4migrate 能存取其他節點上的 Netscape Calendar Server 4.0 資料。

移至 cal_svr_base/opt/SUNWics5/cal/sbin 目錄。
在 ncs4dirpaths.dat 檔案中，為所有節點上的資料指定目錄路徑名稱。例如，下列 ncs4dirpaths.dat 檔案包括三個節點的目錄路徑：

/apps/ncs/calendar/unison/db/nodes/N0/perm
/apps/ncs/calendar/unison/db/nodes/N1/perm
/apps/ncs/calendar/unison/db/nodes/N2/perm

若要執行移轉公用程式，請在指令行上鍵入 ncs4migrate。
從 ncs4migrate 功能表，指定 S 選項以移轉所有使用者。或者，如果您要移轉使用者過濾檔案 (ncs4userfilter.dat) 中的特定使用者，請指定 O 選項。
監視移轉日誌檔以檢查移轉狀態。請參閱檢查移轉日誌檔，以取得更多資訊。
移轉完成之後，依照檢查移轉資料所述檢查移轉行事曆資料庫。

檢查移轉日誌檔

ncs4migrate 公用程式會在 cal_svr_base/opt/SUNWics5/cal/sbin 目錄中產生具有下列名稱的日誌檔：

ncs4migrate_yyyymmdd-hhmmss.log

其中，yyyymmdd-hhmmss 為指示移轉開始時間的時間標記。

如果 ncs4migrate 公用程式執行的時間太長，請檢查日誌檔的大小是否正在增加，若是則表示公用程式仍在執行中。

註	為避免日誌檔太大，請考量省略 ncs4migrate verbose (V) 選項。

檢查移轉資料

移轉完成之後，請在目標機器上執行下列步驟：

執行 csdb 公用程式的 check 指令來掃描行事曆資料庫，以確定是否發生任何損毀。如果 check 指令偵測到任何損毀，請執行 csdb 公用程式的 rebuild 指令以重建資料庫。

如需有關 csdb 公用程式的 check 與 rebuild 指令的說明文件，請參閱說明文件網站上的「Sun ONE Calendar Server 管理員指南」。

如有必要，請重新啟動 Calendar Server。

使用者可以使用 Calendar Express 存取移轉的行事曆資料庫。

---

csrename 公用程式

csrename 公用程式將重新命名行事曆使用者，如下所示：

行事曆資料庫檔案 – 重新命名行事曆資料庫檔案中的使用者 (使用者 ID)，然後將新的資料庫檔案寫入目標目錄。現有行事曆資料庫檔案不會被修改。
LDAP 目錄伺服器 – 轉換 Calendar Server LDAP 屬性中的使用者 ID (即帶「ics」字首的屬性)。系統會適當地修改 LDAP 目錄伺服器。

csrename 公用程式位於以下目錄中：

cal_svr_base/opt/SUNWics5/cal/sbin

執行 csrename 之前，您必須首先執行以下作業：

為您要轉換的使用者建立輸入對映檔案 (-m 選項)。
如有必要，佈建 LDAP 目錄伺服器中的所有新使用者。
停止 Calendar Server。

若要執行 csrename，必須以 icsuser 的身份 (或以配置期間指定的 Calendar Server 運行時間使用者 ID 的身份) 登入。如果您以超級使用者 (root) 的身份執行 csrename，則可能需要重設新資料庫檔案的權限。若要修改 LDAP 目錄伺服器屬性，還必須具有該目錄的管理權限。

如果您具有前端/後端伺服器配置，則必須在每個後端伺服器上執行 csrename。

csrename 語法

請使用以下語法來執行 csrename：

csrename [-t DestinationDB ] [-c ConfigFile ] [-e ErrorFile ] -m MappingFile rename [DB|LDAP]

-t DestinationDB 指定 csrename 產生包含轉換的使用者名稱的新資料庫所在的目標目錄。預設值為 MigratedDB。

csrename 完成後，ics.conf 檔案中的 caldb.berkeleydb.homedir.path 參數必須指向目標資料庫。可以重設 caldb.berkeleydb.homedir.path 以指向目標資料庫目錄，也可以將目標資料庫檔案移至該參數所指定的目錄。

-c ConfigFile 為輸入參數，用於指定 Calendar Server 配置檔案。預設值為 ics.conf 檔案。

csrename 使用配置檔案中的 caldb.berkeleydb.homedir.path 參數決定輸入行事曆資料庫的位置。行事曆資料庫的預設位置為 cal_svr_base/var/opt/SUNWics5/csdb。

-e ErrorFile 是 csrename 寫入所有錯誤或無法解決的資料庫項目的檔案。預設值為 MigrateError。

-m MappingFile 指定輸入對映檔案。預設值為 MigrateMapping。

輸入對映檔案是文字檔案，可將現有使用者 ID 對映至新使用者 ID。

執行 csrename 之前，必須先建立對映檔案。每一行指定一個項目，新舊值之間用空格分隔。例如：

tchang tc897675
jsmith js963123
...
bkamdar bk548769

DB|LDAP 指定要進行更新的資料庫：

DB 僅轉換新行事曆資料庫中的使用者 ID (預設值)。
LDAP 同時轉換新行事曆資料庫和 LDAP 目錄伺服器屬性中的使用者 ID。

csrename 範例

根據名為 DBMapFile 的對映檔案重新命名使用者，並在目標目錄中建立名為 newcalDB 的新行事曆資料庫：

csrename -t newcalDB -m DBMapFile rename DB

根據名為 NewNames 的對映檔案中的值重新命名使用者，在目標目錄中建立名為 NewDB 的新行事曆資料庫，並修改 LDAP 目錄伺服器中的 Calendar Server 屬性：

csrename -t NewDB -m NewNames rename LDAP

上一個      目錄      索引      下一個

---

Copyright 2003 Sun Microsystems, Inc.。版權所有。