Novellインポート/エクスポート変換ユーティリティを使用すると、eDirectoryとの間でのLDIFファイルのインポートおよびエクスポートが簡単になります。詳細については、「Novellインポート/エクスポート変換ユーティリティ」を参照してください。
LDIFインポートを正しく機能させるには、Novellインポート/エクスポート変換ユーティリティが読み込み、および処理できるLDIFファイルを最初に作成する必要があります。このセクションでは、LDIFファイル形式および構文について説明し、正しいLDIFファイルの例を示します。
LDIFは、広く一般的に使用されているファイル形式で、ディレクトリ情報およびディレクトリで実行可能な変更操作について記述します。LDIFは、実際のディレクトリ内で使用されている記憶フォーマットとは完全に独立していて、通常は、LDAPサーバとの間でディレクトリ情報をエクスポートまたはインポートするために使用します。
一般的に、LDIFは簡単に生成できます。そのため、awkやperlなどのツールを使用して、固有の形式のデータをLDAPディレクトリに移動できます。また、LDIF形式でテストデータを生成するスクリプトを作成することもできます。
Novellインポート/エクスポート変換ユーティリティでインポートするファイルは、LDIF 1形式である必要があります。次に、LDIF 1のファイルの基本ルールを示します。
LDIF内容レコードは、エントリ全体の内容を表します。次に、4つの内容レコードが定義されたLDIFファイルの例を示します。
1 version:1
2 dn:c=US
3 objectClass:top
4 objectClass:country
5
6 dn:l=San Francisco, c=US
7 objectClass:top
8 objectClass:locality
9 st:San Francisco
10
11 dn:ou=Artists, l=San Francisco, c=US
12 objectClass:top
13 objectClass:organizationalUnit
14 telephoneNumber:+1 415 555 0000
15
16 dn:cn=Peter Michaels, ou=Artists, l=San Francisco, c=US
17 sn:Michaels
18 givenname:Peter
19 objectClass:top
20 objectClass:person
21 objectClass:organizationalPerson
22 objectClass:iNetOrgPerson
23 telephonenumber:+1 415 555 0001
24 mail:Peter.Michaels@aaa.com
25 userpassword:Peter123
26
このLDIFファイルは、次の部分から構成されています。
表 135. LDIFファイルコンポーネント
LDIF変更レコードには、ディレクトリに対して行う変更が記述されます。LDAPの更新操作(追加、削除、変更、およびDNの変更)はすべて、LDIF変更レコードに記述できます。
LDIF変更レコードでは、LDIF内容レコードと同じ形式の識別名指定子、属性値指定子、およびレコード区切り記号を使用します(詳細については、「LDIF内容レコード」を参照してください)。LDIF内容レコードとの違いは、LDIF変更レコードにはchangetypeフィールドがあることです。changetypeフィールドは、変更レコードが指定する操作を識別します。
changetypeフィールドは、次の5つのいずれかの形式をとる必要があります。
表 136. changetypeフィールドの形式
追加変更レコードは、内容変更レコード(「LDIF内容レコード」を参照)に、changetype: addフィールドを属性値フィールドの直前に追加したものと同じです。
すべてのレコードでタイプが一致している必要があります。内容レコードと変更レコードを混在させることはできません。
1 version:1
2 dn:c=US
3 changetype:add
4 objectClass:top
5 objectClass:country
6
7 dn:l=San Francisco, c=US
8 changetype:add
9 objectClass:top
10 objectClass:locality
11 st:San Francisco
12
14 dn:ou=Artists, l=San Francisco, c=US
15 changetype:add
16 objectClass:top
17 objectClass:organizationalUnit
18 telephoneNumber:+1 415 555 0000
19
20 dn:cn=Peter Michaels, ou=Artists, l=San Francisco, c=US
21 changetype:add
22 sn:Michaels
23 givenname:Peter
24 objectClass:top
25 objectClass:person
26 objectClass:organizationalPerson
27 objectClass:iNetOrgPerson
28 telephonenumber:+1 415 555 0001
29 mail:Peter.Michaels@aaa.com
30 userpassword:Peter123
31
削除変更レコードはエントリの削除を指定するので、削除変更レコードに必要なフィールドは識別名指定子と「削除」変更タイプだけです。
次に、「追加」変更タイプのLDIFファイルで作成した4つのエントリを削除するLDIFファイルの例を示します。
重要: 以前に追加したエントリを削除するには、エントリの指定順序を逆にする必要があります。順序を逆にしないと、コンテナ内のエントリが空でないため削除操作が失敗します。
1 version:1
2 dn:cn=Peter Michaels, ou=Artists, l=San Francisco, c=US
3 changetype:delete
4
5 dn:ou=Artists, l=San Francisco, c=US
8 changetype:delete
9
10 dn:l=San Francisco, c=US
11 changetype:delete
12
13 dn:c=US
14 changetype:delete
15
「変更」変更タイプでは、すでに存在するエントリに対して属性値の追加、削除、および置換を指定できます。変更指定子は、次の3つのいずれかの形式をとる必要があります。
表 137. 変更指定子要素
次の「変更」変更タイプの例では、cn=Peter Michaelsエントリに別の電話番号を追加します。
1 version:1
2 dn:cn=Peter Michaels, ou=Artists, l=San Francisco, c=US
3 changetype:modify
4 # add the telephone number to cn=Peter Michaels
4 add:telephonenumber
5 telephonenumber: +1 415 555 0002
6
1つのLDAP変更要求にさまざまな変更を組み合わせて指定できるのと同じように、1つのLDIFレコードに複数の変更指定子を指定できます。ハイフン(-)だけが記述されている行は、各変更指定子に対する属性値指定の終わりを示します。
次のLDIFファイルの例では、さまざまな変更指定子が使用されています。
1 version: 1
2
3 # An empty line to demonstrate that one or more
4 # line separators between the version identifier
5 # and the first record is legal.
6
7 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US
8 changetype: modify
9 # Add an additional telephone number value.
10 add: telephonenumber
11 telephonenumber: +1 415 555 0002
12 -
13 # Delete the entire fascimiletelephonenumber attribute.
14 delete: facsimileTelephoneNumber
15 -
16 # Replace the existing description (if any exists)
17 # with two new values.
18 replace: description
19 description: guitar player
20 description: solo performer
21 -
22 # Delete a specific value from the telephonenumber
23 # attribute.
24 delete: telephonenumber
25 telephonenumber: +1 415 555 0001
26 -
27 # Replace the existing title attribute with an empty
28 # set of values, thereby causing the title attribute to
29 # be removed.
30 replace: title
31 -
32
「DN変更」変更タイプでは、エントリのリネーム、移動、またはその両方ができます。この変更タイプは、2つの必須フィールドと1つのオプションフィールドで構成されます。
表 138. 「DN変更」変更タイプのフィールド
次の「DN変更」変更タイプの例で、エントリのリネーム方法を示します。
1 version:1
2
3 # Rename ou=Artists to ou=West Coast Artists, and leave
4 # its old RDN value.
5 dn:ou=Artists,l=San Francisco,c=US
6 changetype:moddn
7 newrdn:ou=West Coast Artists
8 deleteoldrdn: 1
9
次の「DN変更」変更タイプの例で、エントリの移動方法を示します。
1 version:1
2
3 # Move cn=Peter Michaels from
4 # ou=Artists,l=San Francisco,c=US to
5 # ou=Promotion,l=New York,c=US and delete the old RDN.
5 dn:cn=Peter Michaels,ou=Artists,l=San Francisco,c=US
6 changetype:moddn
7 newrdn:cn=Peter Michaels
8 deleteoldrdn:1
9 newsuperior:ou=Promotion,l=New York,c=US
10
次の「DN変更」変更タイプの例では、エントリを移動し、同時にリネームする方法を示します。
1 version:1
2
3 # Move ou=Promotion from l=New York,c=US to
4 # l=San Francisco,c=US and rename it to
5 # ou=National Promotion.
5 dn:ou=Promotion,l=New York,c=US
6 changetype:moddn
7 newrdn:ou=National Promotion
8 deleteoldrdn:1
9 newsuperior:l=San Francisco,c=US
10
重要: LDAP 2のRDN変更操作では、エントリの移動はサポートされません。LDAP 2クライアントでLDIF newsuperior構文を使用してエントリを移動しようとすると、その要求は失敗します。
LDIFファイル内で行を折り返すには、行を折り返したい場所で単に行区切り記号(改行、またはキャリッジリターンと改行の組み合わせ)を挿入し、その後にスペースを追加します。LDIFパーサは、行の先頭にスペースを見つけると、その行の残りのデータと前の行のデータを結合して解析します。そのため、先頭のスペースは無視されます。
マルチバイトのUTF-8文字の途中では、行を折り返さないでください。
次に、行の折り返しを含む(13および14行目)LDIFファイルの例を示します。
1 version:1
2 dn:cn=Peter Michaels, ou=Artists, l=San Francisco, c=US
3 sn:Michaels
4 givenname:Peter
5 objectClass:top
6 objectClass:person
7 objectClass:organizationalPerson
8 objectClass:iNetOrgPerson
9 telephonenumber:+1 415 555 0001
10 mail:Peter.Michaels@aaa.com
11 userpassword:Peter123
12 description:Peter is one of the most popular music
13 ians recording on our label.He's a big concert dr
14 aw, and his fans adore him.
15
LDIFファイルで問題が発生した場合、次のことを考慮してください。
LDIFファイルで、あるエントリを追加するレコードを、そのエントリのペアレントを追加するレコードの前に記述してしまう場合があります。この場合、LDAPサーバが新しいエントリを追加しようとするときに、そのエントリのペアレントが存在しないためエラーが生成されます。
この問題は、単に前方参照の使用を有効にするだけで解決できます。前方参照の作成を有効にすると、エントリを作成するときにそのペアレントがまだ存在していない場合でも、このペアレント用に前方参照というプレースホルダが作成されるため、エントリを正常に作成できます。後の操作でペアレントが作成されると、前方参照は通常のエントリに変更されます。
LDIFのインポートが完了した後でも、1つ以上の前方参照が残っている場合もあります(たとえば、LDIFファイルでエントリのペアレントが作成されなかった場合など)。この場合、前方参照はConsoleOneTMに不明オブジェクトとして表示されます。前方参照エントリは検索できますが、前方参照エントリには属性も属性値もないため、(objectClass以外の)属性を読み込むことはできません。ただし、前方参照の下に位置する実オブジェクトエントリ上では、すべてのLDAP操作が正常に機能します。
前方参照エントリは「不明」のオブジェクトクラスを持ち、また、内部NDS EF_REFERENCEエントリにフラグが設定されています。ConsoleOneでは、「不明」のオブジェクトクラスを持つエントリは、中央に疑問符が表示される丸い黄色いアイコンで示されます。LDAPでも不明オブジェクトクラスのオブジェクトを検索できますが、現在のところ、LDAPからエントリフラグの設定にアクセスしてそれが前方参照エントリであることを確認する方法はありません。
前方参照エントリは、単にオブジェクトを作成すれば、通常のオブジェクトに変更できます(LDIFファイルまたはLDAPクライアント要求などを使用して作成します)。前方参照としてすでに存在するエントリを作成するようにeDirectoryで指定すると、eDirectoryは既存の前方参照エントリを、作成するように指定したオブジェクトに変換します。
LDIFのインポート時に前方参照を有効にするには、次を実行します。
ConsoleOneで、［ウィザード］>［NDSインポート/エクスポート］の順に選択します。
［LDIFファイルをインポートする］>［次へ］の順にクリックします。
インポートするデータを含むLDIFファイルの名前を入力し、［次へ］をクリックします。
データをインポートするLDAPサーバを選択します。
［詳細］>［前方参照を許可］>［閉じる］の順にクリックします。
［次へ］>［終了］の順にクリックし、LDIFのインポートを開始します。
データをデータサーバへ移行するときに前方参照を有効にするには、次を実行します。
ConsoleOneで、［ウィザード］>［NDSインポート/エクスポート］の順に選択します。
［LDAPサーバ間でデータを移行］>［次へ］の順にクリックします。
移行するエントリを保持するLDAPサーバを選択し、［次へ］をクリックします。
移行するエントリの検索基準を指定し、［次へ］をクリックします。
データを移行するLDAPサーバを選択します。
［詳細］>［前方参照を許可］>［閉じる］の順にクリックします。
［次へ］>［終了］の順にをクリックします。
コマンドラインインタフェースで前方参照を有効にするには、-F LDAPターゲットハンドラオプションを使用します。
詳細については、「LDIFターゲットハンドラのオプション」を参照してください。
ファイル内のレコードを処理する前に、［操作を表示するが実行しない］LDIFソースハンドラオプションを使用してLDIFファイルの構文をチェックできます。
LDIFソースハンドラは、LDIFファイル内のレコードを処理するときに常に構文をチェックします。このオプションを使用すると、レコードの処理を無効にして、構文を検証できます。
LDIFのインポート時に構文をチェックするには、次を実行します。
ConsoleOneで、［ウィザード］>［NDSインポート/エクスポート］の順に選択します。
［LDIFファイルをインポートする］>［次へ］の順にクリックします。
インポートするデータを含むLDIFファイルの名前を入力し、［詳細］をクリックします。
［操作を表示するが実行しない］>［閉じる］>［次へ］の順にクリックします。
データをインポートするLDAPサーバを選択します。
［次へ］>［終了］の順にクリックし、LDIFのインポートを開始します。
コマンドラインインタフェースでLDIFファイルの構文をチェックするには、-n LDIFソースハンドラオプションを使用します。
詳細については、「LDIFソースハンドラのオプション」を参照してください。
Novellインポート/エクスポート変換ユーティリティは、ターゲットハンドラによる処理に失敗したレコードをすべてリストしたLDIFファイルを自動的に作成します。ユーティリティによって生成されたLDIFエラーファイルを編集してエラーを修正し、サーバに再適用することで、失敗したレコードに含まれているインポートまたはデータの移行を完了できます。
ConsoleOneで、［ウィザード］>［NDSインポート/エクスポート］の順に選択します。
実行するタスクをクリックします。
［詳細］をクリックします。
［ログファイル］フィールドに、出力メッセージ(エラーメッセージを含む)を記録するファイル名を指定します。
［失敗したレコードのLDIF出力ファイル］フィールドに、失敗したエントリをLDIF形式で出力するファイル名を指定します。
このファイルを使用して、エラーを検査または修正できます。また、修正したファイルをディレクトリに再適用することもできます。
［閉じる］をクリックします。
表示される指示に従って、選択したタスクを完了します。
コマンドラインユーティリティでエラーログオプションを設定するには、-l一般オプションを使用します。
詳細については、「一般オプション」を参照してください。
一部のLDIFの問題を理解するには、LDAPクライアントSDKがどのように機能するかを理解する必要があります。LDAPソースハンドラ、LDAPターゲットハンドラ、またはその両方に、次のデバッギングフラグを設定できます。
表 139. LDAP SDKデバッギングフラグ
この機能を有効にするには、LDAPソースハンドラおよびターゲットハンドラで-eオプションを使用します。-eオプションに指定する整数の値は、LDAP SDKでさまざまな種類のデバッグ情報を有効にするビットマスクです。
詳細については、「LDAPソースハンドラのオプション」および「LDAPターゲットハンドラのオプション」を参照してください。
LDIFではLDAP更新操作を表すことができるので、LDIFを使用してスキーマを変更できます。
クラスを追加するには、単に、NDSObjectClassDescriptionの仕様に従った属性値をsubschemaSubentryのobjectClasses属性に追加します。
NDSObjectClassDescription = "(" whsp
numericoid whsp
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ]
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
[ "MUST" oids ]
[ "MAY" oids ]
[ "X-NDS_NOT_CONTAINER" qdstrings ]
[ "X-NDS_NONREMOVABLE" qdstrings ]
[ "X-NDS_CONTAINMENT" qdstrings ]
[ "X-NDS_NAMING" qdstrings ]
[ "X-NDS_NAME" qdstrings ]
whsp ")"
次の例のLDIFファイルでは、person objectClassをスキーマに追加します。
1 version:1
2 dn:cn=schema
3 changetype:add
4 objectClasses:( 2.5.6.6 NAME 'person' DESC 'Standard
5 ObjectClass' SUP ndsLoginProperties STRUCTURAL MUST
6 (cn $ sn) MAY (description $ seeAlso $ telephoneNum
7 ber $ fullName $ givenName $ initials $ uid $ userPa
8 ssword) X-NDS_NAMING ('cn' 'uid') X-NDS_CONTAINMENT
9 ('organization' 'organizationalUnit' 'domain') X-NDS
10 _NAME 'Person' X-NDS_NOT_CONTAINER '1' X-NDS_NONREMO
11 VABLE '1')
12
必須属性は、オブジェクトクラス記述のMUSTセクションにリストします。personオブジェクトクラスの場合は、必須属性はcnとsnです。
オプション属性は、オブジェクトクラス記述のMAYセクションにリストします。personオブジェクトクラスのオプション属性は、description、seeAlso、telephoneNumber、fullName、givenName、initials、uid、およびuserPasswordです。
定義されるオブジェクトクラスを包含するオブジェクトクラスは、オブジェクトクラス記述のX-NDS_CONTAINMENTセクションに指定します。personオブジェクトクラスを包含するオブジェクトクラスは、organization、organizationalUnit、およびdomainです。
属性を追加するには、単に、NDSAttributeTypeDescriptionの仕様に従った属性値をsubschemaSubentryのattributes属性に追加します。
NDSAttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other AttributeType
[ "EQUALITY" woid] ; Matching Rule name
[ "ORDERING" woid] ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; Syntax OID
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ] ; default user modifiable
[ "USAGE" whsp AttributeUsage ] ; default userApplications
[ "X-NDS_PUBLIC_READ" qdstrings ]
; default not public read ('0')
[ "X-NDS_SERVER_READ" qdstrings ]
; default not server read ('0')
[ "X-NDS_NEVER_SYNC" qdstrings ]
; default not never sync ('0')
[ "X-NDS_NOT_SCHED_SYNC_IMMEDIATE" qdstrings ]
; default sched sync immediate ('0')
[ "X-NDS_SCHED_SYNC_NEVER" qdstrings ]
; default schedule sync ('0')
[ "X-NDS_LOWER_BOUND" qdstrings ]
; default no lower bound('0')
;(upper is specified in SYNTAX)
[ "X-NDS_NAME_VALUE_ACCESS" qdstrings ]
; default not name value access ('0')
[ "X-NDS_NAME" qdstrings ] ; legacy NDS name
whsp ")"
次の例のLDIFファイルでは、title属性タイプをスキーマに追加します。
1 version:1
2 dn:cn=schema
3 changetype:add
4 attributeTypes:( 2.5.4.12 NAME 'title' DESC 'Standa
5 rd Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{
6 64} X-NDS_NAME 'Title' X-NDS_NOT_SCHED_SYNC_IMMEDIA
7 TE '1' X-NDS_LOWER_BOUND '1')
8
属性は、明示的に単一値として定義されない限り、デフォルトでは複数値です。次の例のLDIFファイルでは、SYNTAXセクションの後にSINGLE-VALUEキーワードを追加することによって、titleを単一値として定義しています。
1 version:1
2 dn:cn=schema
3 changetype:add
4 attributeTypes:( 2.5.4.12 NAME 'title' DESC 'Standa
5 rd Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{
6 64} SINGLE-VALUE X-NDS_NAME 'Title' X-NDS_NOT_SCHED
7 _SYNC_IMMEDIATE '1' X-NDS_LOWER_BOUND '1')
8
通常、新しいスキーマエレメントを追加する場合は問題ありませんが、既存のスキーマエレメントを変更または拡張する場合には注意が必要です。すべてのスキーマエレメントはOIDによって固有に識別されるため、標準スキーマエレメントを拡張すると、元のOIDを使用する場合でも実際にはそのエレメントに対して2つめの定義が作成されます。このため、不整合が発生することがあります。
スキーマエレメントの変更が必要な場合もあります。たとえば、開発しながらスキーマエレメントを洗練していくときに、新しいスキーマエレメントの拡張または修正が必要な場合があります。次のような場合は、クラスに直接新しい属性を追加せずに、通常は補助クラスのみを使用します。
次のサンプルLDIFファイルは、2つの新しい属性と、この新しい属性に付随する補助クラスを作成して、inetOrgPersonエントリをエントリのオブジェクトクラスとして補助クラスと補助クラスの属性値に追加します。
version:1
# Add an attribute to track a bear's hair.The attribute is
# multi-valued, uses a case ignore string syntax,
# and has public read rights
# Values may include:long hair, short, curly, straight,
# none, black, and brown
# X-NDS_PUBLIC_READ '1' The 1 allows public read,
# 0 denies public read
dn:cn=schema
changetype:modify
add:attributeTypes
attributeTypes:( 2.16.840.1.113719.1.186.4.10 NAME
'bearHair' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-NDS_PUBLIC_READ '1' )
# add an attribute to store a bear's picture
dn:cn=schema
changetype:modify
add:attributeTypes
attributeTypes:( 2.16.840.1.113719.1.186.4.11 NAME
'bearPicture' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
SINGLE-VALUE )
# create an Auxiliary class for the bearfeatures
dn:cn=schema
changetype:modify
add:objectclasses
objectclasses:(2.16.840.1.113719.1.186.6.101 NAME
'bearFeatures' MAY (bearHair $ bearPicture) AUXILIARY)
# now create a user named booboo
dn:cn=booboo,o=jellystone
changetype:add
cn:booboo
sn:bear
givenName:booboo
bearHair:Short
bearHair:Brown
bearHair:Curly
bearPicture:<file:///c:/tmp/alien.jpg
objectClass:top
objectClass:person
objectClass:inetOrgPerson
objectClass:bearFeatures
# now create a person named yogi that will later be changed
# into a bear when bearFeatures is added to its objectClass
# list
dn:cn=yogi,o=jellystone
changetype:add
cn:yogi
sn:bear
givenName:yogi
objectClass:top
objectClass:person
objectClass:inetOrgPerson
# now morph yogi into a bear by adding bearFeatures
dn:cn=yogi,o=jellystone
changetype:modify
add:objectClass
objectClass:bearFeatures
-
add:bearHair
bearHair:long
bearHair:black
#bearPicture:<file:///c:/tmp/yogi.jpg>
-
# to morph yogi back to a person, simply delete the
# objectClass bearFeatures
dn:cn=yogi,o=jellystone
changetype:modify
delete:objectClass
objectClass:bearFeatures
補助クラスを削除するときに、objectClassリストから補助クラスを削除する場合には、補助クラスに関連する値を削除する必要はありません。eDirectoryによって、この処理は自動的に行われます。
補助クラスが"MUST"属性を保持している場合、補助クラスをobjectClassリストに追加する同じ変更操作でも、補助クラスをすべて指定する必要があり、これを怠ると変更に失敗します。