Growi運用

Ubuntu 24.04環境でのGrowi 7.0.23→7.1.0へのバージョンアップ
Growiで全文検索できないときの対処(ElasticSearchに伴うプラグインアップデート)
growiのバージョンアップ/ダウングレード手順。(v7.1.0未対応)
Growi v7.xでページ編集時に空白になる問題に対処(Apache リバースプロキシのWebSocket設定)
Ubuntu 20.04 / nginx環境でgrowiをv6.x→v7.0.xにアップグレード。(nginxリバースプロキシのWebSocket設定)
Growi v7.1.xのアップグレード手順

Ubuntu 24.04環境でのGrowi 7.0.23→7.1.0へのバージョンアップ

Ubuntu 7.1.0はかなり大きめの仕様変更がありました。

https://github.com/weseek/growi/releases/tag/v7.1.0

いくつかハマったポイントがありましたが、「自分はこの手順でうまくいった」 というメモを残します。

バージョンアップ前環境

Ubuntu 24.04
Mongodb 6.0.19
npm 10.9.0
node v20.18.0
yarn 1.22.22
Growi 7.0.23

以下の手順に沿ってインストール済みです。

https://barrel.reisalin.com/books/growi/page/ubuntu2404growi-v7v710

バージョンアップ後環境

Ubuntu 24.04
Mongodb 6.0.19
npm 10.9.0
node v20.18.0
pnpm 9.12.3
Growi 7.1.0

ここで分かるように、パッケージ管理がyarnからpnpmへと変わっています。

さっくりとした手順

Growiサービスを停止します。
Growiのディレクトリを退避します。
新たにgit cloneを行います。
チェックアウトを行います。
pnpmのインストールを行います。
アプリのビルドを行います。
Growiスタートアップスクリプトをコピーします。
Growiサービスを起動します。
バージョンアップを確認します。

なぜか通常のgit checkoutはビルドがうまくいきませんでした。

Growiサービスの停止

Growiサービス停止前確認

systemctl status growi.service

active(running)を確認します。

Growiサービス停止

sudo systemctl stop growi.service

Growiサービス停止後確認

systemctl stop growi.service

inactive(dead)を確認します。

Growiディレクトリの退避

ディレクトリ退避

筆者環境は/home/www-data/growiです。

sudo mv /home/www-data/growi /path/to/backup/directory/growi_org

ディレクトリ退避確認

ls -l /path/to/backup/directory/growi_org

ファイル一覧が参照できることを確認します。

Growiデータの新規取得

git clone

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

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

ディレクトリ移動

cd /home/www-data/growi && pwd

先ほどcloneしたディレクトリですが、退避前のディレクトリと同じことを確認します。

Growi v7.1.0をチェックアウト

チェックアウト

sudo git checkout -b v7.1.0 refs/tags/v7.1.0

lfs pull

sudo git lfs pull

pnpmパッケージのインストール

npm install

sudo npm install -g pnpm

インストール確認

pnpm --version

9.12.3を確認(2024/11/02現在)

Growiインストール

lfs pull

sudo git lfs pull

pnpmインストール

sudo pnpm install

※ マシンスペックによっては相当時間がかかります
※ Done in 【時間】と書かれていたらアップグレード完了です

ビルド

sudo npm run app:build

退避させたGrowiから起動スクリプトのコピー

筆者のように、起動スクリプトをGrowiのインストールディレクトリに仕込んでいる場合の手順です。

スクリプトコピー

sudo cp -pi /path/to/backup/directory/growi_org/growi-start.sh /home/www-data/growi/

それぞれ、バックアップしたディレクトリとcloneしたディレクトリです。

コピー確認

ls -l /home/www-data/growi/growi-start.sh

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

growiサービスを起動します。

再開前のステータス確認

systemctl status growi.service

inactive (dead)を確認します

サービス再起動

sudo systemctl start growi.service

※ 完全に起動していないと、アクセスしても503エラーが発生します。

再開後のステータス確認

systemctl status growi.service
サービススクリプトを[growi]にしている場合

active (running)を確認します

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

