ojixiiさんの投稿一覧
chageコマンドの--maxdaysに-1を指定する
「/etc/login.defs」のPASS_MAX_DAYSに-1を設定する
この設定はパスワードの有効期限（最大日数）を無効にするものです。
この問題はパスワードの変更後に再変更できないようにする期間が対象なので
パスワードの最小変更間隔を設定する --mindays と PASS_MIN_DAYS の設定が適切です。
例えば、パスワードの有効期限切れで変更を強制され、やむなく新しいパスワード（Y）に
変更したものの覚えにくくて、すぐ元のパスワード（X）に戻したいと思っても、
PASS_MIN_DAYS の日数が経過するまでは再変更できない、ということです。
なおこの問題（27843）は PASS_MIN_DAYS を問われてますが
PASS_MAX_DAYS を問われる問題（27844）もあります。
「他のオブジェクトクラスを定義するための基底クラス」であるオブジェクトクラスの種類は 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 の全権限が与えられているかと思います。