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

・①は②の一部であり、②に含まれる（①は②のサブセットである）

①と②は異なる機能だと思います。一部でもないです。

・①＝②ではない

YESです。

・setは②の全てを表示し、その中に①が含まれる（setの表示は、①以外の部分が存在する）

setコマンド（オプションなし）は ①シェル変数 に加えて環境変数などを表示します。
オプション名を指定しない「set -o（または set +o）」コマンドは、②のすべて？ というか設定状況を表示します。

①シェル変数は、シェルの中でのみ有効な変数です。変数名も値も任意です。
$ aaa=100
とすると、シェル変数 aaa には 100 という値が設定されていることになります。
シェル変数をどのように定義してどう使うかはユーザーが決めることです。

②シェルのオプションは、こちらの問題にあるとおり allexport とか emacs とか、名前も機能も決まってます。
有効/無効を切り替えることで、シェルを使う上で便利になったりシェルの動作を自分好みの操作感にできます。
機能を有効にするかどうかはユーザーが決められます。

ご質問の意図を読み違えてたらすみません。
「元のリクエストヘッダに192.168.1.10を教える」というのがちょっとよくわからなかったのですが、
ここで言ってるのは、
・デフォルトでは、Hostフィールドには クライアントからのHostフィールドが含まれてない
（その代わりに プロキシサーバのホスト名（例の場合は 192.168.1.10）が送られる）
・クライアントからのHostフィールドをプロキシ先のサーバへ送りたいような場合には
「proxy_set_header」と変数$hostを使って、「proxy_set_header Host $host;」のようにする
ということなんじゃないかなあと思います。。

あまり詳しくはわかりませんが、/etc/inittab は Upstart でも使用可能だけど非推奨 というスタンスのようです。
以下 RHEL6 のマニュアルですが参考に。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/migration_planning_guide/ch04s02s03

なので、Upstart が inittab の機能のどこまで使えるか使えないか というよりは、基本的には使わないもの。
ということから「/etc/inittab」を設定ファイルとして使用しないinitプログラムは「Upstart」～」と理解していいのではないかと思います。

rpc.mountd は、自分の中のざっくりな理解では「NFSを使うにあたってバージョン問わずサーバ側で必要なもの」だったので
興味持って調べてみたのですが、「NFSv4では要らん」と書かれた資料が見つかりませんでした。。
もし文献等ありましたら教えていただきたいです。

一応、参考URLの先には以下のようにあったので、NFSv4 でも必要だと思っていました。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-nfs

rpc.mountd デーモンは、エクスポートを設定するために NFS サーバーで引き続き必要ですが、ネットワーク上の操作には関与しません。

あとはこちらにも NFS 2,3 および 4 で使用されるとありました。
https://docs.oracle.com/cd/E39368_01/admin/ol_about_nfs.html

リクエストされたNFS共有をNFSサーバーがエクスポートし、クライアントがその共有にアクセス可能であることを確認することにより、NFSv2およびNFSv3クライアントからのマウント・リクエストを処理します。
NFSv4の場合、このサービスはエクスポートを設定する場合のみ必要です。

NFSv4で役割は変わっているものの、いずれにせよ必要なように思えますが、いかがでしょうか。

LinuC ですが正にほぼ同じ箇所を学習していました。

1行ずつ読み取るとこうですかね。

olcAccess: to * → 全てのエントリに対して
by anonymous read → 認証前のユーザは参照できます
by * none → それ以外のユーザはアクセスできません

が、これ2行目の条件によって全ユーザ（未認証ユーザ含む）がマッチしますので、3行目が評価されることはありません。

もう少し丁寧に説明すると、

by anonymous read

の anonymous は認証される前のユーザ（匿名ユーザではないです）であり、認証可能なユーザを含む全ユーザを意味します。
参考に以下のようにあります。

「by anonymous auth」の記述があるのは、LDAPサーバにアクセスする際は必ず認証を行う必要があるためです。認証される前のユーザの為に、anonymousを指定します。この記述がないとそもそも認証ができなくなりますので、注意が必要です。

よって、2行目で「全てのエントリを全てのユーザが参照できる」ということになります。
さらに、3行目「by * none」は以下の理由により評価されません。

by以降に記述されている条件は順番に処理され、条件にマッチするとそれ以降の条件は処理されません。記述する順番には注意が必要です。

