「魔法の箒を思わせるような都内の超低空飛行」を体験するため、羽田空港まで東京モノレール羽田線を利用。


滑るように、建物を縫うかのようにモノレールは羽田空港に到着。
ここでの目的は

「チップス」です。疲れにダイレクトに効く揚げ物、それも英国スタイルとなれば味は格別。

この、
- ジェットの爆音が響き
- 時折、燃料のにおいがあり
- 展望デッキからの飛行機が見られる
という、「東京都内で最も空に近い場所」はかなり乙なものです。


こういう場所ではフィッシュアイもしっかり活きました。
「魔法の箒を思わせるような都内の超低空飛行」を体験するため、羽田空港まで東京モノレール羽田線を利用。


滑るように、建物を縫うかのようにモノレールは羽田空港に到着。
ここでの目的は

「チップス」です。疲れにダイレクトに効く揚げ物、それも英国スタイルとなれば味は格別。

この、
という、「東京都内で最も空に近い場所」はかなり乙なものです。


こういう場所ではフィッシュアイもしっかり活きました。
Webサーバのみならず、サーバ運用において「どのプロセスがCPU/メモリを喰っているか」というボトルネックの把握は重要です。
それを把握するためのスクリプトのご紹介です。
以下の3点が主な理由です:
といっても、topやwコマンドなどでは煩雑な情報が多いため、シンプルに
に絞り込みを行います。というのも、プロセスの暴走は先に示したとおり、CPU/メモリを多く使うからです。
それをより分かりやすく視覚化するスクリプト例が以下の通り。
top-procs.sh等の名前で、任意の場所に作成します。
#!/bin/bash
#================================================================
# System Resource Monitor (Refined by Riza)
#================================================================
# --- Colors ---
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
CYAN='\033[0;36m'
BOLD='\033[1m'
NC='\033[0m' # No Color
# --- Defaults ---
TOP_N=5
MODE="all" # all, cpu, mem
# --- Usage ---
usage() {
echo -e "${CYAN}Usage: $(basename "$0") [-c] [-m] [-n NUM] [-h]${NC}"
echo " -c : CPU使用率順で表示"
echo " -m : メモリ使用率順で表示"
echo " -n NUM : 表示する行数を指定 (Default: ${TOP_N})"
echo " -h : ヘルプ表示"
exit 0
}
# --- Argument Parsing (getopts is standard) ---
while getopts "cmn:h" opt; do
case $opt in
c) MODE="cpu" ;;
m) MODE="mem" ;;
n) TOP_N="$OPTARG" ;;
h) usage ;;
\?) usage ;;
esac
done
# --- Core Function ---
# Arguments:
# 1: Sort Key (e.g., -pcpu or -pmem)
# 2: Title
# 3: Format String for ps
show_top() {
local sort_key="$1"
local title="$2"
echo -e "\n${BOLD}${CYAN}--- ${title} (Top ${TOP_N}) ---${NC}"
# Header format specifically tailored for clarity
printf "${YELLOW}%-6s %-6s %-8s %-20s %s${NC}\n" "%CPU" "%MEM" "PID" "USER" "COMMAND"
echo "---------------------------------------------------------"
# ps command explanation:
# -e : Select all processes
# -o : User-defined format
# --sort : Internal sorting (descending with -)
# head : Limit output
ps -e -o pcpu,pmem,pid,user,args --sort="${sort_key}" | \
head -n "$((TOP_N + 1))" | tail -n "$TOP_N" | \
awk '{
# Highlighting logic
cpu=$1; mem=$2;
# Colorize CPU if > 50% or MEM > 50% (Arbitrary threshold for visual aid)
color="'"${NC}"'";
if (cpu > 50.0 || mem > 50.0) color="'"${RED}"'";
else if (cpu > 10.0 || mem > 10.0) color="'"${GREEN}"'";
# Reconstruct the line with printf for alignment
# $1=CPU, $2=MEM, $3=PID, $4=USER, $5...=COMMAND
# Capture the full command (args) which starts from $5
cmd=""; for(i=5;i<=NF;i++) cmd=cmd" "$i;
printf "%s%-6s %-6s %-8s %-20s %s%s\n", color, $1, $2, $3, $4, cmd, "'"${NC}"'"
}'
}
# --- Main Logic ---
case $MODE in
cpu)
show_top "-pcpu" "CPU Consumers"
;;
mem)
show_top "-pmem" "Memory Consumers"
;;
all)
show_top "-pcpu" "CPU Consumers"
show_top "-pmem" "Memory Consumers"
;;
esac
echo ""
ps --sort の活用: これが最大の改良点よです。ps aux | sort -k ... はデータをテキストとして処理するから遅いのですが、ps --sort=-pcpuはカーネルから情報を取得する段階でソートします。-n オプションの追加: ./top-procs.sh -n 10 と打てばトップ10が見られるようにしています。./top-procs.sh
を実行することで、
--- CPU使用率 (上位 5 プロセス) ---
%CPU PID COMMAND
-----------------------------------------
52.10% 12345 ruby_app_server: /var/www/webapp1 (production)
9.40% 1086 /usr/sbin/database_server [...]
3.80% 42162 /usr/sbin/web_server -k start
1.50% 42161 /usr/sbin/web_server -k start
0.90% 7978 nodejs_process /path/to/nodejs_app/server.js
--- メモリ使用率 (上位 5 プロセス) ---
%MEM PID COMMAND
-----------------------------------------
13.10% 1984 /usr/bin/java -Xms256m -Xmx256m [...] search_engine -Des.path.home=/usr/share/search_engine [...]
10.00% 1086 /usr/sbin/database_server [...]
7.50% 12345 ruby_app_server: /var/www/webapp1 (production)
3.90% 78630 ruby_app_server: /var/www/webapp2 (production)
3.80% 76583 ruby_app_server: /var/www/webapp3 (production)
が出てきます。
この例では、rubyアプリが圧倒的にCPUを消費し、ElasticSearchがメモリを食っているというのが分かります。
そして、
-a / 引数無し : CPUとメモリの両方を表示-c : CPU情報のみを表示-m : メモリ情報のみを表示-h : これら引数やスクリプトの内容を表示と、目的に合わせた柔軟な表示も可能にしています。
こういった障害発生時のボトルネック判定時、いちいちスクリプトの場所を探すという悠長なことはできません。
なので、余裕がある(つまりこのスクリプトを作成した直後です)状況で、
sudo ln -sf /path/to/script/top-procs.sh /usr/local/bin/top-procs
として、どこからでもコマンドを呼び出せるようにします。(スクリプトの場所は自分がこれを保存した絶対パスを指定してください)
which top-procs
で
/usr/local/bin/top-procs
と表示されればコマンド化は完了。こうすることにより、どのユーザーでもこのコマンド一発で上記のボトルネック判定が可能になります。
https://barrel.reisalin.com/books/950a4/page/apachephp-fpm
のスクリプトの改良版となります。
-r オプションでreloadのみ実施#!/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) オプションの追加: プロセスを殺さずに設定を読み直す。このスクリプトをコマンドとして実行できるようにします。
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。設定変更のみを対象。-h この引数を表示。
概要:
Nextcloudアップデート後に出るようになった
高性能バックエンドが構成されていません - 高性能バックエンドなしでNextcloud Talkを実行すると、非常に小規模な通話 (最大2~3人の参加者)でのみ利用できます。複数の参加者との通話がシームレスに機能するようにするためには高性能バックエンドを設定してください。
このメッセージを対処するため、「高性能バックエンドサーバ」とやらをインストールすることにします。
当初はこれは考慮していませんでした(個人用のファイルサーバとして使っていたため)が、
「自分の信条を曲げてまでDockerを入れてしまった以上、こいつもDockerで入れる」
と“それはそれ、これはこれ/That's another matter entirely, chaps."の精神でインストールしていきます。
接続の安定化・高速化です。
これまでPHP(Nextcloud本体)が行っていた「誰と誰をつなぐか」という重い処理(シグナリング)を、専用のGo言語プログラム(高性能バックエンド)が肩代わりします。これにより、通話開始までの時間が短縮され、サーバー全体の負荷が劇的に下がります。
sudo aptitude install docker-compose
筆者の好みでaptitudeを用いています。
openssl rand -hex 16
4accc25d95464f00a9537dc956bd5414といった文字列が出ます。これを以下「共有シークレット」と呼びます。
任意のコンテナ設定ファイル群に以下を作成します。
mkdir -p /path/to/container/directory/nextcloud-signaling
cd /path/to/container/directory/nextcloud-signaling && pwd
このディレクトリに入り、ファイルを作っていきます。
※ドメイン名などは自分の環境に合わせましょう。※
[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) を記述します。
cd /path/to/container/directory/nextcloud-signaling && pwd
念のため、先ほど作成したディレクトリにいることを確認してください。
sudo docker-compose up -d
sudo docker ps
STATUS が UPになっていれば問題なく起動できています。
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を確認します。
systemctl status apache2.service
active(running)を確認します
sudo systemctl restart apache2.service
systemctl status apache2.service
active(runnning)を確認します。
ブラウザで、
にアクセスし、{"nextcloud-spreed-signaling":"Welcome", ...}の表示が出ていればOKです。
Nextcloudに管理者ログインし、[管理設定] > [Talk] > [高性能バックエンド] を設定します。
設定後、「保存」ボタンをクリックします。 「OK: 実行中のバージョン: x.x.x~docker」 と表示されれば完了です。
もっとさっくり言うと:
重たいApacheやPHPは、本当に必要な画面表示の時だけ働けば良くなったので、サーバー全体が静かになり、反応速度(レスポンス)が向上します。
諸々が落ち着き、ボードゲームに手を出す余裕が生まれました。

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

