この節では、LDAP 経由で、オブジェクトクラスを作成、表示、および削除する方法を説明します。
cn=schema エントリには、ディレクトリスキーマの各オブジェクトクラスの定義を格納し、複数の値を持つ属性 objectClasses があります。それらの定義は ldapmodify(1) コマンドを使用して追加できます。
新しいオブジェクトクラス定義とユーザー定義オブジェクトクラスへの変更は 99user.ldif ファイルに保存されます。
ほかのオブジェクトクラスから継承する複数のオブジェクトクラスを作成するときは、最初に親オブジェクトクラスを作成する必要があります。新しいオブジェクトクラスがカスタム属性を使用するときは、その属性も事前に定義しておく必要があります。
各オブジェクトクラス定義に、1 つ以上の OID を指定する必要があります。新しいオブジェクトクラスには少なくとも次の要素を使用することを考慮してください。
オブジェクトクラス OID。オブジェクトクラスのオブジェクト識別子に相当します。OID はスキーマオブジェクトを一意に識別する文字列で、通常は小数点で区切られた数値です。
LDAP v3 に厳密に準拠するには、有効な数値 OID を指定する必要があります。OID の詳細または企業のプレフィックスを要求するには、iana@iana.org の IANA (Internet Assigned Number Authority) に電子メールを送信するか、http://www.iana.org IANA Web サイトを参照してください。
オブジェクトクラス名。オブジェクトクラスの一意の名前に相当します。
親オブジェクトクラス。このオブジェクトクラスが属性を継承する既存のオブジェクトクラスです。
このオブジェクトクラスをほかの特定のオブジェクトクラスから継承させない場合は、top を使用します。
一般に、ユーザーエントリに対して属性を追加する場合、親オブジェクトは inetOrgPerson オブジェクトクラスになります。企業エントリに対して属性を追加する場合、親オブジェクトは通常 organization または organizationalUnit になります。グループエントリに対して属性を追加する場合、親オブジェクトは通常 groupOfNames または groupOfUniqueNames になります。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。
http://www.ietf.org/rfc/rfc4517.txt RFC 4517 に指定された構文に従って、オブジェクトクラス定義を準備します。
ldapmodify(1) コマンドを使用して、オブジェクトクラス定義を追加します。
Directory Server によって、指定した定義に 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 $ |
生産環境では、1.2.3.4.5.6.8 ではなく、有効な一意の OID を指定します。
cn=schema エントリには、ディレクトリスキーマの各オブジェクトクラスの定義を格納し、複数の値を持つ属性 objectClasses があります。それらの定義は、ldapsearch(1) コマンドを使用して読み取ることができます。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と 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 があります。X-ORIGIN 'user defined' を含む定義を削除するには、ldapmodify(1) コマンドを使用します。
スキーマは cn=schema 内の LDAP ビューによって定義されるため、ldapsearch ユーティリティーおよび ldapmodify ユーティリティーを使用してスキーマをオンラインで表示、変更することができます。しかし、削除できるスキーマ要素は、X-ORIGIN フィールドに 'user defined' という値が設定されている要素だけです。サーバーは他の定義を削除しません。
ユーザー定義の要素の変更は、 99user.ldif ファイルに保存されます。
DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と 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 |
Directory Server によって追加された X-ORIGIN 'user defined' を含めて、このスキーマ定義を拡張として分類する必要があります。