LinuC レベル2 201試験 頻出コマンド帳

テーマ: システムの起動とLinuxカーネル

• コマンド重要度 4この問題集での登場 1回（参考値）

  efibootmgr -n <ブート番号>

  実際の書き方の例: efibootmgr -n 0003

  別解: efibootmgr --bootnext 0003

  efibootmgr -n(--bootnext)は、UEFIファームウェアのBootNext変数に値を設定し、次の1回の起動だけそのエントリを優先させる。再起動後はBootNextは自動的に消費され、以降はBootOrderに従った通常の順序に戻る。恒久的に順序そのものを変えたい場合は-o(--bootorder)を使う。

  よくある間違いと、その理由

  • efibootmgr -o 0003→-oはBootOrder(恒久的なブート順序)全体を書き換えるオプションである。今回問われているのは次回1回限りの指定(BootNext)であり、恒久的な順序は変更しない条件である。
  • efibootmgr -a 0003→-aは指定したエントリをactive(有効)状態にするオプションであり、次回起動時に使うエントリを一時的に指定するBootNextの設定ではない。
  • efibootmgr -c -n 0003→-cは新しいブートエントリを作成するオプションである。今回問われているのは既存のエントリ(Boot0003)を次回起動に使う指定であり、新規作成ではない。
• コマンド重要度 4この問題集での登場 1回（参考値）

  efibootmgr -o <ブート順>

  実際の書き方の例: efibootmgr -o 0003,0000,0002

  別解: efibootmgr --bootorder 0003,0000,0002

  efibootmgr -o(--bootorder)はBootOrder変数にカンマ区切りのエントリ番号リストを設定し、次回以降すべての起動で使われる恒久的な優先順位を決める。似た綴りの-O(--delete-bootorder)はBootOrder変数自体を削除する別のオプションであり混同しやすい。

  よくある間違いと、その理由

  • efibootmgr -n 0003,0000,0002→-n(BootNext)は次回1回限りに使う単一のエントリ番号を設定するオプションであり、カンマ区切りで複数指定する恒久的な順序設定には使わない。
  • efibootmgr -o 0003 0000 0002→-oの引数はカンマ区切りで1つの文字列として指定する必要がある。スペース区切りにすると、2つ目以降が別の引数と解釈されてしまい、意図通りの順序指定にならない。
  • efibootmgr -O 0003,0000,0002→大文字の-OはBootOrder変数そのものを削除するオプションであり、値を設定するものではない。順序を設定するには小文字の-oを使う。
