ojixiiさんの投稿一覧
「他のオブジェクトクラスを定義するための基底クラス」であるオブジェクトクラスの種類は ABSTRACT が正解で良いと思います。
ABSTRACT はエントリの共通基盤のような役割で、STRUCTURAL は人や組織など実体のエントリを表現する役割のクラスです。
STRUCTURAL は ABSTRACT のように「基底として他のクラスを定義する」という役割を持つわけではありません。
仰る通り、inetOrgPerson の基底クラス（親クラス）は organizationalPerson で、
さらに organizationalPerson の基底クラス（親クラス）は person です。
person の定義は次のようになってます。
objectclass ( 2.5.6.6 NAME 'person'
DESC 'RFC2256: a person'
SUP top STRUCTURAL ←
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
SUP行で、基底（親）クラスに top を指定して、種類には STRUCTURAL を指定しています。
top は ABSTRACT（抽象型）のオブジェクトクラスで、すべてのエントリは最終的にこの top を継承してます。
https://tex2e.github.io/rfc-translater/html/rfc4512.html
All entries belong to the 'top' abstract object class.
X は Y の基底（親）クラスなので～ と辿るならば、最終的には
すべてのオブジェクトクラスの基底（親）は top（ABSTRACT）に行き着くはずです。
黒本ですよね。読みましたがたぶんどちらも間違ってないと思います。
/etc/cloud/cloud.cfg.d/ はインスタンスの 起動時に使用する ユーザーデータ、
/var/lib/cloud/ はインスタンスに 実際に使用した ユーザーデータ（やインスタンスの情報など）が配置される場所です。
ちゃんとユーザーデータを設定したのになんか正しく動いてないな？？ という時に
/var/lib/cloud/ にある実際に読み込まれたユーザーデータを見たり、ログを見るとかして調査するわけです。
黒本は「ユーザデータ～略～などは /var/lib/cloud ディレクトリに保存されます。」とあるので
インスタンスを起動する際に使用したユーザーデータを指していると思われます。
このあたりが参考になるかもしれません。
/etc/cloud/cloud.cfg.d
cloud.cfg.d ディレクトリーでは、cloud-init の追加ディレクティブを追加できます。
/var/lib/cloud
cloud-init を実行すると、/var/lib/cloud の下にディレクトリーレイアウトが作成されます。このレイアウトには、インスタンス設定の詳細情報を提供するディレクトリーとファイルが含まれます。
cloud-init は、ユーザーが提供および設定するディレクティブに対応します。通常、これらのディレクティブは cloud.cfg.d ディレクトリーに含まれています。
cryptsetupで暗号化パーティションを構築する場合、
原本である１個のマスターキーに対し、最大８つのパスフレーズで暗号化されたマスターキーがキースロットに格納されますが、
LUKSモードの場合ですね。
・cryptmount -c で変更できる"パスワード"とは、上記"パスフレーズ"と同じものを指しているのでしょうか。
YESです。
・cryptmount -g で作成できる"復号キー"とは、上記"マスターキー"と同じものを指しているのでしょうか。
こちらもYESです。
manに則った記述とはいえ用語が混ざっていてわかりづらいですが、同じものです。
そもそも両コマンドは同じ暗号化パーティションに対し相補的に使うものではなく
全く別の管理機構のため1つの暗号化パーティションに対してはどちらかを選択した方だけを使って構築・管理する、というイメージですか？
"選択した方だけ" とはなるかどうかは使い方次第とは思います。
そもそもパッケージが別で、cryptsetup は（たしか）標準でインストールされているのに対して
cryptmount は追加でインストールが必要だったはずです。
よって、cryptmount を使う理由がなければ cryptsetup のみで済むと思います。
また、cryptmount の方が機能が少ないので、上で仰るようなパスフレーズの追加や
キースロットの確認などをしたければ cryptsetup を併用するというケースもあると思います。
#file: file.txt
owner: lpic
group: lpic
user::rwx
group::r-x
黒い画像のgetfaclの出力にある「user:guest:rwx」の行が抜けてないでしょうか？
$ getfacl file.txt
# file: file.txt
# owner: lpic
# group: lpic
user::rwx
user:guest:rwx ←ここ
group::r-x
group:guest:rw-
mask::rwx
other:r--
コマ問のおおもとは問題集の 27860 と思われますが、やはり同じ出力です。
「user:guest:rwx」によって、ユーザー guest には明示的に rwx の全権限が与えられているかと思います。
同じくあんまり有識でもない＆推測まじりですが、
特に④については私も学習時に気になって調べたのでお力になれるかもです。
①allow bind_anon_cred、 disallow bind_anon が許可/禁止する対象は
どちらも「匿名バインド」のみですよね？非認証バインドも含んでいたりしませんよね？
こちらはYESと思います。
man 5 slapd.conf を抜粋します。
allow
Specify a set of features (separated by white space) to allow (default none). snip
bind_anon_cred allows anonymous bind when credentials are not empty (e.g. when DN is empty). bind_anon_dn allows
unauthenticated (anonymous) bind when DN is not empty
・allow bind_anon_cred は匿名バインド（anonymous bind）を許可
disallow
Specify a set of features (separated by white space) to disallow (default none). bind_anon disables acceptance of
anonymous bind requests. Note that this setting does not prohibit anonymous directory access (See "require
authc").
・disallow bind_anon は匿名バインド要求の受け入れを無効
②disallow側には、なぜ「非認証バインド」の禁止設定が無いのでしょうか
man にも記述はないので推測ですが、
非認証バインドはデフォルトで禁止であり、許可の定義を書かなければ禁止扱いだからでしょうか。
③ping-tのディレクティブの表のallow側の説明にて、わざわざ"(DNが指定されていない場合)" "(DNが指定されている場合)"などの
注釈カッコ書きがあるのはなぜですか。単純に匿名バインドの許可,禁止と書けばよいのでは。
ここも推測ですが"匿名バインド"と"非認証バインド"の説明をあえて説明欄に入れてるってことですかね。。
ただ↑で引用した man の記述の通りではあるようです。
④他サイトですが
https://linuc.org/study/samples/3328/
ここの回答と解説にて
非認証バインドはデフォルトでは使用不可になっており、slapd.confに"allow bind_anon_cred"を指定することで使用可能となる
と書かれています。ping-tを信じるとallow bind_anon_cred は匿名バインドの許可であり非認証バインドの許可ではありませんよね。
上記サイトの解説側が間違っているということになりますか。
ちなみに以下にも同様に書かれてます。
https://www5f.biglobe.ne.jp/inachi/openldap/admin21/security-ja.html
非認証バインドは結果として匿名認可になります。非認証バインドはデフォルトでは利用できませんが、 slapd.conf(5) に "allow bind_anon_cred" を指定することにより利用できるようになります。
が、これはどちらも誤り（誤訳？）かなと思っています。
slapd.conf の man にある通り、「bind_anon_cred は 匿名バインドを許可」と理解してよいはずです。
bind_anon_cred allows anonymous bind when credentials are not empty (e.g. when DN is empty).
bind_anon_dn allows unauthenticated (anonymous) bind when DN is not empty
とはいえ文章だけではやっぱり不安だったので、学習時に検証してみたログをくっつけておきます。
結果としては man の記述の通りの挙動でした。
■ allow bind_anon_cred（匿名バインドの許可）
＜匿名バインド（バインドDNなし）＞
# ldapsearch -x -w XXXXX -b 'dc=example,dc=com' '(objectClass=*)'
→ 戻り値 0
＜非認証バインド（バインドDN(-D)あり、パスワード(-w/-W)無し）＞
# ldapsearch -x -D 'uid=XXXXX,ou=xxx,dc=example,dc=com' -b 'dc=example,dc=com' '(objectClass=*)'
ldap_bind: Server is unwilling to perform (53)
additional info: unauthenticated bind (DN with no password) disallowed
（⇒ unauthenticated bind（非認証バインド）は許可されていない）
■ allow bind_anon_dn（非認証バインドの許可）
＜匿名バインド（バインドDNなし）＞
# ldapsearch -x -w XXXXX -b 'dc=example,dc=com' '(objectClass=*)'
ldap_bind: Invalid credentials (49)
＜非認証バインド（バインドDN(-D)あり、パスワード(-w/-W)無し）＞
# ldapsearch -x -D 'uid=XXXXX,ou=xxx,dc=example,dc=com' -b 'dc=example,dc=com' '(objectClass=*)'
→ 戻り値 0