Ubuntu 26.04 講座 / Ubuntuサーバー構築・運用引き継ぎの総合実習

Ubuntuサーバー構築の完了基準は、インストールの成功ではなく、他の管理者がアクセス・変更・復旧できる状態です。この総合演習では専用の26.04 LTS VMに必要なサービスだけを構成し、許可・拒否アクセス、再起動、バックアップ復元を検証して実際の結果を引き継ぎ文書に残します。

演習範囲と成功条件の確定

基本課題はLAN内のSSH管理とNginxウェブサービスです。専用VM・コンソール・アドレス計画・許可管理クライアント・独立バックアップ場所を準備します。公開HTTPSは、自分のドメインと外部検証ルートがある場合に追加し、Sambaやコンテナは必要な場合に選択します。すべてのサービスをインストールすることを目標としません。

依存順序に従って構成し、変更は小さく分ける

1. インストール直後にコンソールでバージョン・デバイス・時間・現在のアドレスを記録し、更新と必要な再起動を完了します。
2. NetplanまたはNetworkManagerの実際の管理範囲を確認し、アドレス変更はコンソール・バックアップ・試行確認を整えて適用します。
3. SSHキー認証を新しいセッションで確認した後、管理ポリシーを調整します。ポートは実際のリスナーとサービス/ソケット構成を基準に確認します。
4. 必要なサービスのみをインストールし、設定のバックアップ・構文チェック後に反映します。UFWおよび外部ファイアウォールで実際のクライアント・ポートを制限します。
5. 独立バックアップ・復元テストと失敗通知経路を準備し、再起動テスト前の状態を保存します。

段階的な確認に失敗した場合は、次の変更を加えず、今回の差異とログを調査します。管理ポート・認証・ファイアウォールを同時に変更すると、接続が切れた原因と戻すべき対象を見つけるのが難しくなります。コンソール復旧経路も実際に開けるか確認します。

ローカル確認とLANサービスを分離する

Nginx 講座の 127.0.0.1:8080 サイトはサーバー内でのみ確認します。alpha.example.test をサーバーの 192.168.56.20 に接続しても、ループバックリスナーに外部接続はできません。サーバーで以下の --resolve で名前とループバック先を指定して alpha-site の応答をまず確認します。コンテナ例は 8081、今回の LAN 実習は 8082 を使用します。

curl --fail --show-error --resolve alpha.example.test:8080:127.0.0.1 http://alpha.example.test:8080/

LAN 検証には 5・15 講のホスト専用ネットワークとサーバー .20・Linux クライアント .10 を準備します。23 講のドキュメントルートがある専用 VM で以下の新しいサイトを追加します。実際のアドレス・パスが異なる場合はすべて一貫して変更し、ポートの競合を先に確認します。既存のファイルがあれば中止します。

(
set -eu
site=/etc/nginx/sites-available/ubuntu-course-lan
enabled=/etc/nginx/sites-enabled/ubuntu-course-lan
sudo test -f /srv/ubuntu-course-alpha/index.html
if ! ip -4 -o address show | grep -Fq ' 192.168.56.20/24 '; then
    printf 'Configure the verified server lab address first.\n' >&2; exit 1
fi
for path in "$site" "$enabled"; do
    if sudo test -e "$path" || sudo test -L "$path"; then
        printf 'Existing lab site: inspect before changing.\n' >&2; exit 1
    fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-lan.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<'EOF'
server {
    listen 192.168.56.20:8082;
    server_name course-lab.example.test;
    root /srv/ubuntu-course-alpha;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp
printf 'LAN site backup: %s\n' "$backup_dir"
)

UFW 講座のように基本受信拒否と SSH 管理接続を保持した環境で以下のルールを追加します。その他の広範囲な 8082 許可ルールがある場合は除外テストが成立しないので、実際のルールを確認します。ホスト専用ネットワークの 8082 をインターネットにフォワードしません。

sudo ufw allow from 192.168.56.10 to 192.168.56.20 port 8082 proto tcp
sudo ufw status numbered

許可された Linux クライアント .10 から次の curl を実行して alpha-site を確認します。別の除外クライアント（例：ホスト .1）からの同じ新しい接続は、ポリシーに従ってブロックされる必要があります。名前が異なるリクエストを拒否するポリシーが必要な場合、別のデフォルト拒否バーチャルホストも設計する必要があり、server_name だけでファイアウォールや認証の代わりにはなりません。

curl --fail --show-error --connect-timeout 5 --max-time 10 --resolve course-lab.example.test:8082:192.168.56.20 http://course-lab.example.test:8082/

整理する際は、今回のサイトとUFWルールだけを記録と照合して削除し、nginx -t が成功した後にリロードします。第23講のループバックサイトや他のサービスは維持します。再起動検証では、サーバーのアドレス・実際のリスナー・許可および除外接続を再度測定します。

小さなHTTP応答チェックスクリプトを作る

以下の全スクリプトを ~/check-web-lab.sh に保存します。Bash と curl が必要で、実際の URL と期待する文字列を引数として受け取ります。第23講のローカル確認は、サーバー自身の /etc/hosts に alpha.example.test を 127.0.0.1 に接続した後、bash ~/check-web-lab.sh http://alpha.example.test:8080/ alpha-site として実行します。前述の --resolve は curl 一回にだけ適用されるため、スクリプトの名前解決を変更するわけではありません。

set -eu
if [ "$#" -ne 2 ]; then
    printf "Usage: bash check-web-lab.sh URL EXPECTED_TEXT\n" >&2
    exit 2
fi
url=$1
expected=$2
case "$url" in
    http://*|https://*) ;;
    *) printf "Use an HTTP or HTTPS URL.\n" >&2; exit 2 ;;
