
以前持ってた充電機能付きのストラップを紛失したので買い直しました。
見た目は上部などパラコート風。で、見て分かるようにコネクタ付き。

今回はカバーの覆いがストラップのコネクタに。返しとスプリングがあるので多少の衝撃では問題ない作りになってます。
これで、機動性と「ケーブル忘れてどうしよう」を解決できます。

以前持ってた充電機能付きのストラップを紛失したので買い直しました。
見た目は上部などパラコート風。で、見て分かるようにコネクタ付き。

今回はカバーの覆いがストラップのコネクタに。返しとスプリングがあるので多少の衝撃では問題ない作りになってます。
これで、機動性と「ケーブル忘れてどうしよう」を解決できます。
Nextcloudのアップデートは、それほど頻繁に行う作業ではありません。しかし、だからこそ毎回「あれ、このコマンド実行したっけ?」となりがちです。
筆者自身も、メンテナンスモードの切り替えやデータベースのバックアップなど、手順を一つひとつ確認しながら作業していました。そこで「毎回やることはスクリプトに任せよう」と考え、更新前のバックアップから updater.phar の実行までを一通り補助する Bash スクリプトを作成しました。
今回は、そのスクリプトの仕組みを紹介します。
動作を想定している環境は以下の通りです。
www-dataUbuntu系で一般的な構成であれば、そのまま利用できるようになっています。
最初に環境に合わせて、スクリプト冒頭の変数だけ変更します。
NC_DIR="/var/www/html/nextcloud"
NC_USER="www-data"
DB_NAME="nextcloud"
DB_USER="nextcloud"
BACKUP_DIR="/var/backups/nextcloud"
続いて実行権限を付与します。
chmod +x nextcloud_update.sh
最後に sudo で起動します。
sudo ./nextcloud_update.sh
途中では
を対話形式で確認します。
確認しながら進められるので、完全自動化というより「操作ミスを減らすための半自動化」という位置付けです。
Bashで自動化というと「全部ワンコマンドで終わらせる」方向へ行きがちですが、個人的にはサーバーの更新作業はそこまで割り切らない方が安心だと考えています。
特に Nextcloud のアップデートは、途中で状況を確認したくなる場面も少なくありません。
そのため、このスクリプトでは各工程ごとに確認を挟み、「人が判断するところ」と「機械に任せるところ」を分ける構成にしました。
毎回同じ手順を思い出しながら実行するより、確認すべきポイントだけに集中できるので、更新作業はかなり気楽になります。
以下がスクリプト全文です。
#!/bin/bash
# ==============================================================================
# Nextcloud Update & Database Backup Script
# ==============================================================================
set -euo pipefail
# --- 変数定義(環境に合わせて変更してください) ---
NC_DIR="/var/www/html/nextcloud"
NC_USER="www-data"
PHP_BIN="php"
# DB設定
DB_NAME="nextcloud"
DB_USER="nextcloud"
DB_HOST="localhost"
BACKUP_DIR="/var/backups/nextcloud"
# --- ユーティリティ関数 ---
log_info() {
echo -e "\n\e[34m[INFO]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1"
}
log_warn() {
echo -e "\e[33m[WARN]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1"
}
log_error() {
echo -e "\e[31m[ERROR]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1" >&2
}
ask_proceed() {
local prompt_msg="${1:-次のステップに進みますか?}"
while true; do
read -rp "👉 ${prompt_msg} [y/N]: " answer
case "${answer}" in
[yY]|[yY][eE][sS])
return 0
;;
[nN]|[nN][oS]|"")
log_warn "ユーザーにより処理が中断されました。"
exit 1
;;
*)
echo "'y' または 'n' を入力してください。"
;;
esac
done
}
# --- 前提チェック ---
# root 権限チェック(sudo 経由を含む root 以外は即時終了)
if [ "${EUID}" -ne 0 ]; then
log_error "このスクリプトは root 権限で実行する必要があります。(例: sudo $0)"
exit 1
fi
log_info "前提条件と実行権限を確認しています..."
if [ ! -d "${NC_DIR}" ]; then
log_error "Nextcloudディレクトリが見つかりません: ${NC_DIR}"
exit 1
fi
if ! command -v mysqldump &> /dev/null && ! command -v mariadb-dump &> /dev/null; then
log_error "mysqldump または mariadb-dump コマンドが見つかりません。"
exit 1
fi
mkdir -p "${BACKUP_DIR}"
# ==============================================================================
# Step 1: データベースパスワードの取得と認証確認
# ==============================================================================
log_info "【Step 1】データベース情報の入力"
read -rsp "🔑 DBユーザー (${DB_USER}) のパスワードを入力してください: " DB_PASS
echo
# パスワードの疎通確認
if ! MYSQL_PWD="${DB_PASS}" mysqladmin -h "${DB_HOST}" -u "${DB_USER}" ping &>/dev/null; then
log_error "データベースへの接続に失敗しました。パスワードまたはホスト設定を確認してください。"
exit 1
fi
log_info "データベースへの接続を確認しました。"
# ==============================================================================
# Step 2: メンテナンスモードの有効化
# ==============================================================================
log_info "【Step 2】メンテナンスモードの有効化"
ask_proceed "メンテナンスモードをONにしますか?"
sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode --on
log_info "メンテナンスモードを有効化しました。"
# スクリプト異常終了時にメンテナンスモード解除を促すトラップを設定
cleanup() {
if [ $? -ne 0 ]; then
log_warn "エラーが発生したため処理を停止しました。"
log_warn "必要に応じてメンテナンスモードを解除してください:"
log_warn "sudo -u ${NC_USER} ${PHP_BIN} ${NC_DIR}/occ maintenance:mode --off"
fi
}
trap cleanup EXIT
# ==============================================================================
# Step 3: DBバックアップの実行(インラインパスワード処理)
# ==============================================================================
log_info "【Step 3】DBバックアップの実行"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_backup_${TIMESTAMP}.sql.gz"
ask_proceed "DBバックアップを開始しますか? (保存先: ${BACKUP_FILE})"
# dumpコマンドの判定(MariaDB/MySQL互換)
DUMP_CMD="mysqldump"
command -v mariadb-dump &> /dev/null && DUMP_CMD="mariadb-dump"
# MYSQL_PWD環境変数を使用することで、psコマンド等へのパスワード露出を防止
if MYSQL_PWD="${DB_PASS}" ${DUMP_CMD} -h "${DB_HOST}" -u "${DB_USER}" --single-transaction --quick "${DB_NAME}" | gzip > "${BACKUP_FILE}"; then
log_info "バックアップが正常に完了しました: ${BACKUP_FILE}"
else
log_error "バックアップ処理中にエラーが発生しました。"
exit 1
fi
# ==============================================================================
# Step 4: updater.phar によるアップデート実行
# ==============================================================================
log_info "【Step 4】updater.phar の実行"
log_warn "updater自体の対話プロンプトが表示されます。画面の指示に従って操作してください。"
ask_proceed "updater.phar を起動しますか?"
cd "${NC_DIR}"
sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/updater/updater.phar"
# ==============================================================================
# Step 5: 状態の確認とメンテナンスモードの調整
# ==============================================================================
log_info "【Step 5】最終確認とメンテナンスモードの解除"
current_mode=$(sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode)
echo "現在の状態: ${current_mode}"
if echo "${current_mode}" | grep -q "enabled"; then
read -rp "👉 メンテナンスモードをOFF(解除)にしますか? [y/N]: " unfreeze
if [[ "${unfreeze}" =~ ^[yY]$ ]]; then
sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode --off
log_info "メンテナンスモードを解除しました。"
else
log_warn "メンテナンスモードを維持したまま終了します。"
fi
fi
# ==============================================================================
# Step 6: バージョン確認
# ==============================================================================
log_info "【Step 6】バージョンの確認"
sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" status
log_info "すべての更新手順が完了しました。"
trap - EXIT
単にコマンドを並べるだけではなく、「途中で失敗しても致命傷にならないこと」を意識しています。
set -euo pipefailBashスクリプトでは定番ですが、非常に重要です。
このような場合は、その時点で処理を停止します。
「バックアップに失敗したのに、そのままアップデートが続く」といった事故を防ぐためです。
EUID を利用して、root 権限以外では実行できないようにしています。
sudo ./nextcloud_update.sh
以外の実行方法では即座に終了します。
昔ながらの
mysqldump -pPASSWORD
という書き方は、ps コマンドなどからパスワードが見えてしまいます。
そこで本スクリプトでは
MYSQL_PWD
環境変数を利用しています。
賛否のある方法ではありますが、少なくともコマンドライン引数へ平文パスワードを残すより安全です。(なお筆者は別スクリプトを利用していますが、それはまた別のお話)
一番怖いのは
というパターンです。
そこで trap cleanup EXIT を利用し、異常終了した場合は
occ maintenance:mode --off
を案内するようにしています。
「解除方法を忘れた」という事態を防ぐための保険です。
処理は次の順番で進みます。
まずは
mysqldump または mariadb-dumpの存在を確認します。
ここで問題があれば、それ以上処理は進みません。
パスワードを入力したあと、
mysqladmin ping
で接続テストを行います。
アップデート直前になって認証エラーが発覚するより、最初に確認してしまった方が安心です。
occ maintenance:mode --on
を実行します。この操作の前にも確認プロンプトを表示するため、誤操作を防げます。
バックアップには
mysqldumpmariadb-dumpのどちらか利用可能な方を自動で選択します。
取得したSQLは、そのまま gzip 圧縮して保存します。
nextcloud_backup_20260821_153000.sql.gz
のように日時付きファイルになるため、履歴も管理しやすくしています。
Nextcloud標準の
updater.phar
を実行します。ここから先はNextcloud側の対話画面になりますので、画面の案内に従って更新を進めます。
更新後は
occ statusまで実行します。最後に現在のバージョンが表示されれば、一通りの更新は完了です。
サーバー運用では「バックアップを取ってから更新する」は当たり前ですが、人間は当たり前ほど慣れてしまうものです。だから私は、忘れない仕組みを作るようにしています。
「運用者は呼吸するかのようにできる。だが、第三者に任せられるか? すっごく焦ってるときに緊急アップデートをした時は?」のためにも、確実に動く仕組みは大切というお話でした。
何かと使っているポモドーロタイマーソフト