占い代わりのアグリコラ。強い職業に恵まれました。特に、日雇いと同時に畑を耕す職業や、増築分の石の数を減らす職業のおかげ。
また、小進歩も
も加わり、手番を圧縮。63点という高得点を撮ることもできました。
こういう、物理のコンポーネントは本当に落ち着きます。
1ヶ月以上溜めていた万年筆のインク補充が完了。

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

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


新たに4本ともなれば、大容量のペンケースもギチギチです。
この特別な万年筆は更に特別な場所で行う必要があると理解。

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

の「サブカラーで表現する」色彩戦略は合っていました。
クリスタルエレメントなみに使いやすいフェザードラフトを調合。
は本作では貴重です。
無垢の鍵、解放後。(サルドニカのメインクエスト終了後)。特に、「属性追加・氷」が必要です。
また、品質上限999や投入回数増などのスキルツリーをアクティベートしていきます。
調合メニューから「ルフト」を選びます。

ヴィント鉱を入れ

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

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

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

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

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

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

ここで「属性追加・氷」を入れます。
あとは様々な効果を発現させておきます。

属性・超属性を決めていきます。
ここでの属性値はなんと15。リビルドでは逆にこの属性値は徒になりますが、全ての属性でこの2桁は大概のマテリアル環をアクティベートできます。
Nextcloud32.0.2にアップデート後に表示された際に出てきた
Client Push
Client Push is not installed, this might lead to performance issue when using desktop clients.
と出てきたので、これを導入しました。筆者のようにIP/クローラー制限やMod_Securityを利用している方でもなんとかなる手順にしています。
正式名称は「High Performance Back-end / notify_push」。
一言でいうと、「ファイルの変更をクライアントに『瞬時に』知らせる機能」です。
郵便受けの確認に例えるとわかりやすいでしょう。
「必須ではありませんが、導入すると劇的に快適になります」
このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。
など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。
※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。
もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は
方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。
Nextcloudの管理者画面 >「アプリ」> 虫眼鏡アイコンで 「Client Push」を検索 > インストール・有効化します。
ここまでは単純です。
cd /path/to/nextcloud/root/directory && pwd
自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)
sudo -u www-data php occ maintenance:mode --on
運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。
Client Pushは「WebSocket」という特殊な通信を使用します。Apacheでこれを扱えるようにモジュールを有効化します。
sudo a2enmod proxy proxy_http proxy_wstunnel
systemctl status apache2.service
active(running)を確認します
sudo systemctl restart apache2.service
systemctl status apache2.service
active(runnning)を確認します
このタイミングでサービス再起動が必要なのは何故かというと、
を有効化していないと、この後のApache設定変更時に「これらのモジュールが無い」とサーバは判断するからです。
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を確認します。
systemctl status apache2.service
active(running)を確認します
sudo systemctl restart apache2.service
systemctl status apache2.service
active(runnning)を確認します
Client Pushは、Webサーバーとは別に裏方で動くプログラムです。これを常駐させるための設定ファイルを作成します。
`/etc/systemd/system/notify_push.service`
を、任意の方法で作成します。
※ User や WorkingDirectory、ExecStart のパスは、ご自身の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)を確認します
ここがつまずきポイントでした。
サーバーが自分自身のURL(https://your.domain.com)にアクセスした際、ネットワーク環境(ヘアピンNATなど)によっては一度外に出てグローバルIP経由で戻ってくる場合があります。
この場合、Nextcloudは「外部からのアクセス」とみなして通信を拒否してしまいます。これを防ぐため、config.php に自身のグローバルIPを信頼済みプロキシとして登録します。
sudo cp -pi /path/to/nextcloud/root/config/config.php /path/to/backup/directory/config.php.$(date +%Y%m%d)
格納場所は自分の環境に合わせます。
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 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)は環境に合わせて変更してください。
sudo systemctl restart notify_push
systemctl status notify_push.service
active(running)を確認します。
Nextcloudの管理画面(「概要」または「ログ」)を確認し、「Client Push」に関する警告が消えていれば導入成功です。
これでファイル同期が爆速になり、サーバー負荷も低減されているはずです。警告を消したいだけの場合でも、この手順を行っておけば「高セキュリティかつ高性能」な環境が手に入ります。
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を個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。
など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。
※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。
もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は
方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。
正直、筆者はDockerを信用していませんが「必要ならば入れるまで」です。
cd /path/to/nextcloud/root/directory && pwd
自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)
sudo -u www-data php occ maintenance:mode --on
運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。
AppAPIは、背後でDockerコンテナを立ち上げてアプリケーションを実行します。まずはUbuntuサーバー自体にDockerが入っているか確認し、なければインストールします。
sudo aptitude update
※筆者の好みでaptitudeを用いています。好みに応じてaptに読み替えてください。
sudo aptitude install docker.io
sudo systemctl start docker
sudo systemctl enable docker
systemctl status docker.service docker.socket
active(running)とenabledを確認します。
NextcloudはApacheユーザー(通常 www-data)で動作していますが、Dockerは roto 権限で動いています。NextcloudからDockerを安全に操作させるために、Docker Socket Proxy という中継役のコンテナを立ち上げるのが推奨される方法です。
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
出力されたリストの中に、以下の特徴があれば成功です。
nextcloud_app_api_dsp という名前がある。Up X seconds や Up X minutes となっている。(ここが Exited だと停止しています)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にログインし、
管理 > AppAPI
に進みます。
Deploy Daemonsの項目の+デーモンを登録に進みます。
以下のように設定します。
このあと、「Check connection」をクリックします。「Daemon connection successful」と出たら「Register」をクリックします。
再びNextcloudがインストールされているWebサーバに接続します。
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
systemctl status apache2.service
active(running)を確認します
sudo systemctl restart apache2.service
systemctl status apache2.service
active(runnning)を確認します
管理者権限でNextcloudにログインし、
AppAPIデフォルトのデプロイデーモンはHaRPを使用していません。パフォーマンス向上のため、アップグレードをご検討ください。
とメッセージが警告に変わっていればOKです。
全く問題ありません。誤差レベルです。
今回使用する alpine/socat というコンテナは、非常に軽量なことで有名な「Alpine Linux」というOSをベースに、socat という単純な転送プログラムだけが動いています。
サーバー全体のメモリが数GBある環境であれば、このコンテナの存在に気づかないレベルの軽さですので、ご安心ください。
このコンテナに関しては、「データが消えても問題ない(そもそもデータを保存しない)」仕組みになっているため、大丈夫です。
このコンテナ nextcloud_app_api_dsp は、「土管(パイプ)」のような役割しかしていません。
--restart always というオプションのおかげで、Ubuntuサーバーを再起動すると、このコンテナも自動的に「新品の状態」で立ち上がります。立ち上がった瞬間から、再び「中継役(土管)」としての仕事を再開します。前回の中身を覚えている必要がないため、これで正常に動作します。
カメラの試し撮りを行った帰り、iPadを広げた途端に強烈な情報が目に入りました。
それは
と言えるものであり、その場で手続きを済ませ、翌日に到着。

ハリー・ポッターシリーズ、
それぞれのLAMY AL-Star。そもそもLAMY万年筆は愛用品。しかも、それぞれの寮の色。ペン先も使いやすいEF。
それぞれ、プレミア価格ではなく在庫ありという幸運にも助けられ、届きました。
さて、ここまでの逸品。量産品を愛用する身ではありますが「それはそれ」です。これを最大限に活かすため、まずはインクを決めるところからです。
それぞれの寮に合わせ
はワンパターンです。かといって別の色というのも何か合いません。そこで、新たなインクを買い求めました。

そこで決めたのは、「寮のサブカラー」です。
さらに、インクに寮のマステを貼り、更に迷いをなくします。
書き味などを確かめるのはこのあとで。
Powered by WordPress & Theme by Anders Norén