2行目の条件により「全ユーザ」がマッチしますので、3行目は評価されないんですね。
よって、「アクセス制御の設定をしていない条件と同じ定義」となります。

うーん、確かにあまり良問ではないのかもしれませんが、誤りが明確ですので消去法で解けるかと思います。
mail, weekly, include は、解説にある表から誤った説明がされていることがわかります。

mail ：ログ切り替え失敗時に指定されたアドレスにメールする
　→回答時はよくわかってなかったけど、mailのみの記載でもサーバ管理人に送られると思って×

「ログ切り替え失敗時にメールするメールアドレス」が×
mail に設定するのは、「ログ切り替えによって削除されるログを送付するメールアドレス」です。

weekly：1週間ごとにログを削除する
　→一週間ごとと決まってるので×

「ログを削除する」が×
weeklyやdaily などは「切り替えのタイミング」を指定するものです。

include：ログ切り替え後に実行するスクリプト
　→スクリプトを記載する必要があるので〇
　（実際にはスクリプトの記載ではなく、ディレクトリ名の指定だったようですが。）

→ 「切り替え後に実行するスクリプト」が×
includeは「設定ファイルが置かれたディレクトリ」を指定するものです。

rotate の説明は正しいものですから○で、
compress についてはおっしゃる通り値を取らない設定項目ですから 設定項目の意味を問うものになっていますが（weekly も同様ですね）、
ほかに正しいものがないので ○ ... と考えてよいのではないかなと思いました。

未起動の ジョブ を自動実行できる ですね。
解説の「実行履歴を管理しており、未実行のジョブを検出できる」の部分が該当するかと思います。

実際にどのようになってるかについては、参考の中盤あたりにある0anacronの中身と
「1時間おきに実行する 0anacron では、「毎日実行するジョブの実行状況の確認」を行い、未実行の場合 anacron を実行します。」
の部分が該当するかなと思います。

カレントディレクトリに展開せずに ですね。
展開しないと内容を参照することはできませんが、標準出力に展開すればカレントディレクトリには展開されずに済みます。

こちら LinuC でのお話でしたが参考になるかと思います。
https://mondai.ping-t.com/g/posts/647

man 5 slapd.conf には以下のようにありますね。

allow
：（省略）
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.

bind_anon_cred は、認証情報が空でないとき (たとえば DN が空のとき) に anonymous bind（匿名バインド）を許可する。
bind_anon_dn は、DN が空ではないときに非認証（anonymous）バインドを許可する。
（どっちの説明にも「anonymous」入っててややこしいですけど、
bind_anon_dn の方は「unauthenticated bind」とあるので「非認証バインド」としてよいと思います）

一応manの通りで間違ってなさそうだなあと思いつつ、勉強がてら実機で検証してみました。
結論からいうと
　bind_anon_cred → 匿名バインドが許可される
　bind_anon_dn → 非認証バインドが許可される
という動作でした。つまりmanおよび今の27550での説明が正しいということになります。

非認証バインド（=DNの指定のみ、パスワード指定なし）を allow bind_anon_cred の環境下で実行すると、以下のようになりました。

# ldapsearch -x -D 'uid=bbb,ou=aaa,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 (DN with no password) disallowed（非認証バインドは許可されてません）」
というエラーが出ることから、allow bind_anon_cred では非認証バインドは許可されてないということです。
一方、同じコマンドを allow bind_anon_dn で実行すると、検索が行われて結果が返りました。

てことで、教科書を持ってないし他のWebサイトの真偽もよくわかりませんが、実際の挙動に則った説明にはなっているようです。

ポイントはdropの戻りですかね？
firewalldの設定ファイル（/usr/lib/firewalld/zones/drop.xml）のdescriptionの2文目を読む限り
仕様としては「戻りは許可」になっていそうです。

<?xml version="1.0" encoding="utf-8"?>
<zone target="DROP">
  <short>Drop</short>
  <description>Unsolicited incoming network packets are dropped. 
Incoming packets that are related to outgoing network connections are accepted. 
Outgoing network connections are allowed.</description>
</zone>

このあたりでも戻りは許可と言われてます。
https://atmarkit.itmedia.co.jp/ait/articles/1602/18/news019_2.html

