ojixiiさんの投稿一覧
LDAP のデータベースを更新する際に、更新したいデータを入力した LDIF ファイルを使用することができます。
直接編集するのが推奨されないのはデータベース本体の LDIF ファイルの方ですね。
ディレクトリーのエントリーまたは属性を追加、更新、または削除する場合は、（中略）LDIF ファイルを渡すことができます。
一応こちらの問題集にも、別の問題の参考の部分ですが以下の説明があります。
LDAPサーバにディレクトリ情報(エントリ)を登録したり、エントリの内容を変更したりするには、LDIF（LDAP Data Interchange Format）ファイルを利用します。
こんな感じです。changetype:add を記述した LDIF ファイルを ldapmodify に指定して、アカウントを追加しています。
# cat hoge.ldif
dn: uid=hoge,ou=demo,dc=example,dc=com
changetype: add ★★
objectClass: account
objectClass: posixAccount
uid: hoge
userPassword: {SSHA}jHJwBwTy2442DzP2QlMmcWOTXt53y2Ef
uidNumber: 1005
gidNumber: 1005
cn: hoge
homeDirectory: /home/hoge
loginShell: /bin/bash
★ hoge というアカウントがない状態で、hoge アカウントを追加してみる
# slapcat -n 1 | grep hoge
#
# ldapmodify -D "cn=Manager,dc=example,dc=com" -W -f hoge.ldif ★ldapmodify に LDIFファイルを指定
Enter LDAP Password:
adding new entry "uid=hoge,ou=demo,dc=example,dc=com"
# slapcat -n 1 | grep hoge ★登録に成功したことを確認
dn: uid=hoge,ou=demo,dc=example,dc=com
uid: hoge
cn: hoge
homeDirectory: /home/hoge
ここ、自分もかなりわかりづらかった記憶があります。
Require not ip 10.0.0.1 の場合、アクセス元が10.0.0.1なら偽というのは合ってる？では192.168.0.1なら何を返すのか？
Require notだけ、たとえ条件(の否定)が合致しても真は返さない特殊な仕様だとういことでしょうか？
Require not については、真を返すことはなく、偽または中立を返します。
意味が解らないと思いますが、実際そう書かれてます。
https://httpd.apache.org/docs/2.4/ja/mod/mod_authz_core.html#require
The result of the Require directive may be negated through the use of the not option. As with the other negated authorization directive , when the Require directive is negated it can only fail or return a neutral result, and therefore may never independently authorize a request.
この中立（neutral result）というのは、どうやら条件を評価しない場合に返るもののようです。
よって「10.0.0.1」の場合、すなわち条件に合致する場合には「偽」が返るものと思われます。
（このあたりの説明が「真を返さない」という説明になっているのでしょうが、実際「中立を返す」とか書かれてもよくわからないんだろうなと思った記憶があります。）
逆に、真を返すことが絶対にない仕様なのであれば、RequireAllの中なら問題がない理由もよく分かりません。
RequireAllは中の条件が全て真なら真とするディレクティブなのであれば、Require notが真を返さないならRequireAllが真になることもまたあり得ないことになってしまうのでは。
たとえばこういう条件のとき、
＜RequireAll＞
①Require all granted
②Require not ip 10.0.0.1
＜/RequireAll＞
①は常に真を返します。
②は、例えば 10.0.0.1 だったら 条件に合致する＝偽を返し、
RequireAllの動作としては、すべての条件に合致しない＝アクセスが拒否される という動作になるものと思われます。
さらに、Require not の条件に合致しない、例えば 192.168.0.1 のような場合には、
先ほどの同じページ RequireAll の説明に以下のようにあります。
If none of the directives contained within the directive fails, and at least one succeeds, then the directive succeeds. If none succeed and none fail, then it returns a neutral result. In all other cases, it fails.
・一つも偽を返さない＋一つ以上が真の場合には成功を返す
・どれも真でなく、偽でもない場合は中立を返す
・それ以外は失敗を返す
192.168.0.1 からアクセスがあったとき、②Require not は「中立」を返すはずです。
このとき、①は真、②が中立を返すために、「一つも偽を返さない＋一つ以上が真の場合には成功を返す」
の要件に当てはまり、アクセスできる という動作のようです。
中立という言葉を考えると、＜RequireAll＞ は「全ての条件が失敗しない場合に真」と理解した方がよいのかもしれません。
allow-query や allow-transfer は options ステートメントに限らず zone ステートメントなどにも設定できます。
以下に options と zone ステートメントでの設定例があります。
https://bind9.readthedocs.io/en/v9.18.1/security.html#access-control-lists
（↑には allow-query だけだったので念のため zone ステートメントのグラマーを確認しましたが、allow-transfer も含まれています。）
https://bind9.readthedocs.io/en/v9.18.1/reference.html#zone-statement-grammar
RHEL のガイドでも同じように抜粋してました。
https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/9/html/managing_networking_infrastructure_services/proc_writing-bind-acls_assembly_setting-up-and-configuring-a-bind-dns-server
（ただこの問題の場合は acl と controls ステートメントに挟まれているので違和感はありますが）
ステートメントをあえて限定していないのか、問題のために例を単純化してるのかはわかりませんが、
ここについては ACL の設定例を提示しているだけと受け止めていいかと思います。
「clientsについてはアクセスする時間帯の制限はない」という理解であっていると思います。
逆に言うとclientsでないクライアントからのアクセスは時間制限があるので、
「その他の（時間制限される）クライアントと同様に、localmembersのアクセスも制限したい」
という意図なのかなと自分は受け取りました。
上記はモジュールBがロードされていないとモジュールDはロードできないのでしょうか？
仰る通り B と D に依存関係はないので、D のロードに B は必要ないはずです。
ここのポイントは、モジュール B も D も依存しているモジュールが同じ（A と C）なので、
「B がロードされている＝モジュール A と C がロードされている＝ D もロードできる」
という事だと思います。
ちなみに逆もいえるはずです（D がロードされてれば、B もロードできる）