Chill with You Lo-Fi Story。そのオリジナルグッズ群を手に入れました。

ステッカー群やアクキー、万年カレンダー。

手頃なサイズ感と世界観が好きなので、ThinkPadとというキャンパスを埋めていきます。

ただでさえ情報過多な天板が

隙間が更になくなりました。

キーボードレストもこの通り。これで、作業中でもポモドーロタイマーを意識する必要が出てきます。
ノートPCでゲームをする機会が増えたので、小型軽量のコントローラーを購入。

中身は箱とほぼ同じ


これだけコンパクトなのはありがたいのですが、

ユーティリティバッグに入らなくなりました。そこで、

母手作りのポーチに差し替えです。これなら
をいれてもスッキリ収まります。スリザリン要素が少なくなったのはストラップで担保。後の拡張性にも備えられるものになりました。
こちらの記事から約一年。
8/03 : 契約、初期設定(UFW / fail2ban)
とあることから、実質丸一年が経過。その1年での振り返りを行ってみたいです。
2026年8月時点でのリソース使用量
--- 💻 サーバーのCPU状態 ---
稼働時間 (Uptime): 8 days
ロードアベレージ (Load Avg): 0.22, 0.22, 0.19
CPU名 (Model): AMD EPYC-Milan Processor
スペック (Speed): 2.00 GHz (1996.250 MHz)
コア数 (Cores): 4 threads
--- メモリとスワップ ---
[物理メモリ(Physical Memory)]
total used free shared buff/cache available
Mem: 5.8Gi 3.7Gi 447Mi 163Mi 2.1Gi 2.1Gi
Swap: 4.9Gi 1.1Gi 3.8Gi
[zRAM の展開状況]
NAME DISKSIZE DATA COMPR ALGORITHM STREAMS ZERO-PAGES TOTAL MEM-LIMIT MEM-USED MIGRATED MOUNTPOINT
/dev/zram0 2.9G 1.1G 254.4M lzo-rle 4 50834 261.6M 0B 948.3M 199K [SWAP]
--- ストレージ(Storage Status) ---
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 145G 62G 83G 43% /
/dev/vda16 881M 222M 598M 28% /boot
/dev/vda15 105M 6.2M 99M 6% /boot/efi
s3fs 4.0G 0 4.0G 0% /mnt/wasabi2
s3fs 4.0G 0 4.0G 0% /mnt/wasabi
--- CPUを利用しているプロセス: CPU Consumers (Top 10) ---
%CPU %MEM PID USER UNIT COMMAND
------------------------------------------------------------------------------------------
8.0 4.3 796409 www-data apache2.service Passenger RubyApp:
4.4 6.8 621372 mysql mysql.service /usr/sbin/mysqld
2.8 3.6 796362 www-data apache2.service Passenger AppPreloader:
1.1 2.0 789277 www-data apache2.service /usr/sbin/apache2 -k start
0.7 2.1 784299 www-data apache2.service /usr/sbin/apache2 -k start
0.6 2.0 784297 www-data apache2.service /usr/sbin/apache2 -k start
0.6 3.9 622142 root growi.service node --import
0.6 1.8 620879 mongodb mongod.service /usr/bin/mongod --config /etc/mongod.conf
0.5 0.4 784275 root apache2.service Passenger core
0.5 0.2 622750 www-data apache2.service /usr/sbin/apache2 -k start
--- メモリを利用しているプロセス: Memory Consumers (Top 10) ---
%CPU %MEM PID USER UNIT COMMAND
------------------------------------------------------------------------------------------
0.4 11.2 479114 elastic+ elasticsearch.service /usr/share/elasticsearch/jdk/bin/java -Des.network
4.4 6.8 621372 mysql mysql.service /usr/sbin/mysqld
8.0 4.3 796409 www-data apache2.service Passenger RubyApp:
0.0 4.1 786930 www-data apache2.service Passenger RubyApp:
0.6 3.9 622142 root growi.service node --import ./bin/runtime/env-preload.mjs dist/s
0.0 3.8 796066 www-data apache2.service Passenger RubyApp:
2.8 3.6 796362 www-data apache2.service Passenger AppPreloader:
0.0 3.2 990 root mnt-wasabi.mount
0.2 2.9 789814 www-data php8.3-fpm.service php-fpm: pool www
0.4 2.8 794701 www-data php8.3-fpm.service php-fpm: pool www
何というか
というメモリを食いまくるサイト(そのほかLaravel Stack)を運営していてOoM Killerが発生しなかったものだと思っています。
これが一番のポイントです。筆者は広告が嫌いなので、自分のサイトにも作っていません。そのため、SEOや広告料収入によるアクセスアップを狙っていません。
「これは俺のメモ帳だ。節度を持ってアクセスする分にはかまわないがそれ以外は容赦しない」
というスタンスを貫いています。
更に、tcpレベルでの嫌がらせをやらかす相手にはipsetで防御。
https://barrel.reisalin.com/books/one-outs/page/ipsetddos
先にあった、Swapにブロックデバイスを追加することにより、スワップアウトが更に効率化しています。
https://barrel.reisalin.com/books/linux/page/ubuntuzram
これが一番です。Mod_Securityを「偽陽性を踏んだから単にそれをRemoveしよう」という雑な運用から
「偽陽性を踏みがちなアクション(記事の投稿、ファイルのアップロード)だけを無視する」というリアルタイム外科手術的な技法へと変換。
これにより
「攻撃は防ぐ 偽陽性は排除する おまえごときに『両方』やるのは そうそう難しいことじゃあないな」
と言えるようになったのが極めて大きいです。
「4GB→6GB」にスペックアップしたとしても普通に運用したらOoM Killerやアクセス過多に陥ったであろうシステムを
AIの力を借りての運用という形でした。
筆者にとっての必須エディタ、Growi。そのv8.0.0が出たので、以下の要件に基づきアップデートを行いました。
実施日: 2026年7月29日
対象環境: Ubuntu 24.04 (非Docker環境 / systemd運用)
その他要件:
| item | version |
|---|---|
| OS | Ubuntu 24.04 |
| GROWI | 7.5.7 |
| node.js | 24.14.1 |
| npm | 11.13.0 |
| pnpm | 11.1.1 |
GROWIの最新リリースにおける変更点(ES7の完全廃止、jemalloc対応、メモリ最適化、ESM移行)に対する自環境の適合状況を確認。
ES8/ES9のみに対応しているため、以下を確認。
curl -X GET "http://localhost:9200/" |grep number
→ 9.4.4となっていたので、要件を満たすことは確認しました。
ldconfig -p | grep jemalloc
libjemalloc.so.2 (libc6,x86-64) => /lib/x86_64-linux-gnu/libjemalloc.so.2と出たのでモジュールも確認済みです。
ここまでやれば、覚悟を決めてアップデートを行います。
※筆者は
systemdに登録したサービス起動プログラムがGrowiのルートディレクトリ/home/www-data/growi配下にあるgrowi-start.shを参照して各種環境をキックしています。
※ご自身の環境に合わせ修正を行ってください※
#!/bin/bash
# nvmのdefaultエイリアスが指すディレクトリを動的に取得してPATHに追加
# これにより、nvm installでバージョンを上げてもこのスクリプトの書き換えが不要になります
DEFAULT_NODE_VER=$(cat "$NVM_DIR/alias/default")
export PATH="$NVM_DIR/versions/node/$DEFAULT_NODE_VER/bin:$PATH"
GROWI_DIR="/home/www-data/growi"
cd $GROWI_DIR
# 環境変数の設定
export NODE_ENV=production
export AUDIT_LOG_ENABLED=true
export FORCE_WIKI_MODE=private
export MONGO_URI=mongodb://localhost:27017/growi
export ELASTICSEARCH_URI=http://localhost:9200/growi
export REDIS_URI=redis://localhost:6379
export PASSWORD_SEED=(設定済みのパスワード)
# npm run app:server を使用する(npmが内部で正しいパスを見つけてくれます)
# execを使うことでsystemdとの親和性を維持します
exec npm run app:server
このファイルを修正していきますが:バックアップを確実に行います。
sudo cp -pi /home/www-data/growi/growi-start.sh /path/to/backup/directory/growi-start.sh.$(date +%Y%m%d)
diff -u /path/to/backup/directory/growi-start.sh.$(date +%Y%m%d) /home/www-data/growi/growi-start.sh
エラー(差分)がなければ両者ともファイルがあり、バックアップが取れています。
バックアップ後、/home/www-data/growi/growi-start.shの編集を行います。(自分の環境に合わせます)
export JEMALLOC_ENABLED=true を追加export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 を追加MONGO_URI に ?maxPoolSize=10 パラメータを付与具体的には以下のような差分が取れていればOKです。
diff -u /path/to/backup/directory/growi-start.sh.$(date +%Y%m%d) /home/www-data/growi/growi-start.sh
# 環境変数の設定
export NODE_ENV=production
+export JEMALLOC_ENABLED=true
+export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
export AUDIT_LOG_ENABLED=true
export FORCE_WIKI_MODE=private
-export MONGO_URI=mongodb://localhost:27017/growi
+export MONGO_URI=mongodb://localhost:27017/growi?maxPoolSize=10
export ELASTICSEARCH_URI=http://localhost:9200/growi
export REDIS_URI=redis://localhost:6379
sudo systemctl restart growi.service
指定した環境変数および jemalloc ライブラリが GROWI プロセス(Node.js)へ正常にロードされていることを確認しました。
JEMALLOC_ENABLED=true および LD_PRELOAD が正常に適用されていることを確認。lsof および /proc/{PID}/maps コマンドにより、libjemalloc.so.2 が Node.js プロセスに読み込まれていることを確認。以下をバックアップします。
cat /etc/mongod.conf |grep dbPath
として、ここのディレクトリ一式を控えます。(筆者環境 /home/mongodb)
このディレクトリを任意の方法でバックアップします。
/growi/root/directory/apps/app/public
(筆者環境 /home/www-data/growi/apps/app/public)ここも念のためバックアップします。
※ 添付ファイルのアップロード先をAWSやAzureなどにしている場合は不要です
スナップショット機能などでシステム全体をバックアップした方が確実で安心です。
sudo systemctl stop elasticsearch.service
sudo systemctl stop growi.service
systemctl status elasticsearch.service growi.service | grep Active
inactive(dead)を確認します。
sudo cp -a /var/lib/elasticsearch/ /path/to/backup/dir/elastic_bk.$(date +%Y%m%d)
自分の環境に合わせます。
sudo ls -l /path/to/backup/dir/elastic_bk.$(date +%Y%m%d)
バックアップした内容があることを確認します。(※管理者権限でないとこのディレクトリを見ることはできません)
cd /home/www-data/growi && pwd
自分の環境に合わせます。(筆者環境/home/www-data/growi)
sudo git fetch --tags
sudo git tag -l
スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。
sudo git stash
sudo git checkout 【バージョン】
リリースタグは再確認しましょう。今回は 2026/07/28にリリースされたv8.0.0を選択しました。
sudo pnpm i
※これができるのは、筆者のgrowi実行環境がrootだからです。このパーミッション設定は確実に確認しましょう。
NODE_OPTIONS="--max-old-space-size=4096" sudo pnpm run app:build
→ ビルド時のメモリ大量使用を抑えるため上限を抑えています。余談ですが、ここは神に祈る作業です。
sudo systemctl restart elasticsearch.service
sudo systemctl restart growi.service
systemctl status elasticsearch.service growi.service | grep Active
active(running)を確認します。
※一般権限で見られないため
sudo su -
pgrep -f "node.*growi" | xargs -I {} lsof -p {} 2>/dev/null | grep jemalloc
MainThrea 479521 root mem REG 253,1 830656 15385 /usr/lib/x86_64-linux-gnu/libjemalloc.so.2
必要に応じてバックアップしたファイル一式やスナップショットを削除します。
体温以上の暑さが続く中、これだけは外せないという暑さ対策グッズはこれに落ち着きました。