確かに「戻りも不可」＝実質的に通信不可 とうたっているサイトも散見されたので
一応簡単に試してみましたが、dropに指定したIPアドレスへのpingも返りましたし、
送信および戻りに関しては遮断されてる感じはしなかったです。

あんまり有識でもないんですが、調べてて勉強になったので共有させてもらいますね。

GRUB でどのカーネルを使って起動するようにするのかは、
/etc/default/grubの中の"GRUB_DEFAULT"という項目で定義してます。
で、ちょっと見てみたんですが、この項目の既定値が統一されていないみたいなんですね。
（異なる要因が GRUB と GRUB2 なのか、ディストリビューションなのかまではわからないのですが）

手元の Ubuntu 19.04 では「GRUB_DEFAULT=0（menuentryの0番目）」、
CentOS 7.9では「GRUB_DEFAULT=saved（前回起動時と同じものを使う）」となってました。

新しいカーネルをインストールすると0番目のエントリに追加されるので、
GRUB_DEFAULT=0となっているシステムでは新しいカーネルで起動するようになる、
そうでないシステムでは手動で設定する必要がある、
ということなのかなあと思います。

「rm してから ln を実行する」で合っていると思います。
ちなみにシンボリックリンクがある状態で（rmを実行せず）ln 実行したら、ちゃんと怒られました。

# ls /etc/systemd/system/default.target
/etc/systemd/system/default.target
# ln -s /lib/systemd/system/graphical.target /etc/systemd/system/default.target
ln: failed to create symbolic link '/etc/systemd/system/default.target': File exists

パッケージ名を指定するのは -i または --install の時だけですね。
インストールする前に指定する場合は パッケージファイル名
インストールした後に指定する場合は パッケージ名
と覚えるといいと思います。

インストールのときは、インストールするためのパッケージファイルを
インターネット等から入手してインストールしますので、
"パッケージファイル"としての名前が必要です。
（パッケージ名だけだと「そんなファイルはない」と怒られます）

# dpkg -i sl
dpkg: error: cannot access archive 'sl': No such file or directory

-r や -L などの時は、既にインストールした後なのでパッケージの名称を指定します。
インストール後は「パッケージファイル名」で認識されていませんので、
そんなパッケージはインストールされてないぞと怒られます。

# dpkg -L sl_5.02-1_amd64.deb 
dpkg-query: package 'sl_5.02-1_amd64.deb' is not installed

「/etc/cron.allow」と「/etc/cron.deny」ファイルが存在しない場合の挙動は以前から議論のある内容のようですね。
https://ping-t.com/modules/forum/index.php?topic_id=4866
https://ping-t.com/modules/forum/index.php?topic_id=2749

事情が変わったのかなと思って MIRACLE LINUX 9（5.14.0-70.13.1.el9_0.x86_64）で確認してみましたが、
「どちらのファイルもない場合はrootだけ使用可能」は変わってませんでした。

[guest@ML9 ~]$ ls /etc/cron.allow /etc/cron.deny
ls: cannot access '/etc/cron.allow': No such file or directory
ls: cannot access '/etc/cron.deny': No such file or directory
[guest@ML9 ~]$ crontab -e
You (guest) are not allowed to use this program (crontab)  ★
See crontab(1) for more information

man 1 crontab にも以下の記述です。

If neither of these files exist, then only the super user is allowed to use crontab.

ただ、少し調べてみたところ、
LinuC の方（レベル1 102）の例題だと「どちらも存在しない場合は全ユーザが利用可能」となってたり、
https://linuc.org/study/samples/3341/

LPI Learning Materials だと「ディストリビューションごとに異なる」となってます。
https://learning.lpi.org/en/learning-materials/102-500/107/107.2/107.2_01/#_configure_access_to_job_scheduling

If neither of these files exist, the user’s access to cron job scheduling depends on the distribution used.

一応 MIRACLE LINUX の man 1 crontab では「POSIXに準拠している」とあったので、
POSIXを見てみると、以下のようにありました：（最新 POSIX:2008-2018）
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html

If neither file exists, only a process with appropriate privileges shall be allowed to submit a job.

「どっちのファイルもない場合は、適切な権限を持ったプロセスだけがジョブ登録できますよ」

それからUbuntu（Debian系）については以下に記述があります。
https://help.ubuntu.com/community/CronHowto#Allowing.2FDenying_User-Level_Cron

