カテゴリー: ガジェット Page 1 of 109

再びの充電機能付きストラップ

以前持ってた充電機能付きのストラップを紛失したので買い直しました。

見た目は上部などパラコート風。で、見て分かるようにコネクタ付き。

今回はカバーの覆いがストラップのコネクタに。返しとスプリングがあるので多少の衝撃では問題ない作りになってます。

これで、機動性と「ケーブル忘れてどうしよう」を解決できます。

NextcloudアップデートとDBバックアップを行うBashスクリプトの解説

Nextcloudのアップデートは、それほど頻繁に行う作業ではありません。しかし、だからこそ毎回「あれ、このコマンド実行したっけ?」となりがちです。

筆者自身も、メンテナンスモードの切り替えやデータベースのバックアップなど、手順を一つひとつ確認しながら作業していました。そこで「毎回やることはスクリプトに任せよう」と考え、更新前のバックアップから updater.phar の実行までを一通り補助する Bash スクリプトを作成しました。

今回は、そのスクリプトの仕組みを紹介します。

動作環境

動作を想定している環境は以下の通りです。

  • Ubuntu 20.04 LTS / 22.04 LTS / 24.04 LTS
  • MySQL または MariaDB
  • PHP / Bash
  • root 権限(sudo)
  • Apache実行ユーザ: www-data

Ubuntu系で一般的な構成であれば、そのまま利用できるようになっています。

スクリプト本体

最初に環境に合わせて、スクリプト冒頭の変数だけ変更します。

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 pipefail

Bashスクリプトでは定番ですが、非常に重要です。

  • コマンドが失敗した
  • 未定義変数を参照した
  • パイプラインの途中でエラーが発生した

このような場合は、その時点で処理を停止します。

「バックアップに失敗したのに、そのままアップデートが続く」といった事故を防ぐためです。

root権限の確認

EUID を利用して、root 権限以外では実行できないようにしています。

sudo ./nextcloud_update.sh

以外の実行方法では即座に終了します。

パスワードをコマンドラインへ残さない

昔ながらの

mysqldump -pPASSWORD

という書き方は、ps コマンドなどからパスワードが見えてしまいます。

そこで本スクリプトでは

MYSQL_PWD

環境変数を利用しています。

賛否のある方法ではありますが、少なくともコマンドライン引数へ平文パスワードを残すより安全です。(なお筆者は別スクリプトを利用していますが、それはまた別のお話)

trapによる復旧案内

一番怖いのは

  • メンテナンスモードON
  • エラー発生
  • そのまま終了

というパターンです。

そこで trap cleanup EXIT を利用し、異常終了した場合は

occ maintenance:mode --off

を案内するようにしています。

「解除方法を忘れた」という事態を防ぐための保険です。

実行の流れ

処理は次の順番で進みます。

1. 前提条件の確認

まずは

  • root権限
  • Nextcloudディレクトリ
  • mysqldump または mariadb-dump

の存在を確認します。

ここで問題があれば、それ以上処理は進みません。

2. データベース接続の確認

パスワードを入力したあと、

mysqladmin ping

で接続テストを行います。

アップデート直前になって認証エラーが発覚するより、最初に確認してしまった方が安心です。

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

occ maintenance:mode --on

を実行します。この操作の前にも確認プロンプトを表示するため、誤操作を防げます。

4. データベースをバックアップ

バックアップには

  • mysqldump
  • mariadb-dump

のどちらか利用可能な方を自動で選択します。

取得したSQLは、そのまま gzip 圧縮して保存します。

nextcloud_backup_20260821_153000.sql.gz

のように日時付きファイルになるため、履歴も管理しやすくしています。

5. updater.phar を起動

Nextcloud標準の

updater.phar

を実行します。ここから先はNextcloud側の対話画面になりますので、画面の案内に従って更新を進めます。

6. 最終確認

更新後は

  • メンテナンスモードの状態確認
  • 必要ならOFFへ変更
  • occ status

まで実行します。最後に現在のバージョンが表示されれば、一通りの更新は完了です。

