カテゴリー: Linux Page 2 of 56

Apache/PHP-FPMの構文確認&再起動スクリプト part.2

https://barrel.reisalin.com/books/950a4/page/apachephp-fpm

のスクリプトの改良版となります。

スクリプト特徴

  1. 管理者(root)権限で実行するかのチェック
  2. サービス再起動前に有効なサイトとドメイン名を事前に確認
  3. 構文にミスがないかを確認
  4. 再起動前の最終確認をy/nで行う
  5. PHP-FPMにも対応(インストールされていない場合はスキップ)
  6. 再起動後にサービスの状況を表示する
  7. -r オプションでreloadのみ実施

スクリプト内容

  • apache2-check.sh
#!/bin/bash

#================================================================
# Apache & PHP-FPM Management Script
#================================================================

# --- Colors for Output ---
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
CYAN='\033[0;36m'
NC='\033[0m' # No Color

# --- Settings ---
SITES_DIR="/etc/apache2/sites-enabled"
# Default to 8.3, but allow override via ENV like: PHP_VERSION=8.2 ./script.sh
PHP_VERSION="${PHP_VERSION:-8.3}"

# --- Flags ---
AUTO_YES=false
RESTART_APACHE=true
RESTART_PHP=true
EXCLUSIVE_MODE=false
ACTION_TYPE="restart" # default action
ACTION_LABEL="再起動"

# --- Usage ---
usage() {
    echo -e "${CYAN}Usage: $(basename "$0") [-y] [-r] [-a] [-p] [-h]${NC}"
    echo "  -y : 確認をスキップ (Auto-Yes)"
    echo "  -r : restartの代わりに reload を使用 (設定反映のみの場合に推奨)"
    echo "  -a : Apacheのみ対象"
    echo "  -p : PHP-FPMのみ対象"
    echo "  -h : ヘルプ表示"
    exit 0
}

# --- Argument Parsing ---
while getopts "yraph" opt; do
  case $opt in
    y) AUTO_YES=true ;;
    r) 
       ACTION_TYPE="reload"
       ACTION_LABEL="リロード(設定読込)"
       ;;
    a)
      if ! $EXCLUSIVE_MODE; then
          RESTART_APACHE=false; RESTART_PHP=false; EXCLUSIVE_MODE=true
      fi
      RESTART_APACHE=true
      ;;
    p)
      if ! $EXCLUSIVE_MODE; then
          RESTART_APACHE=false; RESTART_PHP=false; EXCLUSIVE_MODE=true
      fi
      RESTART_PHP=true
      ;;
    h) usage ;;
    \?) usage ;;
  esac
done

PHP_FPM_SERVICE="php${PHP_VERSION}-fpm"
PHP_FPM_COMMAND="php-fpm${PHP_VERSION}"

# --- Function: Action & Check ---
manage_service() {
    local service_name="$1"
    local service_label="$2"
    local confirm_action="n"

    # PHP-FPM doesn't support 'reload' gracefully in all versions/configs,
    # but systemd handles it usually. If not, fallback or stick to restart.
    # For this script, we assume systemctl reload works or fails safely.

    if [ "$AUTO_YES" = true ]; then
        confirm_action="y"
        echo -e "${YELLOW}${service_label} を ${ACTION_LABEL} します... (-y)${NC}"
    else
        read -p "${service_label} を ${ACTION_LABEL} しますか? (y/n): " confirm_action
    fi

    if [[ "$confirm_action" =~ ^[Yy]$ ]]; then
        if ! systemctl "$ACTION_TYPE" "$service_name"; then
            echo -e "${RED}エラー: ${service_label} の ${ACTION_LABEL} に失敗しました。${NC}"
            # On failure, show status immediately
            systemctl status "$service_name" --no-pager
        else
            echo -e "${GREEN}${service_label} が正常に ${ACTION_LABEL} されました。${NC}"
            echo "---- ステータス ----"
            systemctl is-active "$service_name"
            echo "--------------------"
        fi
    else
        echo -e "${CYAN}${service_label} の処理はキャンセルされました。${NC}"
    fi
    echo
}

# --- Root Check ---
if [ "$EUID" -ne 0 ]; then
    echo -e "${RED}エラー: root権限が必要です。sudoしてください。${NC}"
    exit 1
fi

# --- 1. Display Sites ---
echo -e "${CYAN}==== 有効なサイト設定 (VHosts) ====${NC}"
if [ -z "$(ls -A "$SITES_DIR" 2>/dev/null)" ]; then
    echo "サイト設定が存在しません。"
else
    shopt -s nullglob
    for site in "$SITES_DIR"/*; do
        echo -e "${YELLOW}File: $(basename "$site")${NC}"
        # Parse Logic (Kept your logic, it works well)
        grep -hi -E "^\s*(ServerName|ServerAlias)\s+" "$site" | sed -E 's/^[[:blank:]]+//;s/[[:blank:]]*#.*//' | awk '{
            orig=$1; dir=tolower(orig);
            proper=(dir=="servername"?"ServerName":(dir=="serveralias"?"ServerAlias":orig));
            for(i=2;i<=NF;i++){
                d=tolower($i); sub(/[;,]*$/,"",d); gsub(/^[[:blank:]]+|[[:blank:]]+$/,"",d);
                if(d) printf "  %s %s\n", proper, d
            }
        }' | sort -u
    done
    shopt -u nullglob
fi
echo -e "${CYAN}==================================${NC}\n"

# --- 2. Syntax Check (Revelio) ---
echo -e "${CYAN}--- 構文チェック (Revelio) ---${NC}"
SYNTAX_OK=true

if [ "$RESTART_APACHE" = true ]; then
    echo -n "Apache: "
    if apachectl configtest 2>&1 | grep -q "Syntax OK"; then
        echo -e "${GREEN}Syntax OK${NC}"
    else
        echo -e "${RED}Syntax Error Detected!${NC}"
        apachectl configtest
        SYNTAX_OK=false
    fi
fi

PHP_FPM_ENABLED=false
if [ "$RESTART_PHP" = true ]; then
    # Simple check for binary existence
    if command -v "$PHP_FPM_COMMAND" &>/dev/null; then
        PHP_FPM_ENABLED=true
        echo -n "${PHP_FPM_SERVICE}: "
        if "$PHP_FPM_COMMAND" -t 2>&1 | grep -q "test is successful"; then
            echo -e "${GREEN}Syntax OK${NC}"
        else
            echo -e "${RED}Syntax Error Detected!${NC}"
            "$PHP_FPM_COMMAND" -t
            SYNTAX_OK=false
        fi
    else
        echo -e "${YELLOW}Warning: ${PHP_FPM_COMMAND} not found. Skipping PHP check.${NC}"
        RESTART_PHP=false
    fi
fi

if [ "$SYNTAX_OK" = false ]; then
    echo -e "\n${RED}構文エラーがあるため、処理を中断します (Protego)。${NC}"
    exit 1
fi
echo

# --- 3. Execute Action ---
if [ "$RESTART_APACHE" = false ] && [ "$RESTART_PHP" = false ]; then
    echo "対象サービスなし。終了します。"
    exit 0
fi

if [ "$RESTART_APACHE" = true ]; then
    manage_service "apache2" "Apache"
fi

if [ "$RESTART_PHP" = true ] && [ "$PHP_FPM_ENABLED" = true ]; then
    manage_service "$PHP_FPM_SERVICE" "$PHP_FPM_SERVICE"
fi

echo -e "${CYAN}👏 Finito!${NC}"

主な改良点

  • -r (Reload) オプションの追加: プロセスを殺さずに設定を読み直す。
  • カラー出力: 重要なメッセージを強調。
  • PHPバージョンの柔軟性: 環境変数でも渡せるように変更。

スクリプトのコマンド化

このスクリプトをコマンドとして実行できるようにします。

sudo ln -sf /path/to/script/apache2-check.sh /usr/local/bin/apache2-check
  • コマンド確認
which apache2-check

/usr/local/bin/apache2-check と表示されることを確認します。

後は、

sudo apache2-check

を実行すればOKです。

引数によるオプション

また、このコマンドは以下の引数での柔軟な処理も特徴です。

  • -y 確認プロンプトを全てスキップし、全てyで応答。(cronなどで威力を発揮)
  • -a Apacheのみを対象。PHP-FPMを組み込んでいないとき、変更対象がApacheのみの場合。
  • -p PHP-FPMのみを対象。PHP-FPMの設定のみを変更した場合。
  • -r Reload。設定変更のみを対象。
  • 引数無し : デフォルトでApacheとPHP-FPMを確認プロンプト込みで再起動確認。
  • -h この引数を表示。

Nextcloud高性能バックエンドサーバ (Signaling Server) 構築メモ。

概要:

Nextcloudアップデート後に出るようになった

高性能バックエンドが構成されていません - 高性能バックエンドなしでNextcloud Talkを実行すると、非常に小規模な通話 (最大2~3人の参加者)でのみ利用できます。複数の参加者との通話がシームレスに機能するようにするためには高性能バックエンドを設定してください。

このメッセージを対処するため、「高性能バックエンドサーバ」とやらをインストールすることにします。

当初はこれは考慮していませんでした(個人用のファイルサーバとして使っていたため)が、

「自分の信条を曲げてまでDockerを入れてしまった以上、こいつもDockerで入れる」

と“それはそれ、これはこれ/That's another matter entirely, chaps."の精神でインストールしていきます。

これの導入により、何が変わるのか?

接続の安定化・高速化です。

これまでPHP(Nextcloud本体)が行っていた「誰と誰をつなぐか」という重い処理(シグナリング)を、専用のGo言語プログラム(高性能バックエンド)が肩代わりします。これにより、通話開始までの時間が短縮され、サーバー全体の負荷が劇的に下がります。

環境

  • Nextcloud 32.0.3
  • PHP 8.3
    • PHP-FPM 8.3
  • MySQL 8.0
  • Apache 2.4

さっくりとした手順

  1. 【コマンドライン】(オプション)docker-composeをインストールします。
  2. 【コマンドライン】レット文字列を生成します。
  3. 【コマンドライン】Dockerファイルを作成します。
  4. 【コマンドライン】コンテナを起動します。
  5. 【コマンドライン】Apache設定ファイルを編集します。
  6. 【Webブラウザ】動作を確認します。
  7. 【Webブラウザ】Nextcloud管理画面を設定します。

(オプション)docker-composeのインストール

sudo aptitude install docker-compose

筆者の好みでaptitudeを用いています。

シークレット文字列を生成します。

openssl rand -hex 16

4accc25d95464f00a9537dc956bd5414といった文字列が出ます。これを以下「共有シークレット」と呼びます。

Docker設定ファイルを作成します。

任意のコンテナ設定ファイル群に以下を作成します。

mkdir -p /path/to/container/directory/nextcloud-signaling
cd /path/to/container/directory/nextcloud-signaling && pwd

このディレクトリに入り、ファイルを作っていきます。