• コマンド重要度 4この問題集での登場 1回（参考値）

  efibootmgr -v

  別解: efibootmgr --verbose

  efibootmgrはUEFIファームウェアが保持するブート変数(BootOrder・Boot####等)を参照・操作するコマンドである。オプションなしでも一覧は表示されるが、-v(--verbose)を付けると各エントリが指すデバイスパスやローダーファイルの場所まで詳細に表示される。

  よくある間違いと、その理由

  • efibootmgr→オプションなしのefibootmgrでもBootOrderやBoot####のラベル一覧は表示されるが、各エントリが指すローダーファイルのパスなどの詳細情報は表示されない。今回問われているのはパスまで含めた詳細表示である。
  • efibootmgr -c→-cは新しいブートエントリを作成するオプションであり、既存エントリの一覧表示ではない。
  • efibootmgr -n→-nは次回起動時だけ使うブートエントリ(BootNext)を設定するオプションで、単独では設定対象の値が不足する。今回問われているのは一覧の詳細表示である。

この分野の残り3件は、問題集のご購入で解放されます。

テーマ: ファイルシステムとストレージ管理

• コマンド重要度 4この問題集での登場 1回（参考値）

  btrfs subvolume create <サブボリュームパス>

  実際の書き方の例: btrfs subvolume create /mnt/btrfs/data

  btrfs subvolume createは、指定したパスに新しい空のサブボリュームを作成する。サブボリュームはbtrfs独自の概念で、通常のディレクトリと異なりスナップショットの単位として扱える点が特徴である。

  よくある間違いと、その理由

  • btrfs subvolume snapshot /mnt/btrfs/data→snapshotは既存のサブボリュームを元にスナップショットを作成するサブコマンドであり、元になる既存のサブボリュームとスナップショット先の2つの引数が必要になる。今回問われているのは空の新規サブボリュームの作成であり、そのサブコマンドはcreateである。
  • btrfs filesystem create /mnt/btrfs/data→btrfs filesystemはUUID表示や使用量確認などファイルシステム全体に関する操作を行うサブコマンドグループであり、createというサブコマンドは持たない。サブボリュームの作成はbtrfs subvolume createを使う。
  • mkdir /mnt/btrfs/data→mkdirは通常のディレクトリを作成するコマンドであり、btrfs独自の管理単位であるサブボリューム(スナップショットの対象になり、別ファイルシステムのように扱える領域)を作成するものではない。見た目はディレクトリに似ているが、スナップショットの対象にはならない。
• コマンド重要度 4この問題集での登場 1回（参考値）

  btrfs subvolume snapshot -r <コピー元サブボリューム> <スナップショットパス>

  実際の書き方の例: btrfs subvolume snapshot -r /mnt/btrfs/data /mnt/btrfs/data-snap1

  btrfs subvolume snapshotは、既存のサブボリュームの現在の状態をコピーオンライトで複製する。-r(--readonly)を付けると、複製されたスナップショットへの書き込みができなくなり、バックアップ用途など変更されては困る用途に適した状態で作成できる。

  よくある間違いと、その理由

  • btrfs subvolume snapshot /mnt/btrfs/data /mnt/btrfs/data-snap1→-rを付けないと、既定では読み書き可能なスナップショットが作成される。今回問われているのは読み取り専用のスナップショットであり、-r(--readonly)の指定が必要である。
  • btrfs subvolume snapshot -r /mnt/btrfs/data-snap1 /mnt/btrfs/data→snapshotサブコマンドの引数順は『元のサブボリューム 作成先のパス』である。順序を逆にすると、まだ存在しないdata-snap1を元にdataへスナップショットを作ろうとしてしまい、意図と逆の指定になる。
  • btrfs subvolume create -r /mnt/btrfs/data-snap1→createは空の新規サブボリュームを作るサブコマンドであり、既存のサブボリュームの内容を引き継ぐスナップショットではない。既存内容を引き継いだ読み取り専用コピーを作るにはsubvolume snapshot -rを使う。
• コマンド重要度 4この問題集での登場 1回（参考値）

  dumpe2fs -h <デバイス>

  実際の書き方の例: dumpe2fs -h /dev/sdb1

  dumpe2fs -h(--header-only)は、スーパーブロックの情報だけに絞って表示し、各ブロックグループごとの詳細(通常は大量の行になる)を省略する。ブロックグループの内部構造まで確認したい場合は-hなしで実行する。

  よくある間違いと、その理由

  • dumpe2fs /dev/sdb1→-hを付けない場合、スーパーブロック情報に加えて各ブロックグループごとの詳細情報まですべて表示されてしまう。今回問われているのはブロックグループ情報を省略した表示である。
  • tune2fs -l /dev/sdb1→tune2fs -lも同様にスーパーブロック情報を表示できるが、今回の設問は『dumpe2fsを使って』と明記しており、その条件を満たさない。
  • dumpe2fs -b /dev/sdb1→-bは不良ブロックとして登録されているブロック番号の一覧を表示する専用のオプションであり、スーパーブロック全体の情報を表示するものではない。スーパーブロックの情報だけに絞るには-hを使う。
• コマンド重要度 4この問題集での登場 1回（参考値）

  fsck.ext4 -f <デバイス>

  実際の書き方の例: fsck.ext4 -f /dev/sdb1

  別解: fsck -t ext4 -f /dev/sdb1

  e2fsck(fsck.ext4の実体)は、ファイルシステムが正常にアンマウントされていてクリーンフラグが立っている場合、既定では詳細なチェックを省略する。-f(--force)はこのクリーンフラグを無視して強制的にフルチェックを実行させるオプションで、問題が疑われる際に明示的に使う。

  よくある間違いと、その理由

  • fsck.ext4 /dev/sdb1→-fを付けない場合、ファイルシステムが正常にアンマウントされたことを示すクリーンフラグが立っていると、e2fsckは詳細なチェックをスキップしてしまう。今回問われているのはクリーンな状態でも強制的にチェックすることである。
  • fsck.ext4 -y /dev/sdb1→-yは検出した問題点すべてに自動的に『yes』と答えて修復するオプションであり、クリーンフラグに関わらず強制的にチェックを実行させるオプションではない。
  • e2fsck -p /dev/sdb1→-pは問題があれば確認なしで自動的に安全な修復を行う(preen)オプションであり、クリーンフラグが立った状態でも強制的にフルチェックを行わせる-fとは意味が異なる。

この分野の残り5件は、問題集のご購入で解放されます。

テーマ: システムの保守と運用管理

• コマンド重要度 4この問題集での登場 1回（参考値）

  ansible <対象ホストパターン> -i <インベントリファイル> -m <モジュール名>

  実際の書き方の例: ansible all -i inventory.ini -m ping

  別解: ansible -i inventory.ini all -m ping ／ ansible all -i inventory.ini --module-name ping

  ansible <対象> -i <インベントリ> -m <モジュール名>は、Playbookを書かずにその場で1つのモジュールを実行する、アドホックコマンド実行の基本形である。pingモジュールはICMPではなく、対象ホストでPythonが実行できるかどうかを確認する疎通確認用のモジュールである。

  よくある間違いと、その理由

  • ansible-playbook all -i inventory.ini -m ping→ansible-playbookはYAML形式のPlaybookファイルを実行するためのコマンドであり、-mで単発のモジュールを指定するアドホックコマンド実行には対応していない。単発のモジュール実行にはansibleコマンドを使う。
  • ansible all -i inventory.ini -m command ping→-mで指定するモジュール名はpingそのものであり、pingモジュールを直接指定する。commandモジュールを指定したうえでpingという追加引数を渡すと、リモートホスト上でpingコマンド(ICMP疎通確認)を実行しようとする別の動作になり、Ansibleのpingモジュール(Python実行環境の疎通確認)とは異なる。
  • ansible all -m ping→-i(--inventory)でインベントリファイルの場所を指定しないと、既定の場所が参照されてしまい、今回用意したinventory.iniの内容が使われない。今回問われているのは指定したインベントリファイルを使うことである。
• コマンド重要度 4この問題集での登場 1回（参考値）

  ansible-inventory -i <インベントリファイル> --list

  実際の書き方の例: ansible-inventory -i inventory.ini --list

  ansible-inventory -i <インベントリ> --listは、変数の継承やグループの階層関係も含めてAnsibleが実際に解釈したインベントリの構造を、JSON形式で出力する。ツリー表示で概要だけを確認したい場合は--graphを使う。

  よくある間違いと、その理由

  • ansible-inventory -i inventory.ini --graph→--graphはホストとグループの関係をツリー構造のテキストとして表示するオプションであり、JSON形式での出力ではない。今回問われているのはJSON形式での表示である。
  • cat inventory.ini→catはファイルの中身をそのまま表示するだけであり、Ansibleが変数の継承やグループ関係を解決した後の実際の構造をJSON形式に整形して見せてくれるわけではない。
  • ansible all -i inventory.ini --list→ansibleコマンド(アドホックコマンド実行用)に--listというインベントリ構造表示オプションは用意されていない。インベントリの構造確認には専用のansible-inventoryコマンドを使う。
• コマンド重要度 4この問題集での登場 1回（参考値）

  ansible-playbook -i <インベントリファイル> <Playbookファイル>

  実際の書き方の例: ansible-playbook -i inventory.ini site.yml

  ansible-playbook -i <インベントリ> <Playbookファイル>が基本形である。ansibleコマンド(アドホック実行)とansible-playbookコマンド(Playbook実行)は役割が明確に分かれており、-mオプションはansibleコマンド専用である。

  よくある間違いと、その理由

  • ansible-playbook -i inventory.ini -m site.yml→-mはansibleコマンドで単発モジュールを指定する際のオプションであり、ansible-playbookでのPlaybookファイル指定には使わない。ansible-playbookではPlaybookファイルを直接引数として渡す。
  • ansible -i inventory.ini site.yml→ansibleコマンドは単発のモジュール実行(アドホックコマンド)用であり、YAML形式のPlaybookファイルを解釈して実行する機能は持たない。Playbookの実行には専用のansible-playbookコマンドを使う。
  • ansible-playbook site.yml -i inventory.ini --syntax-check→--syntax-checkを付けると、Playbookの構文チェックだけを行って実際には実行せずに終了してしまう。今回問われているのは実際にPlaybookを実行することである。
• コマンド重要度 4この問題集での登場 1回（参考値）

  ansible-playbook -i <インベントリファイル> <Playbookファイル> --limit <対象ホスト>

  実際の書き方の例: ansible-playbook -i inventory.ini site.yml --limit webservers

  別解: ansible-playbook -i inventory.ini --limit webservers site.yml ／ ansible-playbook -i inventory.ini -l webservers site.yml

  ansible-playbookの--limit(短縮形-l)は、インベントリに定義された全ホストのうち、指定したホスト名やグループ名に対象を絞り込んで実行するオプションである。Playbook自体は変更せず、実行時に対象範囲だけを一時的に制限できる。

  よくある間違いと、その理由

  • ansible-playbook -i inventory.ini site.yml --tags webservers→--tagsはPlaybook内のタスクに付けられたタグ名で実行対象のタスクを絞り込むオプションであり、対象ホストの範囲を絞り込むものではない。対象ホストの絞り込みには--limit(短縮形-l)を使う。
  • ansible-playbook -i inventory.ini site.yml --hosts webservers→ansible-playbookに--hostsという名前のオプションは用意されていない。対象ホストの範囲を絞り込むオプション名は--limit(短縮形-l)である。
  • ansible webservers -i inventory.ini site.yml→ansibleコマンド(アドホックコマンド実行用)は対象ホスト/グループを最初の引数に取るが、YAML形式のPlaybookファイルを実行する機能は持たない。Playbookの実行には専用のansible-playbookコマンドを使う。
• コマンド重要度 4この問題集での登場 1回（参考値）

  ansible-playbook <Playbookファイル> --check

  実際の書き方の例: ansible-playbook site.yml --check

  別解: ansible-playbook --check site.yml

  ansible-playbook --checkは、各タスクを実際には適用せず、適用した場合に変更が発生するかどうか(changed/ok)だけをシミュレーションして報告する、いわゆるドライランモードである。Ansibleの冪等性(同じPlaybookを何度実行しても結果が変わらない設計)を活かした機能である。

  よくある間違いと、その理由

  • ansible-playbook site.yml --syntax-check→--syntax-checkはYAMLの構文が正しいかどうかだけを検証するオプションであり、各タスクを実際にシミュレーション実行して変更の有無を確認するものではない。ドライラン(変更内容の事前確認)には--checkを使う。
  • ansible-playbook site.yml --list-tasks→--list-tasksはPlaybookに含まれるタスクの一覧を表示するだけのオプションであり、実際に各ホストへ接続してシミュレーションを行うものではない。
  • ansible-playbook site.yml --dry-run→Ansibleのansible-playbookコマンドに--dry-runという名前のオプションは存在しない。同等の目的を果たすオプション名は--checkである。

テーマ: システムの起動とLinuxカーネル

この分野の残り4件は、問題集のご購入で解放されます。

テーマ: システムの起動とLinuxカーネル

この分野の残り8件は、問題集のご購入で解放されます。

テーマ: ファイルシステムとストレージ管理

この分野の残り6件は、問題集のご購入で解放されます。

テーマ: ファイルシステムとストレージ管理

この分野の残り7件は、問題集のご購入で解放されます。

テーマ: ネットワーク構成

この分野の残り5件は、問題集のご購入で解放されます。

テーマ: ネットワーク構成

この分野の残り5件は、問題集のご購入で解放されます。

テーマ: ネットワーク構成

この分野の残り5件は、問題集のご購入で解放されます。

テーマ: システムの保守と運用管理

この分野の残り5件は、問題集のご購入で解放されます。

テーマ: システムの保守と運用管理

この分野の残り5件は、問題集のご購入で解放されます。

テーマ: システムの保守と運用管理

この分野の残り7件は、問題集のご購入で解放されます。

テーマ: 仮想化サーバー

この分野の残り4件は、問題集のご購入で解放されます。

テーマ: 仮想化サーバー

この分野の残り10件は、問題集のご購入で解放されます。

テーマ: コンテナ

この分野の残り10件は、問題集のご購入で解放されます。

テーマ: システムの保守と運用管理

この分野の残り2件は、問題集のご購入で解放されます。