さっくりとしたまとめ

サーバー運用では「バックアップを取ってから更新する」は当たり前ですが、人間は当たり前ほど慣れてしまうものです。だから私は、忘れない仕組みを作るようにしています。

「運用者は呼吸するかのようにできる。だが、第三者に任せられるか? すっごく焦ってるときに緊急アップデートをした時は?」のためにも、確実に動く仕組みは大切というお話でした。

Thinkpad、ステッカー更新。

何かと使っているポモドーロタイマーソフト

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

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

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

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

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

キーボードレストもこの通り。これで、作業中でもポモドーロタイマーを意識する必要が出てきます。

コントローラー追加とポーチの差し替え。

ノートPCでゲームをする機会が増えたので、小型軽量のコントローラーを購入。

中身は箱とほぼ同じ

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

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

母手作りのポーチに差し替えです。これなら

  • ACアダプター
  • マウス
  • イヤホン
  • ケーブル
  • コントローラー

をいれてもスッキリ収まります。スリザリン要素が少なくなったのはストラップで担保。後の拡張性にも備えられるものになりました。

X Server切り替え1年後の雑感。

こちらの記事から約一年。

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                                 

何というか

  • Growi
  • Nextcloud
  • Redmine

というメモリを食いまくるサイト(そのほかLaravel Stack)を運営していてOoM Killerが発生しなかったものだと思っています。

なぜメモリが枯渇しなかったか

アクセスを絞っている

これが一番のポイントです。筆者は広告が嫌いなので、自分のサイトにも作っていません。そのため、SEOや広告料収入によるアクセスアップを狙っていません。

「これは俺のメモ帳だ。節度を持ってアクセスする分にはかまわないがそれ以外は容赦しない」

というスタンスを貫いています。

クローラーや迷惑ボットの排除

  • 一度でも不審な攻撃/その兆候を見せたら次のアクセスを禁じる「ONE OUTS」システム
  • 雑なクローラーを別サイトへと転送。その推論モデルを破綻させるような文言を随所に仕込み、Webアプリの重い処理に到達させない「Jailhouse Lock」システム

更に、tcpレベルでの嫌がらせをやらかす相手にはipsetで防御。

https://barrel.reisalin.com/books/one-outs/page/ipsetddos

zRamによるメモリ圧縮

先にあった、Swapにブロックデバイスを追加することにより、スワップアウトが更に効率化しています。

https://barrel.reisalin.com/books/linux/page/ubuntuzram

AIとの対話によるセキュリティ案強化

これが一番です。Mod_Securityを「偽陽性を踏んだから単にそれをRemoveしよう」という雑な運用から

「偽陽性を踏みがちなアクション(記事の投稿、ファイルのアップロード)だけを無視する」というリアルタイム外科手術的な技法へと変換。

これにより

「攻撃は防ぐ 偽陽性は排除する おまえごときに『両方』やるのは そうそう難しいことじゃあないな」

と言えるようになったのが極めて大きいです。

結局のところ

「4GB→6GB」にスペックアップしたとしても普通に運用したらOoM Killerやアクセス過多に陥ったであろうシステムを

  • 自分のサイト運営方針に則って数を絞り
  • 不穏なアクセスを防ぐことが第一歩と考えた

AIの力を借りての運用という形でした。

Growiを7.5.7→8.0.0へアップデートしたときの作業メモ

概要

筆者にとっての必須エディタ、Growi。そのv8.0.0が出たので、以下の要件に基づきアップデートを行いました。

リリース情報

実施日: 2026年7月29日
対象環境: Ubuntu 24.04 (非Docker環境 / systemd運用)
その他要件:

itemversion
OSUbuntu 24.04
GROWI7.5.7
node.js24.14.1
npm11.13.0
pnpm11.1.1

必要要件の確認

GROWIの最新リリースにおける変更点(ES7の完全廃止、jemalloc対応、メモリ最適化、ESM移行)に対する自環境の適合状況を確認。

Elasticsearchバージョン確認

