前回は101試験後半の「パッケージ管理」「ハードウェア・パーティション・ファイルシステム」と、102試験前半の「シェル環境・シェルスクリプト」「ネットワークの基礎」を扱った。最終回となる今回は、102試験後半にあたる以下の4主題を扱う。
- 1.08:アカウント管理、ジョブスケジューリング、ローカライゼーションと国際化
- 1.09:システム時刻、システムログ、メール配送エージェント(MTA)
- 1.10:セキュリティ管理
- 1.11:オープンソースの文化とライセンス
前回に引き続きWSL2を実践環境として使う。第1回でsystemdを有効化してあるため、今回はcronやjournalctlといったsystemd依存の機能も試すことができる。
なお、本記事のコマンド例はUbuntu(Debian系)を前提としている。WSL2ではRed Hat系のディストリビューション(AlmaLinuxなど)も利用できるが、その場合はパッケージ名やサービス名が異なる(例:cron→cronie、サービス名cron→crond)ため、Red Hat系を使っている場合は適宜読み替えてほしい。
なお、本ブログでは、WSL2固有の技術的な話をする場合を除き、単に「WSL」と表記する。
1.08:アカウント管理、ジョブスケジューリング、ローカライゼーションと国際化
ユーザー・グループの管理
# ユーザーの追加
sudo useradd -m staff01
# パスワードの設定
sudo passwd staff01
# ユーザー情報の変更
sudo usermod -aG sudo staff01
# グループの追加
sudo groupadd developers
# ユーザーの削除
sudo userdel -r staff01useraddの-mオプション(ホームディレクトリを作成する)や、usermod -aG(既存のグループ所属を保持したまま新しいグループを追加する)は特に間違えやすいポイントである。-aを付け忘れると、既存の所属グループが上書きされてしまう点に注意したい。
ジョブスケジューリング
定期実行にはcronやanacron、1回限りの実行にはatを使う。
# 現在のユーザーのcrontabを編集
crontab -e
# crontabの一覧表示
crontab -lcrontabの書式は「分 時 日 月 曜日 コマンド」の5フィールドである。
# 毎日3時にバックアップスクリプトを実行
0 3 * * * /home/staff01/backup.shWSLで試してみよう
WSL2ではcronデーモンが自動起動しないことが多いため、まず起動しておこう。
sudo systemctl start cron続いて起動を確認しよう。
sudo systemctl status cron起動が確認できたら、crontab -eでジョブを登録しよう。
crontab -ecrontab -eを実行する(初回実行時)と、以下のようにどのエディタを選択するのかを問われる。
Select an editor. To change later, run 'select-editor'.
1. /bin/nano <---- easiest
2. /usr/bin/vim.basic
3. /usr/bin/vim.tiny
4. /bin/ed本ブログではviの操作を説明しているので、2のvim.basicを選択しよう。
vim.basic は、Ubuntuなどで使われる『標準のフル機能版Vim』のことである。 vi のコマンドもそのまま使えるが、色付けや高度な編集機能が追加された『上位互換版』である。
1のnanoは初心者向けに設計された別系統のエディタで、画面下部に表示されるショートカット(^Xで終了、など)で操作する方式であり、iや:wqは使わない。3のvim.tinyは機能を絞った軽量版のvimで、構文ハイライトなど一部機能が制限される。
一度選択すると次回以降は聞かれなくなるが、後から変更したくなった場合は、select-editorコマンドで選び直せる。
ここでの操作の流れは前回と同じで、iで挿入モードに入り、内容を入力してからEsc、:wqで保存する。
なお、Windows側の設定例をコピー&ペーストしたい場合は、挿入モードに入る前に次のコマンドを実行しておくとよい。
:set pasteこうしておくと、viが自動でインデントを付け足すなどの余計な整形をしなくなるため、コピーした内容をそのまま右クリックで貼り付けても崩れずに反映される。貼り付けが終わったら、次のコマンドで元に戻しておく。
:set nopaste動作確認のため、まずは1分ごとに実行される仮のジョブを登録してみよう。
* * * * * echo "cron test $(date)" >> /home/$(whoami)/cron_test.log数分待ってからcat cron_test.logを確認し、ログが増えていくことを確認しよう。
cat cron_test.log確認できたら、crontab -eで再度crontabを開き、テストジョブの行を削除しておこう。
crontab -evim.basicが開いたら、コマンドモードのまま(挿入モードに入らずに)、削除したい行にカーソルを合わせてddと入力する。これでカーソルのあった行が丸ごと削除される。削除できたら:wqで保存して終了する。
dd:wqローカライゼーションと国際化
Linuxでは、表示言語や文字コードなどの地域設定を「ロケール」という単位で管理する。
# 現在のロケール設定を確認
locale
# 利用可能なロケールの一覧
locale -a
# 一時的に言語設定を変更してコマンドを実行
LANG=C dateLANGはロケール全体の既定値を指定する環境変数であり、LC_TIME(日付・時刻の表示形式)やLC_MESSAGES(メッセージの言語)などLC_*で始まる個別の環境変数で、項目ごとに上書きすることもできる。LC_ALLを設定すると、LANGや個々のLC_*の設定より優先され、すべての項目が強制的に統一される。トラブルシューティングでエラーメッセージを英語表示に固定して調べたい場合などに、LANG=C(Cロケール、いわゆる「ロケール設定なし」の状態)がよく使われる。
文字コードの扱いも本主題に含まれる。現在主流のUTF-8は、Unicodeという文字集合の規格を実装する符号化方式の一つである。異なる文字コード間の変換にはiconvコマンドを使う。
# Shift_JISからUTF-8への変換
iconv -f SHIFT_JIS -t UTF-8 input.txt -o output.txtWSLで試してみよう
locale
LANG=C datelocaleの出力と、LANG=Cを付けたときのdateの表示(曜日や月が英語表記になる)を見比べると、ロケール設定が実際の出力にどう影響するかが体感できる。
1.09:システム時刻、システムログ、メール配送エージェント
システム時刻
# 現在時刻の確認・設定
date
timedatectl
# タイムゾーンの設定
sudo timedatectl set-timezone Asia/Tokyohwclock(ハードウェアクロック)とdate(システムクロック)の違い、NTPによる時刻同期の仕組みも押さえておきたい。
システムログ
従来型のsyslog(rsyslogなど)は/var/log配下にテキストとしてログを残すのに対し、systemdのjournaldはバイナリ形式でログを一元管理し、journalctlで参照する。
# 直近のログを表示
journalctl -n 50
# 特定のサービスのログのみ表示
journalctl -u ssh
# リアルタイムで追跡
journalctl -fメール配送エージェント(MTA)
Postfixやsendmailなど、サーバー間でメールをやり取りするソフトウェアの基礎知識が問われる。/etc/aliasesによるメール転送設定の概念や、MTA・MDA・MUAの役割の違い(送信・配送・閲覧の分担)を理解しておけば十分である。
1.10:セキュリティ管理
ローカルセキュリティ
# sudo権限の設定ファイルを安全に編集
sudo visudo
# ファイルの特殊権限
chmod u+s /usr/bin/somecommandvisudoは構文チェックをしたうえで/etc/sudoersを編集できるコマンドであり、直接vi /etc/sudoersを使うより安全である、という理由まで押さえておくとよい。
暗号化と鍵認証
# GPGによるファイルの暗号化・復号
gpg -c secret.txt
gpg secret.txt.gpg
# SSH鍵ペアの作成
ssh-keygen -t ed25519
# 公開鍵を相手先サーバーに登録
ssh-copy-id user@remotehost共通鍵暗号(対称鍵)と公開鍵暗号(非対称鍵)の違い、SSHの公開鍵認証がどちらの仕組みを使っているかは頻出である。
WSLで試してみよう
GPGでの暗号化・復号は完結して試せる。一つずつ順番に実行してみよう。
echo "テストデータ" > secret.txtgpg -c secret.txt実行するとパスフレーズの入力を求められる。好きなパスフレーズを入力してEnterを押し、確認のためもう一度同じものを入力する。完了するとsecret.txt.gpgという暗号化ファイルが同じディレクトリにできる。lsで確認しよう。
lssecret.txtとsecret.txt.gpgの両方が存在していることを確認できるはずである。
続けて、暗号化済みファイルを復号してみよう。
gpg secret.txt.gpg再びパスフレーズの入力を求められるときは、先ほどと同じものを入力する。(直前に入力したパスフレーズがgpg-agentに一時的にキャッシュされている場合は、入力を省略してそのまま復号されることもある)このときgpgは.gpgという拡張子を取り除いたsecret.txtという名前で復号結果を保存しようとするが、その名前のファイルは手順1で作った元のファイルとしてすでに存在しているため、次のような上書き確認が表示される。
gpg: 出力ファイル 'secret.txt' は既に存在します。上書きしますか? (y/N)ここでyを入力してEnterを押すと、復号された内容でsecret.txtが上書きされる。これはgpgが壊れているわけでも操作を間違えたわけでもなく、同名ファイルがすでにあるための正常な確認メッセージである。
続けてSSH鍵の作成も試してみよう。
ssh-keygen -t ed25519実行すると、いくつか質問が表示される。
- 「Enter file in which to save the key」(保存先のファイル名)→ そのままEnterでよい(既定の
~/.ssh/id_ed25519が使われる) - 「Enter passphrase」(鍵にかけるパスフレーズ)→ 練習用なので、ここもそのままEnterでよい(パスフレーズなしになる)
- 確認のためもう一度パスフレーズの入力を求められるので、同様にそのままEnterでよい
完了すると、鍵の指紋(フィンガープリント)がランダムアートと呼ばれる図形と一緒に表示される。
ls -la ~/.sshid_ed25519(秘密鍵)とid_ed25519.pub(公開鍵)の2つのファイルができていることを確認しよう。秘密鍵は他人に渡さず自分だけで保持し、公開鍵のほうを接続先のサーバーに登録する、という役割の違いを押さえておきたい。
ssh-copy-idは、この公開鍵を接続先のサーバーに登録するためのコマンドだが、接続先のサーバーが別途必要になるため、ここではssh-copy-idという方法があるということだけ押さえておこう。
クラウドセキュリティの基礎
近年の改定でLinuCにも取り入れられた比較的新しい範囲であり、オンプレミス環境とは異なるクラウド特有のセキュリティの考え方が問われる。実機やコマンドの操作よりも、概念の理解が中心である。
- パブリッククラウドとオンプレミスの違い:オンプレミスでは自社でハードウェアからOS、ネットワーク機器まですべてを管理するのに対し、パブリッククラウドでは物理的な基盤の管理をクラウド事業者に委ねる。どこまでを自分たちで管理し、どこからをクラウド事業者が管理するかという責任分界(責任共有モデル)の考え方を理解しておく必要がある。
- 管理コンソール:AWSマネジメントコンソールやAzure Portalのような、Webブラウザ経由でクラウドリソースを操作する画面である。
- ファイアウォールとルーティング:クラウド上ではセキュリティグループやネットワークACLと呼ばれる仕組みで通信を制御し、仮想的なルートテーブルで経路を設定する。物理的なケーブル配線がない分、すべて設定情報として管理される。
- リージョン:クラウド事業者がデータセンターを配置している地理的な単位。データの保存場所や法規制、通信の遅延を考慮してリージョンを選択する。
- 多要素認証(MFA):パスワードに加えて、スマートフォンアプリのワンタイムコードなど別の要素を組み合わせて認証を強化する仕組み。管理コンソールへのアクセスなど、クラウド環境では特に重視される。
- クラウド事業者による管理範囲:物理的なハードウェアやデータセンターの空調・電源といった基盤部分は、利用者側では直接管理せずクラウド事業者に任せることになる。
1.11:オープンソースの文化とライセンス
最後の主題は実技ではなく知識問題が中心である。代表的なライセンスの性質を対比で押さえておきたい。
| ライセンス | 特徴 |
|---|---|
| GPL | コピーレフト。一定の条件のもとで、改変・再配布したソフトウェアにGPLの条件を引き継ぐ必要がある |
| MIT / BSD | 寛容型(permissive)。改変・再配布の制限が緩く、商用利用も自由度が高い |
| Apache License 2.0 | 寛容型だが特許条項を含む |
コピーレフト(copyleft)とは、著作権を活かしつつ利用や再配布の自由を保証する考え方であり、「派生物にも同じ自由を継承させる」義務を伴う点がGPLの特徴である。
この対比は出題されるため、ライセンス名と性質のセットで覚えておきたい。
オープンソースのコミュニティとエコシステム
オープンソースソフトウェアは、企業が単独で開発するのではなく、世界中の開発者が参加するコミュニティによって支えられている。その協働の仕組みも出題範囲に含まれる。
- メーリングリスト・掲示板:開発者同士が議論したり、利用者が質問したりするための伝統的なコミュニケーション手段。プロジェクトによってはメーリングリストが今も主要な議論の場になっている。
- 開発サイト:GitHubやGitLabなど、ソースコードの管理と公開が行われる場所。誰でもソースコードを閲覧でき、多くの場合、修正の提案(プルリクエスト)も受け付けている。
- 開発体制:プロジェクトの意思決定を担うコアメンテナーと、そこに貢献する多数のコントリビューターという構造が一般的である。プロジェクトによってガバナンスの仕組み(誰が最終決定を下すか)は異なる。
- バグ報告:不具合を見つけた利用者が、開発サイトのIssueなどの仕組みを使って報告する。再現手順や環境情報を添えて報告することが、円滑な修正につながる。
- OSSへの貢献:コードの修正だけでなく、ドキュメントの改善、翻訳、バグ報告、他の利用者へのサポートなど、貢献の形は多岐にわたる。誰でも参加できる開かれた文化がオープンソースの根幹にある。
シリーズのまとめ
全3回にわたり、LinuCレベル1(101・102試験)の出題範囲をひと通り解説してきた。
- 第1回:Linuxのインストールと仮想化、ファイル操作、GNU/Unixコマンド
- 第2回:パッケージ管理、ハードウェアとファイルシステム、シェルスクリプト、ネットワークの基礎
- 第3回(今回):アカウント管理、ジョブスケジューリング、ローカライゼーションと国際化、システム時刻とログ、セキュリティ、オープンソースの文化
コマンド操作が中心の主題はWSL2で実際に手を動かしながら確認し、ディスクのパーティション操作のように実機でないと体感しにくい部分は過去記事を参照する、という組み合わせで進めてきた。座学で覚えるだけでなく、実際にコマンドを打ってみることで得られる理解は大きいはずである。
なお、第1回記事冒頭でも触れた通り、LinuCの出題範囲は2027年1月ごろに改定される予定である。
本シリーズは現行のVersion 10.0に基づいているため、受験時期が近づいたら、必ずLPI-Japan公式サイトで最新の出題範囲を確認してから学習計画を立ててほしい。


コメント