ojixiiさんの助け合いフォーラム投稿一覧

LDAP のデータベースを更新する際に、更新したいデータを入力した LDIF ファイルを使用することができます。
直接編集するのが推奨されないのはデータベース本体の LDIF ファイルの方ですね。

https://docs.redhat.com/ja/documentation/red_hat_directory_server/12/html/managing_directory_attributes_and_values/assembly_managing-directory-entries-using-the-command-line_managing-directory-attributes-and-values#assembly_providing-input-to-the-ldapadd-ldapmodify-and-ldapdelete-utilities_assembly_managing-directory-entries-using-the-command-line

ディレクトリーのエントリーまたは属性を追加、更新、または削除する場合は、（中略）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 もロードできる）

自分の理解で恐縮ですが。。

ハードリンクは同じ実体を指すポインタですので、
chrootの内外で同じファイルへのハードリンクが存在すると、
chroot内で変更した際の影響がchroot外（＝ホストシステム）へも及んでしまうことになりますよね。

マウントについては、マウントする際にアクセス権の設定や（読み取り専用とか）
書き込みできたとしても書き込むユーザを限定するとかのオプションの指定ができますから、
きちんと権限設定をしてマウントすることによって、ホストへの影響を最小限にできる。
という点がマウントの利点なのではないかなと思っています。

私も同様の認識です。
BIOSパスワードは物理的に盗難されにくいものに対する追加的な保護という意味で有効なのかなと理解してます。
近年よく使われてるシンクライアント端末も紛失・盗難時に情報を守るためですよね。

ちなみに、じゃあCMOSクリアをネットワーク経由でできてしまったらダメじゃないのかなと
学習していた当時に思った記憶があるのですが、
「IPMIなどでリモートから電源操作はできるようにしてあるサーバは多いが、BIOSの設定までできるかはサーバの設定次第。
更にBIOSの初期化（CMOSクリア）に関してはリモート操作はサポートされてない可能性がある」
みたいな結論でした。参考までに。

実機見てみましたが、手元の CentOS 7.9 と CentOS 9 では -vvv は実行可能 かつ 英語版のmanに説明がありました。
パッケージはそれぞれ pciutils-3.5.1-3.el7.x86_64 と pciutils-3.7.0-5.el9.x86_64 です。

ディストリビューションの違いかなと思って Ubuntu の man を参照してみましたが、
日本語manには掲載されていないのに対して、英語manには -vvv の説明があります。
https://manpages.ubuntu.com/manpages/bionic/ja/man8/lspci.8.html
https://manpages.ubuntu.com/manpages/bionic/en/man8/lspci.8.html
日本語のmanは最新のオプションに追随してない可能性があるかもしれないです。

「PEM 可読性」で検索したところ、こんな感じのご意見が見つかりました。
https://www.oresamalabo.net/entry/2020/03/01/194300#PEM-%E3%81%8C%E7%94%A8%E3%81%84%E3%82%89%E3%82%8C%E3%82%8B%E7%90%86%E7%94%B1

ここでの「可読性」は「読んでわかる」というよりも、テキストなので人間が中身を参照できるということかなと自分は理解していました。
バイナリファイルを可読性があるとは言えないと思いますので…

確かに「どのクライアントも」の選択肢は時間帯に関する言及がないので、正しいようにも見えますね。

ただ逆に言うと、仰る通り eigyobi の条件も満たさなきゃいけないので
「eigyobi の時間内の 443 ポートを使った通信は、どのクライアントもアクセスできる」
とかなら○だと思います。
あるいは
「443 ポートを使った通信は、どの時間帯のどのクライアントもアクセスできる」
とかなら明確に×ですよね。

少し悩ましい選択肢ですが、他の2つが明確な正解なので消去法で落としてよいところかなと思います。

fsckコマンドもファイルシステムの指定は必須ではなく、
指定しない場合は自動判定してくれますので、内部的に判断しているものと思います。