ES8/ES9のみに対応しているため、以下を確認。

curl -X GET "http://localhost:9200/" |grep number

9.4.4となっていたので、要件を満たすことは確認しました。

OSメモリ最適化モジュールの確認

ldconfig -p | grep jemalloc

libjemalloc.so.2 (libc6,x86-64) => /lib/x86_64-linux-gnu/libjemalloc.so.2と出たのでモジュールも確認済みです。

ここまでやれば、覚悟を決めてアップデートを行います。

さっくりとしているが面倒な手順

  1. Growi実行スクリプトの修正を行います。
  2. 修正結果が反映されたことを確認します。
  3. 関連サービスの停止を行います。
  4. (推奨)mongodbをまるごとバックアップしておきます。
  5. Growiのアップデートを行います。
  6. アップデートの確認を行います。

Growi実行スクリプトの修正

※筆者は

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の編集を行います。(自分の環境に合わせます)

主な変更内容
  • JEMALLOC の有効化: export JEMALLOC_ENABLED=true を追加
  • LD_PRELOAD の明示: export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 を追加
  • MongoDB 接続プールの最適化: 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

設定ファイルの修正確認

  • Growiサービスの再起動
sudo systemctl restart growi.service

指定した環境変数および jemalloc ライブラリが GROWI プロセス(Node.js)へ正常にロードされていることを確認しました。

  • プロセスの環境変数確認:
    JEMALLOC_ENABLED=true および LD_PRELOAD が正常に適用されていることを確認。
  • メモリマップ / ファイルハンドラ確認:
    lsof および /proc/{PID}/maps コマンドにより、libjemalloc.so.2 が Node.js プロセスに読み込まれていることを確認。

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

  1. Growiに管理者権限でログインします。
  2. 管理トップ>アプリ設定に進み、「メンテナンスモードを開始する」をクリックします。
  3. トップページに戻り「メンテナンスモード」が表示されていることを確認します。

バックアップ

以下をバックアップします。

  • mongodbの格納データ
cat /etc/mongod.conf |grep dbPath

として、ここのディレクトリ一式を控えます。(筆者環境 /home/mongodb)

このディレクトリを任意の方法でバックアップします。

  • Growiの添付ファイル一式が納められているディレクトリ(ファイルアップロード先をlocalにしている場合のみ)
/growi/root/directory/apps/app/public

(筆者環境 /home/www-data/growi/apps/app/public)ここも念のためバックアップします。

※ 添付ファイルのアップロード先をAWSやAzureなどにしている場合は不要です

  • vpsや仮想ゲストの場合はシステム全体:推奨

スナップショット機能などでシステム全体をバックアップした方が確実で安心です。

ElasticsearchとGrowiの停止

  • Elasticsearchサービス停止
sudo systemctl stop elasticsearch.service
  • Growiサービス停止
sudo systemctl stop growi.service
  • サービス停止確認
systemctl status elasticsearch.service growi.service | grep Active

inactive(dead)を確認します。

作業前バックアップ

  • データディレクトリを丸ごとコピー (-aオプションでパーミッションを維持)
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)

バックアップした内容があることを確認します。(※管理者権限でないとこのディレクトリを見ることはできません)

growiディレクトリに移動します

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を選択しました。

  • pnpm install
sudo pnpm i

※これができるのは、筆者のgrowi実行環境がrootだからです。このパーミッション設定は確実に確認しましょう。

  • ビルド
NODE_OPTIONS="--max-old-space-size=4096" sudo pnpm run app:build

→ ビルド時のメモリ大量使用を抑えるため上限を抑えています。余談ですが、ここは神に祈る作業です。

ElasticsearchとGrowiの再開

  • Elasticsearchサービス開始
sudo systemctl restart elasticsearch.service
  • Growiサービス開始
sudo systemctl restart growi.service
  • サービス開始確認
systemctl status elasticsearch.service growi.service | grep Active

active(running)を確認します。

