Michael Donnelly
設計LDAP目錄樹
原著：Michael Donnelly
翻譯：Beta Xmu/Grind
原文：http://www.ldapman.org/articles/tree_design.html
??乍看之下，設計一個LDAP伺服器的目錄拓撲好像是很麻煩的事。但是只要預先計劃一下，那這件事就變得相對簡單了。此文中，我們將分別討論每個你必須考慮的主題：
什麼是目錄樹？它們看起來像什麼？
選擇你的目錄的基準DN
一個目錄樹的例子
規劃你的目錄拓撲
??這是為sendmail.net關於LDAP這個話題的一系列文章中的第二篇。這個系列作為一個整體將為帶著你從「只是看一下」到配置一個可以應用和服務的目錄的LDAP基礎集的整個過程。這個系列的其它文章可以在http://www.ldapman.or/articles 上找到。你可以看一下「An Introduction to LDAP」
的第一和第二部分，在ldapman.org上也可以找到。
什麼是目錄樹？
??簡單來說，一個目錄樹就是一個規定儲藏各種不同類型信息的容器的組織方法。你可以把它看做是你的數據的歸檔系統。
??LDAP目錄伺服器分層保存著它們的信息，和UNIX的文件系統很像。這些層次規定從邏輯上把一定條目的信息分組（或者劃分子組）。這些組在許多情況下很有用：
為一個或多個組的數據在其它伺服器或站點上授權認證
數據複製
安全和訪問控制
可伸縮性
??參考下面這個非常簡單的目錄樹的例子。我將任何無關的信息都拿掉了，這樣我們就能夠把注意力集中在樹的本身。
??在最上層，我們有個root，這是每個目錄樹的起點。root下面的是兩個類別，每個下面還有兩個子類別。注意Employees是按照部門分的，Customers是按照地區分的。如何分組是沒有限制的。雖然我在這裡只是每層顯示了兩個組，但是如果你需要的話，你的目錄里的任何一層裡面都可以有許多組。
選擇你的目錄基準DN
??在開始之前，我要說這裡沒有一種正確的方法來設置目錄結構。你選擇的設計可能看起來和其它你看到的相似，下次就可能差別很大。你如果想測試你的目錄樹的設計，這裡有個主要的標準：是否有效的適合你當前的和計劃的需要？如果是，你就是正確的。
??目錄的最頂層，即上面提及得目錄樹的root，是目錄樹的基準，也就是所謂的基準標識名（Base Distinguished Name），或者基準DN（base DN）。原則上，你可以選擇你的基準DN的格式，我推薦一個當前最流行的格式（你可能需要借這個機會更新對改變基準DN格式的記憶）。
??追溯到1998年，RFC2247把DNS域名編碼作為LDAP（和X.500）的標識名的基礎。從那時起，越來越多的地方使用這種格式。如果你正在計劃整合Microsoft Active Directory，這是你唯一能使用的方法，所以不要為選擇操心了??Redmond已經為你做好了這個選擇。
??這種格式是非常簡單的。讓我們假設你的公司的Intenet域名是foobar.com。RFC2247把這個DNS域名轉換為下面的DN：
dc=foobar，dc=com
??這個dc指「Domain Component」，注意DNS名字的每個部分都按順序描述。
??那麼你的基準DN是什麼呢？假設你公司的Internet域名以.com結尾，你最好的選擇是dc=com。如果你的Internet域名以.net結尾，那麼基準DN使用dc=net。知道這個方法了嗎？如果你公司現在或者將來都不會上網，那你可以選擇dc=local。
??在基準DN下面，你就有一個和你DNS域名剩下部分相應的條目。例如，foobar.com的上幾層看起來就像這樣：
??讓我們假設foobar.com公司準備與wocket.com和gizmo.com合併。沒問題！感謝你的先知先覺，你的目錄結構可以適應在公司命運中的突然變化。你只需要簡單的在dc=com下面加入dc=work和dc=gizmo條目。那麼你目錄的上幾層就像這樣：
一個目錄樹的例子
??你初始的目錄結構越好，以後需要重新修補的就越少。通常來說，你設計你的目錄要保證個別的條目不必從一棵樹移到另一個棵。你可能會發現一個分佈均勻層次較淺的結構工作得最好，樹的每個分枝包含的對象根本不太可能移動很多。考慮下面的問題，一個虛構的foobar.com的目錄樹。他們花一年時間分階段鋪開他們的LDAP目錄，漸漸的基於LADP的服務越來越多。
??注意每個分支是由ou=
的形式組成，OU表示Organizational Unit，在以前X.500時，OU被用來描述你的公司的組織結構。你今天所做好的，但是每次公司部門結構改變時，你不得不重新組織你的目錄樹，為什麼要給自己帶來額外的工作呢？相反的，foobar採用了簡單的途徑：他們把工作關係，部門信息，和類似的數據保存在每個僱員的LDAP條目里。他們依然存儲了同樣的數據，但是少了很多工作。
ou=employees
??foobar.com的所有員工都這裡列出。既然隨著時間的改變分組方案不可避免要改變，Foobar控制住了任何形式的企圖把這個分組方案改變成小組的趨勢：人們改變了職位，部門，甚至從一個洲到另一個洲。取而代之，每個員工的位置，部門和公司分配信息都被保存在員工的LDAP條目里，包括email，公共HR信息，和NIS信息。
ou＝ITaccounts
??當foobar.com把NIS password和mail路由信息都放到LDAP里時，那將會有一點困惑。你如何處理諸如root，nobody，www等賬號呢？像這些的IT accounts共享了許多與員工賬號相同的屬性（密碼，uid和gid，email地址，等等）但是和一般人們有根本上的不同。（你上次是什麼時候查找root的電話號碼？）為了保持員工信息的唯一性，他們創建一個特別的OU來存放這種賬號。LDAP連接控制可以防止非IT職員讀到這些數據。
ou＝customers
??Foobar.com把他們的顧客聯繫信息放到LDAP目錄里。這樣每個僱員都可以查詢這個目錄來找到顧客的銷售報告，支持聯繫信息，等等。很少有顧客從一個洲移到另一個洲。
??當公司成長時，他們可能希望把地域性的伺服器之間的信息做個拷貝。因為他們已經把客戶的信息分到各個小組裡去，所以他們能整理這個拷貝來適應每個站點的銷售人員的需要。
ou=locations
??常常想知道你New York辦公室的地址嗎？或者是「Coffe Stain Conference Romm」的電話號碼？是不是常被人叫在上午10點去「Scenic View」會議室開會，但你不知道怎麼樣去找到那個地方？
??那麼，這樣事不會發生在foobar.com的員工身上，他們把所有有關他們的辦公室，會議室，和其它類似的信息都放在LDAP目錄里。公司的基於LDAP的電話簿可以很快的很簡單的提取這些信息。
ou=devices
??Foobar同時也決定把他們的計算機，印表機，和其它計算機設備的信息保存在LDAP裡面。這也讓他們的系統管理員可以把他們網路的每個設備的主機名、IP地址、MAC地址、當前用戶和組、標記、系列號、結構型號、操作系統名稱版本、位置和描述信息都保存在一個地方。
??一個自定義的Web GUI允許系統管理員和公司的資產管理員輸入，修改和查詢這些信息。一些自定義的腳本可以用來直接從LDAP產生DNS和NIS的主機映射。資產管理工具可以自動定時更新硬體信息，這樣你不費吹灰之力也能保證這些信息是最新的。
??但是為什麼把所有路由器、交換機、印表機、個人電腦、蘋果機和UNIX系統信息都放在一個OU里呢？因為他們都共享同類型的信息。一個UNIX伺服器和一個印表機有很大不同，但是保存這種類型的信息在本質上是一樣的。如果有個問題：「給我所有Windows PCs的列表」，他們就很容易通過OS Name來查詢到。
??好的，但是如果是這樣的問題：「給我所有laptop的列表」？Foobar.com實現了一些自定義的LDAP屬性來讓他們來跟蹤每個設備的「Machine Class」和「Machine SubClass」屬性，以提供他們所需要的粒度。「Machine Class」的值包括了Netgear，Printer，Windows，Mac，UNIX。「Machine SubClass」包括了router，switch，inkjet，laser，desktop，laptop，workstation，server。這些類和子類信息的集合可以靈活和精確的在許多情況下跟蹤所有的網路設備。
規劃你的目錄拓撲
??現在你可能想知道怎樣設計的自己的目錄了吧，讓我們來看一個例子。在上面的例子里，foobar.com用了五個主要的類別，ou=customers再分成子類。（記住，這只是一個例子，對每個公司來說它不一定是最好的）。實際上，你可能想增加一個類別來處理NIS組的信息，郵件列表信息等等。
??那麼那些OU適合你呢？我讓你看一下設計的過程。畢竟，你正在建立你的LDAP伺服器來適應你自己情況的需要。上面的例子應該可以幫助你對如何組織你的數據有個感覺。這兒有一些比較廣泛的指導方針來幫助你完成這個過程：
如果有可能，要避免一個不得不修改的目錄樹設計。設法不要讓目錄樹基於公司組織圖，一個當前的商業模式或者相似的東西。
你要避免從一個OU向另一個OU移動LDAP記錄。如果你可以預見這會經常發生在你的設計中，設法去重新設計。你能把兩個或者更多的分支整合成一個嗎？你能用一個屬性－location，department－去完成同樣的目的嗎？
你是否有在某些關係上相似的數據，但是如何使用這些數據卻有很大的不同？你能為每種類型的條目創建獨立的OU嗎？如果條目無論什麼理由都沒有必要從一個OU移動到另一個OU，那麼保持這些組是分開的。（考慮上面的例子，ou＝Employees和ou＝ITaccounts）
如果你要在同一點複製數據，考慮是否你能把一個OU分成按照你用戶的需要的子OU。重新考慮這樣做是否會導致一個對象從一個OU移動到另一個OU。（在上面的例子里，customers的OU要分類是正常選擇，employees的OU則不是）
如果你需要隱藏目錄中的一部分數據，不管是為安全原因或者只是簡單的防止混淆，你可以用一個OU來做這個事。如果這違反了上面主要方針的任何一條，那麼你就不得不判斷自己要做什麼－安全是棘手的話題，有不同的處理方法。
??這兒有一些你可能考慮存放在LDAP目錄的數據對象的比較廣泛的指導方針。根據你的需要，每個都可以分成單獨的OU。
員工信息
顧客信息，新老顧客
當地飯店的電話號碼和描述，taxi服務，等等
會議室，辦公場所信息，等等
LCD放映機,flip chars,和其它攜帶型「會議室」設備
計算機：桌面電腦,便攜電腦,伺服器,印表機,網路設備
郵件列表
NIS group map
NIS netgroup map
看起來很簡單吧？但是不要忽略了下面這些：
NIS password map。這個map保存了個別員工的信息。你能夠分析這個文件和保存每個用戶login name，password，uid和gid numbers，login shell，和home directories作為在ou＝employees和ou＝Itaccounts下的個別的LDAP條目的用戶特定的屬性。
Organizational charts。Org charts本質上來說反映了每一個員工的job title，manager，department，和（或者）business unit。通過你的org chart和每個員工單獨記錄的相關信息的分析。你總可以從保存在目錄里的一系列managers來得出公司的org chart。
NIS aliases map。Aliases map保護了許多不同類型的信息，個人的mail routing信息和交替的email地址都要作為每個員工的LDAP條目的部分來保存。Mailing list 信息能被保存在自己的OU里，如cetera。我有一整篇文章來描述在LDAP中存放email，所以請耐心等待。
??最後，我希望你覺得這篇文章對你有用。如果你有任何意見或者問題，請發email: Donnelly@ldapman.org
Michael Donnelly
9 may 2000
