目錄伺服器附有標準模式,內含數以百計的物件類別與屬性。雖然標準物件類別與屬性應足以因應您大部分的需求,但仍有可能需要建立新的物件類別與屬性,以延伸模式。如需標準模式的簡介與如何依據本身的部署設計模式的指示,請參閱「Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide」。
本章說明如何管理您的模式,其中包含下列主題:
開啟模式檢查後,目錄伺服器會確認所有的匯入、增加以及修改作業確實符合目前所定義的目錄模式。
每個項目的物件類別與屬性均符合模式。
項目中包含其所有已定義之物件類別的所有必要屬性。
項目僅包含其物件類別所允許的屬性。
修改項目時,目錄伺服器會對整個項目執行模式檢查,而不是僅檢查進行修改的屬性。因此,若項目中有任何物件類別或屬性不符合模式,作業即可能失敗。
但模式檢查並不會驗證屬性值在語法方面的有效性。
模式檢查預設為開啟。一般情況下,在執行目錄伺服器時請開啟模式檢查。許多用戶端應用程式均假設,開啟模式檢查即表示所有項目皆符合模式。但在開啟模式檢查後,目錄伺服器並不會因此而驗證目錄中現有的內容。唯一能夠確保所有目錄內容均符合模式的方法,是在增加任何項目或重新初始化所有項目之前開啟模式檢查。
在某些情況下您會想關閉模式檢查,例如為使已知符合模式的 LDIF 檔案加快匯入作業速度而關閉,是其中之一。但如此做會有匯入項目不符合模式的風險。若關閉模式檢查,則無法偵測不符合模式的匯入項目。
如需在複寫環境中使用模式檢查的詳細資訊,請參閱複寫目錄模式。
當項目不符合模式時,即可能無法搜尋此項目,而使項目的修改作業失敗。若要更正此問題,請遵循此程序中的步驟。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
為避免日後需要修正模式規範遵循問題,請在進行部署前事先規劃您的模式,以儘可能減少模式變更。如需更多資訊,請參閱「Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide」。
若標準模式不足以因應您的目錄需求,可以加以延伸。自訂模式時,請遵循下列指示:
儘可能重複使用現有的模式元素。
儘可能減少您為每個物件類別所定義的必要屬性數目。
請不要定義多個相同用途的物件類別或屬性。
儘可能保持模式的單純性。
自訂模式時,請勿在標準模式中修改、刪除或取代屬性或物件類別的任何現有定義。這些動作可能導致無法與其他目錄和 LDAP 用戶端應用程式相容的問題。
請勿修改任何目錄伺服器內部操作屬性。但您可以為外部應用程式建立您自己的操作變數。
一律定義物件類別,而不要使用 objectClass: extensibleObject。目錄伺服器不會對具有物件類別 extensibleObject 的項目執行模式檢查,因此無法限制或檢查項目中所含的屬性。目錄伺服器無法檢查出應用程式中的拼字錯誤,例如將 givenName 屬性類型誤植為 giveName。再者,目錄伺服器也必須假設 extensibleObject 項目所有其他未定義的屬性皆為多值屬性,且使用區分大小寫的字串語法。此外,有些應用程式須依賴具有特定物件類別的項目。一般而言,若您的應用程式必須使用物件類別的延伸,則不應放棄模式管理。此時應建立內含應用程式所需屬性的輔助物件類別。
本節包含有關預設目錄模式與建立自訂屬性與物件類別的資訊。
目錄伺服器隨附之模式的相關說明,位於儲存在 instance-path/config/schema/ 目錄中的檔案集內。
此目錄包含目錄伺服器與相關產品的所有共用模式。LDAP v3 標準使用者與組織模式位於 00core.ldif 檔案中。舊版目錄所使用的配置模式則位於 50ns-directory.ldif 檔案中。
請勿在伺服器執行時修改此目錄中的檔案。
每個 LDAP 物件類別或屬性,都必須指定唯一的名稱與物件識別碼 (OID)。定義模式時,OID 在您的組織中必須是唯一的。一個 OID 即足以因應您所有的模式需求。接著,您可以為屬性與物件類別的此 OID 新增分支。
取得及指定您模式中的 OID 時,須執行下列動作:
從網際網路位址指派機構 (IANA) 或國家機構為您的組織取得 OID。
有些國家/地區已為公司指定 OID。若您的組織尚無 OID,您可以從 IANA 加以取得。
建立 OID 登錄,以便追蹤 OID 指定。
OID 登錄是一份由您自己維護的清單,其中列出您的目錄模式中所使用的 OID 與 OID 說明。OLD 登錄可確保任何 OID 皆不會用於多項用途上。
建立 OID 樹狀結構中的分支以容納模式元素。
以 OID.1 代表屬性,並以 OID.2 代表物件類別,在 OID 分支或您的目錄模式下建立至少兩個分支。若要定義您自己的對應規則或控制,您可以視需要新增分支,如 OID.3。
建立新屬性與物件類別的名稱時,請讓名稱具有意義,以便使用模式。
您可以在自訂元素中加上唯一前綴,以避免自訂模式元素與現有模式元素之間產生命名衝突。以 Example.com Corporation 為例,它可在其各個自訂的模式元素前加上前綴 Example。它也可增加名為 ExamplePerson 的特殊物件類別,以識別其目錄中的 Example.com 員工。
請注意,在 LDAP 中,屬性類型名稱與物件類別名稱均會區分大小寫。應用程式應將其視為區分大小寫的字串。
當現有的物件類別不支援您必須儲存在目錄項目中的所有資訊時,您可以新增物件類別。
有兩種方法可新建物件類別:
建立許多新的物件類別,一一用於需要增加屬性的各個物件類別結構上。
建立單一物件類別,並使其支援您為目錄所建立的所有屬性。您可以將此類型的物件類別定義為 AUXILIARY 物件類別,而加以建立。
假設您的站點必須建立 ExampleDepartmentNumber 與 ExampleEmergencyPhoneNumber 屬性。您可以建立數個允許這些屬性有一些子集的物件類別。您可以建立名為 ExamplePerson 的物件類別,並使其允許 ExampleDepartmentNumber 與 ExampleEmergencyPhoneNumber 屬性。ExamplePerson 的父系將是 inetOrgPerson。接著,您可以建立名為 ExampleOrganization 的物件類別,並使其也允許 ExampleDepartmentNumber 與 ExampleEmergencyPhoneNumber 屬性。ExampleOrganization 的父系將是 organization 物件類別。
新的物件類別會以 LDAP v3 模式顯式,如下顯示:
objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.3 NAME 'ExamplePerson' DESC 'Example Person Object Class' SUP inetorgPerson STRUCTURAL MAY (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) ) objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.4 NAME 'ExampleOrganization' DESC 'Example Organization Object Class' SUP organization STRUCTURAL MAY (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
此外,您也可以建立允許上述所有屬性的單一物件類別。接著,您即可對要使用屬性的任何項目使用此物件類別。單一物件類別將如下所示:
objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.5 NAME 'ExampleEntry' DESC 'Example Auxiliary Object Class' SUP top AUXILIARY MAY (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
新的 ExampleEntry 物件類別會以 AUXILIARY 標示,表示無論其結構物件類別為何,皆可用於任何項目。
在決定如何實作新的物件類別時,請考量下列事項。
多重 STRUCTURAL 物件類別將會導致需建立及維護更多模式元素。
一般而言,會將元素的數量保持在較小的情況,而不需太多的維護。但若您打算在模式中增加二或三個物件類別,使用單一物件類別可能會較為容易些。
多重 STRUCTURAL 物件類別在資料設計上的要求較為慎重與嚴苛。
嚴苛的資料設計將迫使您考量在物件類別結構中納入資料各個部分。這項限制可能確實有幫助,但也可能綁手綁腳。
單一 AUXILIARY 物件類別可在您需要將資料放置到多種類型的物件類別結構上時,簡化所需的資料設計。
例如,假設您在人員與群組項目上皆需要 preferredOS。您可以僅建立單一物件類別以允許此屬性。
請設計與實際物件及群組元素相關,且可形成合理群組的物件類別。
請避免為新的物件類別設定必要屬性。
必要屬性會使您的模式缺乏彈性。當您建立新的物件類別時,請設定允許的屬性,而不要設定必要屬性。
定義新的物件類別後,您必須決定物件類別所允許及要求的屬性,以及此物件類別繼承自哪些或哪個物件類別。
當現有的屬性不支援您必須儲存在目錄項目中的所有資訊時,您可以新增屬性。請儘可能使用標準屬性。請搜尋原本即已存在於預設目錄模式中的屬性,並使用與新的物件類別相關的屬性。
例如,您可能會發現,您想儲存到人員項目上的資訊,超出 person、organizationalPerson 或 inetOrgPerson 物件類別所支援的範圍。您想在目錄中儲存生日時,標準目錄伺服器模式中卻沒有屬性存在。您可以建立名為 dateOfBirth 的新屬性。請定義允許此屬性的新輔助類別,以允許此屬性用於代表人員的項目上。
建立自訂模式檔案時,請留意下列事項,尤其是使用複寫時更需特別注意:
新增模式元素時,所有屬性皆須先完成定義,方可用於物件類別中。您可以在相同的模式檔案中定義屬性與物件類別。
您所建立的每個自訂屬性或物件類別,應定義於單一的模式檔案中。此做法可防止伺服器在載入最新建立的模式時,覆寫了任何先前的定義。目錄伺服器在載入模式檔案時,會先依據數字順序,再依字母順序。
手動定義新的模式定義時,一般理想的做法是將這些定義增加到 99user.ldif 檔案中。
當您使用 LDAP 更新模式元素時,新的元素會自動寫入 99user.ldif 檔案中。因此,您在自訂模式檔案中所做的任何其他模式定義變更,均可能遭到覆寫。僅使用 99user.ldif 檔案,可防止模式元素重複的情況,以及模式變更遭到覆寫的風險。
由於目錄伺服器會依據字母數字順序載入模式檔案,且會先載入數字,因此您應以下列格式為自訂模式檔案命名:
[00-99] filename.ldif
此數字高於任何已定義的目錄標準模式。
若您以低於標準模式檔案的數字為模式檔案命名,伺服器即可能在載入模式時發生錯誤。此外,所有標準屬性與物件類別皆會在您的自訂模式元素完成載入後,才會載入。
請確定自訂模式檔案的名稱在數字與字母上皆未高於 99user.ldif,因為目錄伺服器會使用最高順序的檔案進行其內部模式管理。
例如,若您建立模式檔案,並將其命名為 99zzz.ldif,則在您下次更新模式時,所有 X-ORIGIN 值為 'user defined' 的屬性,都將寫入 99zzz.ldif 中。結果將造成兩個 LDIF 檔案含有重複的資訊,而 99zzz.ldif 檔案中的部分資訊可能會遭清除。
根據一般通則,應以下列兩個項目識別您所增加的自訂模式元素:
自訂模式檔案之 X-ORIGIN 欄位中的 'user defined';
更具說明性的標籤,如 X-ORIGIN 欄位中的 'Example.com Corporation defined',以便讓其他管理員更容易瞭解自訂模式元素。例如,X-ORIGIN ('user defined' 'Example.com Corporation defined')。
若您以手動方式增加模式元素,且未使用 X-ORIGIN 欄位中的 'user defined',模式元素在 DSCC 中即會處於唯讀狀態。
當您使用 LDAP 或 DSCC 增加自訂模式定義時,伺服器即會自動增加 'user defined' 值。但若您未在 X-ORIGIN 欄位中加入更多說明性的值,日後就可能就難以瞭解此模式的相關用途。
請手動將自訂模式檔案傳播到所有的伺服器上,因為這些變更不會自動複寫。
當您變更目錄模式時,伺服器會留存時間戳記,以記錄變更模式的時間。在每個複寫階段作業開始時,伺服器會將其時間戳記與其用戶的時間戳記進行比較,然後在必要時發送模式變更。對於自訂模式檔案,伺服器只會保存一個時間戳記,而此戳記與 99user.ldif 檔案相關聯。這表示,您對 99user.ldif 以外的檔案所做的任何自訂模式檔案變更或增加,都不會進行複寫。因此,您必須將自訂模式檔案傳播到所有其他的伺服器上,以確保所有模式資訊均存在於拓樸各處。
本節說明如何透過 LDAP 建立、檢視及刪除屬性類型。
cn=schema 項目具有多值屬性 attributeTypes,此屬性含有目錄模式中各種屬性類型的定義。您可以使用 ldapmodify(1) 指令增加至這些定義。
新的屬性類型定義,以及您對使用者定義的屬性類型所做的變更,都會儲存在 99user.ldif 檔案中。
對於每個屬性類型定義,您必須至少提供一個 OID 以定義您新的屬性類型。請考慮對新的屬性類型至少使用下列元素:
屬性 OID。對應至您屬性的物件識別碼。OID 是一個可唯一識別模式物件的字串,通常為小數點十進位數字。
如需嚴格的 LDAP v3 規範遵循,則必須提供有效數值 OID。若想進一步瞭解 OID,或要為您的企業申請前綴,請將電子郵件寄至 IANA (網際網路位址指派機構) iana@iana.org,或造訪 IANA 網站。
屬性名稱。對應至屬性的唯一名稱。也稱為其屬性類型。屬性名稱必須以字母開頭,且只能包含 ASCII 字母、數字與連字符。
屬性名稱可包含大寫字母,但 LDAP 用戶端不會以大小寫分辨屬性。以區分大小寫的方式處理屬性名稱時,應遵循 RFC 4512 第 2.5 款的規定。
您可以選擇性地為屬性類型加入替代屬性名稱,亦即別名。
屬性說明。以簡短的說明性文字說明屬性的用途。
語法。供 OID 參照,用以說明屬性將包含的資料。
屬性語法及其 OID 均列載於 RFC 4517 中。
允許的值數目。屬性預設為多值屬性,但您也可以將屬性限定為單一值。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
根據 RFC 4517 中所指定的語法,備妥您的屬性類型定義。
使用 ldapmodify(1) 指令,增加您的屬性類型定義。
請注意,目錄伺服器會將 X-ORIGIN 'user defined' 增加到您所提供的定義中。
下列範例使用 ldapmodify 指令,增加使用「目錄字串」語法的新屬性類型。
$ cat blogURL.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogURL.ldif Enter bind password: modifying entry cn=schema $ |
在生產環境中,您必須提供有效且唯一的 OID,而非 1.2.3.4.5.6.7。
cn=schema 項目具有多值屬性 attributeTypes,此屬性含有目錄模式中各種屬性類型的定義。您可以使用 ldapsearch(1) 指令讀取這些定義。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
下列指令可顯示所有屬性類型的定義:
$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes |
-T 選項可使 ldapsearch 指令不會進行 LDIF 換行,而使您能夠更容易地使用 grep 或 sed 之類的指令處理輸出。若您接著透過 grep 指令對此指令的輸出使用管道符號,就只能檢視目錄模式內使用者定義的延伸。例如:
$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes | grep "user defined" attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) |
cn=schema 項目具有多值屬性 attributeTypes,此屬性含有目錄模式中各種屬性類型的定義。您可以使用 ldapmodify(1) 指令刪除具有 X-ORIGIN 'user defined' 的定義。
模式係由 LDAP 檢視定義於 cn=schema 中,因此您可以使用 ldapsearch 與 ldapmodify 公用程式,以線上方式檢視及修改模式。但您只能刪除在 X-ORIGIN 欄位中具有 'user defined' 值的模式元素。伺服器將不會刪除其他定義。
您對使用者定義的屬性所做之變更,會儲存在 99user.ldif 檔案中。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
檢視所要刪除之屬性類型的定義。
如需詳細資訊,請參閱檢視屬性類型。
使用 ldapmodify(1) 指令,刪除模式中所出現的屬性類型定義。
下列指令將刪除範例 11–1 中所建立的屬性類型:
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: attributeTypes attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) ^D |
請注意,您必須納入 X-ORIGIN 'user defined' 這項由目錄伺服器增加,而用以將此模式定義歸類為延伸的屬性。
本節說明如何透過 LDAP 建立、檢視及刪除物件類別。
cn=schema 項目具有多值屬性 objectClasses,此屬性含有目錄模式中各種物件類別的定義。您可以使用 ldapmodify(1) 指令增加至這些定義。
新的物件類別定義,以及您對使用者定義的物件類別所做的變更,都會儲存在 99user.ldif 檔案中。
若要建立數個繼承自其他物件類別的物件類別,您必須先建立父系物件類別。若您的新物件類別使用自訂屬性,則也必須先定義這些屬性。
對於每個物件類別定義,必須至少提供一個 OID。請考慮對新的物件類別至少使用下列元素:
物件類別 OID。對應至您物件類別的物件識別碼。OID 是一個可唯一識別模式物件的字串,通常為小數點十進位數字。
如需嚴格的 LDAP v3 規範遵循,則必須提供有效數值 OID。若想進一步瞭解 OID,或要為您的企業申請前綴,請將電子郵件寄至 IANA (網際網路位址指派機構) iana@iana.org,或造訪 IANA 網站。
物件類別名稱。對應至物件類別的唯一名稱。
父系物件類別。此物件類別從中繼承屬性的現有物件類別。
若不讓此物件類別繼承自其他特定物件類別,請使用 top。
一般而言,若要為使用者項目新增屬性,父系將會是 inetOrgPerson 物件類別。若要為公司項目新增屬性,父系通常是 organization 或 organizationalUnit。若要為群組項目新增屬性,父系通常是 groupOfNames 或 groupOfUniqueNames。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
根據 RFC 4517 中所指定的語法,備妥您的物件類別定義。
使用 ldapmodify(1) 指令,增加您的物件類別定義。
請注意,目錄伺服器會將 X-ORIGIN 'user defined' 增加到您所提供的定義中。
下列範例使用 ldapmodify 指令新增物件類別。
$ cat blogger.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogger.ldif Enter bind password: modifying entry cn=schema $ |
在生產環境中,您必須提供有效且唯一的 OID,而非 1.2.3.4.5.6.8。
cn=schema 項目具有多值屬性 objectClasses,此屬性含有目錄模式中各種物件類別的定義。您可以使用 ldapsearch(1) 指令讀取這些定義。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
下列指令可顯示所有物件類別的定義:
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses |
-T 選項可使 ldapsearch 指令不會進行 LDIF 換行,而使您能夠更容易地使用 grep 或 sed 之類的指令處理輸出。若您接著透過 grep 指令對此指令的輸出使用管道符號,就只能檢視目錄模式內使用者定義的延伸。例如:
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses | grep "user defined" objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) $ |
cn=schema 項目具有多值屬性 objectClasses,此屬性含有目錄模式中各種物件類別的定義。您可以使用 ldapmodify(1) 指令刪除具有 X-ORIGIN 'user defined' 的定義。
模式係由 LDAP 檢視定義於 cn=schema 中,因此您可以使用 ldapsearch 與 ldapmodify 公用程式,以線上方式檢視及修改模式。但您只能刪除在 X-ORIGIN 欄位中具有 'user defined' 值的模式元素。伺服器將不會刪除其他定義。
您對使用者定義的元素所做的變更,會儲存在 99user.ldif 檔案中。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
檢視要刪除之物件類別的定義。
如需詳細資訊,請參閱檢視物件類別。
使用 ldapmodify(1) 指令,刪除模式中所出現的物件類別定義。
下列指令將刪除範例 11–4 中所建立的物件類別:
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) ^D |
請注意,您必須納入 X-ORIGIN 'user defined' 這項由目錄伺服器增加,而用以將此模式定義歸類為延伸的屬性。
當您新增屬性至模式時,必須建立含有新屬性的新物件類別。雖然直接將屬性增加到已含有您所需之大部分屬性的現有物件類別中,似乎是很方便的做法,但此舉卻會危及與 LDAP 用戶端之間的互通操作。
目錄伺服器與現有 LDAP 用戶端之間的互通操作,依賴於標準 LDAP 模式。若您變更標準模式,也將在升級伺服器時遇到困難。同理,您亦不可刪除標準模式元素。
目錄伺服器模式儲存在 cn=schema 項目的屬性中。與配置項目相同,這也是可在伺服器啟動期間從檔案讀取的 LDAP 模式檢視。
您用以延伸目錄伺服器模式的方法,取決於您是否要控制模式延伸儲存時所使用的檔案名稱。此外也取決於您是否要透過複寫發送變更給用戶。請參閱下表,以根據您特定的情況決定所要執行的程序。
表 11–1 延伸模式的方式
作業 |
指示 |
---|---|
您不使用複寫。想增加自訂模式檔案,藉以延伸模式。 | |
您希望透過 LDAP 延伸模式。 | |
您要使用複寫。想在所有伺服器上保留自訂模式檔案的檔案名稱。 | |
您要使用複寫。想在主伺服器複本上增加自訂模式檔案,藉以延伸模式。接著,要讓複寫機制將模式延伸複製到用戶伺服器上。 |
如需有關物件類別、屬性與目錄模式的更多資訊,以及如何延伸模式的相關指示,請參閱「Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide」中的「Designing a Directory Schema」。如需有關標準屬性與物件類別的資訊,請參閱「Sun Java System Directory Server Enterprise Edition 6.1 Man Page Reference」。
本節針對可延伸目錄模式的多種方法提供相關資訊。
模式檔案是位於 instance-path/config/schema/ 中的 LDIF 檔案。instance-path 對應於目錄伺服器實例所在的檔案系統目錄。例如,實例可能位於 /local/ds/ 中。這些檔案可定義標準模式,供目錄伺服器以及所有依賴目錄伺服器的伺服器使用。如需有關檔案與標準模式的說明,請參閱「Sun Java System Directory Server Enterprise Edition 6.1 Reference」與「Sun Java System Directory Server Enterprise Edition 6.1 Man Page Reference」。
模式檔案只會在伺服器啟動時讀取一次。檔案的 LDIF 內容會增加至 cn=schema 中模式的常駐記憶體 LDAP 檢視。模式定義的順序是很重要的,因此模式檔案名稱的開頭處會加上號碼,並依據字母數字順序載入。只有安裝期間所定義的系統使用者,才能寫入此目錄中的模式檔案。
直接在 LDIF 檔案中定義模式時,請勿於 X-ORIGIN 欄位中使用 'user defined' 值。此值必須保留給透過 cn=schema 的 LDAP 檢視所定義,同時出現在檔案 99user.ldif 中的模式元素使用。
99user.ldif 檔案含有其他 ACI,供 cn=schema 項目與所有使用指令行或 DSCC 增加的模式定義使用。新增模式定義時,即會覆寫 99user.ldif 檔案。若要修改此檔案,您必須立即重新啟動伺服器,以確保更新目前的變更。
請勿修改其他模式檔案中所定義的標準模式。但您可以新增檔案以定義新的屬性與物件類別。例如,若要在多部伺服器上定義新的模式元素,您可以先將元素定義於名為 98mySchema.ldif 的檔案中,再將此檔案複製到所有伺服器的模式目錄中。接著您必須重新啟動所有伺服器,以載入新的模式檔案。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
建立您自己的模式定義檔案,如 98mySchema.ldif。
模式檔案中的定義所使用之語法,說明於 RFC 4517 中。
(可選擇) 若此伺服器是可傳送更新至其他伺服器的主伺服器複本,請將您的模式定義檔案複製到複寫拓樸中的每個伺服器實例上。
複寫機制無法偵測您對含有模式的 LDIF 檔案所做的任何直接變更。因此,即使在重新啟動主伺服器後,您的變更仍不會複寫至用戶。
請重新啟動已複製了模式定義檔案之每個目錄伺服器實例。
您的變更將在伺服器重新啟動後生效,並重新載入模式定義。
模式係由 LDAP 檢視定義於 cn=schema 中,因此您可以使用 ldapsearch 與 ldapmodify 公用程式,以線上方式檢視及修改模式。但您只能修改在 X-ORIGIN 欄位中具有 'user defined' 值的模式元素。伺服器會拒絕對其他定義的任何修改。
新的元素定義,以及您對使用者定義的元素所做的變更,都會儲存在 99user.ldif 檔案中。
您可以使用 DSCC 執行此作業。如需有關資訊,請參閱目錄服務控制中心介面與 DSCC 線上說明。
從指令行修改模式定義很可能會發生錯誤,因為您必須一字不漏地鍵入冗長的值。但您可以在更新目錄模式時所需的程序檔中使用此功能。
使用 ldapmodify(1) 指令,增加或刪除個別的 attributeTypes 屬性值。
使用 ldapmodify(1) 指令,增加或刪除個別的 objectClasses 屬性值。
若要修改其中一個值,必須先刪除該特定值,再將其增加為新值。之所以必須這麼做,是因為這些屬性是多值屬性。如需詳細資訊,請參閱修改多值屬性的某個值。
如需有關自訂模式檔案的資訊,請參閱使用自訂模式檔案延伸模式。下列程序說明如何使用複寫機制,將模式延伸傳播至拓樸中的所有伺服器。
在部分程序中,您可使用 DSCC 來執行本作業。如需其它資訊,請參閱目錄服務控制中心介面以及 DSCC 線上說明。其他部份的程序僅可使用指令行進行。
以下列其中一種方式備妥您的模式延伸:
模式檔案中的定義所使用之語法,說明於 RFC 4517 中。
在存放模式定義檔案的主伺服器上,執行 schema_push 指令。
此程序檔不會實際將模式發送至複本。此程序檔會將特殊的屬性寫入模式檔案中,使模式檔案在載入時隨即進行複寫。如需更多資訊,請參閱 schema_push(1M) 線上手冊。
重新啟動存放模式定義檔案的主伺服器。
複寫機制無法偵測您對含有模式的 LDIF 檔案所做的任何直接變更。當您在執行 schema_push 後重新啟動伺服器時,伺服器會載入所有模式檔案,接著複寫機制會將新的模式複寫至用戶。
每當您在兩部伺服器之間配置一或多個尾碼的複寫時,模式定義也會自動複寫。模式定義的自動複寫可確保所有複本均具有完整且相同的模式,並以此模式定義所有可複寫至用戶的物件類別與屬性。主伺服器因此也含有主伺服器模式。
但模式複寫並不是即時的,即使您透過 LDAP 修改模式也是如此。目錄資料更新時,或在模式修改後第一次啟動複寫階段作業時,皆會觸發模式複寫。
若要對所有複本執行模式,至少必須對所有主伺服器啟用模式檢查。在執行 LDAP 作業的主伺服器上檢查模式時,模式並不需在用戶更新後進行檢查。為提昇效能,複寫機制會略過對用戶複本的模式檢查。
請勿關閉集散中心與專屬用戶的模式檢查。模式檢查並不會影響用戶的效能。請持續開啟模式檢查,以指出複本內容是否符合其模式。
主伺服器會在用戶初始化期間自動將模式複寫至用戶。無論何時,只要模式透過 DSCC 或指令行工具進行修改,主伺服器也將自動複寫模式。依預設會複寫整個模式。任何在用戶上尚不存在的其他模式元素,皆會在用戶上建立,並儲存於 99user.ldif 檔案中。
例如,假設主伺服器在啟動時於 98mySchema.ldif 檔案中含有模式定義。此外同時假設,您接下來將定義與其他伺服器 (主伺服器、集散中心或專屬用戶) 的複寫協議。當您後續由此主伺服器初始化複本時,複寫的模式將含有來自 98mySchema.ldif 的定義,但定義會儲存在複本伺服器上的 99user.ldif 中。
於用戶初始化期間複寫模式後,若在主伺服器上修改 cn=schema 中的模式,也將使整個模式複寫至用戶。因此,透過指令行公用程式或 DSCC 對主伺服器模式所做的任何修改,均會複寫至用戶。這些修改會儲存在主伺服器的 99user.ldif 中,而透過前述的相同機制,這些修改亦可儲存在用戶的 99user.ldif 中。
請考量下列在複寫環境中維護模式一致性的指示:
請勿修改用戶伺服器上的模式。
修改用戶伺服器上的模式可能會導致複寫錯誤。這是因為用戶上的模式差異,可能會導致來自供應者的更新不符合用戶上的模式。
在多重主伺服器複寫環境中,請修改單一主伺服器上的模式。
當您修改兩部主伺服器的模式時,最新更新的主伺服器會將其模式版本傳播至用戶。用戶上的模式因此可能會變得與其他主伺服器上的模式不一致。
配置部分複寫時,需同時考量下列事項:
當供應者在部分複寫配置中發送模式時,部分用戶複本上的模式將是主伺服器複本之模式的副本。因此,模式將可能無法對應於所套用的部分複寫配置。
一般而言,目錄伺服器會依照模式中的定義複寫每個項目的所有必要屬性,以避免違反模式。當您配置部分複寫而排除必要屬性時,必須停用模式檢查。
若對部分複寫啟用模式檢查,可能無法以離線方式初始化複本。若排除必要屬性,目錄伺服器將不允許您從 LDIF 載入資料。
若您對部分用戶複本停用了模式檢查,部分用戶複本所在的整個伺服器實例,都將不會執行模式檢查。因此,請避免將相同伺服器實例上的供應者複本配置為部分用戶。
複寫機制每次複寫模式時,預設會將整個模式傳送至用戶。以下兩種情況不適合將整個模式傳送至用戶:
使用 DSCC 或從指令行對 cn=schema 所進行的修改,僅限於使用者定義的模式元素,所有標準模式皆不會變更。若您經常修改模式,在每次傳送大量的未變更模式元素時,都會使得效能受到影響。您可以僅就使用者定義的模式元素進行複寫,而提昇複寫與伺服器的效能。
當目錄伺服器上的主伺服器複寫至 Directory Server 5.1 上的用戶時,這些版本的配置屬性模式將不會相同,而會產生衝突。在此情況下,您必須僅就使用者定義的模式元素進行複寫。
目錄伺服器使用 11rfc2307.ldif 模式檔案。此模式檔案符合 RFC 2307。
Directory Server 5.2 之前的目錄伺服器版本使用 10rfc2307.ldif 模式檔案。
無法使用 DSCC 執行此作業。請依照此程序中的說明使用指令行。