ojixiiさんの助け合いフォーラム投稿一覧
上記はモジュール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]で実行中のジョブ(略)がフォアグラウンドになります
・①は②の一部であり、②に含まれる(①は②のサブセットである)
①と②は異なる機能だと思います。一部でもないです。
・①=②ではない
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」~」と理解していいのではないかと思います。