ワークマンにて購入。
直射日光を遮ることで、体感温度は数度から10℃近く下がると言われています。また、輻射熱を遮る点でも重要です。
強い紫外線、まぶしさは目から入って脳に疲労物質を出させる原因になります。
普段の眼鏡と同じ度にすることで、普段の視界のまましっかり減光できます。
血管が集まる首元、首の横、脇の下、手首などを直接冷やせます。
この対策グッズでもMVPです。ハンディファンで生暖かい風を浴びるより合理的です。

このシンデレラフィットするかのようなヒップバッグも見つけられました。これで鞄にもつけられるので満足。
この暑い夏は始まったばかりですが、なんとか死なないように抑えていきたいものです。
BookStackでは「アプリケーションロゴ」を設定できますが、そのままではアップロードした画像が高さ86pxへリサイズされてしまいます。
そのため、CSSでロゴを大きく表示すると画像がぼやけてしまいます。そもそも86pxは昨今のモダンなCMSにあるまじき解像度ではあるので、手を入れます。
そこでファイル本体を少し修正し、高解像度のロゴ画像をそのまま利用できるようにしました。
BookStackに管理者権限でログインし、管理>カスタマイズに遷移。
カスタムheadタグで
<style>
.logo-image {
height: 128px !important;
width: auto !important;
}
</style>
のような指定はできるものの、超ローレぞ加工され、表示がぼやけます。そこで、要素を調べると、保存された画像自体が86×86になっていました。
この原因を調べます。
インストールされているUbuntuサーバで
cd /path/to/BookStack/directory && pwd
として(筆者環境/home/www-data/Bookstack)BookStackのホームディレクトリに移動。
file public/uploads/images/system/20xx-xx/xxxx.jpg
で、該当のファイルを調べます。
JPEG image data
86x86
つまり、CSSではなくアップロード時に画像が縮小されていました。
いかにCSSで指定してもだめな原因はプログラムそのものにあります。なので、その上流の「ファイルのアップロードを司るファイル」にメスを入れます。
それを司るファイルをチャットAIとともに調査。
BookStackのルートディレクトリからたどれる
app/Settings/AppSettingsStore.php
にそれがありました。
protected function updateAppLogo(Request $request): void
{
if ($request->hasFile('app_logo')) {
$logoFile = $request->file('app_logo');
$this->destroyExistingSettingImage('app-logo');
$image = $this->imageRepo->saveNew(
$logoFile,
'system',
0,
null,
86
);
setting()->put('app-logo', $image->url);
}
}
null,
86
が指定されているため、高さ86pxへリサイズされた画像が保存されます。
ここまで分かれば、後は修正開始です。
cd /path/to/BookStack/directory && pwd
自分の環境に合わせます。(筆者環境/home/www-data/Bookstack)
sudo cp -pi app/Settings/AppSettingsStore.php /path/to/backup/AppSettingsStore.php.$(date +%Y%m%d)
※注意点※
diff -u /path/to/backup/AppSettingsStore.php.$(date +%Y%m%d) app/Settings/AppSettingsStore.php
任意のバックアップディレクトリを指定します。
エラーがないことを確認します。人間「バックアップはやってる」と思いながらもバイアスや手なりでスキップしがちです。この段階でそのミスやバイアスを潰します。
なぜdiffを使うのかは、ls -lで両ファイルを比べるより確実だからと言うのと、後述する修正確認でも使うからです。
app/Settings/AppSettingsStore.phpファイルを、リサイズを行わないよう変更します。(要管理者権限)
具体的には以下の差分になるように。
- $image = $this->imageRepo->saveNew($logoFile, 'system', 0, null, 86);
+ $image = $this->imageRepo->saveNew($logoFile, 'system', 0, null, null);
diff -u /path/to/backup/AppSettingsStore.php.$(date +%Y%m%d) app/Settings/AppSettingsStore.php
ここで、なぜdiffを逆にする意味が生まれます。逆にしないと直したところが-、元が+で表示されます。これは視覚的にも感覚的にもよろしくありません。「え? 正しい修正をしたのに消されるの?」となりがちです。
sudo -u www-data php artisan optimize:clear
でキャッシュをクリアします。
PHP-FPMなら
sudo systemctl restart php8.3-fpm
Mod-PHP環境なら
sudo systemctl restart apache2
で、実行環境を再起動します。
BookStackに管理者権限でログインし、管理>カスタマイズに遷移。
カスタムheadタグで
<style>
.logo-image {
height: 128px !important;
width: auto !important;
}
</style>
のように設定し、(或いは設定されていることを確認し)、保存をクリック。
管理>カスタマイズ
から、ファイルをアップロードします。
BookStack標準ではヘッダー高さが少し窮屈なので、必要に応じてヘッダーも調整します。
例
header {
min-height: 72px;
}
.logo-image {
height: 64px !important;
}
ここから先はBookStackに戻り、高解像度でロゴが表示されれば設定はOKです。