ブラウザから設定したgrowiのドメイン/IPにアクセスします。
画面下部にあるバージョンが7.1.0であることを確認します。

Growiで全文検索できないときの対処(ElasticSearchに伴うプラグインアップデート)

概要

サーバのパッケージアップデート後、Growiで全文検索ができない現象が発生しました。

状況確認

elasticsearch状況確認

systemctl status elasticsearch.service

状況確認結果

 
● elasticsearch.service - Elasticsearch
     Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2023-08-09 20:32:57 JST; 12min ago
       Docs: https://www.elastic.co
    Process: 992 ExecStart=/usr/share/elasticsearch/bin/systemd-entrypoint -p ${PID_DIR}/elasticsearch.pid --quiet (code=exited, status=1/FAI>
   Main PID: 992 (code=exited, status=1/FAILURE)

 8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]:         at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:1>
 8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]:         at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAware>
 8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]:         at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:11>
 8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]:         at org.elasticsearch.cli.Command.main(Command.java:77)
 8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]:         at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:125)
 8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]:         at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:80)
 8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]: For complete error details, refer to the log at /var/log/elasticsearch/elasticsea>
 8月 09 20:32:57 chisato.lyco.reco systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE
 8月 09 20:32:57 chisato.lyco.reco systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
 8月 09 20:32:57 chisato.lyco.reco systemd[1]: Failed to start Elasticsearch.
lines 1-17/17 (END)

→ ElasticSearchがうまく稼働していない事象を確認。

原因調査

ElasticSearchのログ確認

sudo tail -50 /var/log/elasticsearch/elasticsearch.log

ログ抜粋

[2023-08-09T20:32:56,947][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [chisato.lyco.reco] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalArgumentException: Plugin [analysis-icu] was built for Elasticsearch version 7.17.10 but version 7.17.12 is running
        at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:173) ~[elasticsearch-7.17.12.jar:7.17.12]

と、パッケージ更新時にElasticSearchが上がったのに、その中のプラグインが対応していないためこの事象が発生です。

対処

入っていたプラグインをアンインストール
最新バージョンのプラグインを再インストール
プラグイン再インストール後に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起動

sudo systemctl restart elasticsearch.service

環境によってはサービス起動まで時間が掛かります

ElasticSearch起動確認

systemctl status elasticsearch.service

● elasticsearch.service - Elasticsearch
     Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2023-08-09 20:53:39 JST; 27s ago
       Docs: https://www.elastic.co
   Main PID: 2930 (java)
      Tasks: 93 (limit: 9152)
     Memory: 786.6M
     CGroup: /system.slice/elasticsearch.service
             ├─2930 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.tt>
             └─3114 /usr/share/elasticsearch/modules/x-pack-ml/platform/linux-x86_64/bin/controller

 8月 09 20:53:14 chisato.lyco.reco systemd[1]: Starting Elasticsearch...
 8月 09 20:53:39 chisato.lyco.reco systemd[1]: Started Elasticsearch.

起動を確認。

Growiで事象の解消確認

Growiアプリにブラウザでアクセスします。
管理者権限でログインします。
設定＞Elasticsearch管理を進み、以下のように接続されていればOKです。

growiのバージョンアップ/ダウングレード手順。(v7.1.0未対応)

概要

Wikiツールとして有効に利用しているgrowi。そのバージョンアップ及びダウングレード方法のメモです。