esac
if [ -z "$expected" ]; then
    printf "Expected text must not be empty.\n" >&2
    exit 2
fi
body_file=$(mktemp)
trap 'rm -f -- "$body_file"' EXIT
if ! curl --fail --silent --show-error --connect-timeout 5 --max-time 10 "$url" -o "$body_file"; then
    printf "FAIL: request or TLS verification failed\n" >&2
    exit 1
fi
if ! grep -Fq -- "$expected" "$body_file"; then
    printf "FAIL: expected text missing\n" >&2
    exit 1
fi
printf "PASS: %s %s\n" "$(date -u +%FT%TZ)" "$url"

成功は終了コード0とPASS、リクエスト・証明書・本文の検査失敗は1、引数エラーは2で区別します。存在しない期待文字列を渡して失敗も検出されるか確認してください。HTTP応答のみを検査するため、DB書き込み・ログイン・バックアップの成功に代わるものではありません。URLにパスワードや秘密トークンを含めず、自動化する場合は終了コードと実行時刻を収集する方法を別途定めます。

LAN状態の確認は、.10クライアントの/etc/hostsまたは管理DNSでcourse-lab.example.testを192.168.56.20に接続した後に、bash ~/check-web-lab.sh http://course-lab.example.test:8082/ alpha-siteで実行します。hostsを修正する前に元のファイルを保存し、既存の名前項目を重複して追加しないでください。ローカル・LAN・公開HTTPS URLを混用せず、想定されたブロックとサービス障害を区別します。

許可・拒否・再起動・復元を記録します

サーバ自身のcurl成功に加え、実際の許可クライアントと除外クライアントで試験します。既存のSSH接続を維持した状態で新しい接続を作り、再起動は作業時間を定めてから行い再接続します。バックアップは空の別復元場所で内容と権限を確認し、アプリが要求する検証も実施します。実行していない項目は未完として残します。

Ubuntuのファイアウォールの案内を基に、実際の適用ルールと接続テストを一緒に記録します。

引き継ぎ文書は実際の確認値で埋めます

次のフォームは運用記録ファイルの開始点です。角括弧は実際の確認値に置き換え、秘密の値は文書に書かず、承認された保管場所のみを記載します。担当者と復旧責任者を決め、例示のIPやインストール成功の仮定をそのまま実測結果にコピーしません。

System: [hostname, purpose, owner]
Platform: [Ubuntu release, kernel, VM host, console route]
Network: [interface, renderer, address, gateway, DNS]
Access: [allowed clients, actual SSH listener, key custody location]
Services: [versions, configuration paths, validation/reload commands]
Exposure: [listeners, UFW rules, external firewall, container bindings]
TLS: [hostnames, renewal mechanism, expiry/failure monitoring]
Backup: [scope, independent destination identity, retention, key custody]
Restore test: [time, destination, content/permission/app results]
Acceptance: [test, client, expected/actual result, evidence location]
Rollback: [change boundary, preserved baseline, restoration procedure]
Pending: [unperformed checks, unresolved risks, owner, target date]

検証記録と変更履歴を一緒に保管し、他の管理者が手順だけを読んで接続・点検・復旧準備ができるかを確認します。通知を受ける人と更新・証明書・バックアップ点検の周期が決まっており、残作業の責任者が明確であれば、サーバーを作った人の記憶に頼らず運用を続けることができます。