使用:openldap-servers-2.4.23-34.el6_5.1.x86_64
タスク:crontab
のスクリプトを作成して、スケジュールされたデータベースの完全バックアップを作成します。
1)slapcat
-デフォルト形式のBerkeley DBでファイルを作成します。
2)slapcat
は、slapd
の実行中に実行できます(bdb/hdb
データベースが使用されている場合)。
3)slapcat
の後にファイルを復元するには-slapadd
を使用する必要があります(ldapadd
ではありません)。
4)slapcat/add
はパスワードを必要としません。
5)slapadd
は、slapd
が停止したときにのみ実行できます。
例:
$ slapcat -f /etc/openldap/slapd.conf -b "dc=db_1" -l db_1_backup.ldif
$ slapadd -l db_1_backup.ldif
slapcat/add
の代わりに、ldapsearch/add
を見てみましょう。
1)ldapsearch
-slapcat
とほぼ同じ情報を持つファイルを作成します。
2)ldapadd
-ldapsearch
のファイルを使用できます。slapd
を停止する必要はありません。
3)ldapadd/search
-パスワードが必要です。
例:
$ ldapsearch -D "cn=root,dc=db_1" -W -b "dc=db_1" "dc=db_1" -LLL > db_1_backup2.ldif
$ ldapadd -x -D "cn=root,dc=db_1" -W -f db_1_backup2.ldif
だから-質問は:
1)このツールの説明に何か不足していますか?
2)ldapadd/slapadd
とladpsearch/slapcat
の違いは何ですか?
良い要約、いくつかの追加ポイント:
slapcat
は、(ローカル)ダイレクトストレージバックエンドが何であってもダンプします。バークレー(hdbまたはbdb)である必要はありません。 [〜#〜] olc [〜#〜] (cn=config
)。 LDIF形式 にダンプします。 (直接とは、ローカルに保存されている場合でも、SQLバックエンドなどではなく、OpenLDAPによって直接管理されることを意味します。)ldapadd
にはslapd isが必要、slapadd
にはis notが必要ldapsearch
には、slapd
isが実行されている必要があります。slapcat
は、BDBバックエンドで実行されているかどうかは気にしません。要するに:
slapcat
は、マスターのダウンタイムがあっても、迅速に復元できる適切なバックアップを取得する方法です(さまざまなタイプのレプリケーション設定でこれを回避できます)。これは、一般的なバックアップとアップグレード前のバックアップに使用するものです。ldapsearch
(+
なし)はportableバックアップを取得します。おそらく他のディレクトリサーバーにほとんど問題なくロードできますが、これは単純なOpenLDAPセットアップ(レプリケーションなし、特別なオーバーレイなし、書き換えなし)、およびUUIDの保持/メタデータの作成/変更を気にしない場合。データに合わせて追加のスキーマファイルも必要になります。ldapadd
(他のID ldapmodify
を使用)を使用すると、slapadd
/slapcat
だけでは実現不可能または不可能であるLDAP変更(オブジェクトの変更、削除、および名前変更)を簡単に適用できますほとんどの管理者にとって、主な考慮事項は、LDIFの内容が少しずつ異なることと、slapd
を実行する(または実行しない)ための要件から生じます。より重要な違いは次のとおりです。
slapcat
は、LDAPプロトコルのオーバーヘッド、認証、アクセス制御、オブジェクトと時間制限、オーバーレイを省略してデータベースをダンプするだけなので、より高速です。また、LDAP階層に従って検索しません。slapadd
の方が高速です(ここでもLDAPプロトコルのオーバーヘッドはありません)。既知の正常なバックアップを復元する場合は、クイックモード(-q
)で実行して、大量のインポートを高速化できます。 。スキーマチェック(-s
)を無効にすることもできますが、OpenLDAPバージョン間のスキーマまたはデータ検証の小さな変更は前例がないことに注意してください。slapcat
はローカルデータベースに制限されており、ldapsearch
のように他のディレクトリ(back-ldap
、back-meta
など)にクロスオーバーすることはありません。同じことがslapadd
/ldapadd
にも当てはまります。ldapsearch
は、バックエンドに保存されていない動的属性を返します。 hasSubordinates
またはオーバーレイによって維持される変数(slapo-memberof
など)。これらをldapadd
でロードする際に問題が発生します(例:no-user-modificationの操作属性)。書き換え(slapo-rwm)も、ディレクトリの内容のldapsearch
のビューをゆがめる可能性があります。slapcat
には内部(操作)属性が含まれます。レプリケーションを使用している場合、これらの属性は重要です。レプリケーションを使用すると、バックアップへの依存がやや少なくなりますが、ldapadd
を使用してマスターをリロードすると、すべてのオブジェクトはレプリケーションによってrecreatedになります(変更されたentryUUID
entryCSN
)。 「+」属性にldapsearch
(またはallop
overlay)を指定した場合これはslapcat
と同じではありません。その理由については、前のポイントを参照してください。これらの属性には、作成/変更DNおよびタイムスタンプも含まれます。これは、一部のアプリケーションにとって重要な場合があります。slapcat
はLDAP階層(暗黙の順序)を監視しないため、ldapadd
でデータの順序が有効である保証はありません。つまり、運用属性を削除しても、下位変数が上位の上に表示される可能性があるため、ldapadd
は文句を言うことがあります。 (親)。 LDAP仕様では、親が存在する必要がありますが、この点で検索結果の順序は定義されていません。以下のハワードのコメントを参照してください。OpenLDAPのslapadd
は、いくつかのバックエンドの順序付けられていないデータを暗黙的にサポートします。ピンチでは、すべての「順不同」の親が作成されるまで、エラー継続オプション(-c
)でslapadd
を繰り返し使用し、エラーコード32(そのようなオブジェクトがない)を受信しなくなると停止する可能性があります、欠落した親を意味します)、すべてのオブジェクトに対してコード68(既に存在する)のみを受け取ります。ldapadd
はLDAPルールとオーバーレイの対象です。参照整合性、ppolicy(パスワードポリシー)slapcat
は、少なくともuserPasswordにbase-64エンコードされた属性値を使用することを好みます(属性名の後に::
で示されます)ldapsearch
には、LDIFフォーマット、および大きな属性を個別のファイルに書き込むためのオプションがさらにあります。 referrals および aliases も処理できます。slapcat
は、オーバーレイがある場合は機能しません。 memberOf
。したがって、slapcat
/slapadd
を実行すると、メンバーシップオーバーレイが機能しなくなります。