投稿者: manualmaton Page 3 of 279

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は、本当に必要な画面表示の時だけ働けば良くなったので、サーバー全体が静かになり、反応速度(レスポンス)が向上します。

週末のソロゲー2連。

諸々が落ち着き、ボードゲームに手を出す余裕が生まれました。

宝石の煌めきソロ

BGGのバリアントを自分なりに調整したもの。固め取り戦略がうまくいき、18点の勝利となりました。

アグリコラ

占い代わりのアグリコラ。強い職業に恵まれました。特に、日雇いと同時に畑を耕す職業や、増築分の石の数を減らす職業のおかげ。

また、小進歩も

  • 食物2つを柵に変換
  • 麦1つを野菜に変換

も加わり、手番を圧縮。63点という高得点を撮ることもできました。

こういう、物理のコンポーネントは本当に落ち着きます。

補充と試し書き。

1ヶ月以上溜めていた万年筆のインク補充が完了。

手持ちの万年筆、全て補充したあと、いよいよ、

『ハリー・ポッター ホグワーツ限定モデル』全てにインクを入れました。

新たに4本ともなれば、大容量のペンケースもギチギチです。

この特別な万年筆は更に特別な場所で行う必要があると理解。

オフィスビルの休憩スペースという、ある意味相応しいところで実施。

  • グリフィンドール / 金 / 橙路
  • スリザリン / 銀 / 冬将軍
  • ハッフルパフ / 黒 / 竹炭
  • レイブンクロー / 銅 / 春暁

の「サブカラーで表現する」色彩戦略は合っていました。

『ライザのアトリエ3(DX含む)』気体の属性値追求。(全属性のフェザードラフト調合)

クリスタルエレメントなみに使いやすいフェザードラフトを調合。

  • 気体
  • 動物素材
  • 影響拡大つき

は本作では貴重です。

いつ頃作れるか?

無垢の鍵、解放後。(サルドニカのメインクエスト終了後)。特に、「属性追加・氷」が必要です。

また、品質上限999や投入回数増などのスキルツリーをアクティベートしていきます。

必要な素材、鍵

  • ヴィント鉱
  • きのこ
  • 中和剤
  • シンティラ鉱石
  • 風晶玉(ルフトからのレシピ変化)
  • 巨鳥の風切羽
  • 秘密の鍵:属性値増加系
  • 秘密の鍵:属性追加・氷

調合手順

調合メニューから「ルフト」を選びます。

ヴィント鉱を入れ

中和剤を入れます。(賢者の石もしっかりした中和剤です)

属性値増加・中(強があればなおよし)を使います。

シンティラ鉱石を入れて風晶玉にレシピ変化します。

ここでも「属性値増加」の鍵を用います。

適当な位置で超属性「超濃度」を持つ素材を入れます。

巨鳥の風切羽を入れてフェザードラフトに変化します。

ここで「属性追加・氷」を入れます。

あとは様々な効果を発現させておきます。

属性・超属性を決めていきます。

ここでの属性値はなんと15。リビルドでは逆にこの属性値は徒になりますが、全ての属性でこの2桁は大概のマテリアル環をアクティベートできます。

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)が残っている限り繋がり続けます。

色と差し色。

カメラの試し撮りを行った帰り、iPadを広げた途端に強烈な情報が目に入りました。

それは

  • No Time
  • No Choise
  • Without Thinking

と言えるものであり、その場で手続きを済ませ、翌日に到着。

ハリー・ポッターシリーズ、

  • スリザリン
  • レイブンクロー
  • ハッフルパフ
  • グリフィンドール

それぞれのLAMY AL-Star。そもそもLAMY万年筆は愛用品。しかも、それぞれの寮の色。ペン先も使いやすいEF。

それぞれ、プレミア価格ではなく在庫ありという幸運にも助けられ、届きました。

さて、ここまでの逸品。量産品を愛用する身ではありますが「それはそれ」です。これを最大限に活かすため、まずはインクを決めるところからです。

それぞれの寮に合わせ

はワンパターンです。かといって別の色というのも何か合いません。そこで、新たなインクを買い求めました。

そこで決めたのは、「寮のサブカラー」です。

  • スリザリン:銀
    • 冬将軍。この冷徹な野心を「冬」に込めました。
  • ハッフルパフ:黒
    • 竹炭。最も多用する色は、彼等の調和、連帯力に一致。
  • グリフィンドール:金
    • 橙路。色合いが金に近かったためこちらに。「路は自分で切り開く」グリフィンドールの精神にも合います。
  • レイブンクロー:銅
    • 春暁。同じく銅の鈍さと明るさ。彼等の寮ならそれこそ暁まで研究や議論に明け暮れいるでしょう。

さらに、インクに寮のマステを貼り、更に迷いをなくします。

書き味などを確かめるのはこのあとで。

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が起動しません。編集後は慎重に確認を行いましょう。

IDEA SPHERE 『前任者の罠を解除せよ』使い手の意図を読み解く