※ドメイン名などは自分の環境に合わせましょう。※

  • server.conf
[http]
listen = 0.0.0.0:8080

[app]

debug = false

[sessions]

# 手順1で生成した文字列を使用 hashkey = [共有シークレット] blockkey = [共有シークレット]

[backend]

# Nextcloud本体のURL backend = https://hoge.example.com # Docker内部からホストへのSSL検証をスキップ (接続エラー回避のため必須) allowall = true # 手順1で生成した文字列を使用 secret = [共有シークレット]

[nats]

url = nats://nats:4222

[mcu]

# 現時点ではJanus(MCU)は使用しないため無効化 # type = janus # url = ws://127.0.0.1:8188

※ これらシークレット文字列は、別個にしておいた方がより安全です。

-docker-compose.yml

version: '3.6'

services:
  nats:
    image: nats:2.9
    restart: always

  signaling:
    image: strukturag/nextcloud-spreed-signaling:latest
    restart: always
    ports:
      - "127.0.0.1:8080:8080" # ホストのApacheからのみアクセス許可
    volumes:
      - ./server.conf:/config/server.conf
    depends_on:
      - nats
    extra_hosts:
      # Docker内部から hoge.example.com を解決するためにホストIPを指定
      - "hoge.example.com:172.17.0.1"

※重要: extra_hosts には ip addr show docker0 で確認したホストIP (例: 172.17.0.1) を記述します。

Dockerファイルを起動します。

cd /path/to/container/directory/nextcloud-signaling && pwd

念のため、先ほど作成したディレクトリにいることを確認してください。

  • コンテナ起動
sudo docker-compose up -d
  • コンテナ起動確認
sudo docker ps

STATUS が UPになっていれば問題なく起動できています。

Nextcloudのバーチャルサイトの編集

  • バーチャルファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/nextcloud.conf /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d)

.confやバックアップディレクトリは自分の環境に合わせます。

  • バーチャルファイルのバックアップ確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

差分が無いことでバックアップを確認します。

  • ファイル編集

/etc/apache2/sites-available/nextcloud.conf を、任意の方法で編集します。(エディタという宗教問題が絡むため)

他のリダイレクト設定やセキュリティ設定(RewriteRuleなど)に干渉されないよう、<VirtualHost *:443> ブロック内のなるべく上の方に記述するのがコツです。

<VirtualHost *:443>
    # (その他既存の設定...)

    # ====================================================
    # Signaling Server 設定
    # ====================================================

    # 1. バックエンド(Docker)に正しいホスト名とプロトコルを伝える
    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"

    # 2. プロキシ設定
    # "upgrade=websocket" オプションにより、http/ws を自動判別してヘッダーを渡す
    ProxyPass "/standalone-signaling/" "http://127.0.0.1:8080/" upgrade=websocket
    ProxyPassReverse "/standalone-signaling/" "http://127.0.0.1:8080/"

    # ====================================================

    # ... (これ以降にDocumentRootやセキュリティ設定が続く) ...
  • 編集後の差分確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

以下の差分を確認します。

+# ====================================================
+    # Signaling Server 設定
+    # ====================================================
+    # 1. バックエンド(Docker)に正しいホスト名とプロトコルを伝える
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    # 2. プロキシ設定
+    # "upgrade=websocket" オプションにより、http/ws を自動判別してヘッダーを渡す
+    ProxyPass "/standalone-signaling/" "http://127.0.0.1:8080/" upgrade=websocket
+    ProxyPassReverse "/standalone-signaling/" "http://127.0.0.1:8080/"
+    # ====================================================
+

設定反映

  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します。

動作確認

ブラウザで、

https://hoge.example.com/standalone-signaling/api/v1/welcome

にアクセスし、{"nextcloud-spreed-signaling":"Welcome", ...}の表示が出ていればOKです。

Nextcoloud管理画面設定

Nextcloudに管理者ログインし、[管理設定] > [Talk] > [高性能バックエンド] を設定します。

  • 高性能バックエンドURL: https://hoge.example.com/standalone-signaling/
  • 共有シークレット: 手順1で生成した文字列
  • SSL証明書を検証する: チェックを入れる

設定後、「保存」ボタンをクリックします。 「OK: 実行中のバージョン: x.x.x~docker」 と表示されれば完了です。

FAQ

Q. Dockerを入れることでサーバそのものが高負荷になるということは?

A. むしろ逆で、サーバー全体の負荷は「劇的に下がります」。

  • これまで(高性能バックエンドなし):
    • Nextcloudの画面を開いている間、ブラウザは数秒おきに「着信はありますか?」「新しいチャットはありますか?」とサーバー(Apache/PHP)に聞きに行きます(ポーリング方式)。 そのたびに Apacheが動き、PHPが起動し、データベースに接続し… という重い処理が走っていました。これがサーバーを高負荷にする原因です。
  • これから(高性能バックエンドあり):
    • Docker(Go言語)が、ブラウザと「1本のパイプ(WebSocket)」を繋ぎっぱなしにします。 情報はパイプを通ってスッと届くため、「着信確認」のための無駄な処理がゼロになります。

Q. メモリは食いますか?

A. メモリは食いますが、CPUは休まります。

  • Dockerコンテナが常駐するため、約50MB〜100MB程度のメモリ を常に確保(占有)します。これは増えます。
  • しかし、上記の「無駄な確認作業」がなくなるため、CPUの利用率はガクンと下がります。 サーバーにとって一番きついのは「メモリを確保すること」ではなく「CPUをブン回すこと」なので、トータルではサーバーが楽になります。

もっとさっくり言うと:

  • 1. 以前(高性能バックエンドなし)
    • 動作: ブラウザが「ねえ、着信ある?」「ねえ、メッセージ来た?」と、数秒おきにApacheを叩き起こしていました。
    • 負荷: そのたびに、数十MBのメモリを使うPHPプロセス が起動し、データベースに接続し、確認して終了する…という「重い開け閉め」を繰り返していました。
  • 2. 現在(高性能バックエンドあり)
    • 動作: 今回導入した signaling コンテナ(7MB/筆者環境)が、ブラウザと細い糸電話(WebSocket)を繋ぎっぱなしにします。
    • 負荷: 何もなければただ待っているだけ(CPU 0.02%/筆者環境)。着信があった時だけ、「来たよ!」と一瞬で伝えます。

重たいApacheやPHPは、本当に必要な画面表示の時だけ働けば良くなったので、サーバー全体が静かになり、反応速度(レスポンス)が向上します。

Nextcloud 32.xにClient Pushを導入して高速化させる(Mod_Security導入状況で躓いたこと)

Nextcloud32.0.2にアップデート後に表示された際に出てきた

Client Push
Client Push is not installed, this might lead to performance issue when using desktop clients.

と出てきたので、これを導入しました。筆者のようにIP/クローラー制限やMod_Securityを利用している方でもなんとかなる手順にしています。

Client Push (notify_push) とは?

正式名称は「High Performance Back-end / notify_push」。
一言でいうと、「ファイルの変更をクライアントに『瞬時に』知らせる機能」です。

導入前と導入後の違い

郵便受けの確認に例えるとわかりやすいでしょう。

  • Client Pushなし(ポーリング方式)
    • クライアントが、30秒おきに「ねえ、何か新しいファイルある?」「変更ない?」とサーバーへ聞きに行きます。
    • デメリット: サーバーはずっと質問攻めにされます。また、変更があってから聞きに行くまでにタイムラグ(遅延)が発生します。
  • Client Pushあり(プッシュ方式)
    • クライアント~サーバーが専用のホットライン(WebSocket)で繋がりっぱなしになります。
    • サーバー上のファイルが変更された瞬間、サーバーから「変更あったよ!」と通知(プッシュ)します。
    • メリット: 変更が即座に反映されます。無駄な問い合わせがなくなるため、サーバーの負荷も下がります。

Client Pushは導入すべきか?

「必須ではありませんが、導入すると劇的に快適になります」

  • 個人利用:
    • PCで保存した写真がスマホに「パッ」と出るようになるので非常に快適です。
  • 複数人/組織利用:
    • 強く推奨します。多数のユーザーによる「変更ある?」というアクセス集中を防げるため、サーバー安定化に寄与します。

環境

  • Nextcloud 32.0.2
  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0
  • PHP 8.3 (PHP-FPM 8.3)

(再掲)フェイズゼロ:政治交渉

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • Nextcloudの高速化に寄与するnotify_pushをサーバに入れる。
  • Apacheの設定変更を行う
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は

  • 個人運用だからそもそも関係ない
  • フェイズゼロをクリアした

方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。

さっくりとした手順

  1. 【Nextcloud Web画面】Client Pushをインストールします。
  2. 【コマンドライン】Nextcloudのメンテナンスモードを有効化します。
  3. 【コマンドライン】Apacheの設定ファイルを編集します。
  4. 【コマンドライン】Apacheの設定ファイルを反映させます。
  5. 【コマンドライン】Nextcloudのメンテナンスモードを無効化します。
  6. 【コマンドライン】notify_pushをサービス化します。
  7. 【コマンドライン】Nextcloudのconfigで、Trusted Proxyを有効化します。
  8. 【コマンドライン】Nextcloudのpushサービスを有効化します。
  9. 【Nextcloudクライアント】レスポンスの向上を確認します。

ClientPushのインストール

Nextcloudの管理者画面 >「アプリ」> 虫眼鏡アイコンで 「Client Push」を検索 > インストール・有効化します。

ここまでは単純です。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

Apache設定

Client Pushは「WebSocket」という特殊な通信を使用します。Apacheでこれを扱えるようにモジュールを有効化します。

sudo a2enmod proxy proxy_http proxy_wstunnel

念のため:apacheリスタート

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

このタイミングでサービス再起動が必要なのは何故かというと、

  • proxy
  • proxy_http
  • proxy_wstunnel

を有効化していないと、この後のApache設定変更時に「これらのモジュールが無い」とサーバは判断するからです。

Nextcloudのバーチャルサイトの編集

  • バーチャルファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/nextcloud.conf /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d)

.confやバックアップディレクトリは自分の環境に合わせます。

  • バーチャルファイルのバックアップ確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

差分が無いことでバックアップを確認します。

※余談:執拗なまでのバックアップ

「責任範囲を明確にするため」です。

設定ファイルというものは、どこかのミスであっという間に破綻する「すぐそこにある破滅」です。「起きてしまった破滅」からすぐリカバリーできるため、「何かあったときの責任者は誰か(芋を引くのはどいつか?)」を決める絶好の証拠になります。

○自分の設定でミスが起きた:潔く諦め、原状回復に努めましょう。
○誰かの設定ミス:追求や晒し上げは後にして、原状回復に努めましょう。責任者は誰かと追求してもサーバは止まり続けます。

ここで重要なのは、サービスが止まった「この時点で」重要なのは、「誰がやったか」ではなく「いかに早く復旧させるか」です。

  • ファイル編集

