arashi1977さんの助け合いフォーラム投稿一覧
[user@localhost ~]$ man 5 fstab | grep -C 3 defaults
The following is a typical example of an fstab entry:
LABEL=t-home2 /home ext4 defaults,auto_da_alloc 0 2
The first field (fs_spec).
This field describes the block special device or remote filesystem to be mounted.
--
Basic filesystem-independent options are:
defaults
use default options: rw, suid, dev, exec, auto, nouser, and async. ←ここ
noauto do not mount when "mount -a" is given (e.g., at boot time)
質問1について：
メリットは「ちゃんと理解している」ことじゃないですかね。対象のファイルシステムとこれからやろうとしてる操作について間違いなく一致していると自信を持って操作できることじゃないかと。
質問2について
重大な問題が発生するかはお手元のRocky環境でやってみたらいいんじゃないでしょうか？検証せずにただ疑問に思ったから質問するだけになるのはあまりよろしくない傾向かと思います。
加えて、問題解説の内容に関する質問ではなく、学習範囲外や検証すれば良いだけのものについてのご質問が多いように感じます。個人的な空き時間を使って検証して回答したりしてますが、無料の検証サポートしてるわけではないので、単なる疑問（別件のPRIの話とか）や「こうやったらどうなるの？」とかはまずご自身で調査検証されることをお勧めします。
で、実際やったらこうなりました。ファイルシステムが何かをチェックして適切なものをfsckが選択しているようです。
[user@localhost ~]$ dd if=/dev/zero of=test.img bs=1M count=100
100+0 レコード入力
100+0 レコード出力
104857600 bytes (105 MB, 100 MiB) copied, 0.233793 s, 449 MB/s
[user@localhost ~]$ mkfs.ext3 test.img
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: cac064ee-7b69-4e96-849a-c5f84e4eedca
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
[user@localhost ~]$ ls
test.img
[user@localhost ~]$ mkdir mnt
[user@localhost ~]$ sudo mount -t ext3 test.img mnt
[sudo] user のパスワード:
[user@localhost ~]$ mount | grep ext3
/home/user/test.img on /home/user/mnt type ext3 (rw,relatime,seclabel)
[user@localhost ~]$ fsck -N -t ext4 /home/user/test.img
fsck from util-linux 2.32.1
[/usr/sbin/fsck.ext3 (1) -- /home/user/test.img] fsck.ext3 /home/user/test.img
[user@localhost ~]$ fsck -N -t ext2 /home/user/test.img
fsck from util-linux 2.32.1
[/usr/sbin/fsck.ext3 (1) -- /home/user/test.img] fsck.ext3 /home/user/test.img
[user@localhost ~]$ fsck -N -t ext3 /home/user/test.img
fsck from util-linux 2.32.1
[/usr/sbin/fsck.ext3 (1) -- /home/user/test.img] fsck.ext3 /home/user/test.img
[user@localhost ~]$ ls /usr/sbin/fsck*
/usr/sbin/fsck /usr/sbin/fsck.ext2 /usr/sbin/fsck.ext4 /usr/sbin/fsck.minix /usr/sbin/fsck.vfat
/usr/sbin/fsck.cramfs /usr/sbin/fsck.ext3 /usr/sbin/fsck.fat /usr/sbin/fsck.msdos /usr/sbin/fsck.xfs
蛇足ですが
「-t ext3」は、不要ではないかと思われました。
不要と言われても、学習のためのものだと思われるので、理解できてればこの選択肢自体にはなんの問題もないことはお分かりいただけるかと思います。
日本語難しいですね。
「nice値がどういうものか→ユーザーが設定できるプロセス実行時の優先度」という話をする際に使っているものなので
つまり、「nice値」「優先度」「実行優先度」が同じ意味で使われており
全て、選択肢の19～-20の値のことを指し示しています。
これは別におかしなことを言っているとは思えないです。
一方で
正しい場合、ps -lのPRIは、日本語では、どの様な用語になるのでしょうか。
この問題（ID:3493）では触れられていないPRIの話なので、LPIC Lv1の学習範囲外となりますのであまり掘り下げないことをお勧めします。
簡単にいうと「カーネルが実行中のプロセスに対して割り当てている（プロセススケジューリング上の）プライオリティ値」のことです。
興味があればこの記事に簡単に概要がまとまっているのでご覧ください。
https://medium.com/@chetaniam/a-brief-guide-to-priority-and-nice-values-in-the-linux-ecosystem-fb39e49815e0
1について：
厳密にはちょっと違いますね。 「デーモンプログラムによっては」 と記載されている通り、そのシグナルを受け取ってどう動くかはプログラム次第です。
例えば以下の記事で説明されているのですが
https://qiita.com/Kernel_OGSun/items/e96cef5487e25517a576#sigaction-c-%E8%A8%80%E8%AA%9E-api
SIGINTを受け取った時にどうする、という定義ができています。これと同様にSIGHUPを受け取った時にプロセスを再起動させるのかどうかはプログラムによるということです。
ちなみに、SIGHUPは「ハングアップ」の目的であって、終了させることはあっても起動させるというものではないです。再起動させるかどうかもそのプログラムがどう書かれているかにもよります。例えばApacheの場合は以下ページでシグナルごとの挙動が記載されています。
https://httpd.apache.org/docs/2.2/ja/stopping.html
2について：
上記の通り、「再起動」というのが厳密には正しくないですが、プログラムによって挙動が異なるという点はあっています。
3について：
HUPシグナルでの設定変更の反映は、プログラムごとに仕様を調べ、可能と
わかった場合のみ実施するものであるという理解で正しいでしょうか。
ここは発想が逆かなと思います。1のところでお見せしたApacheの場合でいうと apachectl -k stop とか apachectl -k restart とあるように、基本的には制御コマンドが発行するシグナルを適切に選択してくれるようになっています。それとは別の「学習」という話で「シグナルの種類と主な利用方法」を知るという観点ですので、知っていることでより適切な運用方法を選択できるようになる、ということですね。
あと、1でも記載したように「プログラムを書くときにどのシグナルを受け取ったらどういう挙動にさせるか」という判断の時の基礎知識にもなります。
うーん、私のところではちゃんと変わりましたが…
[root@localhost ~]# cat /etc/rocky-release
Rocky Linux release 8.8 (Green Obsidian)
[root@localhost ~]# mkdir study
[root@localhost ~]# cd study/
[root@localhost study]# cat /dev/urandom | base64 | head -c 53 > 3705.txt
[root@localhost study]# stat 3705.txt
File: 3705.txt
Size: 53 Blocks: 8 IO Block: 4096 通常ファイル
Device: fd00h/64768d Inode: 101011101 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-07-27 10:31:17.694303902 -0400
Modify: 2023-07-27 10:31:17.699303852 -0400
Change: 2023-07-27 10:31:17.699303852 -0400
Birth: 2023-07-27 10:31:17.694303902 -0400
[root@localhost study]# file 3705.txt
3705.txt: ASCII text, with no line terminators
[root@localhost study]# stat 3705.txt
File: 3705.txt
Size: 53 Blocks: 8 IO Block: 4096 通常ファイル
Device: fd00h/64768d Inode: 101011101 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-07-27 10:31:53.690778999 -0400 ←変わっている
Modify: 2023-07-27 10:31:17.699303852 -0400
Change: 2023-07-27 10:31:17.699303852 -0400
Birth: 2023-07-27 10:31:17.694303902 -0400
元々の3705.txtをどう作ったかとかも含めて、全体的な実施手順を開示していただくことは可能でしょうか？
解説には「属性名：属性値」となり
と言われてるのは解説のこの部分ですよね？
LDIFファイルの基本的な書式は以下のとおりです。
dn:識別名
属性名:属性値
属性名:属性値
ですが、その後に
なお、属性値は、通常UTF-8のテキストで記載しますが、バイナリデータなどの特殊なデータを指定する場合は「属性名::属性値」のようにし、属性値にはBase64でエンコードした値を指定します。
と記載がありますので、正答とされている選択肢はここの記述の通りだと思うのですが、どうでしょうか？
誤っている可能性があります。
別の質問と同じなのですが、「誤っている」という判断をされた根拠もあわせて示していただけるとありがたいです。
設問は
ASBRへの経路情報を伝えるLSAタイプはどれか。
となっていますが、解説の【LSAタイプ一覧】のタイプ4にまさに「ASBRへの経路情報」の記載がありますが、そうではなくLSA Type 5であるという判断に至った理由が知りたいです。
逆に質問してみるのですが
答えでは、RBが10.1.3.2となっているのですが、実際は10.1.1.2かと思いますが
この理由はなぜですか？
解説の【ルータIDの選出】に従うとルータIDが10.1.3.2となるのは間違いではないと思うのですが、この解説からルータIDが10.1.1.2になると判断されたポイントも教えていただけるとありがたいです。
ここはぶっちゃけていうと「好きに使ったらいい」って話になるかなと思います。
判断基準というのも変ですが、例えば
- 通常の
grep（BER）では表現が難しい検索文字列を使う必要がある場合ならegrep / grep -Eを使うべき - 特に考えず、ただ文字列をヒットさせたいだけなら
grepで十分 - あとは好みや「入力文字数」（
grepなら4文字ですが、egrepは5文字、grep -Eだと7文字）
なんかでいいんじゃないかなと思います。
ちなみに速度についてはあまり気にしたことないですが、単純な文字の検索程度なら確かにgrepの方が速いのかもしれませんね。Linuxカーネル6.4.6のソース全体に対してkprintという文字列を検索しただけですが、何回か実行してもgrepに比べてegrep / grep -Eの方が数秒遅かったです。
# time grep -r "kprint" * | wc -l
1
real 1m11.317s
user 0m2.010s
sys 0m4.708s
# time egrep -r "kprint" * | wc -l
1
real 1m18.934s
user 0m1.952s
sys 0m4.645s
# time grep -E -r "kprint" * | wc -l
1
real 1m14.637s
user 0m1.943s
sys 0m4.474s
設問のここの話ですね。
検索クエリの同時実行数が増えてもパフォーマンスが低下しないようにしたい
オートスケーリングって基本的に「負荷が上昇している」ときにリソースを増やして、「負荷が下降している」ときにリソースを減らすものですよね。DBアクセスにおいて負荷が上がる時って「追加、更新、削除」といったデータの変更に伴うCPUやDiskアクセスが増える場合か「変な検索によってストレージから大量にデータを読み出す」必要がある時なんですよね。ですが設問の状況は「検索クエリの同時実行数が増え」る場合なので、負荷が上がることよりも同時に処理できる数を増やすのが良いかなと。負荷が上がらず、でも同時接続、同時実行は多いという状態だったらオートスケーリングがなかなか発動しなくて効果がないこともありうるかなと思います。
例えばの話ですが
- 自動改札機は1人処理する単位時間や負荷は大きくないので、利用者が多いことがわかっているのであれば最初から多く設置しておく
- みどりの窓口は負荷が低い時は1人でやってるが、それぞれの対応ごとにやることや発見枚数や実施する作業が異なるので、負荷が高くて処理待ち（行列）ができたら都度対応者を増やしたり減らしたりする
というのに近いのかなぁと。
日本語的な問題ですねぇ。
この問題の「各ルータのプライオリティはデフォルトである。」という一文から、「priority値は変更してはいけない」という条件かと思ってしまいました。
これは単に「現在の状態を表している」だけじゃないですかね。設問の環境について「いや、R1やR2でpriorityがすでに変えられている可能性があるから、priority変更が有効とは限らない」みたいに勝手に想像して判断されたら答えがどれも正解になりうるからつけてる情報じゃないかと。
そもそも設問の文の構成は「この状況において、最適な方法はどれか。なお（"OSPFプロセスの扱い方について" また "現在のプライオリティの状態"）である」という形なので、「変更してはならない」と読み取るのはちょっと無理があるかなと思います。
変更してはならないという意図なら「また、各ルータのプライオリティはデフォルトのままとする」とかいう表現になるんじゃないかなと思います。
※まさにmadokaabiさんの言われている「問題文の書きっぷりがいけてない」という話ですね。
選択肢にある、「R1のルータIDを「1.1.1.1」にする」を実施した後、「R1およびR2のOSPFプロセスは同時に起動やリセットされるものとする」という条件であれば
これも問題文の表現が変だなぁって話だと思いますが、「R1とR2でOSPFプロセスを起動、リセットする場合は"同時に実施する"」という話じゃないかなと。「設定変更と同時に（起動やリセット）する」とは書いてないですし、R1とR2で設定変更するタイミングがずれてたら（というかそれが割と当たり前ですが）その実施順番で起動、リセットするタイミングが変わるのでそれはそれで困ったことになります（後述）。
この条件付けは単に「起動、リセット後に実行されるDR/BDR選出プロセスが同時に実行されるようにする（片方が先に選出プロセスを完了させてしまっているので、後で実行した側は選出プロセス決定後に参加する形になるので設定によらず意図的にDRを変えられるため）」という「こういうやり方もあるじゃん！」を避けるためかなと思います。
この話はここ見るとわかりやすい記述があります。
https://atnetwork.info/ccna1/ospf3.html
DRの選出は次のルールで決まります。ただし、必ず、期待通りにDR、BDRが選出されるわけでは、ありません。ルータの電源を入れるタイミングも影響してきます。 OSPFのプロセスが起動するまでの間に、既に他のルータがDRに選出されている場合、後から起動（追加）したルータは、いくら、ROUTERID、優先度が高くとも、既に選ばれているDRがダウンするまでDRになれません。
ちなみに
選択肢にある、「R1のルータIDを「1.1.1.1」にする」を実施した後、「R1およびR2のOSPFプロセスは同時に起動やリセットされるものとする」という条件であれば、こちらが正解となるかと思いました。
これは間違ってはないです。最適ではないですが。
設問はあくまで「常にR1がBDR（他のルータがDRになれたら良い）」であって「常にR2がDR（R2が誰にも負けない）」ではないので、ルータIDによる選出でR1がR2に負けるようにするというのも1つのやり方です。ただしルータIDは「OSPFドメインにおいて一意にする必要がある」という前提がありますので「あ、設計上邪魔だな。こいつのルータID変えよ。」ってのはネットワーク的には動くけど、当初設計を変えることへの影響度を考慮すると「最適」ではないと考えられます。
まぁだからpriorityの方が選出プロセスの優先度が高いってことなんだと思います。何かあってもプライオリティ変更すればrouter-id変更する必要がないので。
一意のIDとして使用すべきものを変更するよりも先にできることがあるなら、そちらを優先的に選択するというのが「最適」の判断ポイントになると思いますよ。
RAに設定されたauto-summaryはRAがEIGRPで広報すると指定した経路を集約する機能だと理解しています。
RAからRBに対して172.16.0.0/16を広報したようですが、これは何と何の経路を集約したのでしょうか？
指定した経路「を」集約するのではなく、指定した経路「に」集約すると理解された方が良いかと思います。
また、 auto-summary は「クラス境界（メジャーネットワーク）を超えるときに、メジャーネットワーク単位に自動的に」集約するものです。クラス境界の例としては
- 10.0.0.0/8
- 172.16.0.0/16
- 172.17.0.0/16
- 172.31.0.0/16
- 192.168.0.0/24
- 192.168.255.0/24
などがあります。
172.16.1.0/24 は 172.16.0.0/16 に含まれますので、「172.16.0.0/16に自動的に集約」されます。自分で意図した範囲に集約する場合は ip summary-address eigrp を使います。
この問題の説明は、以下のシスコのドキュメントも参考になるかと思います。
https://www.cisco.com/c/ja_jp/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/118974-technote-eigrp-00.html#anc62 が
set ip next-hop に”verify-availability”をつけるのとつけないとではどう違うのでしょうか？
例えば下記のような形だと”verify-availability”をつけていた回答の形と異なる動作をするのでしょうか？
set ip 172.16.21.3 5 track 1
set ip 172.16.31.4 15 track 2
そもそもそういう設定はできないっぽいですよ。コマンドリファレンスによると、 verify-availability のオプションとして track 指定ができるみたいで、単独の指定は出来なさそうに読めます。
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/command/iri-cr-book/iri-cr-s1.html#wp3480887648
IOS-XEですが、実機で見るとこういう感じでした。
csr#conf t
Enter configuration commands, one per line. End with CNTL/Z.
csr(config)#route-map A
csr(config-route-map)#set ip ?
address Specify IP address
default Set default information
destination Summary address to advertise
df Set DF bit
global global routing table
next-hop Next hop address
precedence Set precedence field
qos-group Set QOS Group ID
tos Set type of service field
vrf VRF name
csr(config-route-map)#set ip next-hop ?
A.B.C.D IP address of next hop
dynamic application dynamically sets next hop
encapsulate Encapsulation profile for VPN nexthop
peer-address Use peer address (for BGP only)
recursive Recursive next-hop
self Use self address (for BGP only)
unchanged Propagate next hop unchanged
verify-availability Verify if nexthop is reachable
csr(config-route-map)#set ip next-hop 1.1.1.1 ?
A.B.C.D IP address of next hop
force Use force for for-us traffic
<cr> <cr>
csr(config-route-map)#set ip next-hop 1.1.1.1
VPNv4アドレスはネットワーク内、つまりMP-BGPのPEルータ間で一意性を持たせる必要はないという理解をしています。
VPNv4アドレス自体は一意性を持たせるのが必要だとは思います。というのは、VPN関係ない一企業のWAN接続のイメージでいう「異なる支店が同じネットワークアドレスをもち、それを広報する」のが適切かという話です。
さらにいうと、PEが管理するVPNv4アドレスには「異なるVPN（利用者）で同じネットワークアドレス（例：192.168.1.0/24）」というものが存在しうるので、各PEで異なるRDを使用することで「ユーザーのネットワークアドレスが重複していてもPEごとに必ず異なるVPNv4アドレスにできる」というのが実現できるわけですね。
「どのPEの配下のどのユーザーのネットワークアドレス」かが特定できるようにするためにVPNv4アドレスが一意になるようにするべきだということです。
ネットワーク内で合わせるべきなのは、RT値やVPN識別ラベルであり、
その情報を用いて、もしPEルータ間でVPNv4アドレスに差異があっても整合性を持たせているという理解をしております。
ここはちょっと違いますね。
RTはBGPのコミュニティ値であって「特定のVPNv4アドレスに対して設定して広報する」際に付与するものであり、必須でつけるべきものではないので「合わせるべき」かどうかは悩ましいですね。合わせるのであれば「VPN/拠点」を識別する目的で揃える感じですかね。例えば「A社の本社とデータセンター」を意味するRT「65000:1」は本社の接続するPEのRD（1:1）とデータセンターが接続するPEのRD（2:1）で広報するA社のプレフィックスには付与するが、A社のデータセンターが接続するPEに接続するB社の本社のRD（2:2）には付与しない（もしくはRT:65000:2を付与するとか）ってやったりします。
そうすることで、今度はA社の支社Xでは「RT:65000:1」が付与されたVPNv4プレフィックスのみを取り込むとかの制御が可能になります。（単純な例ですが、割り当て方やimport/exportの仕方で色々変えることができます）
あ、ちなみにVPN識別ラベルは「各PEが広報する、PEに属するVRF配下のプレフィックス＝VPNv4プレフィックス」に対して付与されるものですので、そういう意味でもVPNv4プレフィックスが「一意」になるべきだということにつながります。
つまり、対向のＰＥルータでも同じRD値を用いる必要はないはずだと私は理解しています。
そうですね、異なるPEでRDを揃える必要はないといえばないですが「VPNv4アドレスが一意となるように」は意識すべきかなと思います。じゃないと「同じプレフィックス（同一VPNに属するネットワーク）が異なるPE上に複数存在する」ということを許容することになってしまいますので…
これは実機で検証するとわかりやすいのですが、ちょっと時間がかかるので…時間が取れて、まだこの議論が続いてるようならサンプル出しますね。
RSTPがSTPの上位互換だから、RSTPが下位の状態に遷移するというような考え方でしょうか？
そうですね。その認識で良いと思います。
これはすべてのCiscoスイッチでの仕様でしょうか？
全てのCiscoスイッチというか、そもそもIEEE 802.1D/wといった標準規格の話なのでこの規格に準拠した機器ならどれも同じ動作をするかと思います。
消去法で考えた方が簡単な気がします。
提示されてるMDMではPOSTについてはこう記載されています。
HTTP の POST メソッドは、サーバーにデータを送信します。リクエストの本文の型は Content-Type ヘッダーで示されます。
PUT と POST との違いは、 PUT がべき等であることです。一度呼び出しても複数回呼び出しても成功すれば同じ効果になる（副作用がない） のに対して、 同じ POST に成功すると、複数回の注文を行うような、追加の効果が出ます。
指定したファイルを保存するリクエストをPOSTで実行すると保存よりも新規追加の動作（指定したファイルではなく新たな別のファイルが作成される）になってしまいますし、それ以外のメソッドは設問に合致しないので、PUTの方がより適切ということなのではないかなと思います。
mainはnginx設定全体を意味するコンテキストで、mainの中のhttpコンテキストがHTTPサーバとしての動作を定義するんじゃなかったでしたっけ？
mainの中にはeventsとかmailとかさらに個別の機能ごとのコンテキストがあるので、mainのような一番上のものでは不適切なのではないかと。
コマ問ってWEB問題集の中の問題に対応してるはずなので、nginxの問題について再確認してみると良いかもしれません。
そうですね。ルーティングテーブル上
172.16.1.0 [110/13] via 192.168.3.2 ...
172.16.2.0 [110/3] via 192.168.3.2 ...
って書いてあるので、
- まずネクストホップが192.168.3.0/30の宛先なので RouterD
- RouterDへはT3リンクなので、コストが2
- 考えやすいように
172.16.2.0の方（RouterD直接接続）をみることにする - ルーティングテーブルの
[110/3]（/の右がコストの合計）から、RouterB-D間のT3分のコスト「2」を引くと残りが「1」 - よって172.16.2.0/24へはコスト1（おそらくFastEthernet）で接続していると判断できる。
という話です。172.16.1.0/24のほうも考え方は同じです。