再掲しますが『ハリー・ポッターと賢者の石』のオリバンダー翁の言葉

The wand chooses the wizard, Mr. Potter. It's not always clear why.
「杖が魔法使いを選ぶのです、Mr.ポッター。何故そうなるかは、はっきりとは分かりませんが」

これをまたもや引き合いに出し、「前の魔法使いを選んだ杖」をどう制御したかというお話です。

降ってわいた幸運

本当に些細なきっかけで「カメラの引き取り手を探している人がいる」という家族からの依頼に二つ返事。

「まぁ、何らかの収穫はあるだろう」程度の認識でしたが、その認識を遙かに上回るものがありました。

OLYMPUS E-P5 レンズ付き。

一瞬、自分の目を疑いました。というか三回ぐらい確認しました。

空き箱だけかと思えば

  • レンズ
  • バッテリー
  • 充電セット
  • オプションストラップ
  • カメラカバー
  • カメラケース

と、メモリーカードを除く全てがそこにありました。

筆者はその後継であるE-P7を使っていますが、その前々モデルは眠気も一週間の疲れも吹っ飛ぶものです。

試し撮りの違和感

早速、試し撮りを行いますが、大きな「?」がつくもの。普段のフィギュア撮影を鑑みても

「何かが違う。このレンズ、ここまでズームしないはず」
「なんでこんなにブレるんだ? (15年ぐらい前に買った)E-PL1でもここまで揺れないぞ?」

が最初に思ったこと。広角なのにやたらとズームしている。標準レンズとほぼ同等の60mmがやたらと近い。マイクロフォーサーズの距離感は体で知っているのに、その体感が「明らかに違う」と見て取れるもの。

では、故障か? それはあり得ません。傷一つ無いボディにレンズプロテクターと純正アクセサリ。そしてボロボロに読み込まれたマニュアルは「大切に扱われた代物」という明白なサインです。

そこで、検証を行います。

設定の見直し

設定の中に答え(というか前の持ち主が残した罠)の一つがありました。

それは「デジタルテレコン(カメラ内部でズームする機能)がOn」になっていたという罠。

これを解除して、ようやく見慣れた画角が蘇りました。これを伴って、終わりつつある紅葉を撮りに出かけます。

屋外での検証結果

冬の澄み切った空気での撮影は成功。特に広角レンズの描写力には感動です。紅葉の赤と青空がしっかり決まっています。

これで満足……という訳にはいきませんでした。

カメラからの挑戦状

さて、撤収するかと言うときに、カメラが語りかけるような「声」が聞こえてくるかのようでした。折しも作業用に見ていた『アカギ』の盲目の裏プロ、市川のこの言葉が引っかかったのです。

「まだ半分しか済んでない そうだろう?
 君はわしに向けて引き金を引いた……
 ならば自分に向けても一度引くべきだ
 それでこそ この場は丸く収まろうというもの……
 違うかい? アカギくん…………」

つまり「撮ったときのもう一つの違和感」である「ブレ」を確認しなければならないという、もう一つの決定的な違和感です。

この、カメラ自身からの挑戦状に等しい検証として選んだのが、筆者がよく訪れる葛西臨海水族園。

  • 格段に落ちる光量
  • 動く被写体
  • 多種多様な光源

と、カメラの「ストレステスト」には十分すぎる条件が揃っています。

見つけたカメラの「枷」

水槽を前にして、泳ぐ魚で撮影しましたが:「やはりシャッタースピードが遅くてブレる」でした。念のため、携行していたE-P7は問題なく撮影できます。レンズを差し替えてもです。

  • 屋外では問題なく撮影できた
  • 屋内では真価を発揮できない
  • デジタルテレコンはオフにした

ここで考えられる状況は何か? と、液晶を確認し、一つの決定的な答えを見つけました。

「そういえばISOが全然変化していない!」

です。光量が格段に落ちる屋内。ましてや水族館。ここで求められるのはISO1600を超える超高感度です。マニュアル撮影ならいざ知らず、Pモードでのこの光量はもはや何かの異常……

ではなく「カメラの設定」で、ISOが固定されていたという、もう一つの「枷」を見つけ、それを解放。

結果は歴然。そうして撮影した写真がこちら。「やはりこのカメラは大切に使われていた」という確信を持てました。

思ったこと

「この罠には気づかなかった」というよりも

「なぜ、前の持ち主はこういう設定にしていたのか?」です。おそらく、

  • 三脚大前提
  • スタジオのような強烈な光のもと
  • 細かいものを撮影する

運用をしていたのでしょう。前述した「杖が魔法使いを選ぶ」とは、「杖(カメラ)が魔法使い(使い手)の好みに合うよう、設定で最初からこうなった」と考える方が自然です。

なので、道具というものは、使い手の意志に沿って成長していく。それこそが、オリバンダー翁の言う

「 It's not always clear why / 何故そうなるかは、はっきりとは分かりませんが」

のwhyの正体だと思いました。

Page 3 of 279

Powered by WordPress & Theme by Anders Norén