/etc/apache2/sites-available/nextcloud.conf を、任意の方法で編集します。(エディタという宗教問題が絡むため)

他のリダイレクト設定やセキュリティ設定(RewriteRuleなど)に干渉されないよう、<VirtualHost *:443> ブロック内のなるべく上の方に記述するのがコツです。

<VirtualHost *:443>
    # (その他既存の設定...)

    # ====================================================
    # Nextcloud Client Push (notify_push) 設定
    # ====================================================
    <Location /push>
        ProxyPass ws://127.0.0.1:7867/ws
        ProxyPassReverse ws://127.0.0.1:7867/ws
    </Location>

    ProxyPass /push/ http://127.0.0.1:7867/
    ProxyPassReverse /push/ http://127.0.0.1:7867/
    # ====================================================

    # ... (これ以降にDocumentRootやセキュリティ設定が続く) ...
  • 編集後の差分確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

以下の差分を確認します。

+# ====================================================
+# Nextcloud Client Push (notify_push) 設定
+# ====================================================
+    <Location /push>
+        ProxyPass ws://127.0.0.1:7867/ws
+        ProxyPassReverse ws://127.0.0.1:7867/ws
+    </Location>
+    
+    ProxyPass /push/ http://127.0.0.1:7867/
+    ProxyPassReverse /push/ http://127.0.0.1:7867/
+# ====================================================
+

設定反映

  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

Notifyデーモン(サービス)を作成します。

Client Pushは、Webサーバーとは別に裏方で動くプログラムです。これを常駐させるための設定ファイルを作成します。

  • ファイル作成

`/etc/systemd/system/notify_push.service`

を、任意の方法で作成します。

UserWorkingDirectoryExecStart のパスは、ご自身のNextcloudインストール環境(例: /var/www/nextcloudなど)に合わせて必ず修正してください。

[Unit]
Description = Nextcloud Client Push Node binary
After = network.target

[Service]
Type = simple
User = www-data
Group = www-data
# 【重要】環境に合わせて変更してください。特に、ExecStartは2カ所、修正箇所があります。
WorkingDirectory = /var/www/nextcloud
ExecStart = /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php
Restart = on-failure

[Install]
WantedBy = multi-user.target
  • サービス有効化
sudo systemctl daemon-reload
  • サービス起動
sudo systemctl enable --now notify_push
  • サービス起動確認
systemctl status notify_push.service 

active(running)を確認します

Trusted Proxiesの設定(どハマりした部分)

ここがつまずきポイントでした。