※これは、単にgitのみの手順です。他にシステム要件(他のミドルウェアのバージョンアップや切り戻しなど）がある場合は、それも合わせて実施することを注記いたします。

前提

既にgrowiをインストールしていること。
systemdによってサービス化されていること。
最新版や安定版がリリースされていることを以下のサイトで確認していること。
- https://github.com/weseek/growi/releases

※備考

本手順はv7.1.0には未対応です。

手順

さっくりとした手順

growiのサービスを停止します。
gitコマンドで最新版を引っ張ります。
アップグレードを行います。
growiのサービスを再開します。
アップグレードされたことを確認します。

growiサービスを停止します

growiのステータス確認(停止前)

systemctl status growi.service

※ サービススクリプト名は自分の環境に合わせます。
※ active(running)を確認します

growiのサービス停止

sudo systemctl stop growi.service

growiのステータス確認(停止後)

systemctl status growi.service

inactive (dead)を確認します

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

cd /opt/growi

自分の環境に合わせます。

リリースタグを確認します。

リリースタグ取得

sudo git fetch --tags

リリースタグ確認

sudo git tag -l

スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。

チェックアウトとインストールを行います。

変更を一時的に退避

sudo git stash

チェックアウト

sudo git checkout 【バージョン】

yarn

sudo yarn

※ マシンスペックによっては相当時間がかかります
※ Done in 【時間】と書かれていたらアップグレード完了です

ビルド

sudo yarn app:build

growiサービスを起動します。

再開前のステータス確認

systemctl status growi.service

inactive (dead)を確認します

サービス再起動

sudo systemctl start growi.service

※ 完全に起動していないと、アクセスしても503エラーが発生します。

再開後のステータス確認

systemctl status growi.service
サービススクリプトを[growi]にしている場合

active (running)を確認します

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

ブラウザから設定したgrowiのドメイン/IPにアクセスします。
画面下部にあるバージョンがチェックアウトしたバージョンであることを確認します。

Growi v7.xでページ編集時に空白になる問題に対処(Apache リバースプロキシのWebSocket設定)

事象の内容

Growiのバージョンをv6.3.5→v7.0.11にアップグレード後、既存のページを編集しようとすると編集エリアが空白になってしまう。
新規ページを作成する際に、テンプレートが適用されない。

Wikiとしては致命的な弱点だったため、やむなくv6.3.5に戻したという経緯があります。

ですが、回避策が見つかりましたのでメモとして残します。

事象が発生した環境

Ubuntu 22.04
Apache 2.4
Growi v7.0.11をDockerではなくオンプレ環境で利用。
Apacheによるリバースプロキシを設定

備考

この事象は、以下で回避されました。

Ubuntu 24.04
Apache 2.4
Growi v7.0.23

同一事象をネットで確認。

[7.0.0]データ移行機能を使用した後、記事の編集内容が失われる #8677
- https://github.com/weseek/growi/issues/8677

How to reproduce? (再現手順)

2台のHostPCでそれぞれGrowiを立ち上げています。A環境・B環境と呼称します。

「データ移行」機能を用いて、A環境からB環境にデータをインポートする B環境のGrowiに他のPCからアクセスする記事の編集画面を表示する

What happens? (症状)

記事の編集画面が白紙になっており、そのまま保存しても記事の内容が失われる（添付画面参照）

と、事象が一致。

事象の原因

上記issueのツリーに

私の環境でも編集画面が空白になる現象が観測されました。

私は https-portal を使ってデプロイしているのですが、　growi-docker-compose/examples/https-portal にある WEBSOCKET: 'true' の環境変数を設定し損ねていたのが原因でした。私の環境では、これを設定すると通常通り編集を行えることを確認しております。逆に、コメントアウトすると空白に戻ります。

とあります。

これを原因と断定し、対処に臨みます。

筆者が実施したのはオンプレ（Apacheによるリバースプロキシ）での対処です。

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

現状のgrowiのリバースプロキシの設定を確認。
設定ファイルのバックアップ。
設定ファイルを修正。
修正を反映。
事象の解決確認。

参考にしたURL

How to Reverse Proxy Websockets with Apache 2.4

現段階でのリバースプロキシの設定を確認します。

Apacheのバーチャルファイルを確認

cat /etc/apache2/sites-available/growi.conf

自分の環境に合わせます。

内容の一部抜粋

    # socket.io の path を rewrite する
    RewriteEngine On
    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
    RewriteRule /(.*) ws://localhost:3000/ [P,L]

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

設定そのものはgithubのgrowi公式ドキュメントに沿ったものでしたが、これが引っかかっていたようです。

設定ファイルのバックアップを取ります。

バックアップ

sudo cp -pi /etc/apache2/sites-available/growi.conf /path/to/backup/directory/growi.conf.$(date +%Y%m%d)

ファイル名は自分の環境に合わせます。適宜、任意のバックアップディレクトリを指定します。

バックアップ確認

diff -u /path/to/backup/directory/growi.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi.conf

差分が無いこと（エラーがないこと）でバックアップを確認します。

ファイルを修正します。

上記の設定ファイルを教義・信仰に沿ったエディタで編集します。(要管理者権限)

削除する内容

    # socket.io の path を rewrite する
    RewriteEngine On
    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
    RewriteRule /(.*) ws://localhost:3000/ [P,L]

削除した箇所に追記する内容

     # WebSocketのための設定
     RewriteEngine On
     RewriteCond %{HTTP:Upgrade} =websocket [NC]
     RewriteCond %{HTTP:Connection} upgrade [NC]
     RewriteRule /(.*) ws://localhost:3000/$1 [P,L]

編集後、差分を取ります。

差分確認

diff -u /path/to/backup/directory/growi.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi.conf

差分結果

-    # socket.io の path を rewrite する
-    RewriteEngine On
-    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
-    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
-    RewriteRule /(.*) ws://localhost:3000/ [P,L]
+     # WebSocketのための設定
+     RewriteEngine On
+     RewriteCond %{HTTP:Upgrade} =websocket [NC]
+     RewriteCond %{HTTP:Connection} upgrade [NC]
+     RewriteRule /(.*) ws://localhost:3000/$1 [P,L]

設定を反映します。

構文確認

sudo apache2ctl configtest

Syntax OKを確認します。

Apache再起動前確認

systemctl status apache2.service

active (running)を確認します。

Apache再起動

sudo systemctl restart apache2.service

Apache再起動後確認

systemctl status apache2.service

active (running)を確認します。

事象の解決を確認します。

上記、設定を行ったGrowiサイトにアクセスします。

編集後、左ペイン（エディタ部分）がそのまま残っていれば対処完了です。

Ubuntu 20.04 / nginx環境でgrowiをv6.x→v7.0.xにアップグレード。(nginxリバースプロキシのWebSocket設定)

概要

長らくUbuntu 20.04で動かしているgrowi。こちらもv7.0.xにアップグレードできることを確認しました。

Apacheと同様、nginx環境でも、WebSocketを適切に設定する必要がありました。

環境

Ubuntu 20.04
Growi v6.3.5
非Dockerのオンプレ環境
nginx（この手順に則ってgrowi v6をnginxのリバースプロキシで動かしていました）。

さっくりとした手順

nodeのアップグレードを行います。
growiサービスを停止します。
growiのバージョンアップを行います。
growiサービスを再開します。
nginxのリバースプロキシ設定を書き換え、nginxサービスの再起動を行います。
バージョンアップを行います。

nodeのアップグレード

node -v

v18.16.0はGrowi7系の対象外だったので、nodeを最新安定版に変えるところからスタートします。

n packageのインストール

sudo npm install -g n

nでnode 20系の安定版をインストール

sudo n --stable

バージョンアップ確認

node -v

20.15.0を確認します。

growiのアップグレード前のサービス停止

growiのステータス確認(停止前)

systemctl status growi.service

※ サービススクリプト名は自分の環境に合わせます。
※ active(running)を確認します

growiのサービス停止

sudo systemctl stop growi.service

growiのステータス確認(停止後)

systemctl status growi.service

inactive (dead)を確認します

growiのアップグレード

growiディレクトリの移動

cd /opt/growi

自分の環境に合わせます。

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

sudo aptitude install git-lfs

git-lfsを入れないとclone/build時に画像が表示されません。

lfs -pull

sudo git lfs pull

リリースタグ取得

sudo git fetch --tags

リリースタグ確認

sudo git tag -l

2024/06/30現在のv7系最新版、v7.0.11があることを確認しました。

gitのバージョンを一時的に退避

sudo git stash

チェックアウト

sudo git checkout 【バージョン】

上述した通り、v7.0.11を入力しました。

yarn

sudo yarn

v6.xよりも時間がかかります。

アプリのビルド

sudo yarn app:build

こちらも時間がかかります。

アップグレード後のgrowiサービス開始

再開前のステータス確認

systemctl status growi.service

inactive (dead)を確認します

サービス再起動

sudo systemctl start growi.service

再開後のステータス確認

systemctl status growi.service
サービススクリプトを[growi]にしている場合

active (running)を確認します

nginxのバーチャルファイルを編集

v7.xは、WebSocketによる通信設定を正常に行わないと既存ドキュメントの編集ができません。（編集画面が空白になります）

そのため、nginxの設定を見直します。

既存のgrowiバーチャルファイルを退避

sudo mv /etc/nginx/sites-available/growi.conf /path/to/backup/directory/growi.conf.$(date +%Y%m%d)

大幅に変更する必要があるため、cpではなくmvします。

新規の設定ファイルを作成

【】内を自分の環境に合わせます。

cat <<- __EOF__ | sudo tee -a /etc/nginx/sites-available/growi.conf
upstream growi {
       server 【growiのIPアドレス】:3000;
}

server {
        listen 80;
        server_name 【サーバ名】;
        server_tokens off;
        return  301 https://$host$request_uri;
        access_log 【growiのアクセスログのフルパス】;
        error_log 【growiのエラーログのフルパス】 warn;
}

map $http_upgrade $connection_upgrade {
    default Upgrade;
    ''      close;
}

server {
        listen 443 ssl;
        server_name 【サーバ名】;
        server_tokens off;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;
        ssl_dhparam /etc/nginx/dhparam.pem;
        ssl_ciphers 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;
        ssl_prefer_server_ciphers off;
        add_header Strict-Transport-Security 'max-age=63072000';


        ssl_certificate 【サーバ証明書のフルパス】;
        ssl_certificate_key 【サーバ秘密鍵のフルパス】;

        access_log 【growiのSSLアクセスログのフルパス】;
        error_log 【growiのSSLエラーログのフルパス】 warn;


    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://growi;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 900s;
    }
}