また、fsckコマンドとe2fsckコマンドの実務での使い方まではわからないのですが（すみません）、
ext2/3/4 に関して言えば fsck.ext2/3/4 と e2fsck は実体が同じなので※
使い分けするものではなさそうな気もしますね。。

※CentOS9 のlsの結果ですが、e2fsck と fsck.ext2/3/4 の inode番号がすべて同じです。

# ls -il /usr/sbin/fsck /usr/sbin/fsck.ext* /usr/sbin/e2fsck
101318623 -rwxr-xr-x. 1 root root  44592  8月 25 05:37 /usr/sbin/fsck
101694482 -rwxr-xr-x. 4 root root 364712 10月 17 23:00 /usr/sbin/e2fsck
101694482 -rwxr-xr-x. 4 root root 364712 10月 17 23:00 /usr/sbin/fsck.ext2
101694482 -rwxr-xr-x. 4 root root 364712 10月 17 23:00 /usr/sbin/fsck.ext3
101694482 -rwxr-xr-x. 4 root root 364712 10月 17 23:00 /usr/sbin/fsck.ext4

「pattern」というのは grep の検索条件（検索パターン）が書かれたテキストファイルですね。
「cat pattern」では、cat コマンドにファイル pattern を指定して中身を参照しています。
ファイルの中身「^[^#]」が大事で、このファイルの中身（検索パターン）を参照して
grep -f が動作しますよ ということだと思います。

ファイル pattern の中身は検索パターンが書かれているだけですので、
中身を抜き出した「grep '^[^#]' test.txt」も同じ動作をするはずです。

こちらディストリビューションの違いというより、環境が古いせいじゃないかなと思います。
手持ちの CentOS 6 ではこの問題と同じ表示でしたが
Ubuntu 22 では「avail Mem」になってました。
（試験で新しい方が出題されるか古い方が出題されるはわかりませんが。。）

異なるのは説明の対象ですね。
server string は [global] セクションにある通りサーバそのものの設定で、
comment の方は共有リソース（フォルダとか）の設定です。

こちらの日本 Samba ユーザ会さんの説明が参考になるかもしれません。
http://www.samba.gr.jp/doc/samba2.0_and_linux.html

server string
「ネットワークコンピュータ一覧」で詳細表示した時、「サーバの説明」と「プリンタの説明」に表示する文字列を指定します。
文字列の中の%v は Samba バージョン番号と置換され、%h は ホスト名に置換されます。
（略）
例: server string = Samba %v on %h Linux

comment
共有名のコメント（説明）を記述します。
（略）
例: comment = 企画の共有フォルダ

見え方については、古いですがこちらを見るとイメージがつかめるかもです。
http://linux.kororo.jp/cont/server/samba30.php

1つ目（rpm）と 3つ目（binrpm-pkg）の違いは、ソースパッケージが生成されるかどうかですね。
rpm ではソースを含む全部のパッケージが生成されます（rpm-pkg も同じ動作です）。
binrpm-pkg は「bin」とついている通りバイナリのパッケージのみが生成されます。ソースパッケージは生成されません。

実際にカーネルビルドした際の成果物はこんな感じです。末尾が src.rpm となっているのがソースパッケージです。

$ make rpm
：
書き込み完了: /home/guest/rpmbuild/SRPMS/kernel-3.10.0-1.src.rpm
書き込み完了: /home/guest/rpmbuild/RPMS/x86_64/kernel-3.10.0-1.x86_64.rpm
書き込み完了: /home/guest/rpmbuild/RPMS/x86_64/kernel-headers-3.10.0-1.x86_64.rpm

$ make rpm-pkg
：
書き込み完了: /home/guest/rpmbuild/SRPMS/kernel-3.10.0-2.src.rpm
書き込み完了: /home/guest/rpmbuild/RPMS/x86_64/kernel-3.10.0-2.x86_64.rpm
書き込み完了: /home/guest/rpmbuild/RPMS/x86_64/kernel-headers-3.10.0-2.x86_64.rpm

$ make binrpm-pkg
：
書き込み完了: /home/guest/rpmbuild/RPMS/x86_64/kernel-3.10.0-6.x86_64.rpm
書き込み完了: /home/guest/rpmbuild/RPMS/x86_64/kernel-headers-3.10.0-6.x86_64.rpm

LinuxのソフトウェアRAIDでディスク1本のRAID 0を実現できるかどうかはわかりませんが、RAID 0で必要なディスクは多くのWebサイトでは2本以上と書かれてますので「基本的には2本以上必要」と考えていて良いと思います。
（全部のディストリや仕様を調べたわけじゃないので、あくまで試験範囲の知識において、です;）
https://www.infraexpert.com/study/networking9.html
https://ja.m.wikipedia.org/wiki/RAID
https://e-words.jp/w/RAID_0.html

すみません、どの問題の事を仰ってるのかよくわからなかったのですが、
xz -cd と unxz -c は同じように動作するのか？ という意図のご質問でしたら、その通りだと思います。。
おかしな回答してたらすみません。

mrproperについてはご認識の通りかと思いますが、引っかかってるのはたぶん解説のここのところですかね。

この問題では「現在のカーネル設定を引き継」いで使うとのことなので、現在のカーネルをビルドしたときの設定を .config として現在のディレクトリにコピーしておき、make oldconfig を実行します。

mrproperで初期化してから、必要な設定（現在のカーネルの.config）を持ってきてoldconfigなどを実行していけば、現在の設定を引き継いだカーネルをビルドできるということなのかなと思います。

man 見ても特に説明はありませんでしたので、お考えの通り
edit の -e、list の -l、remove の -r だよ、という補足と捉えてよいかと思います。

200 でも問題はないかもしれませんが、
「書き込みだけ許可」というパーミッションは一般のファイルではまず設定しないはずです。
（この問題が4択であれば選ぶかもしれませんが、だいぶ悩ましいです）

ちなみに /proc/sysrq-trigger というファイル（カーネルパニックを起こさせるファイル）は
確か書き込みのみだったはずですが、これも特殊な例だと思います。

NTPサーバへアクセスして現在時刻を取得するソフトウェア（コマンド）ですので、「コマンドでありクライアントである」の理解でいいのではないかなと思います。

参考までに、NTPクライアントの定義は以下のようになってるようです。
https://e-words.jp/w/NTP%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88.html

Q1 について、厳密に詳しくはないのですが
ジョブはプロセスの集合（シェルから見た実行単位）の認識だったので概ね同じ意味で受け取っていいのではと思います。
ターミナル上で「sleep 10」とか実行しても、フォアグラウンドのジョブ1つともいえるしプロセス1つともいえますよね。

Q2 はジョブを実行しているターミナルとは異なるターミナルからであれば、kill/killall コマンドを実行することができると思います。

server.confやclient.confはデフォルトで存在するファイルではなくて、
基本的には同梱されているサンプルを/etc/openvpnディレクトリ配下にコピーして利用する運用ですね。
systemdの起動ファイルが/etc/openvpn 直下に置かれている *.conf を読み込んで動作するという動きをしてます。

少し古くて恐縮ですが、openvpn-2.4.8-1.el7.x86_64 の /usr/lib/systemd/system/openvpn@.service から抜粋します。

[Service]
Type=notify
PrivateTmp=true
ExecStart=/usr/sbin/openvpn --cd /etc/openvpn/ --config %i.conf   ★★

一応こちらにも「/etc/openvpn/server.conf」として例が挙がっています。
https://atmarkit.itmedia.co.jp/ait/articles/1603/18/news009_3.html
https://www.server-memo.net/server-setting/openvpn/openvpn_2_4-tun.html#toc20

% はあってもなくてもいいみたいです。
https://atmarkit.itmedia.co.jp/ait/articles/1707/21/news001_2.html

プロンプトで「fg %1」または「fg 1」を実行すると、ジョブ番号［1］で実行中のジョブ（略）がフォアグラウンドになります