サーバーが自分自身のURL(https://your.domain.com)にアクセスした際、ネットワーク環境(ヘアピンNATなど)によっては一度外に出てグローバルIP経由で戻ってくる場合があります。

この場合、Nextcloudは「外部からのアクセス」とみなして通信を拒否してしまいます。これを防ぐため、config.php に自身のグローバルIPを信頼済みプロキシとして登録します。

  • configファイルのバックアップ
sudo cp -pi /path/to/nextcloud/root/config/config.php /path/to/backup/directory/config.php.$(date +%Y%m%d)

格納場所は自分の環境に合わせます。

  • 差分確認(※sudo付き)
sudo diff -u /path/to/backup/directory/config.php.$(date +%Y%m%d) /path/to/nextcloud/root/config/config.php

差分が無いことを確認します。

ここでsudoをつけるのは、NextcloudのファイルパーミッションがNextcloudの実行ユーザとrootしか読み取れないため(640)のためです。

Nextcloudの config/config.php を開き、trusted_proxies 配列に追記します。

  'trusted_proxies' => 
  array (
    0 => '127.0.0.1',
    1 => '::1',
    2 => '203.0.113.123',  // ← 【ここに追加】あなたのサーバーのグローバルIP
  ),
  • 差分確認(※sudo付き)
sudo diff -u /path/to/backup/directory/config.php.$(date +%Y%m%d) /path/to/nextcloud/root/config/config.php

以下を確認します。

+    2 => '203.0.113.123',

設定の手動登録

通常は occ notify_push:setup コマンドを使いますが、Bot検知やIP制限などのセキュリティ設定が厳しい環境では、接続テストで「403 Forbidden」や「404 Not Found」が出て失敗することがあります。

そのため、テストをスキップして強制的に設定値を登録するコマンドを使います。

sudo -u www-data php /var/www/nextcloud/occ config:app:set notify_push base_endpoint --value "https://your.domain.com/push"

URLはご自身のものに合わせてください。また、パス(/var/www/nextcloud)は環境に合わせて変更してください。

  • notify_pushサービス再起動
sudo systemctl restart notify_push
  • サービス起動確認
systemctl status notify_push.service 

active(running)を確認します。

確認

Nextcloudの管理画面(「概要」または「ログ」)を確認し、「Client Push」に関する警告が消えていれば導入成功です。

これでファイル同期が爆速になり、サーバー負荷も低減されているはずです。警告を消したいだけの場合でも、この手順を行っておけば「高セキュリティかつ高性能」な環境が手に入ります。

Nextcloud 32.xでAppAPIデプロイデーモンをDockerでインストール。

Nextcloudを32.0.2にアップデート後、以下のエラーを確認しました。

AppAPIデプロイデーモン
AppAPIデフォルトのデプロイデーモンが設定されていません。外部アプリ(Ex-Apps)をインストールするための設定で、デフォルトのデプロイデーモンを登録してください。

Mimetypeの移行が可能
1つ以上のmimetypeマイグレーションが利用できます。時折、特定のファイルタイプをよりよく扱うために新しいmimetypesが追加されます。大規模なインスタンスではmimetypesの移行に時間がかかるため、アップグレード時には自動的には行われません。移行を行うには occ maintenance:repair --include-expensive コマンドを使用してください。

データベースに存在しないインデックス
いくつかの欠落しているオプションのインデックスを検出しました。データベースのパフォーマンスを向上させるために、(Nextcloudまたはインストールされたアプリケーションによって)新しいインデックスが追加されることがあります。インデックスの追加には時間がかかり、一時的にパフォーマンスが低下することがあるため、アップグレード時には自動的には行われません。インデックスが追加されると、それらのテーブルへのクエリが速くなるはずです。インデックスを追加するには、occ db:add-missing-indices コマンドを使用してください。 インデックスが不足: "properties_name_path_user" テーブル内の "properties", "unique_category_per_user" テーブル内の "vcategory", "calobjects_by_uid_index" テーブル内の "calendarobjects"

これについて解消していきます。

環境

  • Nextcloud 32.0.2
  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0
  • PHP 8.3 (PHP-FPM 8.3)

フェイズゼロ:政治交渉

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • NextcloudのアップデートによりDockerコンテナが必要になった。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は

  • 個人運用だからそもそも関係ない
  • フェイズゼロをクリアした

方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。

さっくりとした手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Dcokerをインストールします。
  3. Dockerの起動と自動起動設定を行います。
  4. Docker Socket Proxyのコンテナを立ち上げます。
  5. Nextcloudのメンテナンスモードを無効化します。
  6. NextcloudでDockerデーモンを登録します。
  7. ついでに他のエラーも解消します。
  8. エラーの解消を確認します。

正直、筆者はDockerを信用していませんが「必要ならば入れるまで」です。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

Dockerのインストールを行います。

AppAPIは、背後でDockerコンテナを立ち上げてアプリケーションを実行します。まずはUbuntuサーバー自体にDockerが入っているか確認し、なければインストールします。

  • パッケージ全体のアップデート
sudo aptitude update

※筆者の好みでaptitudeを用いています。好みに応じてaptに読み替えてください。

  • Dockerのインストール
sudo aptitude install docker.io
  • Docker有効化
sudo systemctl start docker
  • Dockerの自動起動
sudo systemctl enable docker
  • Dockerのサービス状況確認
systemctl status docker.service docker.socket 

active(running)enabledを確認します。

Docker Socket Proxyのセットアップ

NextcloudはApacheユーザー(通常 www-data)で動作していますが、Dockerは roto 権限で動いています。NextcloudからDockerを安全に操作させるために、Docker Socket Proxy という中継役のコンテナを立ち上げるのが推奨される方法です。

  • Docker Socket Proxy (socat) を起動
sudo docker run -d \
  --name nextcloud_app_api_dsp \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -p 2375:2375 \
  alpine/socat \
  tcp-listen:2375,fork,reuseaddr unix-connect:/var/run/docker.sock
  • 稼働中のコンテナ一覧を見る
sudo docker ps

出力されたリストの中に、以下の特徴があれば成功です。

  1. NAMES: nextcloud_app_api_dsp という名前がある。
  2. STATUS: Up X secondsUp X minutes となっている。(ここが Exited だと停止しています)
  3. PORTS: 0.0.0.0:2375->2375/tcp のようにポートが表示されている。

※出力例:

CONTAINER ID   IMAGE          STATUS          PORTS                    NAMES
a1b2c3d4e5f6   alpine/socat   Up 2 minutes    0.0.0.0:2375->2375/tcp   nextcloud_app_api_dsp

  • ポートが開いているか確認する

OS側から見て、ポート2375番が待受状態になっているか確認します。

ss -nlt | grep 2375

※成功時の表示例:

LISTEN 0      512          0.0.0.0:2375        0.0.0.0:

※注意: 2375ポートは内部アクセス専用とし、外部公開しないようFW設定を確認してください

これが出ていれば、Nextcloudからの接続を受け付ける準備が完了しています。

  • もし「動いていない(表示されない)」場合

sudo docker ps で何も表示されない場合は、起動に失敗して終了してしまった可能性があります。その場合は以下でエラー原因を確認します。

  • 停止したものも含めて表示
sudo docker ps -a
  • ログ(エラー内容)を表示
sudo docker logs nextcloud_app_api_dsp

※よくあるエラー:
もしログに permission denied と出る場合は、Docker自体へのアクセス権限の問題ですが、今回の sudo docker run で実行していればこの動作は置きにくいでしょう。

  • メンテナンスモード無効化
sudo -u www-data php occ maintenance:mode --off
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、管理画面に入ります。

NextcloudでDockerデーモンを登録します。

管理者権限でNextcloudにログインし、

管理 > AppAPI

に進みます。

Deploy Daemonsの項目の+デーモンを登録に進みます。

以下のように設定します。

  • Daemon configuration template
    • Docker Socket Proxy を選択。
  • 名前
    • docker_socket_proxy (デフォルトのままでOK)
  • 表示名
    • Docker Socket Proxy (デフォルトのままでOK)
  • Deployment method
    • docker-install (デフォルトのままでOK)
  • Daemon host
    • localhost:2375
    • → ここはデフォルトと異なります。せっかくDockerを自サーバ(localhost)に接続したのですから、localhostを入れましょう。
  • Haproxyパスワード
    • HaProxyパスワード」に入っている黒丸(……)をすべて消して空白にします。
    • 先ほどコマンドで立ち上げた alpine/socat というコンテナは、パスワード認証機能を持たないシンプルな「通信中継(土管)」です。そのため、「HaProxyパスワード」という項目は、今回の構成(Docker Socket Proxy)では無視されます。(HaRP Proxyなどもっと複雑な構成で使用します)
  • Nextcloud URL
    • 管理しているNextcloudのURLを入れます。

このあと、「Check connection」をクリックします。「Daemon connection successful」と出たら「Register」をクリックします。

他のエラーの解消

  • MymeTypeの登録

再びNextcloudがインストールされているWebサーバに接続します。

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

sudo -u www-data php occ maintenance:repair --include-expensive
  • インデックスの追加

先ほどのNextcloudのルートディレクトリのまま実行します。

sudo -u www-data php occ db:add-missing-indices

念のため:apacheリスタート

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

エラーの解消を確認します。

管理者権限でNextcloudにログインし、

AppAPIデフォルトのデプロイデーモンはHaRPを使用していません。パフォーマンス向上のため、アップグレードをご検討ください。

とメッセージが警告に変わっていればOKです。

この作業に関するFAQ

Dockerインストールによるメモリ消費量は大丈夫か?

全く問題ありません。誤差レベルです。

今回使用する alpine/socat というコンテナは、非常に軽量なことで有名な「Alpine Linux」というOSをベースに、socat という単純な転送プログラムだけが動いています。

  • 消費メモリ:
    • およそ 2MB ~ 6MB程度です。
  • CPU負荷:
    • 待機時はほぼ 0%です。

サーバー全体のメモリが数GBある環境であれば、このコンテナの存在に気づかないレベルの軽さですので、ご安心ください。

サーバ再起動時、Dockerの設定が消えるのではないか?

このコンテナに関しては、「データが消えても問題ない(そもそもデータを保存しない)」仕組みになっているため、大丈夫です。

なぜ消えても大丈夫なのか(仕組みの解説)

このコンテナ nextcloud_app_api_dsp は、「土管(パイプ)」のような役割しかしていません。

  • データの保存場所:
    -「どのデーモンを使うか」という設定情報は、このコンテナの中ではなく、Nextcloud本体のMySQLデータベースに保存されます。今後インストールする外部アプリ(AIなど)のデータも、Nextcloudのストレージ領域に保存されます。
  • このコンテナの役割:
    • Nextcloud(Webサーバー)からの命令を、Ubuntu本体のDockerシステムに「中継」するだけです。中継役なので、自分自身は何も記憶する必要がありません。
  • 再起動時の挙動:
    • Docker立ち上げ時、コマンド内の --restart always というオプションのおかげで、Ubuntuサーバーを再起動すると、このコンテナも自動的に「新品の状態」で立ち上がります。立ち上がった瞬間から、再び「中継役(土管)」としての仕事を再開します。前回の中身を覚えている必要がないため、これで正常に動作します。

まとめ

  • メモリ: スマートフォンの写真1枚分(数MB)しか使いません。
  • 保存: このコンテナは「ただの通信ケーブル」のようなものなので、記憶を保持する必要がなく、再起動してもNextcloud側の設定(DB)が残っている限り繋がり続けます。

RHEL系Linux(Rocky Linux)でDockerのビルド領域変更

Dockerならではの問題に対処したのでメモを残します。

背景と課題

RHEL / Rocky Linux 9 環境のGPUサーバーにおいて、Dockerビルド(大規模LLMモデルの生成など)を実行した際、ルートパーティション(/)の使用率が100%に達する事象が発生しました。

  • 原因: Dockerはデフォルトで /var/lib/docker(ルート配下)にイメージやビルドキャッシュを保存します。
  • 環境: ルート領域は70GB程度ですが、/home 領域には数TBの空きがります。
  • 対策: パーティションリサイズ(LVM操作)はリスクが高いため、Dockerのデータ保存先(data-root)を /home 配下へ物理的に移行して解決します。

さっくりとした手順

  1. 現状を確認し、サービスを停止します。
  2. Dockerの移行ディレクトリを作成します。
  3. rsyncを用いて安全にデータを移行します。
  4. Dockerの設定ファイルを変更します。
  5. Dockerサービスの再起動を行います。
  6. 設定変更を確認します。

現状の確認とサービスの停止

まず、現在のDocker設定とディスク使用量を確認し、Dockerサービスを停止します。

  • Dockerの保存先確認
docker info | grep "Docker Root Dir"

(デフォルトは /var/lib/docker)

  • Dockerサービスを停止します。
sudo systemctl stop docker docker.socket
  • Dockerサービスの停止を確認します。
systemctl status docker

inactive(dead)を確認します。

移行先ディレクトリを作成します。

大容量領域(今回は /home 配下)に新しい保存用ディレクトリを作成します。

  • ディレクトリ作成
sudo mkdir -p /home/docker/data

データの移行(最重要)

既存のイメージやコンテナデータを保持するため、rsync を用いてデータを同期します。
cp コマンドよりも、権限やタイムスタンプを正確に保持できる rsync を推奨します。
rsyncはRocky9に最初から入っているコマンドです。

  • /var/lib/dockerの中身を、新ディレクトリへコピー
sudo rsync -aqxP /var/lib/docker/ /home/docker/data/

-a: アーカイブモード(権限等を保持)
-x: ファイルシステム境界を越えない
注意: コピー元のパス末尾に / を付けることで、ディレクトリそのものではなく「中身」を転送先に展開します。

設定ファイルの変更 (daemon.json)

  • ファイルのバックアップを取ります。(凄く重要)

何かあったときの切り戻しのため。特に、後述するjsonの編集をミスると地獄行きの通過駅無しの特急が待っています。

sudo cp -pi /etc/docker/daemon.json /path/to/backup/directory/daemon.json.$(date +%Y%m%d)
  • ファイルのバックアップをdiffで取ります。
sudo diff -u /path/to/backup/directory/daemon.json.$(date +%Y%m%d) /etc/docker/daemon.json

一般ユーザが読み取れないディレクトリ構造も考慮して、念のためsudoをつけます。

→ エラーがなければバックアップ成功。ここでコピー元とコピー先を逆にしているのは編集後のdiffを取るためです。

  • Dockerに新しい保存先を認識させるため、/etc/docker/daemon.json を編集します。(エディタは宗教問題のため、自分の教義・信仰に沿ったものを利用してください)

変更例:
data-root オプションを追記します。
JSON形式のため、行末のカンマ(,)の有無に注意してください。

{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "data-root": "/home/docker/data"
}
  • 編集後の差分をdiffで確認します。
sudo diff -u /path/to/backup/directory/daemon.json.$(date +%Y%m%d) /etc/docker/daemon.json

以下のようになっていることを確認します。

-     "data-root": "/var/lib/docker"
+     "data-root": "/home/docker/data"

サービスの起動と確認

Dockerを起動し、設定が反映されているか確認します。

  • Dockerサービスを起動します。
sudo systemctl start docker
  • Dockerサービスの起動を確認します。
systemctl status docker

active(running)を確認します。

  • 設定反映の確認
docker info | grep "Docker Root Dir"

=> Docker Root Dir: /home/docker/data となっていれば成功です。

不要データの削除(任意)

動作確認後、元の /var/lib/docker を削除または退避させて、ルートパーティションの空き容量を回復させます。

安全のため、バックアップを取るか慎重に削除してください。この作業を行うときは深呼吸を3回ほど行い、飲み物を飲むなどして落ち着いてから行いましょう。

sudo rm -rf /var/lib/docker

結果

本対応により、ルートパーティションの圧迫が解消されました。

Before:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   70G   70G   20K 100% /

After:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   70G  6.0G   65G   9% /
/dev/mapper/rl-home  6.9T  198G  6.7T   3% /home

トラブルシューティング

  • SELinux: 起動に失敗する場合、SELinuxが非標準ディレクトリへのアクセスをブロックしている可能性があります。一時的に setenforce 0 で切り分けを行うか、適切なコンテキストを設定してください。
  • JSON構文エラー: daemon.json の記述ミス(カンマ忘れなど)があるとDockerが起動しません。編集後は慎重に確認を行いましょう。

RHEL系LinuxサーバにRTX 6000を認識させる。

※昨今のトレンドである「GPU前提のLinuxサーバ」つまり、AI環境に必須の

  • データセンタークラスのGPU
  • それをRHEL系Linuxに認識させ
  • 更にDockerというトレンドでも動かす

という難易度が高く――そして、インフラ屋にとって極上の素材を得る経験がありました。

そのときのメモです。(氷見の本マグロを捌くことになった調理師のような気分でした)

“逸般”の誤家庭的な環境

まず、これを一般家屋に置くと言うことはないでしょう。

  • OS:
    • Rocky Linux 9.x (Minimal Install)
  • Kernel:
    • 5.14.0-x (RHEL 9 Standard)
  • GPU:
    • NVIDIA RTX 6000 Ada Generation x 1
      • →2025/12/06時点でもちょっとした軽自動車が買えるやつです
  • Driver:
    • NVIDIA Driver 590.xx (Open Kernel Module)
  • Container Runtime:
    • Docker CE 27.x + NVIDIA Container Toolkit

前提環境の整備

  1. OSインストールを行います。(Rocky Linux Minimal)
  2. ネットワークの設定を行います。
  3. dnf updateを済ませます。

NetworkManagerによるネットワーク設定

固定IP化および自動接続設定を行う。

  • 接続プロファイル名の正規化 (デバイス名と合わせる)
sudo nmcli connection modify "Wired connection 1" connection.id eno2
  • 固定IP設定
sudo nmcli connection modify eno2 ipv4.addresses xx.xx.x.x/16
sudo nmcli connection modify eno2 ipv4.gateway Gateway IP
sudo nmcli connection modify eno2 ipv4.dns "DNS1 DNS2"
sudo nmcli connection modify eno2 ipv4.method manual
sudo nmcli connection modify eno2 connection.autoconnect yes

→ これをやっておかないと、再起動したときにNW設定が消えます。

  • 設定反映
sudo nmcli connection up eno2

システム更新とリポジトリ適用

RHEL 9 系でサードパーティ製パッケージを入れるため、これは必須です。特に、CRB (CodeReady Builder) の有効化を忘れると依存解決ができず、高性能GPUを認識させることができません。

  • dnf全更新
sudo dnf update -y
  • サーバ再起動
sudo reboot

→ カーネルアップデートも含まれるため。

  • CRB有効化 (旧 PowerTools)
sudo dnf config-manager --set-enabled crb
  • EPEL導入
sudo dnf install epel-release -y

NVIDIA Driver の導入

ここまで来たらいよいよ本命。(先のマグロの例に例えると、いよいよマグロの身に刃を当てていきます)

【重要】 RTX 6000 Ada はプロプライエタリ版ドライバではなく、Open Kernel Module (open-dkms) を要求します。これに気づかずハマりかけました。

依存関係の解決とリポジトリの導入。

  • 開発ツールの導入
sudo dnf groupinstall "Development Tools" -y
  • カーネルヘッダの導入
sudo dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r) -y
  • NVIDIA公式リポジトリ (RHEL9用) 追加
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