メンテナンスモード無効化

  1. Growiに管理者権限でログインします。
  2. 管理トップ>アプリ設定に進み、「メンテナンスモードを終了する」をクリックします。
  3. トップページに戻り「メンテナンスモード」が表示されていないことを確認します。

バージョンアップを確認します。

  1. 画面下部にあるバージョンがチェックアウトしたバージョン(v8.0.0)であることを確認します。
  2. 各種機能(ページ閲覧や編集)などが正常に行えるかを確認します。

追加モジュールが動いていることを確認します。

  • 一時的に特権ユーザー昇格

※一般権限で見られないため

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のヘッダーロゴを高解像度化する

BookStackでは「アプリケーションロゴ」を設定できますが、そのままではアップロードした画像が高さ86pxへリサイズされてしまいます。

そのため、CSSでロゴを大きく表示すると画像がぼやけてしまいます。そもそも86pxは昨今のモダンなCMSにあるまじき解像度ではあるので、手を入れます。

そこでファイル本体を少し修正し、高解像度のロゴ画像をそのまま利用できるようにしました。

環境

  • BookStack
    • v26.05.1
  • Apache
    • 2.4
  • PHP
    • 8.3-fpm
  • Ubuntu
    • 24.04

最初に試したこと

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へリサイズされた画像が保存されます。

ここまで分かれば、後は修正開始です。

さっくりとした手順

  1. サーバ上で該当するファイルを修正します。
  2. 念のためサービスの再起動を行います。
  3. カスタムheadタグを修正します。
  4. 改めてファイルをアップロードします。

ファイルのバックアップ

  • BookStackのルートディレクトリに移動
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)

※注意点※

  • プログラム根幹をいじります。つまり、何かあったら直したやつの責任です。バックアップは確実に取ります。
  • 更に、Gitなどでアップデートした場合、確実にこれはMasterから上書きされます。「ここを直す」というのは履歴管理を厳に行いましょう。
  • 該当ファイルのバックアップ確認
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/Apacheを再起動

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という認証までついています。それだけに留まらず

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

注意点として:

  • Type-C:バッテリーそのものの充電時に利用
  • Type-A:他の機器への充電時に利用

と極性が固定されていることのようですのでケーブルに注意が必要でした。

いずれにしても、外出しでき、いざというときに迷わないバッテリーは重要です。

携行文具一式(2026年7月版)

若干のアップデートがありました。

「とりあえず、これとスマートフォンがあれば大概の場所でも作業ができる」厳選道具群です。

下段左から

ほぼ日手帳

こちらは日記帳。2021年の1月に途切れましたが、そこからは日々欠かさず、全ての日付で書いています。

カバーは『SPY×FAMILY』コラボ。

ThinkPad

出先での母艦です。一時期、やたらと画面がオフになり、どうすんだこれ状態に陥りかけましたが、のぞき見防止フィルターが触れた面でそうなっているだけと判明。その位置を調整して事なきを得ています。

iPad mini

混雑した電車の中で用いるメインウエポン。様々なタブレットを触った中で

  • iPhoneとの連携
  • Apple pencilによる最高の入力体験
  • 大容量

と、忙しいときでもブログが書け、電子書籍リーダーとしても八面六臂の活躍。少しバッテリーが怪しいので次世代をどうするかが懸案中です。

PC周辺機器ポーチ

スリザリン×アフターヌーンティーコラボ。

  • ACアダプター
  • マウス
  • 充電ケーブル
  • PC用イヤホン
  • メモリカードリーダー
  • USBメモリ

などのジャストサイズ。

ペンケース

母手製の大容量ペンケース。LAMYぎっしり。課題は万年筆がおざなりなってしまうこと。メンテンアンス頻度を上げていく工夫が求められます。

トラベラーズノート

こちらは利用頻度が上がってきました。メモ帳だけでなく、L判縦の写真がそのまま貼り付けられるサイズ感も気に入っています。

と、それなりに量はありますが、これがないと私の一日は始まらないレベルの必須品です。

Page 1 of 109

Powered by WordPress & Theme by Anders Norén