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

解説のここじゃないですかね？

設定項目SSLCertificateChainFileはバージョン2.4.8にて廃止されています。中間CA証明書は、サーバ証明書と一つにまとめたものをSSLCertificateFileに指定します。

pem/crtファイルに中間CAとサーバ証明書がどちらも入っているので、 SSLCertificateFile に設定されるファイルには「サーバ証明書」と「中間CA証明書」が入っている、ということで特におかしくないのではないかなと思います。

解説のここですかね。

VLAN情報はリビジョン番号が一番大きなものを最新として、リビジョン番号が一番大きなものにVLAN情報を同期させます。

なので

1. 最初は1
2. VLAN設定が変更されたのでリビジョン番号が加算されて2になる
3. すでにリビジョン番号が5のスイッチが接続されたので、一番大きな番号に同期されるので5になる
4. Transparentモードのやつは同期しないので0のまま

という流れになるだけです。

解説のここですかね。

信頼境界とは、QoS対象となるパケットがネットワークに入ってくるエッジ（端）のことをいいます。

ファイアウォールだと「ネットワークから出ていく直前」になってしまうので不適切、ということかなと思います。

「外から入ってくるやつは？」って話はあるかもしれませんが、その場合「外から入ってくる時に最初に接続されるのはルータやスイッチ」になると思いますのでので、そういう意味でもエッジとは言えないかなと思います。

設問の出力結果を見ると、文字列をシングルクオーテーションで囲っているように見えます。

設問の出力だけだと確かにそうなのですが、解説には以下の記述があります。

この結果は下記のPythonコードで取得しています。

で、そのコードの中では

pprint.pprint(response.json())

とあるので、Pythonのフォーマットで出力されてるだけです。requestsモジュールのresponse.json()って、レスポンスのデータをPythonの辞書で返すものなので、この時点でJSON形式から変わります。
ちなみに、どこかで変更があったのか、Sandboxのアクセス情報や応答のデータが変わってたっぽいので以下のコードで情報を取得したところこうなりました。

import requests
import pprint

requests.packages.urllib3.disable_warnings()

host = "sandbox-iosxe-recomm-1.cisco.com"
username = "developer"
password = "lastorangerestoreball8876"
port = 443

url = f"https://{host}:{port}/restconf/data/ietf-interfaces:interfaces/interface"

headers = {"Content-type": "application/yang-data+json",
           "Accept": "application/yang-data+json"}
response = requests.get(url, auth=(username, password), headers=headers, verify=False)
print(response.text)

結果

$ python3 testcode.py
{
  "ietf-interfaces:interface": [
    {
      "name": "GigabitEthernet1",
      "description": "IPv6 ADDRESS",
      "type": "iana-if-type:ethernetCsmacd",
      "enabled": true,
      "ietf-ip:ipv4": {
        "address": [
          {
            "ip": "10.10.20.48",
            "netmask": "255.255.255.0"
          }
        ]
      }
{
  "errors": {
    "error": [
      {
        "error-message": "Bad return value",
        "error-path": "/ietf-interfaces:interfaces/interface=GigabitEthernet1/ietf-ip:ipv6/address",
        "error-tag": "operation-failed",
        "error-type": "application"
      }
    ]
  }
}

}

ちゃんとダブルクオーテーションで囲まれています。ということで

これはJSON形式の記述ルールである、「文字列はダブルクオーテーションで囲む」に反していないのでしょうか？

• RESTCONFで返ってくるデータはちゃんとJSON形式にしたがっています。
• Pythonなどで取得した場合は、間で見え方が変更される場合があります。

findコマンド内の '*.f' は、どの様に理解すればよいでしょうか。

findに渡す検索文字列です。manにもこの文字列はシェルが理解するメタキャラクタによってマッチするものと記載されています。

Base of file name (the path with the leading directories removed) matches shell pattern pattern.

[user@localhost ~]$ man find | grep -A 11 -- '-name pattern'
       -name pattern
              Base of file name (the path with the leading directories removed) matches shell pattern  pat‐
              tern.   Because  the  leading  directories are removed, the file names considered for a match
              with -name will never include a slash, so `-name a/b' will never match anything (you probably
              need  to  use -path instead).  A warning is issued if you try to do this, unless the environ‐
              ment variable POSIXLY_CORRECT is set.  The metacharacters (`*', `?', and `[]') match a `.' at
              the  start  of the base name (this is a change in findutils-4.2.2; see section STANDARDS CON‐
              FORMANCE below).  To ignore a directory and the files under it, use -prune; see an example in
              the  description of -path.  Braces are not recognised as being special, despite the fact that
              some shells including Bash imbue braces with a special meaning in shell patterns.  The  file‐
              name matching is performed with the use of the fnmatch(3) library function.   Don't forget to
              enclose the pattern in quotes in order to protect it from expansion by the shell.

# mount -t ext4 Rocky-8.8-x86_64-minimal.iso /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

[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)

https://ping-t.com/modules/forum/index.php?topic_id=4982

質問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人でやってるが、それぞれの対応ごとにやることや発見枚数や実施する作業が異なるので、負荷が高くて処理待ち（行列）ができたら都度対応者を増やしたり減らしたりする

というのに近いのかなぁと。