タグ: Ubuntu Page 2 of 22

改訂・再編集『Ubuntu24.04にApacheをインストールするための具体的手順』

この記事を今のトレンドに合わせた上でのステップバイステップとした記事です。

概要

Ubuntu24.04にWebサーバーApacheをインストールします。最近のトレンドではNginxではあるものの、

  1. 豊富なモジュールとカスタマイズ
  2. 動的コンテンツの設定をしやすい
  3. 小規模サイトを立ち上げる上での手間の少なさ
  4. 外部ファイルやモジュールの連携により、以下のような細かい設定が可能
  • 自宅等からのアクセスログを残さず、ログの透明化を図る
  • Robots.txtを無視する悪質なクローラーの排除
  • mod_securityに代表されるWAF(Web Application Firewall)の設置

を考慮してのApache設定です。

さっくりとした手順

  1. (未実施の場合必須)UFWの設定を行います。
  2. Apacheのインストールを行います。
  3. Apacheの設定を行います。
  4. 設定の反映を確認します。

(未実施の場合必須)UFWの設定

この作業、サーバ移設などになれている人ほど陥る罠です。「設定はしっかりしている。なのにサンプルページすら引っかからない!」という場合、大概が「UFWでポート80/443を空けていない」パターンが大半を占めます。

大前提

SSH接続を許可(ポート22はSSH記事で許可済みを前提とする)。

設定の前の心構え:

UFWは堅牢であると同時に融通の利かない門番です。設定を間違えると「自分のサーバにログインできない」事態が易々と発生します。

そのため、この作業に臨む際は落ち着いて臨みましょう。コマンドを打つ際に3回ぐらい深呼吸してもいいぐらいの心構えです。

  • http通信を許可する
sudo ufw allow http comment 'Allow HTTP traffic for Apache'
  • https通信を許可する
sudo ufw allow https comment 'Allow HTTPS traffic for Apache'
  • 設定を確認する
 sudo ufw status verbose

上記、http/httpsが有効になっていることを確認します。

  • UFWが有効になっていない場合:有効化
sudo ufw enable 

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

  • パッケージ全体のアップデート
sudo aptitude update 
  • apacheのインストール
sudo aptitude install apache2
  • バージョン確認
apache2ctl -v
  • 表示例
Server version: Apache/2.4.62 (Ubuntu)
Server built:   2024-07-22T12:37:10
  • サービス稼働確認
systemctl status apache2.service

enabledactive (running)を確認します。

設定を行います。

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

任意のバックアップディレクトリを指定します。

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

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

  • 設定ファイル追記
sudo tee /etc/apache2/apache2.conf > /dev/null << 'EOF'
ServerSignature Off
ServerTokens Prod
ServerName example.com  # <-- ここに実際のドメイン名またはホスト名を指定
EOF

自分のサーバー名を英数字で置き換えてください。

  1. サーバーの署名をオフにして
  2. 最小限の情報のみを公開し
  3. Webサーバの名前を指定する

内容です。

  • 追記確認
diff -u /path/to/backup/directory/apache2.conf.$(date +%Y%m%d) /etc/apache2/apache2.conf
  • 差分内容
+ ServerSignature Off
+ ServerTokens Prod
+ ServerName 自分のサーバー名

設定反映を確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

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

active (running)を確認します。

  • 設定反映確認
curl -I http://localhost

以下のように、ServerヘッダーにApacheのみが表示されていることを確認します。

Server: Apache

単一VPSでインターネット公開のVPSの運用上の注意 または 「加害者にならないための心構え/具体的手順」。

はじめに

前回の続き。Linuxサーバ運用上の注意を述べましたが、更に難易度が上がり

「このLinuxサーバをインターネットで公開するとき」

の心構えについて述べます。

絶対的な違い:「インターネット上サーバの理不尽な非対称性」

そもそも、ローカル環境とインターネットにこれを公開するというのは

  • 技術
  • 倫理観
  • 運用の手間

が何もかも違います。その中で一番気をつけなければならないのは

「自分自身が加害者になってしまうこと」

です。これはもっと具体的に言うと

「管理者権限を乗っ取られ、自分のサーバが攻撃ツールのフロントエンド/バックエンドとして機能すること」

を意味します。攻撃者は自分自身が表立って行動することを嫌います。そのため、

  • 管理の甘いサーバ
  • 脆弱性があるサービス

などにつけ込み侵入を試み、それを自らの配下として利用します。これは、先に述べた

  • システムダウン
  • バックアップ不備による切り戻し不可

とは何もかもレベルが違うリスクです。

ぶっちゃけ、自分自身が運営しているサーバの瓦解は自分が泣けばそれで済む話ではありますが、自分が管理しているサーバが攻撃に関与したというのは、法的/金銭的/社会的な失墜が絡む大問題。

この、理不尽なまでの非対称性が絡むということを最初に意識してインターネット上サーバでの運営を意識しましょう。

趣味/勉強の範疇での最低限の手段

とはいえ、趣味や勉強の範囲でインターネット接続環境でもLinuxサーバを立ち上げたいという方はいるかと思います。

ここからは、メソロドジーから一歩踏み込み、「より具体的な手段」について述べます。

想定する環境

  • とりあえずLinuxサーバをvpsで立ち上げた。
  • 様々な環境から接続をするから確固たる固定IPを持っていない
  • それでもWebサーバを立ち上げたい

ちょっとした茨の道を進みたい方向けです。

※ ここからは筆者の過去記事から「特に必要な設定」を抜き出し、加筆編集を加えた記事です。※

話の前に筆者環境

  • Ubuntu 24.04
  • apt/aptitudeのパッケージ管理システム

を用います。つまり、makeやリビルドなどは発生しない、再現性の高い環境でのステップバイステップです。

メンテナンス用のユーザを作成する

この作業は極めて重要です。というのも、先に示したとおり、攻撃者が真っ先に/そして最終的に狙うのは管理者権限。つまり、(root)です。

rootへのネットワークを介したログインを禁止すると同時に、メンテナンス用のユーザを作成し、NW上からは、ここから接続することを厳命します。

  • (コンソールを利用して)ユーザ作成
adduser [メンテナンス用ユーザ]

[メンテナンス用ユーザ]は英数字です。その後、パスワード設定などを対話式で求められるので、指示に従って入力します。

  • ログイン確認
exit

物理コンソール/VPSのWebシリアルコンソールから抜けます。

メンテナンス用のユーザ作成確認(メンテナンス用のユーザ)

  • 作成したユーザでログイン確認

Webコンソールで、作成したユーザ名とパスワードでログインできることを確認。

whoami

で、設定したアカウントであることを確認します。

  • rootに昇格できないことを確認
sudo su -

としても、rootに昇格することはできません。なので、一度

exit

でコンソールを抜け、rootでログインし直します。

メンテナンス用のユーザのroot昇格設定(root)

  • メンテナンス用のユーザにsudoを追加

rootでログイン後、

usermod -aG sudo [メンテナンス用ユーザ]

で、sudoグループにこのユーザを加えます。

  • sudo追加確認
id -a [メンテナンス用ユーザ]

で、以下のように表示されることを確認します。

uid=1000(hoge) gid=1000(hoge) groups=1000(hoge),27(sudo),100(users)

修正したユーザのグループに、27(sudo)と表示されることがポイントです。

確認後、

exit

で更にrootを抜け、今度はメンテナンス用のユーザでログインします。

rootのロック (メンテナンス用のユーザ)

  • root昇格

メンテナンス用のユーザでログイン後、

sudo su -

で、rootに昇格できることを確認します。

whoami

root表示されることも確認します。

  • rootロック
passwd -l root

として、rootそのものをロックします。

  • rootのロック確認
exit

を2回行い、Webコンソールから抜けます。

rootロック確認

  • メンテナンス用のユーザ→Webコンソールでログイン可能
  • root→Webコンソールでログイン不可能を確認します。

これ以降はメンテナンス用のユーザで作業を行います。

SSH設定

Ubuntu Desktop系と違い、Ubuntu Serverではsshdがデフォルトでインストールされていない場合があります。

sudo apt install ssh

で、sshdをインストールします。

インストール後、

ssh -V

でバージョンが表示されることを確認し、

systemctl status ssh.service

で、runningenabledを確認します。

このSSHは鍵認証でログインできるようにします。この鍵認証のセキュリティ強度はパスワードと段違い。