__EOF__

こちらの設定ファイルはGrowiの公式ドキュメントに沿ったものです。

nginxの構文チェック

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

を確認します。

nginx再起動

sudo systemctl restart nginx.service

バージョンアップ確認

設定したgrowiのサイトにアクセスします。
チェックアウトしたバージョンであることを確認します。
既存のページにアクセスし、編集できること（編集画面が白くならないこと）を確認します。

Growi v7.1.xのアップグレード手順

概要

V7.1.xからパッケージ管理がyarnではなくmnpmに変更されました。

その手順に合わせたメモです。

前提

既にgrowiをインストールしていること。
systemdによってサービス化されていること。
最新版や安定版がリリースされていることを以下のサイトで確認していること。
- https://github.com/weseek/growi/releases

※備考

v7.0.x以前はyarnを用います。

手順

さっくりとした手順

growiのサービスを停止します。
gitコマンドで最新版を引っ張ります。
アップグレードを行います。
growiのサービスを再開します。
アップグレードされたことを確認します。

growiサービスを停止します

growiのステータス確認(停止前)

systemctl status growi.service

※ サービススクリプト名は自分の環境に合わせます。
※ active(running)を確認します

growiのサービス停止

sudo systemctl stop growi.service

growiのステータス確認(停止後)

systemctl status growi.service

inactive (dead)を確認します

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

cd /opt/growi

自分の環境に合わせます。

リリースタグを確認します。

リリースタグ取得

sudo git fetch --tags

リリースタグ確認

sudo git tag -l

スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。

チェックアウトとインストールを行います。

変更を一時的に退避

sudo git stash

チェックアウト

sudo git checkout 【バージョン】

pnpm install

sudo pnpm install

ビルド

sudo npm run app:build

growiサービスを起動します。

再開前のステータス確認

systemctl status growi.service

inactive (dead)を確認します

サービス再起動

sudo systemctl start growi.service

※ 完全に起動していないと、アクセスしても503エラーが発生します。

再開後のステータス確認

systemctl status growi.service
サービススクリプトを[growi]にしている場合

active (running)を確認します

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

ブラウザから設定したgrowiのドメイン/IPにアクセスします。
画面下部にあるバージョンがチェックアウトしたバージョンであることを確認します。