若標準模式不足以因應您的目錄需求,可以加以延伸。自訂模式時,請遵循下列指示:
儘可能重複使用現有的模式元素。
儘可能減少您為每個物件類別所定義的必要屬性數目。
請不要定義多個相同用途的物件類別或屬性。
儘可能保持模式的單純性。
自訂模式時,請勿在標準模式中修改、刪除或取代屬性或物件類別的任何現有定義。這些動作可能導致無法與其他目錄和 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 以外的檔案所做的任何自訂模式檔案變更或增加,都不會進行複寫。因此,您必須將自訂模式檔案傳播到所有其他的伺服器上,以確保所有模式資訊均存在於拓樸各處。