旧ドライバ/競合の排除

以前のインストール試行や(ハマったところ)、OSに入っているであろうGPUドライバを取り除かないと詰まります。

  • nvidia dkmsドライバのアンインストール
sudo dnf remove nvidia-driver kmod-nvidia-latest-dkms -y
  • nvidia dkmsドライバのリセット
sudo dnf module reset nvidia-driver -y

Open Kernel Module 版のインストール

  • dnf module機能を使って open-dkms ストリームを指定してインストール
sudo dnf module install nvidia-driver:open-dkms -y
  • サーバ全体を再起動してカーネルモジュールをロード
sudo reboot

ドライバ動作確認

nvidia-smi

-> `Driver Version: 590.xx / GPU Name: RTX 6000 Ada / VRAM: xxGB が表示されることを確認します。

コンテナ基盤の構築

筆者はコンテナが好みではないのですが、それはそれです。相手のオーダーに答えるのもまたお仕事。

Docker CE のインストール

ここではpodman ではなく Docker CE を採用しました。

  • Docker CEレポジトリ追加
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
  • Docker CEインストール
sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
  • Docker 自動起動有効化
sudo systemctl enable --now docker
  • 現在のユーザをDockerグループに加える
sudo usermod -aG docker $USER

NVIDIA Container Toolkit の導入

DockerコンテナでGPUが見えないと、せっかく「Dockerを入れろ」というオーダーが無になります。

  • Toolkitインストール
sudo dnf install nvidia-container-toolkit -y
  • Dockerランタイム設定 (daemon.jsonの更新)
sudo nvidia-ctk runtime configure --runtime=docker
  • Tookit/ランタイム反映
sudo systemctl restart docker

動作確認 (パススルーテスト)

コンテナ内部から GPU が見えるか確認します。

sudo docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

成功時、コンテナ内からホスト同様の nvidia-smi 結果が出力されれば動作完了です。

追加要素:最新トレンドに合わせた開発環境の用意。

言語ランタイム (Modern Runtime)の導入

OS標準を汚さず、最新の開発環境を整備する。

  • Node.js 22+:
    • NodeSourceリポジトリより導入。これは割愛です。(どっかしら探せば出てくるので)
  • Python 3.12:
    • Rocky Linuxは3.9。しかも、OSの核となっているプログラムなので、ソースコードを用いて altinstall (共存インストール) しないとサーバそのものが吹っ飛びます。

※実行例

  • 開発環境導入
sudo dnf install -y openssl-devel bzip2-devel libffi-devel zlib-devel readline-devel sqlite-devel tk-devel xz-devel
  • ソースコードダウンロード
wget https://www.python.org/ftp/python/3.12.8/Python-3.12.8.tgz
  • ソースコード展開
tar xzf Python-3.12.8.tgz && cd Python-3.12.8
  • ソースコードconfigure(最適化オプション)
./configure --enable-optimizations
  • CPUコアフルに用いての高速メイク
make -j $(nproc)
  • altinstall
sudo make altinstall

altinstallを入れないと上述したようにサーバが吹っ飛びます。

トラブルシューティング (Tips)

以下のエラーに出くわしたときの原因と対策です。

  • NVRM: requires use of the NVIDIA open kernel modules:
    • 原因: Ada世代のGPUに対し、従来のプロプライエタリドライバを入れたため。
    • 対策: dnf module install nvidia-driver:open-dkms を使用しました。
  • Secure Boot:
    • ドライバ導入前に BIOS/UEFI で Disabled になっていることを確認すること(署名周りのトラブル回避)。

RHEL系サーバ、実物環境下でのネットワーク設定

はじめに

GUIが多くなったとは言え、Linuxサーバは基本的にCLI(コマンドライン)・SSH接続によるリモート操作が基本です。この、CLIの環境下でのネットワーク設定という基本のメモです。

環境とやったこと

極めてよくあるユースケースです。即ち

「サーバ実機はこれである。ひとまず組織内(社内)ネットワークにつなげ」

という指令への対処。

  • 物理サーバ
    • 今回はVPSではありません。実機です。
    • その大きさ、重さを知るのもインフラ屋の醍醐味です。
  • Rocky Liunx 9.x
    • (RHEL系フォーク、ミニマルインストール)
  • ローカルNWにサーバのIPを割り当てる。
  • NW設定を有効化する。
    • 固定IP。クライアントならいざ知らず、サーバ運用は固定IPであるべきです。
    • IP: 172.xx.xx.xx/16 (/16はサブネットマスク255.255.0.0を意味します)
    • GW: 172.xx.254.254 (※これはあくまでも例です)
    • DNSサーバ/ドメイン:ローカルで定められているもの。

さっくりとした手順

ではありますが、かなり慎重に書いています。

  1. RockyLinuxサーバをMinimalでインストールします。
  2. サーバコンソールに直接ログインします。
  3. ネットワークインタフェースを確認します。
  4. nmcliによりネットワークを設定します。
  5. ネットワークインタフェースを有効化します。
  6. サーバを結線してリンクアップを確認します。
  7. 最初のdnf updateを行います。

RockyLinux 9.6インストール

インストール方法については割愛。GUI無しのMinimalをインストールします。というのも、多くのサービスが入ってしまうと、自分が管理しきれない部分が増えると共に、そこが脆弱性となるからです。

また、ここでは最初からネットワークにつなぎません。設置する組織によってはLAN接続も許可制になっているパターンが極めて多いです。(IPも指定されたものを使うというのが実情でしょう)

サーバコンソールにログイン

この段階ではrootでも構いません。何せ、物理的に言葉通りの意味で切断されているのですから。

物理ネットワークの確認

vpsと違い、最初からネットワークにつながっていません。当然、IPも振られていません。なので「どのLANポートを使うか?」から始まります。

nmcli

を実行します。これはNetwork Manager Command Line Interfaceの略であり、RHELサーバの肝と言えるネットワーク設定コマンドです。(普段Ubuntuサーバを使う筆者は少々混乱しました)

筆者環境では

  • eno2
  • eno3

がありました。ここではeno2を確認していきます。

ネットワーク設定

  • 現状確認
nmcli connection show

以下のような例が出てきます。

NAME     UUID                                  TYPE      DEVICE
eno2     UUID文字列                             ethernet  eno2
lo       UUID文字列                             loopback  lo
eno3     UUID文字列                             ethernet  eno3

この、eno2というポートを使います。

  • ※例外

もし、もし NAME 列に Wired connection 1 とあり、DEVICE 列が eno2 ならば、次の手順で名前を変更します。

  • ※例外時の実施- "Wired connection 1" を "eno2" にリネーム
sudo nmcli connection modify "Wired connection 1" connection.id eno2
  • IPとサブネット設定 (CIDR表記でスマートに)
sudo nmcli connection modify eno2 ipv4.addresses 172.xx.xx.xx/16

→ 実際に指定されたIPアドレスを入力します。このとき、二重チェックで「同一ネットワーク内にIPアドレスが無いか? / 打ち間違いがないか?」を確認しましょう。被ってしまうと単純な破滅が待っています。

  • ゲートウェイ設定
sudo nmcli connection modify eno2 ipv4.gateway 172.xx.254.254

こちらも同様。別のゲートウェイを設定していないかを確認。

  • DNS設定
sudo nmcli connection modify eno2 ipv4.dns "DNS1 IPアドレス DNS2 IPアドレス"

→ DHCPと異なり、固定IPはDNSサーバを指定します。組織内では冗長性のため複数あるケースがほとんどです。

  • ドメイン設定
sudo nmcli connection modify eno2 ipv4.dns-search "組織内ドメイン"

→ 組織内ドメインで、FQDNの名前解決を効率化するため。

  • メソッドを手動にしてIPアドレス固定
sudo nmcli connection modify eno2 ipv4.method manual
  • 【重要】自動接続をONにする (これを忘れると再起動後に死ぬ)
sudo nmcli connection modify eno2 connection.autoconnect yes

→ autoconnect no の状態だと、システムが再起動した後、NetworkManagerは設定ファイルは認識していますが、その接続を自発的に起動しません。つまり、何らかの事情でサーバそのものを再起動した場合、このネットワーク設定が断たれます。即ち、あらゆるネットワークから完全に切り離されます。

ネットワーク設定の有効化

ここまで来たらいよいよサーバにネットワークを認識させます。このコマンドの前に深呼吸をして落ち着きましょう。(サーバ室/データセンターからの離席を許されるならこの段階で)

  • 再起動して設定をロード
sudo nmcli connection up eno2
  • IPアドレスの確認
ip addr show eno2

→ インターフェース eno2 に正しいIPアドレス、ネットマスクが割り当てられたか。

eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
  • ルーティングの確認
ip route

→ デフォルトゲートウェイ(外部ネットワークへの出口)が正しく設定されたか。

IPアドレスが正しくても、どこへパケットを送るか(経路情報)がなければ、ローカルネットワーク外へは通信できません。

default via  172.xx.254.254 dev eno2

などの行がないと、外部環境は無意味です。初歩的ですが非常に詰まりやすいポイントです。

  • DNS設定の確認
cat /etc/resolv.conf

→ ネームサーバーと検索ドメインが設定ファイルに反映されたか。

nameserver: 設定した社内のDNSサーバーのIPアドレス(例: nameserver 192.168.1.53)が正しくリストアップされているか。
もしこれらが正しく反映されていなければ、名前解決ができず、Webサイトの閲覧やホスト名でのサーバーアクセスができなくなります。

サーバの結線

上記が確認できたら、サーバという鉄の箱を「ネットワークと通信ができる」状態へと落とし込みます。ここでも、単純ながら致命的なミスが待ち構えています。

以下を確認しましょう。

  • LANポートの接続先と接続元は合っているか?
    • 特に、LANポートの迷路とも言えるサーバ室やデータセンターではこれらを間違えると地獄が待っています。比喩的な意味では無く。
  • LANケーブルは断線が無いか?
    • 切り分けの手間を減らします。
  • ストレートとクロスを間違えていないか?
    • たまにありますが結構盲点です。

疎通確認

  1. Gatewayへの Ping:ping -c 4 172.xx.254.254
    • これが通れば、L2/L3(組織/社内ネットワークへの物理・論理接続)は成功しています。
  2. DNSサーバへの Ping:ping -c 4 [DNSサーバーのIP]
    • これが通れば、名前解決の準備OKです。
  3. 外の世界への Ping:ping -c 4 google.com
    • これで初めて「インターネット接続完了」です。

DNFアップデート

サーバ全体のLinuxシステムを「最新の状態にする」おまじないです。

sudo dnf update -y

ここでの注意点はトラフィック。大容量のデータがこのサーバに流れます。貧弱な回線ではたちまちパンクします。

Complete!と表示されたら、

sudo reboot

で物理的に再起動します。というのも、dnfアップデートはたいがいカーネルの更新も伴うからです。

この再起動後、「先ほどのネットワーク設定が活きているか? 失われていないか?」が伴い、初めてこのネットワーク設定という初歩的な設定が完了します。

BookStackのカスタム404ページを更に変更。

以前のこのページを更に差し替え。

/path/to/BookStack/resources/views/errors/

の`404.blade.php`の内容を、

<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>404 Not Found: The Final Problem</title>
<style>
  @import url('https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700;900&display=swap');

  body {
    background-color: #000000;
    color: #d4d4d4;
    font-family: 'Noto Sans JP', sans-serif;
    margin: 0;
    padding: 20px;
    line-height: 1.6;
    overflow-x: hidden;
  }

  .container {
    max-width: 800px;
    margin: 0 auto;
    border: 2px solid #ff0055; /* Neon Pink Border */
    box-shadow: 0 0 15px #ff0055, inset 0 0 20px rgba(255, 0, 85, 0.2);
    padding: 40px;
    position: relative;
    background: repeating-linear-gradient(
      0deg,
      #0a0a0a,
      #0a0a0a 2px,
      #000000 2px,
      #000000 4px
    ); /* Scanline effect */
  }

  h1 {
    color: #ff0055;
    font-size: 3rem;
    text-align: center;
    text-transform: uppercase;
    text-shadow: 2px 2px 0px #ffffff;
    margin-bottom: 10px;
    letter-spacing: 0.1em;
    font-weight: 900;
  }
  
  .sub-header {
    color: #00ffcc; /* Cyber Green */
    text-align: center;
    font-size: 1.2rem;
    margin-bottom: 40px;
    font-family: monospace;
  }

  h2 {
    color: #ffff00; /* Warning Yellow */
    border-left: 5px solid #ff0055;
    padding-left: 15px;
    margin-top: 40px;
    margin-bottom: 20px;
    font-size: 1.5rem;
    text-shadow: 0 0 5px rgba(255, 255, 0, 0.5);
  }

  p {
    margin-bottom: 1.5em;
    font-size: 1.1rem;
  }

  .shout {
    color: #ff0055;
    font-weight: bold;
    font-size: 1.2rem;
  }

  .emphasis {
    color: #00ffcc;
    font-weight: bold;
  }

  .quote-box {
    border: 1px dashed #00ffcc;
    padding: 15px;
    margin: 20px 0;
    background-color: rgba(0, 255, 204, 0.05);
    font-style: italic;
  }

  .footer-nav {
    margin-top: 50px;
    text-align: center;
    border-top: 1px solid #333;
    padding-top: 20px;
  }

  .btn {
    display: inline-block;
    background-color: #ff0055;
    color: #000;
    padding: 10px 25px;
    text-decoration: none;
    font-weight: bold;
    font-size: 1.2rem;
    border: 2px solid #fff;
    transition: all 0.3s ease;
    box-shadow: 5px 5px 0px #00ffcc;
    transform: skew(-10deg);
  }

  .btn:hover {
    background-color: #000;
    color: #ff0055;
    border-color: #ff0055;
    box-shadow: 5px 5px 0px #fff;
    transform: skew(-10deg) translate(-2px, -2px);
  }

  hr {
    border: 0;
    height: 1px;
    background-image: linear-gradient(to right, rgba(0, 0, 0, 0), rgba(255, 0, 85, 0.75), rgba(0, 0, 0, 0));
    margin: 30px 0;
  }

  /* Glitch Effect Animation for H1 */
  @keyframes glitch {
    2%, 64% { transform: translate(2px,0) skew(0deg); }
    4%, 60% { transform: translate(-2px,0) skew(0deg); }
    62% { transform: translate(0,0) skew(5deg); }
  }
  h1:hover {
    animation: glitch 0.3s cubic-bezier(.25, .46, .45, .94) both infinite;
    color: #00ffcc;
  }

</style>
</head>
<body>

<div class="container">
  <h1>404 Not Found</h1>
  <div class="sub-header">ERROR: PAGE ANNIHILATED / ページはアナイアレーションされた</div>

  <h2>💀 第一章:クリエイターの恐怖、ドイル=サンの葛藤</h2>
  <p>時はマッポーの世、ヴィクトリア朝のヤミ。ドイル=サンは自らが生み出した、探偵という名の、知的なリアルニンジャ、シャーロック・ホームズ=サ
ンの存在に辟易していた。</p>
  
  <div class="quote-box">
    「アイエエエ! 私は医術というリアルなサイエンスを極めたいのに!ヘッズどもはホームズ=サンの狂気の物語しか求めない!」
  </div>

  <p>ドイル=サンにとってホームズ=サンは、ニューロンを支配し、創造性を吸い尽くす、邪悪なバイオ・ゴーストの如し! 彼は決断した。<span class="shout">「ホームズ=サンを殺す!完全に、そして、シメやかに、アナイアレーションする!」</span></p>
  
  <p>彼の脳内には既に、ホームズ=サンのデス・プランが構築されていた。ヘッズたちの熱狂、ストランズ・シンジケートの金と欲! これらを断ち切るには、究極のバイオレンス、すなわち、デスしかない!</p>
  <p>ドイル=サンは内心、自らが生み出した、巨大な、そして、熱狂的な読者層(ヘッズ)に恐れをなしていた。「アイエエエ! 彼らは私のロードではない!私が彼らのロードであるはずなのに!」</p>

  <hr>

  <h2>💥 第二章:ライヘンバッハのNRS! 滝壺のデス・ファイト</h2>
  <p>場所はスイス。ライヘンバッハの滝!</p>
  <p>ホームズ=サンの宿敵、モリアーティ=サンとの最終決戦。二人の、知的なリアルニンジャは激流の轟音の中で格闘!</p>
  
  <p class="shout">「イヤーッ!」「グワーッ!」</p>

  <p>ドイル=サンは冷静にペンを走らせる。二人の、そして、彼の分身の如き、ホームズ=サンは滝壺へと落ち、デス! 証拠は一切なし! 完全なアナイア
レーション!</p>
  <p>ストランズ・マガジンに掲載されたこの物語を目撃した読者、すなわち、ヘッズたちは一斉にNRSを発動!</p>
  
  <div class="quote-box">
    「アイエエエエ! ホームズ=サンが死んだナンデ!?」
  </div>

  <p>彼らのリアリティは滝壺へと引きずり込まれた! ホームズ=サンは架空の存在ではない! 彼らの日々の、そして、生きるための精神的な支えであった
のだ!</p>
  <p>ライヘンバッハの滝は単なる、景勝地ではなく、世界のニューロンが崩壊した地点となった。</p>

  <hr>

  <h2>🔥 第三章:IRCの大炎上! フジキドめいた絶望</h2>
  <p>ドイル=サンは勝利を確信! 「これで私は自由だ!」</p>
  <p>だが、彼の解放の喜びは一瞬で砕かれる! ヘッズたちの狂気がドイル=サンの私生活を襲ったのだ!</p>
  <p>電報、手紙、そして、ストランズ・シンジケートからの緊急のIRC通信がドイル=サンの屋敷を包囲! これぞIRCの大炎上!</p>
  
  <div class="quote-box">
    「貴様の殺意、許さん!」「ホームズを戻せ!」「私はドイルのロードをやめる!」
  </div>

  <p>女性のヘッズたちは喪章を付け、ストリートでデモ! マガジンの発行部数は暴落! ドイル=サンは現実のニンジャに襲われるが如く、四方八方からヘ
ッズの狂気に晒された!</p>
  <p>ドイル=サンは悟る。自らの手で生み出した、この物語の世界に囚われていることを!</p>
  <p>これはまるでニンジャスレイヤー、フジキド・ケンジ=サンの如し! 家族を殺され、復讐のソウルに憑依され、望まぬ、そして、終わりの見えない、デス・ファイトの世界に引きずり込まれた!</p>
  <p>ドイル=サンも同じ! 望まぬ、そして、辞めることの許されない、クリエイターとしてのデス・ゲームに囚われたのだ!</p>

  <hr>

  <h2>✨ 第四章:奇跡の生還! 読者の要求がニューロンを支配</h2>
  <p>ドイル=サンに選択肢はなかった。ホームズ=サンを殺すことで得た「自由」は幻想! 彼のリアリティはヘッズたちの狂気によって完全に、そして、シメやかに支配されていた。</p>
  
  <p class="emphasis">「奇跡の生還、これしか策なし!」</p>

  <p>10年の沈黙を経て、ドイル=サンは筆を執る。「空き家の冒険」!</p>
  <p><span class="shout">ゴウランガ!</span> ホームズ=サンは生存していた! モリアーティ=サンとの格闘の後、奇跡的に生還し、三年の間、世界のヤミで潜伏していたという狂気的な筋書き!</p>
  <p>読者、すなわち、ヘッズたちは歓喜! NRSは修復され、IRCの炎上は鎮火!</p>
  <p>ドイル=サンは再び、ホームズ=サンの物語を書き続けるという運命に逆戻り。フジキド=サンがニンジャをスレイする宿命から逃れられない如く、ド
イル=サンもホームズ=サンという知的なリアルニンジャの物語を書き続けるという宿命から逃れられなかったのだ!</p>
  <p>クリエイターとヘッズの関係が逆転した、アリエナイ・インシデント! これぞフィクションを超えた、リアルな、そして、ゴウランガな史実! <span class="shout">スゴイ!</span></p>

  <div class="footer-nav">
    <p>このリアル・ニンジャ・ゴトの文学的事件をさらに掘り下げるか? それとも、次の恐るべき史実を所望か?</p>
    <a href="/" class="btn">トップページへ戻る</a>
  </div>

</div>

</body>
</html>

に置き換え。

のような、マッポーめいた文章にしました。

この手の、遊び心を発揮できるというのは本当に自サイトの強みです。

『ONE OUTS』システム番外:ipsetによるUFWの効率化。

はじめに

筆者が用いているWebへの攻撃を防ぐ、MOD_SECURITYとApache設定、シェルスクリプトの連携「ONE OUTSシステム」。これは「実際にWebサイトにアクセスした者」への盾として機能していますが、「アクセス未満」での低レイヤーでの攻撃を仕掛ける者を防ぎきることができません。

例えば、SYNフラッド攻撃はWebサイトへの攻撃を仕掛けるわけではないのでログに残らず、じわじわとリソースを奪っていきます。

かといって、これらのSYNフラッド攻撃は極めて広範囲のIPレンジから仕掛けてくるので

sudo ufw insert 1 deny from xxx.xxx.xxx.xxx

とするには、ufwでのルールが広範になりすぎてメンテナンス性ならびにシステムパフォーマンスの低下を招きます。

これを解決するための手段を設けました。

環境

  • Ubuntu 24.04
  • ufw導入済み

行ったこと

  1. ipsetコマンドをインストールします。
  2. ブロックリストの設定を行います。
  3. ipsetコマンドでSYNフラッド攻撃を行う攻撃者をレンジごとブロックします。

事前注意

これは、カーネルメモリにufwのブロックリストを付与する、「破壊的アップデート」の可能性が発生します。

  • セキュリティポリシー
  • 明確な運用基準

組織単位 で行う必要があります。

手順

ipsetコマンドのインストール

※筆者の好みでaptitudeを用いています。環境に合わせてapt等に読み替えます。

  • パッケージアップデート
sudo aptitude update
  • ipsetインストール
sudo aptitude install ipset

※ 要注意 ※

ここでは、ipset-persistantコマンドを入れていません。なぜなら、ufwと競合する結果、パッケージ管理はufwを破壊する可能性があるからです。

  • ipsetインストール確認
ipset -v
ipset v7.19, protocol version: 7
ipset v7.19: Kernel error received: Operation not permitted

※この、not permittedは、root権限で実行していないため許可されていないというメッセージです。

ipsetのルール変更

  • ブロックしたいIPを格納するための「セット」をメモリ上に作成します。

これは再起動時に消えます

sudo ipset create ufw-blocklist hash:net

ufwにipsetを参照するルールを追加します。

  • ufwの前段ルールをバックアップ
sudo cp -pi /etc/ufw/before.rules /path/to/backup/before.rules.$(date +%Y%m%d)

→ バックアップ先は任意のものを指定します

  • バックアップ確認
sudo diff -u /path/to/backup/before.rules.$(date +%Y%m%d) /etc/ufw/before.rules 

※ここでsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

  • ファイル修正

上記、/etc/ufw/before.rulesの内容を慎重に修正します。 *.filterのすぐ下の行です。

# ===================================================================
# "ufw-blocklist" セットに含まれるIPからの全パケットを破棄する
-A ufw-before-input -m set --match-set ufw-blocklist src -j DROP
# ===================================================================

# ok all existing rules
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
  • ファイル修正確認
sudo diff -u /path/to/backup/before.rules.$(date +%Y%m%d) /etc/ufw/before.rules 

以下の差分になっていることを確認します。

 *filter
+# ===================================================================
+# "ufw-blocklist" セットに含まれるIPからの全パケットを破棄する
+-A ufw-before-input -m set --match-set ufw-blocklist src -j DROP
+# ===================================================================
+
+# ok all existing rules

リロード前確認(最重要)

さて、ここまで手順通りに行えばufwのリロードは正常に完了します。しかし、ここで今一度

  • sudo ipset create ufw-blocklist hash:netを実行したか?
  • /etc/ufw/before.rulesを編集したか?
  • この編集は既存ファイルの内容を削除していない(追記のみ)か?

を確認しましょう。確認しなければ、この先に待ち構えているのは「失敗した場合の自分自身のロックアウト」にもつながります。

ufwリロード

よく深呼吸しましょう。実行前に何か飲み物を飲んでおいてもいいぐらいです。

sudo ufw reload

ファイアウォールを再読込しましたのメッセージが出れば成功です!

sudo ufw status

でも状態:アクティブを確認します。

ipset のリストを「永続化」する

ipset-persistent の代わりに、UFW自身の起動・停止スクリプトに、リストの保存・復元を組み込みます。

  • A. 保存用ファイルのパスを定義

まず、ipset のリストを保存するファイルを決めておきましょう。 ここではIPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"と定義します。

  • B. UFW起動時にリストを「復元」する設定

ufw が起動する前に、保存したリストを読み込むようにします。

sudo cp -pi /etc/ufw/before.init /path/to/backup/before.init.$(date +%Y%m%d)

でバックアップを取ります。(バックアップディレクトリを一括にしているならbefore.init.$(date +%Y%m%d)の前にbefore.rules.$(date +%Y%m%d)を作っているはず。「タブの補間はせず、確実にファイルのバックアップを取りましょう)

sudo diff -u /path/to/backup/before.init.$(date +%Y%m%d) /etc/ufw/before.init

で、バックアップが成功していることも確認します。※diffでもsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

/etc/ufw/before.initを編集します。

ファイルの一番上(#!/bin/sh の直後)に、以下の行を追記します。

IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"

# 起動時に ipset リストをファイルから復元する
if [ -f "$IPTABLES_IPSET_SAVE_FILE" ]; then
    ipset restore -f "$IPTABLES_IPSET_SAVE_FILE"
fi
sudo diff -u /path/to/backup/before.init.$(date +%Y%m%d) /etc/ufw/before.init
 #!/bin/sh
+IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
+
+# 起動時に ipset リストをファイルから復元する
+if [ -f "$IPTABLES_IPSET_SAVE_FILE" ]; then
+    ipset restore -f "$IPTABLES_IPSET_SAVE_FILE"
+fi

を確認。

  • UFW停止時にリストを「保存」する設定

ufw が停止(またはリロード、シャットダウン)する後に、現在のリストをファイルに保存するようにします。

sudo cp -pi /etc/ufw/after.init /etc/conf_backup/after.init.$(date +%Y%m%d)
sudo diff -u /etc/conf_backup/after.init.$(date +%Y%m%d) /etc/ufw/after.init 

※diffでもsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

/etc/ufw/after.initを管理者権限で編集します。 ファイルの一番上(#!/bin/sh の直後)に、以下の行を追記します。

IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"

# 停止時に現在の ipset リストをファイルに保存する
ipset save -f "$IPTABLES_IPSET_SAVE_FILE"

追記後、

sudo diff -u /etc/conf_backup/after.init.$(date +%Y%m%d) /etc/ufw/after.init 

で差分を確認します。

 #!/bin/sh
+IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
+
+# 停止時に現在の ipset リストをファイルに保存する
+ipset save -f "$IPTABLES_IPSET_SAVE_FILE"
  • コマンド実行権付与
sudo chmod +x /etc/ufw/before.init /etc/ufw/after.init

→ コマンドを追記しているので重要です!

再度のufwリロード前の確認

ここでも

  • /etc/ufw/before.initを編集し、差分通りか?
  • etc/ufw/before.initを編集し、差分通りか?
  • この編集は既存ファイルの内容を削除していない(追記のみ)か?
  • /etc/ufw/before.init /etc/ufw/after.initに実行権限が付与されているか?

を確認しましょう。確認しなければ、こちらも自分自身のロックアウトにつながります。

ufwリロード

よく深呼吸しましょう。今度は手元にあればお茶菓子を食べてもいいぐらいです。

sudo ufw reload

ファイアウォールを再読込しましたのメッセージが出れば成功です!

sudo ufw status

でも状態:アクティブを確認します。

ここまで来たら:SYNフラッド攻撃への対処

これは、対象のIPアドレスをシャットアウトする「慈悲なき王」です。

ブロック対象は慎重に慎重を期します。

  • メモリ上のリストに即時追加
sudo ipset add ufw-blocklist IPアドレス・NWアドレス

→ 実際のIPアドレスを半角で入力しましょう。

  • メモリ上のリストをファイルに「永続化」
sudo ipset save ufw-blocklist -f /etc/ufw/ipsets.save

(sudo ipset save ではない点に注意してください)

  • 永続化確認
cat /etc/ufw/ipsets.save 

として

create ufw-blocklist hash:net family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xcce80b68
add ufw-blocklist IPアドレス・NWアドレス

等と表示されれば成功です。

※この作業はufwリロード不要です。※

まとめ

「相手が回りくどい攻撃をしてきたら、更に回りくどい方法をとらなければならない」という形。

正直、この作業は二度とやりたくない部類に入ります。ですが、一度設定してしまえば

sudo ipset add ufw-blocklist IPアドレス・NWアドレス

で永続的に執拗な攻撃を仕掛ける攻撃者に対処することが可能です。

「Update-motd」を使おう(ユースケース:カスタマイズスクリプトによる遊び心と有用性の追加)

はじめに

筆者が大好きな言葉かつ「何かあったときの道しるべ」としている言葉があります。

In every job that must be done, there is an element of fun. You find the fun and—snap! The job's a game.

映画『メリー・ポピンズ』の『お砂糖ひとさじで / A Spoonful of Sugar』の歌い出しとなっている言葉。

この、

  • どんな仕事にも遊びの要素がある
  • その遊びの要素を見つければ仕事はゲームになる

の2点を『自分自身のLinuxサーバの運用』に組み込んだという話です。

サーバー運用というのは、本来、堅牢性と安定性が求められる、どちらかというと無味乾燥な作業になりがちです。しかし、この単調な作業のどこかに「遊びの要素」を見出し、毎日ログインするのが楽しくなる**ような仕掛けを作れないかと考えました。

その答えが、「ログインコンソールに遊び心を持たせつつ、重要な情報を一瞥できるようにする」という試みです。これにより、単調な作業の始まりが、「今日の情報ブリーフィング」と「ちょっとした楽しみ」に変わります。

いつものようにとりとめない話を強引に組み立てていますが、与太話の延長として読んでいただければ幸いです。

Update-motdとは?

さて、サーバーの「入り口」をゲームのように変えるための舞台装置こそが、Linuxにおける MotD (Message of the Day) の仕組みです。

これは、/etc/update-motd.d/ ディレクトリ配下に配置されたシェルスクリプトやプログラムを順番に実行し、その出力結果を統合してユーザーに表示する仕組みです。

ポイント:

従来の MotD (/etc/motd) が再起動しない限り変わらない「貼り紙」だとすれば、Update-motd はログインのたびに最新の情報に更新される「ニュースフィード」のようなものです。

この動的な特性を利用することで、先述の「遊び心と有用性の追加」というテーマを実現しました。

筆者の例

といっても「なんのこっちゃ」になると思いますので、以下に該当しない方はこれ以降は読まなくて結構です。

  • そもそもLinuxサーバと言われても分からない
  • 仕事は仕事であり遊び心も実用性も不要

では、

/etc/update-motd.d/99-custom に組み込んだ例がこちらです。

#!/bin/bash
# Show weather information. Change the city name to fit your location
ansiweather -l City1 -s true -d true -a false
ansiweather -l City2 -s true -d true -a false

echo "CAST IN NAME OF GOD, YE NOT GUILTY."

# 現在の言語ロケールを保存します。
original_locale=$(locale | grep "LANG=" | cut -d= -f2)

# ロケールを英語に修正します。
export LANG="en_US.UTF-8"

# ロサンゼルス(カリフォルニア)の曜日を調べます。
day_of_week=$(TZ="America/Los_Angeles" date +"%A")

# 金曜日だった場合のみメッセージを表示します。
if [ "$day_of_week" == "Friday" ]; then
    echo "Today is Friday in California."
fi

# 元の言語ロケールに戻します。
export LANG="$original_locale"

ruby /home/user/script/ruby/ssl_checker.rb domain1.example.com domain2.example.com domain3.example.com

bash /home/user/script/bbc_headline.sh

スクリプトの構成と設計思想

このカスタムスクリプトは、

  • ログインコンソールに遊び心を持たせる
  • 重要な情報を一瞥できるようにする

という目的に沿って、大きく四つの機能ブロックで構成されています。

パーソナルな情報の表示と遊び心の追加

コマンド/機能目的と意義
ansiweather -l City1 ...関心のある地域(例:City1, City2)の天気を、カラフルで分かりやすい形式で表示します。作業開始前に個人的な関心事を満たします。
echo "CAST IN NAME OF GOD, YE NOT GUILTY."固定の引用句やメッセージを表示し、ログイン体験にユーモアや個人的なタッチを加えます。
Friday in California Check実行環境のタイムゾーンではなく、特定のタイムゾーン(LA)の曜日をチェックしてメッセージを表示する、技術的な遊び心です。ロケールを一時的に変更し、環境を汚染しないよう元に戻す配慮も含まれています。

サーバー運用上の重要情報チェック

コマンド/機能目的と意義
ruby /home/user/script/...自作のSSL証明書チェッカーを実行し、管理対象のウェブサイトの証明書期限(残日数)をチェックします。期限が近い場合は色を変えて警告するため、サービスの維持に必要な最重要情報を瞬時に把握できます。

外部のニュース情報取得

コマンド/機能目的と意義
bash /home/user/script/...自作のBBCヘッドライン取得スクリプトを実行し、世界のニュースの要約(ヘッドライン)を表示します。作業に入る前にグローバルな視点を持てるようにします。

さっくり言うと

この /etc/update-motd.d/99-custom スクリプトは、ログイン直後の数秒間を、

  1. 個人的な関心事の確認
  2. サーバーの緊急運用リスクのチェック
  3. 世界の主要情報のブリーフィングに使うため

多機能なパーソナルダッシュボードとしての役割を果たしています。

では、各スクリプトを見ていきましょう。

個人的な関心事の確認

  • ansiweather -l City1 ...
    • これは天気をコマンドラインで知るためのコマンド。(ビルトインコマンドではないので sudo apt install ansiweatherでインストールします。
    • これによって、自分が住む町や興味のある都市、行きたい場所などの情報をつかみます。
  • echo "CAST IN NAME OF GOD, YE NOT GUILTY."
    • 単に標準出力にメッセージを流すためのコマンド。サーバ接続を「ショータイム!」とするために仕込んでいます。
  • Friday in California Check
    • 『忍者戦隊カクレンジャー』発の有名なインターネットミーム『Today is Friday in California』をカリフォルニア(ロスアンゼルス)時間の金曜日にのみ表示するというスクリプト。
    • 筆者にとっては金曜日カレーのような意味合いを持ちます。

サーバ運用上のスクリプト

これはAIの力を借りながらも極めて丁寧で重要なスクリプトにしました。なので、スクリプトの意味に関してはChatGPTなりGoogle Geminiなりに聞きましょう。無料アカウントでも親切に教えてくれます。

#!/usr/bin/env ruby

require 'openssl'
require 'socket'
require 'date'
require 'uri'
require 'timeout'

# 色付け用の定数
COLOR_RED = "\e[31m"
COLOR_YELLOW = "\e[33m"
COLOR_GREEN = "\e[32m"
COLOR_RESET = "\e[0m"

# URLの最終的な到達先を取得するメソッド
def get_effective_url(url)
  # curlを使ってリダイレクトを追いかけ、最終的なURLを取得する
  # -s: サイレント, -L: リダイレクト追従, -I: ヘッダのみ, -o /dev/null: ボディ破棄, -w '%{url_effective}': 最終URLを出力
  effective_url = `curl -sLI -o /dev/null -w '%{url_effective}' "#{url}"`
  effective_url.empty? ? nil : effective_url
end

# 証明書の有効期限を取得するメソッド
def get_certificate_expiry_date(url)
  uri = URI.parse(url)
  hostname = uri.host
  port = uri.port || 443 # ポートがなければ443を使う
  ssl_socket = nil
  tcp_client = nil

  begin
    Timeout.timeout(5) do
      tcp_client = TCPSocket.new(hostname, port)
      ssl_context = OpenSSL::SSL::SSLContext.new
      ssl_socket = OpenSSL::SSL::SSLSocket.new(tcp_client, ssl_context)
      ssl_socket.hostname = hostname
      ssl_socket.connect

      cert = ssl_socket.peer_cert
      expiration_date = DateTime.parse(cert.not_after.to_s)
      days_remaining = (expiration_date - DateTime.now).to_i

      return expiration_date, days_remaining
    end
  rescue Timeout::Error
    return nil, "サーバーへの接続がタイムアウトしました。"
  rescue => e
    return nil, e.to_s
  ensure
    ssl_socket&.close
    tcp_client&.close
  end
end

# 結果を表示するメソッド
def print_result(url, expiration_date, days_remaining)
  if expiration_date
    formatted_date = expiration_date.strftime("%Y/%m/%d")
    
    # 残り日数に応じて色を選択
    color = if days_remaining < 14
              COLOR_RED
            elsif days_remaining < 30
              COLOR_YELLOW
            else
              COLOR_GREEN
            end

    puts "サイト #{url} の有効期限は #{formatted_date} です。#{color}残り #{days_remaining} 日です。#{COLOR_RESET}"
  else
    puts "#{COLOR_RED}サイト #{url} の証明書取得に失敗しました: #{days_remaining}#{COLOR_RESET}"
  end
end

# メイン処理
def main
  # コマンドライン引数があるかどうかで処理を分岐
  domains_to_check = if ARGV.empty?
                       # 引数がない場合は、対話式で入力を受け付ける
                       print "チェックしたいサイトのドメインを入力してください(例: example.com): "
                       [gets.chomp]
                     else
                       # 引数がある場合は、それらを全てチェック対象とする
                       ARGV
                     end

  # 各ドメインをチェック
  domains_to_check.each do |domain|
    # 対話モードで空エンターされた場合などをスキップ
    next if domain.nil? || domain.strip.empty?
    
    # http/httpsから始まらない場合はhttpsを付与
    initial_url = domain.start_with?('http') ? domain : "https://#{domain}"
    
    puts "Checking: #{initial_url} ..."
    final_url = get_effective_url(initial_url)

    if final_url.nil?
      puts "#{COLOR_RED}サイト #{initial_url} にアクセスできませんでした。#{COLOR_RESET}"
      next
    end
    
    expiration_date, days_remaining = get_certificate_expiry_date(final_url)
    print_result(final_url, expiration_date, days_remaining)
  end
end

# メイン処理を呼び出し
main

このスクリプトはWebサーバ管理上、とても重要です。

筆者はLet's Encryptのワイルドカード証明書を用いているため、この適切な時期でのチェック(Let's Encryptは90日と短いです)が

  • 「そろそろ準備をしないと」
  • 「まだゆっくりできる」

の判断が可能になります。

BBC Headline

これも、ほぼビルトインコマンドで完結。必要な外部モジュールもxmlintのみ。

#!/bin/bash

# デフォルト値の設定
default_section="world"
default_count=3

# メインセクションのリスト
main_sections=("world" "uk" "business" "politics" "health" "education" "science_and_environment" "technology" "entertainment_and_arts")

# グローバルセクションのリスト
global_sections=("africa" "asia" "europe" "latin_america" "middle_east" "us_and_canada")

# 全セクションのリストを統合
all_sections=("${main_sections[@]}" "${global_sections[@]}")

# 引数の処理
if [[ "$1" =~ ^[0-9]+$ ]]; then
    section=$default_section
    count=$1
else
    section=${1:-$default_section} # 引数1が指定されていない場合はデフォルト値を使用
    count=${2:-$default_count}     # 引数2が指定されていない場合はデフォルト値を使用
fi

# 引数の短縮形を対応する正式名に変換
case "$section" in
    "usa" | "n-usa") section="us_and_canada" ;;
    "me") section="middle_east" ;;
    "latam" | "la") section="latin_america" ;;
    "eu") section="europe" ;;
    "science") section="science_and_environment" ;;
    "entertainment") section="entertainment_and_arts" ;;
    *) section=$section ;; # その他はそのまま
esac

# セクションの検証
if [[ ! " ${all_sections[@]} " =~ " ${section} " ]]; then
    echo "Error: Invalid section '${section}'. Valid sections are: ${all_sections[*]}"
    exit 1
fi

# URLの構築
if [[ " ${main_sections[@]} " =~ " ${section} " ]]; then
    url="https://feeds.bbci.co.uk/news/${section}/rss.xml"
else
    url="https://feeds.bbci.co.uk/news/world/${section}/rss.xml"
fi

# 最初に一度だけRSSフィードをダウンロードし、変数に格納する
xml_content=$(curl -s "$url")

# コンテンツが取得できなかった場合はエラー終了
if [ -z "$xml_content" ]; then
    echo "Error: No headlines found for section '${section}'. Please check the section name or try again later."
    exit 1
fi

# フィードの最終更新日時を取得し、フォーマットする
# 2>/dev/null は、xmllintが出す軽微なエラーを非表示にするため
feed_date_raw=$(echo "$xml_content" | xmllint --xpath "string(//channel/lastBuildDate)" - 2>/dev/null)
if [ -n "$feed_date_raw" ]; then
    # JSTに変換して表示フォーマットを整える
    feed_date_formatted=$(date -d "$feed_date_raw" '+%Y/%m/%d %H:%M:%S %Z')
fi

# 見出しを取得
headlines=$(echo "$xml_content" | xmllint --xpath "//item/title/text()" - 2>/dev/null | sed -e 's/<!\[CDATA\[//g' -e 's/\]\]>//g' | head -n "$count")

# 見出しの表示
echo "BBC News - ${section} section (${count} headlines)"
# 取得した日付を表示
if [ -n "$feed_date_formatted" ]; then
    echo "As of: ${feed_date_formatted}"
fi
echo "--------------------------------------------------" #区切り線
echo "$headlines"

これは

./bbc_headline.sh

とすることで

BBC News - asia section (7 headlines)
As of: 2025/11/02 20:04:03 JST
--------------------------------------------------
300 million tourists just visited China's stunning Xinjiang region. There's a side they didn't see
Devastation on repeat: How climate change is worsening Pakistan's deadly floods
Shein accused of selling childlike sex dolls in France
Cruise cancelled following death of woman left behind on island
From the fringe to the final - India's phenomenon
Why the Indian passport is falling in global ranking
China to loosen chip export ban to Europe after Netherlands row

等の表示が可能になります。

この、日付とニュースの同時表示というのは

「このときにこんなニュースがあった」と、日付と行動の紐付け並びに重要なフックが可能になります。

やや強引なまとめ

と、スクリプトはちょっとした知識とAIの助けがあれば構築可能なものばかりではありますが、

冒頭に掲げた

Spoonful sugar helps medicine goes down(スプーン一杯の砂糖で苦い薬も平気で飲める)

という工夫は何にでも応用可能という言葉で本記事を締めます。

Page 2 of 56

Powered by WordPress & Theme by Anders Norén