In the case where neither file exists, the default on current Ubuntu (and Debian, but not some other Linux and UNIX systems) is to allow all users to run jobs with crontab.
No cron.allow or cron.deny files exist in a standard Ubuntu install, so all users should have cron available by default, until one of those files is created. If a blank cron.deny file has been created, that will change to the standard behavior users of other operating systems might expect: cron only available to root or users in cron.allow.

「どっちのファイルもない場合は、（ほかの Linux とか UNIX とは違って）Ubuntu とか Debian では全ユーザが利用できます」
特に「that will change to the standard behavior users of other operating systems might expect（他のOSのユーザーが期待する標準的な動作に変更されます）」
を読む限りでは、標準的な動作とは異なるってことになるのかなと理解しました。

長くなりましたが、まとめると（個人的な理解で恐縮ですが）、
/etc/cron.allow、/etc/cron.deny の両方がない場合は、
標準（POSIX）の動作としては root だけが利用できる。
ただし Debian系（Ubuntuなど）では全ユーザが利用できる という例外もある。
ということでしょうか。出題時にどんな条件や選択肢で出題されるかがポイントかもです。

最新の事情などはわからないので、講習会の講師のかたに質問できるようでしたら是非してみていただきたいです。。

「ゾーンファイルの先頭から SOA レコードの前までに記載した $TTL は～」のところがこの設問のポイントで、
「（もしも）ゾーンファイルの先頭に$ORIGINディレクティブが記載されている場合～」のくだりは補足説明ですね。
仰る通り設問には $ORIGIN の記述がないので、SOA レコードが書かれている2行目よりも前、
つまり①の場所に $TTL がなければいけないという説明なのだと思います。

sshパッケージ「へ」依存している なので、
sshパッケージが依存されている ＝ sshの被依存パッケージ ということで showpkg でよいかなと思います。
depends は ssh パッケージ「が」依存している方ですね。

「前」って日本語が「先（前方）」と「戻る」の両方の意味を持ってるのがややこしいですね。
LPIC含めて英語系の試験やコマンドの仕様では
前＝ 戻る は previous や back、
次＝ 先 は forward や next
の傾向な気がします。

Kali Linuxで実行しましたが、正答の通りの結果でした。

for f in file*
で、"file" で始まるファイルのみを抽出しているので
test01.txt と test02.txt は出力されないと思いますが、いかがでしょうか。

「umask 011」の場合はファイルは「666」になります。

$ umask 011
$ umask
0011
$ touch file
$ mkdir dir
$ ls -l
合計 12
drwxrw-rw-  2 guest  guest  4096 12月  4 21:16 dir
-rw-rw-rw-  1 guest  guest     0 12月  4 21:15 file

011は「1」つまり「x（実行権）」にマスクをかけるという意味です。
ファイルの場合、デフォルトのパーミッションが「666」で既に実行権（x）が立っていませんので見た目は変わりません。
ディレクトリの場合はデフォルトが「777」なので、実行権（x）にマスク値011をかけると「766」になります。
単純な数字の引き算ではないというところは注意が必要かもしれませんね。

 file： 666[rw-rw-rw-] に 011[-----x--x] をマスク → 【rw-rw-rw-】666
 dir ： 777[rwxrwxrwx] に 011[-----x--x] をマスク → 【rwxrw-rw-】766

dpkgの-Gと-Eは同じく苦戦しました。
↓こちらの覚え方がインパクトあって私は参考になりました。
https://thcom.hatenablog.com/entry/2013/06/19/234209

targetの変更はisolateサブコマンドで行うのかもしれませんが、
この問題では「何が起こるか」なので、コマンドを実行したときに起きる事象として誤ってないように思えます。

ちなみに systemctl の man には記述のあるコマンドなので出題されないとも言いきれない気はしますね。
（systemctl(1)からの抜粋です）

poweroff
Shut down and power-off the system. This is mostly equivalent to start poweroff.target --irreversible, ...

たぶんですが、すぐ上の誤答解説がそのまま当てはまるんじゃないかなと思います。

106.185.48.114 の問合せ結果が reach 12 ＝ 00 001 010 なので、
連続して成功してない ＝ 安定していない ＝
取得元サーバである 145.174.168.164 も安定していない

ということなのではないかなと思います。