鍵交換認証にする理由
  • パスワードが送信されない
    • パスワード認証では、パスワード自体がネットワーク上を流れるため盗聴リスクがあります。
    • 鍵認証では、秘密鍵が署名を生成し、署名のみが送信されるため、秘密情報が直接送られることはありません
  • 総当たり攻撃に強い
    • パスワードは文字数が少ないと短時間で破られる可能性があります。
    • 鍵認証では、2048ビット以上の鍵が使われることが多く、現在の一般的なサーバの計算能力では事実上破ることが不可能です。
  • 盗聴されても再利用できない
    • 鍵認証では毎回異なるチャレンジに対して署名を行うため、録音や再送信による攻撃(リプレイ攻撃)が通用しません。
  • フィッシング耐性が高い
    • パスワード認証は偽サイトに入力してしまうリスクがあります。
    • 鍵認証では秘密鍵がローカルに保管されており、外部に送信されないためフィッシングに強いです。

SSH鍵ペア作成

ssh-keygen -t ed25519
  • 鍵の格納場所は空Enter。(/home/hoge/.ssh/
  • パスワードを設定します。

SSH鍵ペア作成確認

  • 鍵格納ディレクトリに移動
cd .ssh
  • ファイルの内容確認
ls -l

以下のファイルを確認します。

  1. id_ed25519
  2. id_ed25519.pub ※これらのファイルはscp等で自分のクライアントにコピーします。

鍵の設定変更

公開鍵をauthorized_keysに変更し、パーミッションを厳密にします。

  • ファイル名変更
cat id_ed25519.pub >> authorized_keys
  • パーミッション設定
chmod 600 authorized_keys

秘密鍵の保存

この秘密鍵(id_ed25519)は、サーバー全体のアクセス権を持つ、言葉通りの意味でのマスターキーです。

この秘密鍵を奪われることは、サーバーの全権限を奪われることと同義です。 そのため、管理は厳密に、そして自分だけがアクセスできる安全な手段(パスワードマネージャーや暗号化されたストレージなど)で、必ずバックアップをこの段階で行ってください。

その後、適切なターミナルクライアントでこの秘密鍵を登録。接続を確認できたという確証が取れて、初めて実機の前から解放されます。

UFWとFail2banの設定

  1. ファイアウォール(ufw)の設定: 不要な通信をすべて拒否し、必要な通信(SSH, HTTP/S)のみを許可する、基本的な防御壁を構築します。
  2. 不正アクセスの自動検知・ブロック(fail2ban): ログファイルを常時監視し、不審なアクセス元を検知すると、ufwと連携してそのIPアドレスからのアクセスを動的に、そして恒久的にブロックします。
    • SSHへのログイン失敗(3回)
    • ufwがブロックした通信(1回)

Fail2banとは?

fail2banは、サーバーのログファイルを監視し、設定されたパターンに一致する不審なアクセス(パスワード総当たり攻撃など)を検知すると、そのアクセス元のIPアドレスを自動的にファイアウォールの拒否リストに追加する、侵入防止ソフトウェアです。
一度設定すれば、アンインストールしない限りは有効化し続けます。

まず、サーバーの玄関となるファイアウォールufwを設定します。

0-1. システム全体のバックアップ(vpsや仮想サーバの場合)

UFWとfail2banは基本的である分、設定に極めて忠実です。そのため、設定をミスして自分自身のアクセスを禁止した場合、そこに入るための手段はなくなります。

そのため、vps/仮想サーバと言った物理的なログイン手段を持たない場合は、スナップショットやディスクイメージ全体のバックアップを行い、「失敗したときのリカバリー」を行えるようにします。

現に、筆者は、これを怠ったばかりにサーバを作り直したことが3回ほどあります。

0-2. 実機でログインできる準備をしておく(物理サーバの場合)

物理サーバで、サーバ室やデータセンターなどの場合は、この設定が終わるまでは実機の前にいるべきです。

1.1 デフォルトのポリシーを設定

最初に「入ってくる通信は原則すべて拒否、出ていく通信はすべて許可」という基本方針を設定します。これが最も安全な基本設定です。

  • 入ってくる通信を全拒否
sudo ufw default deny incoming
  • 出てくる通信を全許可
sudo ufw default allow outgoing
  • ufw.logの有効化
sudo ufw logging on

これを行わないと、後述するfail2banのアクセスがうまくいきません。

1.2 必要な通信を許可する

次に、必要なサービスへの通信を個別に許可します。SSHの接続を許可する前にufwを有効化すると、サーバーから締め出されてしまうので、必ず先に設定してください。

  • SSH接続を許可(ポート22番)
sudo ufw allow ssh comment 'Allow SSH connections'
  • WebサーバーへのHTTP接続を許可(ポート80番)
sudo ufw allow http comment 'Allow HTTP traffic'
  • WebサーバーへのHTTPS接続を許可(ポート443番)
sudo ufw allow https comment 'Allow HTTPS traffic'

commentオプションで、後からルールを見返したときに分かりやすいようにコメントを付与できます。

これはもちろん基本的な構成です。他のポートを開放・閉じる場合は必要に応じて行います。

1.4 UFWを有効化

ルールを設定したら、ufwを有効化します。

sudo ufw enable

実行すると、「この操作は既存のSSH接続を切断する可能性があります」という警告が出ますが、ステップ1.2でSSHを許可していれば問題ありません。yを入力して実行します。

1.5 設定状態の確認

最後に、設定が正しく反映されているか確認します。

sudo ufw status verbose

Status: activeと表示され、許可したルールが一覧に出ていれば成功です。

1.6 ufw有効化確認

SSHターミナルで

telnet localhost 22

と行ってみます。

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

と通信が可能です。逆に、通信を許可されていないポートでは

telnet localhost 23
Trying 127.0.0.1...
telnet: Unable to connect to remote host: 接続を拒否されました

として、接続することはできません。

手順2:Fail2banのインストールと設定

次に、fail2banをインストールし、ufwと連携させる設定を行います。

2.1 Fail2banのインストール

  • パッケージリストを更新
sudo aptitude update
  • fail2banをインストール
sudo aptitude install fail2ban

筆者の好みでaptitudeを用いていますが、aptでも同様です。

2.2 設定ファイルの仕組み(.conf と .local)

Fail2banの設定は、/etc/fail2ban/ディレクトリにあります。重要なルールとして、jail.confのような.confファイルを直接編集してはいけません。

代わりに、jail.localのように.localという拡張子のファイルを作成し、変更したい項目だけを記述します。.localファイルの内容が.confの内容を上書きする仕組みになっており、これにより、将来Fail2banがアップデートされても、自分が行ったカスタム設定が消えてしまうのを防げます。

2.3 jail.localの作成と解説

教義・信仰に沿ったエディタで、/etc/fail2ban/jail.local というファイル名で新規作成し、以下の内容を記述します。

# SSHへの総当たり攻撃を監視・ブロックする設定
[sshd]
enabled   = true               # このsshd用の設定を有効にする
maxretry  = 3                  # 3回試行を失敗したら
bantime   = -1                 # 無期限にBANする
logpath   = /var/log/auth.log  # この認証ログファイルを監視する
ignoreip  = 127.0.0.1/8 ::1 【ここに自分のIPアドレスを追加】
# ignoreipには、絶対にBANしたくない自分のIPアドレスなどをスペース区切りで指定

# UFWがブロックしたログを監視・ブロックする設定
[ufw]
enabled   = true
filter    = ufw-aggressive
action    = iptables-allports
logpath   = /var/log/ufw.log
maxretry  = 1                  # 1回でもUFWの拒否ログに記録されたら
bantime   = -1                 # 無期限にBANする
ignoreip  = 127.0.0.1/8 ::1 【ここに自分のIPアドレスを追加】

2.4 カスタムフィルターの作成(ufw-aggressive)

上記の[ufw]セクションで指定したufw-aggressiveというフィルターは、自分で作成する必要があります。これは、ufw.logから攻撃元IPアドレスを抜き出すためのルールです。

/etc/fail2ban/filter.d/ufw-aggressive.conf というファイル名で新規作成し、以下の内容を記述します。

[Definition]
failregex = [UFW BLOCK].+SRC=<HOST>
ignoreregex =

failregex: この正規表現パターンに一致するログ行を探し、<HOST>の部分を攻撃元IPアドレスとして認識します。

手順3:設定の反映と動作確認

  1. Fail2banサービスを有効化・起動します。
  • fail2banの有効化(サーバ再起動でも自動的に起動するようにする)
sudo systemctl enable fail2ban
  • fail2banの起動
sudo systemctl start fail2ban
  1. サービスの稼働状態を確認します。
sudo systemctl status fail2ban

active (running)と表示されていれば成功です。

  1. ジェイル(監視)の状態を確認します。
sudo fail2ban-client status

Jail list:に、sshdufwが表示されていれば、監視が開始されています。

これで、不審なアクセスは次回以降、有無を言わせずブロックされる設定となりました。
BANされたIPアドレスは sudo fail2ban-client status sshdsudo fail2ban-client status ufw で確認できます。

まとめ「大いなる力には……」

Linuxの学習で実機を触った方(特にRocky/AlmaなどのRHEL系ディストリビューション)で

sudo su -

を実行したとき、以下のような文言を見かけるのではないでしょうか。

あなたはシステム管理者から通常の講習を受けたはずです。
これは通常、以下の3点に要約されます:
    #1) 他人のプライバシーを尊重すること。
    #2) タイプする前に考えること。
    #3) 大いなる力には大いなる責任が伴うこと。

この#3の「with great power there must also come -- great responsibility」は特に重要です。

少なくとも、Linuxサーバのインターネット公開という「1つの世界」を「他の世界と接続する」行為を試みた者は、この言葉を言葉ではなく魂で理解していきましょう。

余談(という名の本題)

なお、これを力説するのは「筆者が加害者になりかけたことがある」からです。上記の設定などを全く理解せず、rootの意味/覚悟を知らぬままLinuxサーバを自宅から運用するということを行ってしまったため……

たちまちのうちに制御を乗っ取られ、「善意の第三者からの通報」により阻止されたという苦い思いがあります。

この経験は15年もの間、Linuxと筆者を遠ざけ、趣味で触ってもローカル環境で運用するというトラウマとなりました。

ようやく、このトラウマから脱却できつつあるので、初心に立ち返る意味でもこの文章を残します。

BookStackサイトの404を差し替え。

BookStackの404記事を自分好みの文章に差し替えたときのメモです。

環境

  • BookStack v25.07.2
  • PHP8.3
    • PHP-FPM
  • Apache 2.4
    • 実行ユーザはwww-data
  • MySQL 8
  • Ubuntu 24.04

さっくりとした手順

  1. BookStackの404ページへと移動します。
  2. 元々の404ページを退避させます。
  3. カスタム404へと差し替えます。
  4. 設定を反映させます。
  5. 内容を確認します。

BookStackのディレクトリ移動と元ファイルの退避

  • ディレクトリ移動
cd /path/to/BookStack/resources/views/errors/ && pwd

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

  • 404ページの退避
sudo mv 404.blade.php /path/to/backup/404.blade.php.$(date +%Y%m%d)

ファイル全体を差し替えるので、mvを利用します

  • 404ページの退避確認
ls -l /path/to/backup/404.blade.php.$(date +%Y%m%d)

ファイルがあることを確認します。(mvなのでlsで確認)

404ファイル作成

  • 404.blade.php

を、新たなファイルに差し替えます。筆者はこのようにしました。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>404 | もう逃げられない、アーサー</title>
    <style>
        /* 全体設定 */
        body {
            font-family: 'Times New Roman', Times, serif;
            background-color: #f7f7f7;
            color: #333;
            margin: 0;
            padding: 20px;
            line-height: 1.6;
        }

        /* コンテナ */
        .container {
            max-width: 800px;
            margin: 40px auto;
            background-color: #fff;
            padding: 30px;
            box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
            border: 1px solid #ddd;
        }

        /* 404ヘッダー */
        .header {
            text-align: center;
            margin-bottom: 30px;
            border-bottom: 2px solid #a00; /* 赤いライン */
            padding-bottom: 10px;
        }

        .header h1 {
            font-size: 3em;
            color: #a00;
            margin: 0;
        }

        .header p {
            color: #666;
            font-style: italic;
        }

        /* 対話スタイル */
        .dialogue-box {
            margin-bottom: 20px;
            padding: 15px;
            border-left: 5px solid;
        }

        .dialogue-box.editor {
            border-color: #4CAF50; /* 緑色 (編集者/外部の声) */
            background-color: #e8f5e9;
        }

        .dialogue-box.arthur {
            border-color: #2196F3; /* 青色 (アーサー/コナン・ドイル) */
            background-color: #e3f2fd;
        }

        .speaker {
            font-weight: bold;
            display: block;
            margin-bottom: 5px;
            font-size: 0.9em;
            text-transform: uppercase;
        }

        /* 結びのフッター */
        .footer {
            text-align: center;
            margin-top: 30px;
            padding-top: 20px;
            border-top: 1px dashed #ccc;
        }

        .footer a {
            color: #007bff;
            text-decoration: none;
            margin: 0 10px;
            font-weight: bold;
        }

        .footer a:hover {
            text-decoration: underline;
        }

    </style>
</head>
<body>

    <div class="container">

        <div class="header">
            <h1>404 Not Found</h1>
            <p>ページが見つかりません。探偵の不在は、常に混乱をもたらします。</p>
        </div>

        <div class="dialogue-box editor">
            <span class="speaker">編集者(あるいは「声」)</span>
            <p>**もう逃げられない。**<br>
            続きを書け。馬車でストランドの編集部へ行こう。<br>
            よく考えろ。自宅は葬列で包囲されている。<br>
            喪章をつけたロンドン市民が続きを望んでいるんだ。<br>
            君は探偵の大敵を出した直後に滝に落として、雑誌に大損害を与えた。<br>
            もういい、歴史小説は終わりだ。<br>
            **ホームズを生還させるんだアーサー。**<br>
            君は既に有名作家として評価されているんだ!<br>
            母上からの手紙を読め。読むんだ!<br>
            母上も探偵の話を続けろと言っているぞ。<br>
            ファンから殺されたいのか?<br>
            君の作家性を高めるんだ!</p>
        </div>

        <div class="dialogue-box arthur">
            <span class="speaker">アーサー・コナン・ドイル</span>
            <p>**未だ何も評価されちゃいないんだ! 何も!**<br>
            俺にとって本当の小説とは戦争小説のことなんだ!<br>
            アレは俺の小説じゃ無かった!<br>
            生活費を稼ぐため、もっと書けと頼まれた!<br>
            俺は100年戦争小説の為にリアルな騎士道を学び尽くした!<br>
            これを書くために自キャラを滝に落としたら蛆虫どもが非難してくるんだ。<br>
            俺のことを探偵殺しとか駄文を書く暇あったら生き返らせろとか悪口の限りを並べやがった!<br>
            あいつら何なんだ?<br>
            歴史物のなんたるかも知らずに!<br>
            **頭にきたぜ!**</p>
        </div>

        <div class="dialogue-box editor">
            <span class="speaker">編集者(あるいは「声」)</span>
            <p>君にとってホームズの物語は<br>
            **今の栄光の時代だ。断じて過去にはない**</p>
        </div>

        <div class="dialogue-box arthur">
            <span class="speaker">アーサー・コナン・ドイル</span>
            <p>俺は**大英帝国の未来**を書きたいんだ!</p>
        </div>

        <div class="dialogue-box editor">
            <span class="speaker">編集者(あるいは「声」)</span>
            <p>未来? 未来だと?<br>
            君はまだ少年兵のように、戦場に夢を見ているのか?<br>
            ペンで帝国を救うつもりか、アーサー?</p>
        </div>

        <div class="dialogue-box arthur">
            <span class="speaker">アーサー・コナン・ドイル</span>
            <p>救うだと? 違う! **断罪する**んだ。<br>
            俺は帝国の瓦礫の上で、真実の騎士を描く!<br>
            硝煙の中に詩を見た。あの幻を、誰も読もうとしなかった。<br>
            ホームズは観察するだけだ。<br>
            だが俺の騎士は、**行動する!**</p>
        </div>

        <div class="footer">
            <a href="/">本棚へ戻る (Go Home)</a>
            <p style="font-size:0.8em; margin-top:10px;">(探偵は...未だ見つかっていません。)</p>
        </div>
    </div>

</body>
</html>
  • 404.blade.phpの所有者変更
sudo chown www-data:www-data 404.blade.php && ls -l 404.blade.php

www-dataはBookStackの実行ユーザに合わせます。合わせた後、所有者を確認します。

設定反映

  • artisanによるキャッシュクリア
sudo -u www-data php artisan view:clear
sudo -u www-data php artisan cache:clear

設定反映確認

BookStackのサイトにアクセスし、存在しない適当な文字を入れます。

上記、設定した文書があることを確認します。

ユースケース:PHP-FPMプール設定引き上げによるNextcloudのレスポンス改善

環境

  • Nextcloud 31系
  • PHP 8.3
    • PHP-FPM 8.3
  • Redis / APCUなどによる
  • Apache 2.4
  • Ubuntu 24.04
  • MySQL 8
  • メモリ6GB
  • 4 core CPU

事象

Nextcloud Talkを含めたレスポンスが非常に悪いという状況。具体的には

  • トップページがなかなかロードされない。
  • 各画面の遷移状態が悪い。
  • 画像をクリックしても表示に時間がかかる。(分単位であることも)

free -hでもメモリ圧迫という様子を見せず、topをたたいても異常なし。

何よりも、同一サーバに同居する

  • Growi
  • Redmine
  • BookStack

などが正常に動いていて、これらはレスポンスも良好。サーバの性能ではなく、サーバ以外のところに原因があると考え、調査開始です。

原因究明

答えは/var/log配下のphp8.3-fpm.logに現れていました。

[04-Oct-2025 17:32:36] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[04-Oct-2025 18:45:55] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[04-Oct-2025 21:28:57] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

これにより、PHPのリクエストを処理するワーカープロセスの数が上限(5)に達し、リクエストが滞留していることがパフォーマンス低下の直接的な原因だと特定しました。

これが分かれば、後は実際の対処です。

事象改善:さっくりとした手順

  1. PHP-FPMのプール設定ファイルのバックアップを取ります。
  2. 設定ファイルを編集してワーカープロセスの上限数や他の関連する値を引き上げます。
  3. 設定ファイルを反映させるため、各種サービスを再起動します。
  4. 事象の解決を確認します。

設定ファイルのバックアップ

  • ファイルバックアップ
sudo cp -pi /etc/php/8.3/fpm/pool.d/www.conf /path/to/backup/directory/www.conf.$(date +%Y%m%d)

※php-fpmの設定値は、入れているPHPのバージョンによって異なります。自分の環境に合わせたものに修正してください。

 → /home/hoge/backupなど、任意のバックアップディレクトリを指定します。

  • ファイルバックアップ確認
diff -u /path/to/backup/directory/www.conf.$(date +%Y%m%d) /etc/php/8.3/fpm/pool.d/www.conf

 → エラーがなければバックアップが取れています。

備考:なぜdiffを用いてバックアップの確認をするのか?

  • ls -lよりも確実に、元ファイルとバックアップファイルがあるか「両方のファイル」で確認を取るため。
  • 編集後、「どのような編集を行ったのか?」を同じコマンドで確認を取る。
    • 「バックアップ」-「設定ファイル」の順番とすることで、後のdiffの編集を行った、追記を行った箇所が+で表示されます。(同様に削った箇所が-で表示)

特に、設定ファイルの修正は非常にデリケートな問題であり、下手な設定がサーバ全体のシステムダウンを引き起こします。このため、変更管理や後のトラブルの追跡を兼ねてのバックアップはサーバメンテナンスの黄金律として体に覚え込ませましょう。

ファイルの修正

  • ファイルの修正

上記、バックアップを取った後の 元ファイル /etc/php/8.3/fpm/pool.d/www.conf を、管理者権限で、自身の教義・信仰に基づいたエディタで修正します。

こちらの設定値は、aptなどでのパッケージ管理システムでのインストールであれば、

pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

となっていることが多いです。これを、以下のように修正しましょう。

pm.max_children = 15
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

※ サーバ環境などにより、随時、修正を行ってください。

修正後、保存を行います。

  • diffによる差分確認
diff -u /path/to/backup/directory/www.conf.$(date +%Y%m%d) /etc/php/8.3/fpm/pool.d/www.conf

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

; Note: This value is mandatory.
-pm.max_children = 5
+pm.max_children = 15

 ; The number of child processes created on startup.
 ; Note: Used only when pm is set to 'dynamic'
 ; Default Value: (min_spare_servers + max_spare_servers) / 2
-pm.start_servers = 2
+pm.start_servers = 4
 ; The desired minimum number of idle server processes.
 ; Note: Used only when pm is set to 'dynamic'
 ; Note: Mandatory when pm is set to 'dynamic'
-pm.min_spare_servers = 1
+pm.min_spare_servers = 2
 ; The desired maximum number of idle server processes.
 ; Note: Used only when pm is set to 'dynamic'
 ; Note: Mandatory when pm is set to 'dynamic'
-pm.max_spare_servers = 3
+pm.max_spare_servers = 6 
 ; The number of rate to spawn child processes at once.
 ; Note: Used only when pm is set to 'dynamic' 

このように、修正前が-の行、修正後が+の行で修正されていることが分かります。この数値や設定以上に重要なのは「変なスペースや意図した設定以外の情報が含まれていないか?」を、自分の修正した記憶を頼りにすることではなく、コマンドという絶対的な第三者の目で確認することです。

設定反映

PHP-FPMだけでなく、前段のApacheもサービス再起動を行います。

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

active(running)を確認します。

  • PHP-FPMサービス再起動
sudo systemctl restart php8.3-fpm.service
  • PHP-FPMサービス再起動後確認
systemctl status php8.3-fpm.service

active(running)を確認します。

事象改善確認

再びNextcloudにアクセスし、事象が改善したことを確認できれば設定完了です。

余談:なぜこの事象が起きたか?

Nextcloudの利用頻度が高まったからに尽きます。Talkをスマートフォンアプリでも利用したり、データが増えたことで、PHP-FPMの処理能力が追いつかなかったのでしょう。

利用状況に合わせて、ボトルネックを特定し、修正を加えて改善を施していくというのもまた、サーバ運用の苦しくも楽しいところです。

PHP-FPMでNextcloudを動作させるための手順。

PHP-FPMを利用したNextcloudのセットアップ方法です。

なぜ mod_php ではなく PHP-FPM を使うのか?

パフォーマンスとリソース効率を向上させるためです。

従来のmod_phpでは、PHPがApacheの全プロセスに組み込まれるため、画像ファイルのリクエストのようなPHPが不要な処理でもメモリを消費し、無駄が多くなりがちでした。

一方、PHP-FPMはPHPの処理をApacheから完全に独立させた専門のプロセスとして管理します。ApacheはPHPが必要なリクエストだけをPHP-FPMに中継するため、サーバー全体の動作が軽量かつ高速になります。

前提

  • OS: Ubuntu 24.04 LTS
    • → SSH接続できること。
    • ※root権限を持っていること。
    • この権限を持っていない場合、ここから先の設定はできません。
  • データベース: MySQL 8.0
  • Webサーバー: Apache 2.4
    • 実行ユーザーはwww-data
    • ホームディレクトリを /home/www-dataにしています。自分の環境に合わせてください。
  • ドメインとSSL/TLS証明書: 準備済みであること

筆者の好みでaptitudeを用いています。必要に応じてaptをご利用ください。

さっくりとはならない手順

  1. リポジトリの追加とアップデートを行います。
  2. パッケージをインストールしていきます。
  3. PHP-FPMの設定を行います。
  4. PHPのパフォーマンス設定を行います。
  5. MySQLでDB設定を行います。
  6. NextcloudのDBを設定します。
  7. Apacheバーチャルホストの設定を行います。
  8. バーチャルホストの設定を有効化します。
  9. 設定の有効化とサービスの再起動を

リポジトリの追加とアップデート

最新のPHPバージョンを利用するためにppa:ondrej/phpリポジトリを追加していきます。

  • レポジトリ追加
sudo add-apt-repository ppa:ondrej/php
  • パッケージ全体のアップデート
sudo apt update

必要なパッケージのインストール

PHP本体、PHP-FPM、Nextcloudが必要とする各種PHPモジュールをインストールします。

sudo aptitude install php8.3 php8.3-fpm php8.3-opcache php8.3-pdo php8.3-bcmath php8.3-calendar php8.3-ctype php8.3-fileinfo php8.3-ftp php8.3-gd php8.3-intl php8.3-json php8.3-mbstring php8.3-mysql php8.3-posix php8.3-readline php8.3-sockets php8.3-bz2 php8.3-tokenizer php8.3-zip php8.3-curl php8.3-iconv php8.3-xml php8.3-imagick php8.3-gmp php8.3-apcu memcached

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

php -v

表示例

PHP 8.3.25 (cli) (built: Aug 29 2025 12:01:53) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.25, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.25, Copyright (c), by Zend Technologies

PHP-FPMとApacheの連携設定

従来の mod_php を無効化し、PHP-FPMとの通信に必要な proxy_fcgi モジュールなどを有効化します。

  • mod_phpを無効化(もしインストールされていれば)
sudo a2dismod php8.3
  • 必要なモジュールを有効化
sudo a2enmod proxy_fcgi setenvif header rewrite

PHPのパフォーマンス設定

Nextcloudのパフォーマンス向上のため、PHPのメモリ制限、OPcache、APCuを設定します。

  • php.ini の設定 (memory_limit)
sudo sed -i 's/memory_limit = .*/memory_limit = 512M/g' /etc/php/8.3/fpm/php.ini
  • OPcacheとAPCuの有効化

Nextcloud推奨の設定値を /etc/php/8.3/mods-available/ に作成・適用します。

  • OPcache設定
cat <<- __EOF__ | sudo tee /etc/php/8.3/mods-available/opcache.ini
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
  • APCu設定
cat <<- __EOF__ | sudo tee /etc/php/8.3/mods-available/apcu.ini
[acpu]
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200 apc.enable_cli=1
apc.serializer=php
__EOF__

データベースの作成

Nextcloudが使用するMySQLデータベースと専用ユーザーを作成します。

  • MySQLにrootでログイン
mysql -u root -p

以下のSQLコマンドを実行します。YOUR_STRONG_PASSWORD は必ず強固なパスワードに変更してください。

CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'nextcloud'@'localhost' IDENTIFIED WITH mysql_native_password BY 'YOUR_STRONG_PASSWORD';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Nextcloudプログラムの配置

Nextcloud本体をダウンロードし、Webサーバーからアクセスできる場所に配置します。

  • 作業ディレクトリへ移動
cd /tmp && pwd

任意のディレクトリを指定します。

  • 最新版をダウンロードして展開
wget https://download.nextcloud.com/server/releases/latest.zip
unzip latest.zip
  • 展開したファイル一式をWeb公開用ディレクトリに移動
sudo mv nextcloud /home/www-data/
  • 所有者をWebサーバーの実行ユーザーに変更
sudo chown -R www-data:www-data /home/www-data/nextcloud

Apacheバーチャルホストの設定

Nextcloud用のApache設定ファイルを作成します。ここでPHP-FPMとの連携設定を組み込みます。

  • ログディレクトリの作成
sudo mkdir /var/log/nextcloud
  • ログディレクトリをwww-dataに修正。

これは、後のメンテナンス性を高めるためです。

sudo chown www-data:www-data /var/log/nextcloud
  • 設定ファイルの作成

/etc/apache2/sites-available/nextcloud.conf

を、teeで一気通貫で作ります。

# 【】内はご自身の環境に合わせてください
cat <<- __EOF__ | sudo tee /etc/apache2/sites-available/nextcloud.conf
<VirtualHost *:80>
    ServerName 【hoge.example.com】
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName 【hoge.example.com】
    DocumentRoot 【/home/www-data/nextcloud】

    CustomLog /var/log/nextcloud/nextcloud_access.log combined
    ErrorLog /var/log/nextcloud/nextcloud_error.log

    <Directory 【/home/www-data/nextcloud】>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>

    # PHP-FPM連携設定
    <FilesMatch \.php$>
        # SetHandlerで、phpファイルのリクエストをPHP-FPMのソケットに渡す
        SetHandler "proxy:unix:/var/run/php/php8.3-fpm.sock|fcgi://localhost/"
    </FilesMatch>

    # --- SSL設定 ---
    SSLEngine on
    Protocols h2 http/1.1
    SSLCertificateFile 【/etc/certs/hoge.example.com.crt】
    SSLCertificateKeyFile 【/etc/private/hoge.example.com.key】
    # 中間証明書が別に提供されている場合はこちらを有効化
    # SSLCACertificateFile 【/etc/certs/hoge.example.com.CA.crt】

    # --- 推奨SSL/TLS設定 ---
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     on
    SSLCompression          off
    SSLSessionTickets       off

    # --- セキュリティヘッダー ---
    # Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    Header always set Referrer-Policy "no-referrer"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Permitted-Cross-Domain-Policies "none"
</VirtualHost>
__EOF__

設定の有効化とサービスの再起動

  • 作成したサイト設定を有効化
sudo a2ensite nextcloud.conf
  • 構文チェック
sudo apache2ctl configtest

Syntax OK と表示されることを確認

  • fpm/apacheサービスを再起動
sudo systemctl restart php8.3-fpm.service
sudo systemctl restart apache2.service
  • fpm/apache再起動確認
systemctl status php8.3-fpm.service
systemctl status apache2.service

active (running)と表示されていれば正常です。

Webブラウザでのセットアップ

最後に、Webブラウザで https://【設定したドメイン】 にアクセスし、画面の指示に従ってNextcloudの初期設定を完了させます。

  • 管理者ユーザーのユーザー名とパスワードを入力
  • データベース情報を入力
    • データベースのユーザー名: nextcloud
    • データベースのパスワード: 手順5で設定したパスワード
    • データベース名: nextcloud
    • データベースのホスト名: localhost (または localhost:3306)

これで、PHP-FPM上で動作するNextcloud環境の構築が完了します。

BookStackのフォントをサーバ内のフリーフォントに変更。

BookStackの表示フォントを、サーバー内に配置したカスタムフォント(kiloji)に変更したときのメモです。

これには2つの目的があります。

  • 見た目を変えて独自性を出す。
  • サーバ内にあるフォントを指定することで読み込み速度を大幅に上げる。

環境

  • BookStack v25.07.2
  • PHP 8.3
  • MySQL 8
  • Apache 2.4
    • Apacheの実行ユーザはwww-data

さっくりとした手順

  1. カスタムフォントを用意します。
  2. BookStackのpublicフォルダにフォントファイルを格納します。
  3. カスタムCSSを設定します。
  4. 設定を確認します。

カスタムフォントを用意します。

今回用いたのは手書きボールペンのようなフォント、きろ字。(フリーで使えるフォントです)

公式サイトからフォントファイル一式をダウンロードします。

使うフォントファイルは

  • kiroji.ttf
  • kiroji.woff
  • kiroji.woff2
  • kiroji_b.ttf
  • kiroji_b.woff
  • kiroji_b.woff2

となっています。ダウンロード後、サーバの適当な位置に格納します。

BookStackのファイルにフォントを格納します。

  • BookStackのpublicディレクトリに移動
cd /path/to/bookstack/public && pwd

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

  • fontsディレクトリを作成します。
sudo -u www-data mkdir -p fonts/kiloji
  • フォントファイルの格納
sudo -u www-data cp -pi /path/to/fonts/directory/kiroji*woff2 /path/to/bookstack/public/fonts/kiloji/
  • フォントファイルの格納確認
ls -l /path/to/bookstack/public/fonts/kiloji/

追加したフォントがあることを確認します。

カスタムCSSを修正します。

ブラウザでBookStackにアクセスし、管理者権限でログインします。

設定>カスタマイズに移動します。

「カスタムheadタグ」のテキストボックスに、以下のCSSコードを貼り付けます。

<style>
/* --- フォントの定義 --- */

/* 1. 通常の太さのフォントを 'kiloji' として定義 */
@font-face {
  font-family: 'kiloji';
  font-style: normal;
  font-weight: normal;
  src: url('/fonts/kiloji/kiloji.woff2') format('woff2'),
       url('/fonts/kiloji/kiloji.woff') format('woff'),
       url('/fonts/kiloji/kiloji.ttf') format('truetype');
}

/* 2. 太字用のフォントを、同じ 'kiloji' という名前で定義 */
@font-face {
  font-family: 'kiloji';
  font-style: normal;
  font-weight: bold;
  src: url('/fonts/kiloji/kiloji_b.woff2') format('woff2'),
       url('/fonts/kiloji/kiloji_b.woff') format('woff'),
       url('/fonts/kiloji/kiloji_b.ttf') format('truetype');
}

/* --- フォントの適用 --- */

/* 1. ページ全体の基準となる文字サイズとフォントを指定 */
body {
  font-family: 'kiloji', sans-serif !important;
  font-size: 16px; /* ← この数値で大きさを調整 */
}

/* 2. 見出しやナビゲーションなど、個別にフォントが指定されている箇所にも適用 */
h1, h2, h3, h4, h5, h6, .btn, a, input, textarea,
.page-nav, .sidebar-page-nav a, .tri-layout-container, .chapter-contents, .book-contents a {
  font-family: 'kiloji', sans-serif !important;
}
</style>

適用後、ページ下部の「設定を保存」ボタンをクリックします。

設定変更確認

BookStackにアクセスし、指定したフォントに替わっていたら設定変更です。

補足:最初の試行(一部のみフォントが変わったCSS)

以下は、bodyタグにのみフォントを指定した最初のコードです。見出しなど、個別にCSSが設定されている要素には適用されませんでした。

<style>
@font-face {
  font-family: 'kiloji';
  font-style: normal;
  font-weight: normal; 
  src: url('/fonts/kiloji/kiloji.woff2') format('woff2');
}
@font-face {
  font-family: 'kiloji';
  font-style: normal;
  font-weight: bold; 
  src: url('/fonts/kiloji/kiloji_b.woff2') format('woff2');
}
body {
  font-family: 'kiloji', sans-serif !important;
}
</style>

Ubuntu24.04にGrowi2.7.3.xをインストール

概要

Growi v7.3.0のインストールメモです。

MongoDBの関係もあり、インストールするCPUを選びます。

備考

  • v7系は利用するMongoDBの関係上、CPUを選びます。(Celeron系や古いアーキテクチャでは動きません)
  • v7.3.0より、Elasticsearchのバージョンは従来のv8ではなくv9を必要とします。
    • Elasticsearchを用いる方は注意ください。

環境

  • Ubuntu 24.04
  • Apache 2.4

の基本的な設定が済んだという状況です。

前提

  • 名前解決できるドメインが用意されている。
  • そのドメインに応じた証明書が用意されている。

さっくりとはならない手順

  1. 必要なパッケージをインストールします。
  2. nvmをインストールします。
  3. nvm経由でnode,npm,pnpmをインストールします。
  4. Redis-serverをインストールします。
  5. Javaをインストールします。
  6. ElasticSearch 9をインストールします。
    • ElasticSearchの設定変更を行います。
    • ElasticSearchのプラグインをインストールします。
    • ElasticSearchの設定変更を反映します。
  7. MongoDBをインストールします。
    • MongoDBのデータ格納先を変更します。(オプション)
    • MongoDBの設定変更を反映します。(オプション)
  8. Growiのインストールを行います。
    • pnpmを用いてインストールします。
    • アプリのビルドを行います。
    • 自動起動のスクリプトを作成します。
  9. Apacheのリバースプロキシの設定を行います。
  10. ブラウザで初期インストールを行います。

手順

筆者の好みでaptitudeを用いています。適宜、aptに読み替えてください。

必要なパッケージのインストールを行います。

  • git, buildツールなど
sudo aptitude install build-essential git git-lfs apt-transport-https

v7.1系で`git-lfsを入れないとgit-cloneでビルドが行えなかったので、その名残です。

Node.js環境の構築(nvm, npm, pnpm)

Growiの実行にはNode.jsが必要です。ここでは、バージョン管理を容易にするためnvm(Node Version Manager)を使ってインストールします。

メンテナンスユーザーでnvmをインストール

rootではなく、作成したメンテナンスユーザーで実行します。

  • メンテナンスユーザーでログインしていることを確認
whoami
  • nvmインストールスクリプトを実行
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

このスクリプトは、~/.bashrcに必要な設定を自動で追記してくれます。

nvm環境を有効化

設定を現在のセッションに反映させるため、以下のコマンドを実行するか、一度ログアウトして再ログインしてください。

source ~/.bashrc

nvm --versionでバージョンが表示されれば成功です。

nvm経由でNode.jsと各種パッケージをインストール

Growiが必要とするバージョンのNode.jsと、npm, pnpmをインストールします。

  • Node.js v20.19.2 をインストール
nvm install v20.19.2
  • 使用するバージョンとして設定
nvm use v20.19.2
nvm alias default v20.19.2
  • npmをv11.4.0にアップデート
npm install -g npm@11.4.0
  • pnpmをインストール
npm install -g pnpm
rootユーザーにもnvm環境を適用(systemd連携のため)

Growiをサービスとして自動起動させるgrowi-start.shスクリプトは、root権限で実行されるsystemdから呼び出されます。そのため、rootユーザーもnvmの場所を知っている必要があります。

以下のコマンドで、メンテナンスユーザー用にインストールしたnvmへのシンボリックリンクを、rootのホームディレクトリに作成します。

sudo ln -sf /home/【maintenance_user】/.nvm /root/.nvm

【】内は自分のLinuxアカウント(メンテナンスユーザー名)に置き換えてください

これにより、rootで実行されるスクリプトも、メンテナンスユーザーと同じNode.js環境を参照できるようになります。

redis-serverをインストールします。

  • インストール
sudo  aptitude install redis-server
  • 起動確認
systemctl status redis-server

active(running)を確認します。

  • 自動起動有効化
sudo systemctl enable redis-server

Javaをインストールします。

  • インストール
sudo aptitude install openjdk-17-jdk

Elasticsearchをインストールします。

※v7.3.0よりElasticsearchのv9を用いるようになっています。

  • gpg追加
sudo wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
  • レポジトリ追加
sudo echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/9.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-9.x.list
  • パッケージのアップグレード
sudo aptitude update
  • ElasticSearchインストール
sudo aptitude install elasticsearch

※この後、デフォルトパスワードが表示されますが、控えておく程度にしましょう。

JVM設定変更
  • バックアップディレクトリ作成
sudo mkdir /etc/elasticsearch/old

※任意のバックアップディレクトリを指定します。

  • 設定ファイルバックアップ
sudo cp -pi /etc/elasticsearch/jvm.options /etc/elasticsearch/old/jvm.options.$(date +%Y%m%d)
  • 設定ファイル書き換え
echo -e "-Xms256m\n-Xmx256m" | sudo tee -a /etc/elasticsearch/jvm.options
  • 書き換え確認
sudo diff -u /etc/elasticsearch/old/jvm.options.$(date +%Y%m%d) /etc/elasticsearch/jvm.options
  • 差分
+-Xms256m
+-Xmx256m
ElasticSearchの設定変更

※この作業も管理者権限で実行します。

  • root昇格
sudo su -
  • 設定ファイルバックアップ
cp -pi /etc/elasticsearch/elasticsearch.yml /path/to/backup/elasticsearch.yml.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • ファイル書き換え
sed -i -e 's/xpack.security.enabled: true/xpack.security.enabled: false/' \
       -e '/xpack.security.http.ssl:/{n; s/  enabled: true/  enabled: false/}' \
       -e '/xpack.security.transport.ssl:/{n; s/  enabled: true/  enabled: false/}' /etc/elasticsearch/elasticsearch.yml
  • 差分確認
diff -u /path/to/backup/elasticsearch.yml.$(date +%Y%m%d) /etc/elasticsearch/elasticsearch.yml
  • 差分
 # Enable security features
-xpack.security.enabled: true
+xpack.security.enabled: false

 xpack.security.enrollment.enabled: true

 # Enable encryption for HTTP API client connections, such as Kibana, Logstash, and Agents
 xpack.security.http.ssl:
-  enabled: true
+  enabled: false
   keystore.path: certs/http.p12

 # Enable encryption and mutual authentication between cluster nodes
 xpack.security.transport.ssl:
-  enabled: true
+  enabled: false
  • rootから抜ける
exit
ElasticSearchのプラグインを追加
  • analysis-kuromoji インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji
  • analysis-icu インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
自動起動設定反映
  • 起動
sudo systemctl start elasticsearch
  • 起動確認
systemctl status elasticsearch

active(running)を確認します。

  • 自動起動有効化
sudo systemctl enable elasticsearch

MongoDBインストール

レポジトリ追加

  • 必要パッケージインストール
sudo aptitude install gnupg
  • gpg追加
curl -fsSL https://www.mongodb.org/static/pgp/server-6.0.asc | \
   sudo gpg -o /usr/share/keyrings/mongodb-server-6.0.gpg \
   --dearmor
  • レポジトリ追加
echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-6.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/6.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list
MongoDBインストール
  • パッケージのアップグレード
sudo aptitude update
  • MongoDBインストール
sudo aptitude install mongodb-org
保存先変更(オプション)

MongoDBの格納先を、冗長化構成されているパーティションにするため対応しました。

本設定の要注意点

MongoDBは、その性質上、頻繁にファイルの書き換えを行います。そのため、ブロックストレージのような「データ削除ポリシー」が明記されているネットワークストレージに、保存パーティションを指定してはいけません。(筆者はそれで痛い目に遭いました)

本設定が必要な場合は、同じサーバ上の、SSDで行いましょう。

  • 格納ディレクトリ作成
sudo mkdir /home/mongodb

保存先を変えたいところにします

  • 所有者変更
sudo chown -R mongodb:mongodb /home/mongodb
  • 所有者変更確認
ls -ld /home/mongodb
  • 設定ファイルのバックアップ取得
sudo cp -pi /etc/mongod.conf /path/to/backup/mongod.conf.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

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

バックアップが保存されたか、差分がないことで確認します。

  • ファイル書き換え
sudo sed -i 's/dbPath: \/var\/lib\/mongodb/dbPath: \/home\/mongodb/' /etc/mongod.conf
  • 差分確認
sudo diff -u /path/to/backup/mongod.conf.$(date +%Y%m%d) /etc/mongod.conf
  • 差分
-  dbPath: /var/lib/mongodb
+  dbPath: /home/mongodb
自動起動有効
  • mongodサービス起動
sudo systemctl start mongod
  • サービス起動確認
systemctl status mongod

active (running)を確認します

  • 自動起動有効化
sudo systemctl enable mongod

Growiインストール

  • git clone
sudo git clone https://github.com/growilabs/growi /home/www-data/growi

※任意のディレクトリを指定します。

  • ディレクトリ移動
cd /home/www-data/growi && pwd

先ほどcloneしたディレクトリです。

  • チェックアウト
sudo git checkout -b v7.3.0 refs/tags/v7.3.0

2025/09/17時点での最新リリースです

  • pnpmによるインストール
sudo pnpm install

CPUのスペックによっては相当な時間がかかります。

  • ビルド
sudo npm run app:build
必要であればlfs pull
  • lfs pull
sudo git lfs pull

→ v6.1で必要なコマンドでした。v7でビルドできない場合に試してください。

やはり時間がかかります。

自動起動スクリプトの作成

  • systemd作成
cat <<- __EOF__ | sudo tee -a /etc/systemd/system/growi.service
[Unit]
Description = growi
After=network-online.target mongod.service
After=network.target elasticsearch.service
ConditionPathExists=【/home/www-data/growi】

[Service]
ExecStart=【/home/www-data/growi/】growi-start.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target
__EOF__

※【】内を、git cloneしたディレクトリにします。

  • Growiインストールディレクトリに作成
  • 教義・信仰に沿ったエディタで作成します。
  • ファイル名:growi-start.sh
  • growiを配置したディレクトリ内に作成します。
#!/bin/bash

# NVM environmentをロード (NVM_DIRを直接指定)
export NVM_DIR="/root/.nvm" # $HOMEの代わりに直接パスを指定
if [ -s "$NVM_DIR/nvm.sh" ]; then
  \. "$NVM_DIR/nvm.sh"  # nvmをロード
  # 次の行でスクリプト実行時のnodeとnpmのバージョンをログに出力
  echo "NVM for GROWI startup script loaded. Using Node version: $(node -v), npm version: $(npm -v)" > /tmp/growi_nvm_load.log
else
  # NVMが見つからない場合もログに出力
  echo "NVM_DIR ($NVM_DIR) not found or nvm.sh not found for GROWI startup script." > /tmp/growi_nvm_load.log
fi

cd 【/home/www-data/growi】
NODE_ENV=production \
AUDIT_LOG_ENABLED=true \
FORCE_WIKI_MODE=private \
MONGO_URI=mongodb://localhost:27017/growi \
ELASTICSEARCH_URI=http://localhost:9200/growi \
REDIS_URI=redis://localhost:6379 \
PASSWORD_SEED=[任意の文字列] \
npm run app:server

[任意の文字列]は推測されないような英数字+記号を指定します。

  • 権限変更
sudo chmod +x /home/www-data/growi/growi-start.sh
  • systemd設定反映
sudo systemctl daemon-reload
  • growi有効化
sudo systemctl start growi.service
  • growi有効化確認
systemctl status growi.service

active(running)を確認

  • 自動起動有効化
sudo systemctl enable growi.service

Apacheによるリバースプロキシの設定

  • モジュールインストール
sudo a2enmod proxy_http proxy_wstunnel rewrite headers
  • apache再起動
sudo systemctl restart apache2.service
  • ログ保存ディレクトリ作成
sudo mkdir /var/log/growi/
  • 所有者変更
sudo chown -R www-data:www-data /var/log/growi
  • 設定ファイル作成
cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/growi.conf
<VirtualHost _default_:80>
    ServerName 【hoge.example.com】
    # ドメイン名を指定します
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# HTTPアクセスを強制的にHTTPSにリダイレクトします
</VirtualHost>

<VirtualHost _default_:443>
    ServerName 【hoge.example.com】
    # ドメイン名を指定します
    CustomLog /var/log/growi/growi_access.log combined 
    ErrorLog /var/log/growi/growi_error.log

#SSL設定
  SSLEngine on
    Protocols h2 http/1.1
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
#TLS1.3に対応していないクライアントがアクセスする場合は以下を用います
#SSLProtocol -ALL +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLCertificateFile 【/etc/certs/hoge.example.com.crt】
# SSL証明書を指定します
SSLCertificateKeyFile 【/etc/private/hoge.example.com.key】
# 秘密鍵を指定します

    # Header に Host: example.com を追加するため
    ProxyPreserveHost On
    # HTTPS利用時: Header に x-forwarded-proto: https を追加するため
    RequestHeader set x-forwarded-proto 'https'
    # Apache では static assets で 304 が返らないことがあるので ETag を無効化する
    <ifModule mod_headers.c>
            Header unset ETag
    </ifModule>

FileETag None 

<FilesMatch "\.(js|css|png|jpg|gif|svg|woff2?)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

# リバースプロキシー設定
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /(.*) ws://localhost:3000/$1 [P,L]

ProxyPass        / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/


#セキュリティヘッダー付与

    Header always set Strict-Transport-Security "max-age=63072000"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-XSS-Protection "1; mode=block"
</VirtualHost>
__EOF__

【】内を自分の環境に変更してください。

  • 設定反映
sudo a2ensite growi.conf
  • コンフィグ確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache2再起動
sudo systemctl restart apache2.service

Growiインストール確認

http://設定したドメイン でアクセスします。

初期サイトが表示されたらインストール完了です。

  • 管理者メールアドレス
  • 管理パスワード

等を設定してログインします。

Growi v7.1.x・v.7.2.x→v7.3.0へのアップデート

概要

Growi 7.1/7.2からv7.3.0Growiアップグレードの手順です。
Elasticsearchの全文検索を利用している方は「Elasticsearchのバージョンアップ」を伴う作業になります。

前提

  • 既にgrowi v7.1.x/v7.2.xをインストールしていること。
  • 管理画面トップやトップページ右下からバージョンが7.1.xまたは7.2.xであることを再確認します。
  • systemdによってサービス化されていること。
  • 具体的な手順はhttps://atelier.reisalin.com/projects/zettel/knowledgebase/articles/105
  • 最新版や安定版がリリースされていることを以下のサイトで確認していること。
  • https://github.com/growilabs/growi/releases
  • ※設定ファイルの変更やパッケージインストールの変更、nodeのバージョンアップの必要等があれば、それも事前に済ませます。

さっくりはならない手順

  1. Growiをメンテナンスモードにします。
  2. Growi・Elasticsearchのサービスを停止します。
  3. バックアップを取ります。
  4. gitコマンドで最新版をcheckoutします。
  5. アップグレードを行います。
  6. Elasticsearch・Growiのサービスを再開します。
  7. Growiのメンテナンスモードを解除します。
  8. アップグレードされたことを確認します。

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

  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
  • サービス停止確認
systemctl status elasticsearch.service

inactive(dead)を確認します。

  • Growiサービス停止
sudo systemctl stop growi.service
  • サービス停止確認
systemctl status growi.service

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)

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

リポジトリ設定ファイル名をv9用に変更

Elasticsearchのバージョンを指定するリポジトリをv9に変更します。

  • 現行のリポジトリリストをバックアップ
sudo cp -pi /etc/apt/sources.list.d/elastic-8.x.list /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d)
  • リポジトリリストのバックアップ確認
diff -u /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d) /etc/apt/sources.list.d/elastic-8.x.list
  • リポジトリリストの名前変更
sudo mv /etc/apt/sources.list.d/elastic-8.x.list /etc/apt/sources.list.d/elastic-9.x.list
  • リポジトリリストの名前変更確認
ls -l /etc/apt/sources.list.d/elastic-9.x.list

ファイルがあることを確認します。

sedコマンドでファイル内の参照先を8.xから9.xに書き換え

sudo sed -i 's/8.x/9.x/g' /etc/apt/sources.list.d/elastic-9.x.list

Elasticsearchのアップグレード

  • パッケージ全体のバックアップ
sudo aptitude update

好みでaptitudeを用いています。必要に応じてaptを用いてください。

  • Elasticsearchのアップグレード
sudo aptitude upgrade elasticsearch

※ Growiインストール時、/etc/elasticsearch/jvm.optionsファイルなどの設定変更を行っているため、アップグレード時の設定ファイルを残すかどうかの確認では、必ずN(残す)を選択します。

  • プラグインのアンインストール

Growiに必要なElasticsearchのプラグインは自動更新されません。この処置を執らないとせっかくアップグレードしたのに起動しないという事態が発生します。

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji
  • プラグインの再インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji

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 【バージョン】

リリースタグは再確認しましょう。

  • pnpm install
sudo pnpm i
  • ビルド
sudo npm run app:build

ElasticsearchとGrowiの再開

  • Elasticsearchサービス開始
sudo systemctl restart elasticsearch.service
  • サービス開始確認
systemctl status elasticsearch.service

active(running)を確認します。

  • バージョンアップ確認
curl -X GET "localhost:9200"

"number" : "9.1.3",など、9系にアップグレードされていることを確認します。

  • Growiサービス開始
sudo systemctl restart growi.service
  • サービス停止確認
systemctl status growi.service

active(running)を確認します。

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

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

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

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

バージョンアップ後の作業

必要に応じてバックアップしたファイル一式やスナップショットを削除します。

Growi v7.3.0へのバージョンアップに伴う全文検索負荷への対応。(Elasticsearchのバージョンアップ)

Growi をv7.2.10→v7.3.0へとアップグレード後、全文検索ができなくなったので、その対処方法をメモに残します。

環境

  • Growi v7.3.0
    • systemdによってサービス化
  • ElasticSearch v8.19.3
  • Ubuntu 24.04
  • MongoDB v6.0.26
  • node v20.19.2
  • Apache 2.4によるリバースプロキシ

エラー内容

Growiの管理>全文検索管理で以下のエラーが出ました。

Accept version must be either version 8 or 7, but found 9

エラーの原因

Growi v7.3.0のリリースノートで確認したところ、このバージョンからElasticsearch v9がサポート(必須化)されたことが判明しました。

support: Elasticsearch v9 (#10127)

  • Growi(クライアント側): v9形式でリクエストを送信
  • 既存環境(サーバー側): v8.19.3であったため、v9形式のリクエストを拒否

このバージョンの不一致が原因で、検索機能が停止していたと判明。対処を行います。

エラーを解決した手段

Elasticsearchをv9.1.3にバージョンアップしたことで解決しました。

手段によるサーバへの影響

「Elasticsearchバージョンアップ」です。他にこれを使うアプリが同一サーバ上にある場合、その影響を十分に確認ください。

対処方法のさっくりとした手順

  1. Elasticsearch/Growiを停止します。
  2. Elasticsearchのデータディレクトリのバックアップを行います。
  3. Elasticsearchのリポジトリをv9に併せます。
  4. Elasticsearchのバージョンアップを行います。
  5. Elasticsearchのプラグインのアンインストール/インストールを行います。
  6. Elasticsearch/Growiを起動します。
  7. エラーの解消を確認します。

ElasticsearchとGrowiの停止

  • Elasticsearchサービス停止
sudo systemctl stop elasticsearch.service
  • サービス停止確認
systemctl status elasticsearch.service

inactive(dead)を確認します。

  • Growiサービス停止
sudo systemctl stop growi.service
  • サービス停止確認
systemctl status growi.service

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)

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

リポジトリ設定ファイル名をv9用に変更

Elasticsearchのバージョンを指定するリポジトリをv9に変更します。

  • 現行のリポジトリリストをバックアップ
sudo cp -pi /etc/apt/sources.list.d/elastic-8.x.list /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d)
  • リポジトリリストのバックアップ確認
diff -u /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d) /etc/apt/sources.list.d/elastic-8.x.list
  • リポジトリリストの名前変更
sudo mv /etc/apt/sources.list.d/elastic-8.x.list /etc/apt/sources.list.d/elastic-9.x.list
  • リポジトリリストの名前変更確認
ls -l /etc/apt/sources.list.d/elastic-9.x.list

ファイルがあることを確認します。

sedコマンドでファイル内の参照先を8.xから9.xに書き換え

sudo sed -i 's/8.x/9.x/g' /etc/apt/sources.list.d/elastic-9.x.list

Elasticsearchのアップグレード

  • パッケージ全体のバックアップ
sudo aptitude update

好みでaptitudeを用いています。必要に応じてaptを用いてください。

  • Elasticsearchのアップグレード
sudo aptitude upgrade elasticsearch

※ Growiインストール時、/etc/elasticsearch/jvm.optionsファイルなどの設定変更を行っているため、アップグレード時の設定ファイルを残すかどうかの確認では、必ずN(残す)を選択します。

  • プラグインのアンインストール

Growiに必要なElasticsearchのプラグインは自動更新されません。この処置を執らないとせっかくアップグレードしたのに起動しないという事態が発生します。

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji
  • プラグインの再インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji

ElasticsearchとGrowiの再開

  • Elasticsearchサービス開始
sudo systemctl restart elasticsearch.service
  • サービス開始確認
systemctl status elasticsearch.service

active(running)を確認します。

  • バージョンアップ確認
curl -X GET "localhost:9200"

"number" : "9.1.3",など、9系にアップグレードされていることを確認します。

  • Growiサービス開始
sudo systemctl restart growi.service
  • サービス停止確認
systemctl status growi.service

active(running)を確認します。

動作確認

  1. Growiに管理者権限でログインします。
  2. 管理画面>全文検索管理に進みます。
  3. インデックスの再構築を実行し、エラーが発生せず、正常に完了することを確認します。

その後、Growi上でキーワード検索を行い、検索結果が正しく表示されることを確認しました。

Growiのリポジトリ変更に伴う対応。

Growiのリポジトリが

https://github.com/weseek/growi

から

https://github.com/growilabs/growi

に移行したというTwitter(現X)の投稿がありました。今後のサポートなどを踏まえ、今利用しているGrowiのリポジトリの大本を変えます。

環境

  • Ubuntu 24.04
  • Growi v7.2.10
    • Growiの実行ユーザはroot

さっくりとした手順

  1. 現在のリポジトリを確認します。
  2. リポジトリのURLをgitコマンドで変更します。
  3. リポジトリの変更を確認します。

Growiのディレクトリに移動

cd /path/to/growi && pwd

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

gitの参照リポジトリを確認

  • gitコマンドによる確認
sudo  git remote -v
  • 参照結果
origin  https://github.com/weseek/growi (fetch)
origin  https://github.com/weseek/growi (push)

上記を確認。

gitコマンドによるリポジトリ変更

  • リポジトリ変更
sudo git remote set-url origin https://github.com/growilabs/growi.git

gitの参照リポジトリの変更確認

  • gitコマンドによる確認
sudo  git remote -v
  • 参照結果
origin  https://github.com/growilabs/growi.git (fetch)
origin  https://github.com/growilabs/growi.git (push)
  • 最新の履歴確認
sudo git fetch origin
  • ローカルとリモートの差分確認
sudo git status

Your branch is behind 'origin/main' by X commits...
(あなたのブランチは、リモートよりX個のコミット分遅れています)
のように表示されれば、新しいgrowilabsリポジトリへの接続は成功しており、そこに新しい更新が存在することを確認できます。

なお、筆者は別環境で「リポジトリ変更後、新しいバージョン(v7.2.9→v7.2.10)へのバージョンアップを、新しいリポジトリを介して行えたことを補足しておきます。

Page 2 of 22

Powered by WordPress & Theme by Anders Norén