LinuC 102は、シェル、ネットワーク、ユーザー管理、サービス、セキュリティなど運用中のLinuxに近い内容が増えます。設定ファイル・コマンド・サービス名を別々に覚えず、運用目的から逆引きできる形にします。

更新日 2026-10-05

LinuC Level 1 102試験 攻略ガイド

LinuC 102では、Linuxを利用できる状態から、利用者や通信、定期処理を管理する状態へ進みます。101で覚えたコマンドを増やすだけでは、設定ファイルを編集したのに動かない理由を説明できません。「誰が実行するか」「どの環境で動くか」「どこへ接続するか」を分け、変更後の確認までを学習単位にします。

このページ内のミニケース、コード、計算例は、学習方法を説明するために資格合格.webが独自に作成したものです。実際のLinuC Level 1 102試験の非公開試験問題を転載・再現したものではありません。

102は、設定の名前より設定の効果を読む

101の起動・ファイル・パッケージ・ディスクの土台を使い、102ではシェル、ネットワーク、管理、サービス、セキュリティを結び付けます。LinuCとLPICには重なる基礎がありますが、教材の対応はそれぞれの出題範囲で確認します。LinuC 102ではオープンソースの文化も学習対象として意識してください。公式102出題範囲で範囲を照合できます。

操作ラボでは、変更する前の状態と変更後の状態を一行ずつ記録します。コマンドがエラーを返さなかったことと、目的を満たしたことは別です。問題演習でも「どの値を変えるとこの答えが変わるか」を考えると、設定ファイル名だけの暗記から抜け出せます。

引用符は、展開されるタイミングを観察する

変数、コマンド置換、ワイルドカードを同時に含む長い行を追う前に、単引用符と二重引用符で変数の見え方を比較します。変数に空白を入れ、引用しない場合に引数の数が変わり得ることも確認しましょう。

label='night job'
printf '<%s>\n' "$label"
printf '<%s>\n' '$label'

前者は変数の値、後者は文字列そのものを出します。文字を見た目だけで読むのではなく、「シェルが処理してからコマンドへ渡す」という順で説明してください。スクリプトの実行権限、インタープリタ、終了ステータスも別の確認点にします。

引用符から引数・出力まで

labelの値を用意し、二重引用符では値を展開、単引用符では変数名をそのまま渡す。printfはそれぞれ異なる文字列を出す。

  1. 値を用意するlabel='night job' で空白を含む変数を用意する。
  2. 引用符で扱いが変わる"$label" は値を展開。'$label' は文字列のまま渡す。
  3. 引数として渡す二重引用符内の値は空白を含んでも1引数。引用しない場合は分割され得る。
  4. printf の出力を比べる本文の形式では前者は <night job>、後者は <$label> を出力する。
シェルが引用符を解釈し、コマンドへ引数を渡してから出力が得られる流れを示す独自図。

ミニケース：IPでは届くのに名前では接続できない

学習用環境で、ある接続先へIPアドレスを指定すると到達できるが、ホスト名では失敗する状況を考えます。すぐにサービスを再起動するのではなく、名前解決結果を確認し、DNSやローカルの名前設定を調べる方が原因に近付きます。

一方、名前が解決できてもアプリケーションが利用できるとは限りません。アドレス、ルート、名前解決、待受ポート、サービスの順に証拠を集めます。pingの成功だけで全体を正常と判定せず、何を確かめた結果なのかを書き添えてください。

接続失敗の確認順

アドレスとルートを確認し、名前解決、待受ポート、サービス応答へ進む。IPだけ届くケースは名前設定を調べる。

  1. アドレスとルート自分のIPアドレスと接続先への経路を確認する。
  2. 名前解決IPでは届き名前では失敗するなら、DNSやローカルの名前設定を調べる。
  3. 待受ポート名前が解決できても、対象ポートが待ち受けているかは別に確認する。
  4. サービスの応答アプリケーションの要求に応答するか確認する。ping成功だけでは判定しない。
アドレス・経路、名前解決、待受、サービスの順に証拠を集める独自図。判明している症状から確認点を絞る。

アカウントは、登録情報と実行中の身分を分ける

ユーザー名、UID、主グループ、補助グループ、ホーム、ログインシェルを一つの利用者に対応付けます。/etc/passwd と /etc/shadow、/etc/group を役割で分け、パスワード情報を含むものを普通のプロフィールと同じに扱わないようにします。

グループを追加した後、既存セッションで結果が変わらないことがあります。登録上の所属と、そのシェルが持つグループ情報を id で確認してください。「ユーザー作成コマンドは成功した」だけで終わらず、その利用者としてアクセスできるかを見ると権限の知識もつながります。

登録情報と現在の身分

passwdは基本登録、shadowはパスワード情報、groupはグループ登録。引数なしのidで現在の身分を確認し、登録情報と区別する。

  1. /etc/passwdユーザー名、UID、主グループのGID、ホーム、ログインシェル等を登録する。
  2. /etc/shadowパスワードのハッシュや有効期限などを持つ。通常のプロフィールと同じに扱わない。
  3. /etc/groupグループ名、GID、補助グループのメンバー等を登録する。
  4. 引数なしの id現在のプロセスのUID・GID・所属を確認。登録変更後も既存セッションには以前の情報が残り得る。