ワークマン、時々面白いものが見つかります。今回見つけたのはこちら。
モバイルバッテリー&ライト。

一見、ごついカラビナのようですが……

この付け根にUSBケーブルがついています。
つまり、モバイルバッテリーという取り回しに困るものを「ベルトや鞄に固定させる」ことで充電を可能にする仕掛け。
御丁寧に外で使うためIP66という認証までついています。それだけに留まらず

ライトつきです。動力そのものがバッテリーという、盲点のような状態。

注意点として:
と極性が固定されていることのようですのでケーブルに注意が必要でした。
いずれにしても、外出しでき、いざというときに迷わないバッテリーは重要です。
若干のアップデートがありました。
「とりあえず、これとスマートフォンがあれば大概の場所でも作業ができる」厳選道具群です。

下段左から
こちらは日記帳。2021年の1月に途切れましたが、そこからは日々欠かさず、全ての日付で書いています。
カバーは『SPY×FAMILY』コラボ。
出先での母艦です。一時期、やたらと画面がオフになり、どうすんだこれ状態に陥りかけましたが、のぞき見防止フィルターが触れた面でそうなっているだけと判明。その位置を調整して事なきを得ています。
混雑した電車の中で用いるメインウエポン。様々なタブレットを触った中で
と、忙しいときでもブログが書け、電子書籍リーダーとしても八面六臂の活躍。少しバッテリーが怪しいので次世代をどうするかが懸案中です。
スリザリン×アフターヌーンティーコラボ。
などのジャストサイズ。
母手製の大容量ペンケース。LAMYぎっしり。課題は万年筆がおざなりなってしまうこと。メンテンアンス頻度を上げていく工夫が求められます。
こちらは利用頻度が上がってきました。メモ帳だけでなく、L判縦の写真がそのまま貼り付けられるサイズ感も気に入っています。
と、それなりに量はありますが、これがないと私の一日は始まらないレベルの必須品です。
Powered by WordPress & Theme by Anders Norén