BUG's Living Diary

蟲的生活日誌

十一月 30, 2005 • 6:49 午後 0

拜託

你可以狠狠的拒絕我
你可以狠狠的對我說不再是朋友
你可以把所有欠我的東西還給我

如果你還是要用現在的態度面對我

我不曉得我能容忍什麼

容忍對你做的一切不計較成果
容忍你我不再只是原來的朋友
容忍你我的虧欠化為烏有

拜託別再這樣折磨我

我應該讓這一切隨著時間流走

—–

Filed under: 蟲的喜怒哀樂

• 12:28 am 0

現實與長遠

專題討論著, 開始聊起一些有的沒的了
我不得不配服 Cobol 還真能聊, 什麼事他都有辦法講

其中談到了有一個話題, 就是眼光的長遠

在現實的生活中, 不免會遇到許許多多這樣的問題
不僅僅是個人, 團體, 甚至一個國家執政方式

太多人只重視一時的短利, 而忽略了長久的利益

從讀書來看, 從一個團隊來看, 從一個政策的方針來看
都能看出一些端倪

讀書重的是成績, 還是實質的效益?

團隊重的是傳承, 還是一時的功與利?

國家的興衰, 看的出政策的好壞

俗話說的好大智若愚

另一個話題

思考的原創性
事情並不是贊同的人多就一定對, 以訛傳訛
觀念並不是書寫的就一定對, 死讀書, 讀死書

思考, 為的不僅僅是單純的堅持, 更是為了要証明
不管是對還是錯, 你都能吸收這樣的結果得到一個更好的答案
yeah, 太多人重視的是 “對” 與 “錯”，結果並不代表什麼
而是你的思考觀點

嘗試思考創新
我所認為的原創性三大元素
—–

Filed under: 蟲的喃喃自語

十一月 25, 2005 • 2:50 午後 0

LDAP, Lightweight Directory Access Protocol

LDAP, Lightweight Directory Access Protocol
輕量級名錄存取協定

Author: Cwlin
Date: 2005-11-25

何謂 LDAP，Lightweight Directory Access Protocol 輕量級名錄存取協定
乍看之下，你可能不了解，但是舉個遍及全世界的例子，你一定能懂，那就是 DNS，
Domain Name System 網域名稱系統，LDAP 運用了與 DNS 相同的名錄服務，
儘管型式上的不同，但名錄服務仍包含了許多優點。

到此為止，你一定還不知道 LDAP 是在做什麼的，在這裡舉一個最常見的例子
即是認証服務，使用者名稱、密碼的認証，這樣的例子，我們可以知道在 LDAP
上需要儲存帳號與密碼，依據這些帳號，擴充資訊，可讓各種不同的服務
如：Samba, Mail，使用同一份的帳號資料，這樣你可以了解了吧!

“透過同一份帳號資訊使用者可以存取各種不同的服務”

從這個例子我們可以看出，LDAP 有以下的特色：

* 高度的最佳化，快速的存取效率

* 可分散儲存資訊，由各地不同的管理者管理，顯而易見的即是 DNS

* 可自由訂定儲存的資訊類型，以符合使用需求

* 擁有進階的搜尋能力，依據各種的資料型態做搜尋

在往後，會再一一提出以上特色的說明，廢話不多說
現在例用實作的方式帶您進入 LDAP 的世界。

—–

在實務上，最常使用 LDAP 的地方即如前例，認証服務，我們來想想
要讓一個 LDAP 能夠提供認証服務，我們需要那些的資訊?
帳號、密碼、姓名 … 等，以 UNIX 為例，我們似乎還需要 uidNumber, gidNumber,
loginShell，到底需要那些呢? 別擔心 LDAP 事先預設了許多常用的資料欄位。

* 相同類別的資料欄位在 LDAP 中，同屬於一個物件類別 objectClass
* 不同型態的資料欄位在 LDAP 中，我們稱做此物件類別 objectClass 的屬性 attribute

透過以上的資料儲存方式，可建構出所謂的 schema
比類別對資料再更廣義的區分，在此稱做為 “綱要”，意思就類似書藉上的大綱

在 OpenLDAP 中，給我們了幾個主要的 schema
取 nisSchema 為例，它提供了我們認証服務主要的物件類別 posixAccount
裡面即包含了認証服務所需要的屬性，當然不僅僅只有這些
在這裡，提供您一個不錯的網址

AKBK Home – http://ldap.akbkhome.com

在這裡面有所有 OpenLDAP 中的 schema, objectclass, attribute 的詳細介紹

取 inetOrgPerson 為例，一筆 objectClass 的定義如下:

objectclass ( 2.16.840.1.113730.3.2.2
NAME ‘inetOrgPerson’
DESC ‘RFC2798: Internet Organizational Person’
SUP organizationalPerson
STRUCTURAL
MAY (
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
)

SUP 代表物件的繼承，而此物件則繼承了 organizationPerson

inetOrgPerson 的繼承樹如下:

* top
* person
* organizationlPerson
* inetOrgPerson

在這裡，一筆資料當中，可以同包含許多不同的 objectClass，
但 objectClass 有區分三種，結構物件 STRUCTURAL、輔助物件 AUXILARY 以及
抽象物件 ABSTRACT，抽象物件

其中 abstract 抽象物件的功能，如在程式設計的關念般，繼承該物件的物件
必須擁有該相同屬性的設置，通常用於上層物件，在此即為 top

值得注意的是，一筆資料在不同的 objectClass 組合中
必須要有一個 objectClass 的型態為 structural

MUST 為必須要有的屬性，而 MAY 則為可選用的屬性，當然，繼承者可以使用來自上層的屬性
而 inetOrgPerson 可使用的屬性如下:

audio, businessCategory, carLicense, departmentNumber, … 等，如以上定義

除此之外還可以使用

description, seeAlso, userPassword (繼承自 person)

以及

telephoneNumber, destinationIndicator, facsimileTelephoneNumber … 等 (繼承自 organizationPerson)

這些資訊都可以在，上述所提供的 AKBK Home 的網頁中找到

各位應該還有疑問, 那 attribute 的型態該怎麼訂定呢?

attribute 的型態定義如下:

attributetype ( 2.16.840.1.113730.3.1.241
NAME ‘displayName’
DESC ‘RFC2798: preferred name to be used when displaying entries’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )

NAME 即為 attribute 的名稱，而DESC 為描述
EQUALITY 則是搜尋時完整比較的方式
SUBSTR 則是搜尋時片段比較的方式
SYNTAX 則為資料的規則，用來訂定資料該有的格式
SINGLE-VALUE 則代表此屬性僅能擁有一個，這也代表一般無此設定的屬性，能同時擁有好幾個

但剛剛物件定義中出現的 2.16.840.1.113730.3.2.2 與屬性的 2.16.840.1.113730.3.1.241 又是什麼呢?
別擔心，那是獨一無二的物件識別碼(OID)，為了讓資料的物件類別、屬性在全世界的使用中，互相衝突
照正常的程序上，那是需要申請的，但若為個人用途這沒有此必要性，找個沒人用的 OID 就好了
其中 2.16.840.1 代表著該使用的組織的類別，113730 則為組織的編號，往下則可自行細分

有需要申請者，則可至此網址 http://www.iana.org/cgi-bin/enterprise.pl

http://www.iana.org/assignments/enterprise-numbers 則為目前已申請的所有企業

雖然一般的使用不需要定義 schema，但仍需知道如何使用
完整的 schema 定義在此就不贅述了

—–

Filed under: 蟲的研究心得