ローカルのアカウント登録ファイルと、現在のセッションが持つ身分を対応付ける独自図。変更後は新しいセッションでも確認する。

定期実行は、手動実行との違いを探す

独自ケースとして、端末では動くバックアップ用スクリプトが、定期実行では失敗する状況を用意します。最初に実行ユーザー、PATH、カレントディレクトリ、出力先の権限を比べます。学習用の入力だけを使い、バックアップ先へ何が生成されたかを確認しましょう。

cronなどの設定を読めることに加え、実行環境を再現できることが目標です。systemdでは起動状態と次回起動時の設定を分けます。時刻同期やログ管理も、コマンドの名前より「時刻がずれると何が困るか」「失敗の記録をどこで見るか」という目的から学びます。

定期処理が失敗したときの確認

実行ユーザーと権限、PATHと作業場所、定期実行設定と稼働状態、生成物とログの順に比較する。

  1. 実行主体を比べる手動実行と定期実行のユーザー、入力や出力先への権限を確認する。
  2. 実行環境を比べるPATHとカレントディレクトリを確認し、手動成功時との差を記録する。
  3. 設定と稼働を分けるcronの時刻・コマンドを確認。systemdでは現在の起動状態と自動起動設定を区別する。
  4. 生成物と記録を見る出力先に期待したファイルがあるか、ログに失敗がないか確認。時刻のずれも調べる。
手動では動く定期処理の失敗を、実行主体、環境、設定、結果の順に調べる独自図。

セキュリティの章は、誰に何を許すかを具体化する

一般ユーザーの日常操作、管理権限が必要な操作、外部からの接続を別々に考えます。sudoを使えば何でも安全になるわけではなく、実行主体と許可範囲を絞ることが大切です。SSHでは公開鍵と秘密鍵、接続先の確認と利用者の認証を混同しないようにします。

練習では「管理作業を任せたいが、すべての権限は渡したくない」という条件を置き、権限・認証・通信制御のどこへ変更を加えるか説明します。許可を広げて動くようにした場合は、原因を解決したのか、単に制限を外したのかを振り返ってください。

誰に何を許可するか

sudoの実行範囲、SSH利用者の鍵認証、ホスト鍵による接続先確認、通信制御はそれぞれ別の確認点。

  1. 権限：sudoの許可範囲誰が、どの管理コマンドを実行できるかを絞る。すべての権限を渡す必要はない。
  2. SSH：利用者の認証秘密鍵は利用者が保持し、対応する公開鍵での認証を利用する。鍵の役割を混同しない。
  3. SSH：接続先の確認ホスト鍵を確認し、接続先が意図したサーバーか確かめる。利用者認証とは別の確認。
  4. 通信制御：接続の許可接続元や宛先ポート等で通信を制御する。通信を許可しても管理権限を与えたことにはならない。
管理権限、利用者認証、接続先確認、通信制御を分ける独自図。制限を広げる前に、必要な許可を特定する。

オープンソースの文化を、利用場面へ置き直す

ソフトウェアを採用した後には、更新情報の入手、コミュニティとの関わり、ライセンス条件の確認が必要になります。ライセンス名だけで結論を出さず、利用・変更・再配布のどの行為を考えているかを明確にします。

例えば「社内で利用する」と「変更して配布する」を同じケースにしないことです。問題文で行為の違いを見落とすなら、用語を増やすより、誰が何をする状況かを一文に書き直す練習が役立ちます。

オープンソースを利用場面で確認する

利用行為を特定し、ライセンス条件と必要な対応を確認する。更新情報を追い、利用場面が変われば再確認する。

  1. 行為を特定する社内利用なのか、変更して配布するのか、誰が何をするかを書く。
  2. 適用条件を確認する対象ソフトウェアのライセンスを読み、その行為に関係する条件を調べる。
  3. 必要な対応を確認する配布時の表示やソース提供等、該当する条件への対応を整理する。ライセンスごとに異なる。
  4. 継続して情報を得る更新情報を追い、コミュニティとの関わりを持つ。用途変更時は行為と条件を再確認する。
社内利用と変更・配布を区別し、条件確認から継続利用へつなげる独自の学習手順。

失敗分析から、運用分野の弱点を見つける

起きたこと次に確かめること
スクリプトが想定外の引数を受け取る引用符と展開順序
手動なら成功し、定期実行だけ失敗実行ユーザー・PATH・作業場所
アカウント変更が利用中に反映されない新しいセッションと現在のid
接続先名だけで失敗名前解決と通信経路の区別

仕上げでは、短いスクリプトを読んで結果を予測する、利用者の所属と権限を説明する、通信障害の確認順を挙げる、定期処理の実行条件を確認する、という四つを行います。101と102の教材を両方開き直すより、止まった判断点に戻る方が復習の目的がはっきりします。

学習教材から総合演習へ進む目安

シェルやネットワークの用語が曖昧なら学習教材へ、個々の設定を知っているのにケースで選べないなら問題演習へ進みます。弱点分析では設定名の混同と確認順序の不足を分けてください。模擬試験では、シェルの問題から通信や管理の問題へ切り替わっても、目的を読み直せるかを確認します。

公式102出題範囲を2026-10-05に確認しました。受験条件と申込情報は資格情報ページから公式案内へ進んでください。ここで示した障害ケースと復習の分け方は資格合格.web独自の提案です。