カテゴリー: PC Page 10 of 50

Growi v7でページ編集時に空白になる問題に対処(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によるリバースプロキシを設定

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

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' の環境変数を設定し損ねていたのが原因でした。
私の環境では、これを設定すると通常通り編集を行えることを確認しております。逆に、コメントアウトすると空白に戻ります。

とあります。

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

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

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

参考にした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サイトにアクセスします。

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

Nextcloud29.03へのアップグレード後の警告解消。(テーブルにインデックス追加)

概要

Nextcloudを29.0.3にアップデート後、以下の警告を確認しました。

データベースにいくつかのインデックスがありません。 大きなテーブルにインデックスを追加すると、自動的に追加されないまでに時間がかかる可能性があるためです。 "occ db:add-missing-indices"を実行することによって、インスタンスが実行し続けている間にそれらの欠けているインデックスを手動で追加することができます。 インデックスが追加されると、それらのテーブルへのクエリは通常はるかに速くなります。 オプションのインデックス "schedulobj_lastmodified_idx" がテーブル "schedulingobjects"にありません

こちらに対応します。

環境

  • Ubuntu 20.04
  • PHP8.1
  • Nextcloud 29.0.3 (29.0.2からアップデート)

また、nextcloudの実行ユーザーはwww-dataです。

Nextcloudのディレクトリに移動します。

  • ディレクトリ移動
cd /var/www/html/nextcloud && pwd

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

occを実行します。

  • 指示されたコマンドを実行
sudo -u www-data php occ db:add-missing-indices
  • 出力結果
Adding additional schedulobj_lastmodified_idx index to the oc_schedulingobjects table, this can take some time...
oc_schedulingobjects table updated successfully.

警告の解消を確認します。

  1. 上記の措置を執ったNextcloudのサイトに管理者権限でログインします。
  2. 管理>概要に進みます。
  3. 警告が消えていることを確認します。

解消方法がある程度示されているので、Nextcloudは親切です。

Growiバージョンアップ時の問題点と切り戻しでハマったこと。(nodeとturboのバージョンダウン)

Growiのバージョンをv6.3.5 → v7.0.10に変えたところ、以下のデグレを自分の環境で確認しました。

  1. 編集したページを再度編集しようとすると空白になる。
    • 再々編集した場合でも消える場合がある。
  2. 新しいページを作ったときにテンプレートが適用されない。

Wikiとしてこの2つは致命的なので、v6.3.5に切り戻しを行いましたが、ダウングレードできない事象が発生しました。

以下、その対処記録です。

環境

  • Ubuntu 22.04
  • Dockerではなくオンプレ環境で稼働
  • Growi v7.0.10→v6.3.5に切り戻しをしましたが、yarnの途中で失敗しました。

その途中で確認したこと

  1. v7.0.1へのセットアップ後、aptでnodeのバージョンが上がっていたことにより、v6.3.xの対象外になっていました。(18→19)
  2. v7.xへのセットアップ時、それにつれてturboのバージョンも上がっていました。

問題はこの2つにあると仮定して、これらのバージョンダウンを行っていきます。

対処

  • バージョン管理のためにnをインストール
sudo npm install -g n
  • インストール可能なnodeバージョンを確認
n ls-remote --all

→ 18系の最新版18.20.3をインスト-ルします

  • nでバージョンを指定してインストール
sudo n 18.20.3
  • バージョン確認
node -v

v18.20.3を確認

  • turboのバージョンを戻す
sudo yarn update turbo@1.12.2

この後、以下の手順でv7.0.10→v6.3.5へバージョンダウンを行えました。

https://barrel.reisalin.com/books/growi/page/growi

Webアプリはミドルウェアとの兼ね合いでハマることが多いんで注意です。

growiのプラグイン追加。

growiはv6以降よりプラグインを簡単にインストールできる機能が備わっています。

今回、それを用いてテーブル(表)の視認性を向上させました。

growiに管理者権限でログイン後、プラグインインストーラーで

https://github.com/weseek/growi-plugin-datatables

を入力後に「インストール」。インストール後、念のため、growiを再起動します。

導入後、任意のWikiページのテーブルに「Enable Data Table」ボタンが表示されるので、こちらをクリック。

  • 検索欄
  • 列の表示/非表示
  • 並べ替え

などが表示され、

細かい表示もしやすくなっています。

思った以上にかゆいところに手が届く機能なので、growiを使っている方にはおすすめです。

apacheで特定のユーザーエージェントからのアクセスを拒否。

概要

自分のサーバのアクセスログを見たら

"GET /picture.php?/6797/category/73 HTTP/1.1" 200 14394 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"

と、クローラーが大量にアクセスしてきました。robots.txtも意に介さない悪名高いbotのようなので、このアクセスを、サーバで拒否します。

環境

  • Ubuntu 20.04
  • Apache 2.4 (aptでインストールしたため、ディレクトリは/etc/apache2配下にあります。

また、バーチャルサイトによる複数のサイトを運用しているので、そのうちの1つだけを弾きます。

さっくりとした手順

  1. Apacheのバーチャルサイトの設定ファイルのバックアップを取ります。
  2. 設定ファイルを追記します。
  3. 設定を反映します。
  4. 拒否されていることを確認します。

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

  • ディレクトリ移動
cd /etc/apache2/sites-available && pwd
  • ファイルバックアップ
sudo cp -pi hoge.conf /path/to/backup/directory/hoge.conf.$(date +%Y%m%d)

設定を行いたい自分の設定ファイルを、任意のバックアップディレクトリにバックアップします。

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

差分が無ければ(エラーがなければ)バックアップは成功です。

設定ファイル追記

上述した設定ファイルを教義・進行に則ったエディタで編集します。(要管理者権限)

  • 追記例
    DocumentRoot /var/www/html/hoge
    <Directory /var/www/html/hoge>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
     ## GoogleBOTを拒否(正常bot不正bot両方拒否)
     SetEnvIfNoCase User-Agent "Googlebot" bot
     ## Facebookのクローラーを拒否
     SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" fb_bot
     <RequireAll>
      Require all granted
      Require not env bot
      Require not env fb_bot
     </RequireAll>

/var/www/html/hogeは自分の環境に合わせます。

※ついでにGoogleBOTも拒否します。

  • 差分確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf
  • 差分例
-        Require all granted
+     ## GoogleBOTを拒否(正常bot不正bot両方拒否)
+     SetEnvIfNoCase User-Agent "Googlebot" bot
+     ## Facebookのクローラーを拒否
+     SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" fb_bot
+     <RequireAll>
+      Require all granted
+      Require not env bot
+      Require not env fb_bot
+     </RequireAll>

設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動確認
systemctl status apache2.service

active(running)を確認します。

設定反映確認

設定を行ったアクセスログを開きます。

403 3772 "-" "facebookexternalhit/1.1 

のように、ステータスコードが「403」になっていれば、アクセス拒否されています。

思考中、思考中。(piwigoとmatomoの連携)

やりたいこと

フォトアルバムシステム、piwigoをシステム解析システム、matomoに置きたいのですが、どうもうまくいかず。

「ここまでやった」というメモのために残します。

前提

  • 自前でアクセス解析:matomoとフォトアルバム:piwigoをインストール済み。
  • 両者はそれぞれインターネット通信が可能。(相互に見えている)

やったこと

piwigoサイトに管理者権限でログインし、Add< head > Elementをインストールします。

有効にして、設定します。

エレメントの所に、matomoで提示されたトラッキングコードを埋め込みます。

結果

piwigo側のサイトのソース表示で、matomoのトラッキングコードが表示されることを確認しました。

ですが、その後、何回かアクセスを繰り返しているにもかかわらずうまくカウントされません。

  • wordpress : プラグインにより連携可能
  • redmine: view customize pluginで設定可能

まで行いましたが、うまい手は見つからず。

状況を見ながらもう少し続けてみます。

Nextcloud・アプリログのローテーション。

apache/nginxなどと連携した場合のアクセスログではなく、アプリそのもののログローテーションです。

ログの位置

/path/to/nextcloud/directory/data

例えば、 `/var/www/html/nextloud/data`などを示します。

ローテーションファイル

  • /etc/logrotate.d/nextcloud2

を、協議・進行に沿ったエディタを用いて以下のように作成します。

/var/www/html/nextcloud/data/*.log {
    daily
    dateext
    dateformat -%Y%m%d
    rotate 10
    missingok
    notifempty
    su www-data www-data
    create 640 www-data www-data
    sharedscripts
    compress
    delaycompress
        postrotate
                if invoke-rc.d apache2 status > /dev/null 2>&1; then \
                invoke-rc.d apache2 reload > /dev/null 2>&1; \
                 fi;
        endscript
}

ログの位置やローテーションサイクルなどは自分の環境に合わせてください。

sudo logrotate -v /etc/logrotate.d/nextcloud2

でエラーがなければ、アプロログのローテーションは完了です。

Redmine5.1のdmsfプラグインの脆弱性対応。(プラグインアップグレード)

概要

Redmineの文書管理プラグイン、dmsfに脆弱性が発表されたので、その対応を行います。

脆弱性概要

https://jvndb.jvn.jp/ja/contents/2024/JVNDB-2024-000055.html

当該プラグインを有効にしている場合、Redmineにログインしているユーザーによって、Redmineの実行権限で可能な範囲で、サーバー上の任意のファイルを取得されたり削除されたりする可能性があります。

脆弱性対象

バージョン3.1.4より前のバージョン

筆者環境

  • Ubuntu 22.04
  • Apache2.4
  • MySQL 8.0.3
  • Redmine 5.1
  • dmsf 3.1.3

注意事項

脆弱性に対応したバージョンは、2024年5月現在、Redmine 4.2には対応していません。

筆者のようにRedmine 4.2を単独ユーザーで運用していない限りは、以下のオプションを強く推奨します。

  • Redmine及びOS全体のバージョンアップを図る。
  • 本プラグインを無効化する。

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

  1. DBのバックアップ
  2. Webサービス停止
  3. 既存プラグインディレクトリの退避
  4. git cloneによるプラグイン入手
  5. DBマイグレーション
  6. Webサービス起動
  7. プラグインアップグレード確認

DBのバックアップを行います。

  • 作業用ディレクトリに移動
cd /hoge && pwd

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

  • DBのバックアップ取得
 mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql
  1. -u ユーザ オプション db名です。自分の環境に合わせます。
  2. パスワードはDBのユーザパスワードです。

Apacheの停止を行います。

※ 利用者への注意喚起も行ってください。

  • 停止前のステータス確認
systemctl status apache2.service

active (running)を確認します。

  • Apache停止
sudo systemctl stop apache2.service
  • 停止後のステータス確認
systemctl status apache2.service

inactive (dead)を確認します。

既存プラグインを退避します。

  • redmineプラグインディレクトリに移動
cd /redmine/root/directory/plugins && pwd

ディレクトリは自分の環境に合わせます。

  • dmsfプラグイン退避
sudo mv redmine_dmsf /path/to/backup/directory/redmine_dmsf.$(date +%Y%m%d)

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

  • dmsfプラグイン退避確認
ls -ld /path/to/backup/directory/redmine_dmsf.$(date +%Y%m%d)

ディレクトリがあることを確認します。

プラグインをgit cloneします。

  • git clone
sudo -u www-data git clone -b v3.1.4 https://github.com/danmunn/redmine_dmsf

脆弱性に対応したv3.1.4を指定します。

  • clone確認
ls -ld redmine_dmsf

ディレクトリがあることを確認します。

プラグインのアップグレードを行います。

  • Redmineのルートディレクトリに移動
cd /redmine/root/directory && pwd

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

  • bundle install
sudo -u www-data bundle install
  • DBマイグレーション
sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production

Webサービスを再開します。

  • 再開前のステータス確認
systemctl status apache2.service

inactive (dead)を確認します。

  • Apache再開
sudo systemctl start apache2.service
  • 停止後のステータス確認
systemctl status apache2.service

active (running)を確認します。

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

  1. Redmineに管理者権限でログインします。
  2. 管理>プラグインに進みます。
  3. DMSFプラグインが3.1.4になっていることを確認します。
  4. 既存の動作(チケットの発行/編集など)に問題が無いことを確認します。

おまけ:切り戻し手順

このプラグイン、アップグレードの失敗や手順ミスで軽くRedmine全体が機能不全に陥ります。そのため、切り戻し手順を記しておきます。

通常の切り戻し

ディレクトリ移動

  • Redmineのルートディレクトリに移動
cd /redmine/root/directory && pwd

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

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

sudo -u www-data rake redmine:plugins:migrate NAME=redmine_dmsf VERSION=0 RAILS_ENV=production

ディレクトリ削除

sudo rm plugins/redmine_dmsf -Rf

Webサービス再起動

sudo systemctl restart apache2.service

それでもダメだった切り戻し(DBリストア)

cd /hoge
# mysqldumpを行ったディレクトリ

mysql -h localhost -u redmine -p redmine < redmine_backup.$(date +%Y%m%d).sql
# パスワードはredmineインストール時に設定したDBユーザのものです

sudo systemctl restart apache2.service

UbuntuサーバのSwap処理頻度を変更。

Ubuntuサーバを運用中、実メモリに余裕があるにもかかわらずスワップアウトが出ている事象を確認。

これを変更してみます。

環境

  • Ubuntu 20.04
  • メモリ4GB
  • スワップ6GB

事象と設定変更

現状確認

  • メモリ使用量の確認
free -h
  • 自分の環境の確認
              total        used        free      shared  buff/cache   available
Mem:          3.8Gi       1.8Gi       694Mi       176Mi       1.3Gi       1.6Gi
Swap:         6.0Gi       6.0Mi       6.0Gi
  • swappiness確認
cat /proc/sys/vm/swappiness

60を確認しました。

設定変更

sudo cp -pi /etc/sysctl.conf /path/to/backup/directory/systtl.conf.$(date +%Y%m%d)

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

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

差分がなければ(エラーなく実行できれば)バックアップ成功です。

  • sedによるファイル追記
sudo sed -i '$ a\vm.swappiness = 10' /etc/sysctl.conf

上記の参考サイトを元に、swappinessを10に指定します

  • 設定変更確認
diff -u /path/to/backup/directory/systtl.conf.$(date +%Y%m%d) /etc/sysctl.conf
  • 差分
+vm.swappiness = 10
  • 設定反映
sudo sysctl -p

vm.swappiness = 10と結果が返ってくることを確認します。

設定反映確認

cat /proc/sys/vm/swappiness

10に変更されていることを確認します。

まずはこの値で様子を見てみようと思います。

Redmineのプラグインをインストールするときに使うコマンド

概要

Redmineのプラグインを導入する際の基本的な手順をメモしておきます。

前提

こちらは筆者のメイン環境です。各自、自分の環境に合わせてください。

  • 既にRedmineがインストールされている状態
  • Ubuntu系OS
  • WebサーバとしてApache2を利用
  • Ruby on RailsでApacheと連携
  • RedmineはApacheの実行ユーザ(www-data)

インストールの基本

  1. A.プラグインを/redmine/root/directory/plugins配下に設置(必須)
  2. B.依存関係があるrubyプログラムをインストール(オプション)
  3. C.DBマイグレーション(オプション)
  4. D.Webサービス再起動(必須)
  5. E:動作確認(必須)

A-1:Zipファイルをダウンロードする場合の手順

A-1.1:作業用ディレクトリに移動します。

cd /hoge

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

A-1.2:ZIPファイルを入手します。

  • curl
  • wget
  • scpなどで転送
  • デスクトップを兼ねている場合はダウンロード

など、任意の手を用います。

A-1.3:ファイルを解凍します。

unzip plugin.zip

A-1.4:解凍されたファイル群のディレクトリの所有者を変更します。

sudo chown -R www-data:www-data plugin-hoge

バージョン番号が付与されているパターンが多いです

A-1.5:Redmineのプラグインディレクトリに配置します。

sudo mv plugin-hoge /redmine/root/directory/plugins/plugin

配置する際に、バージョン名などを消しておきます。

→ ここを行ったらB以降に進みます。


A-2:git cloneする場合の手順

A-2.1:Redmineのプラグインディレクトリに移動します。

cd /redmine/root/directory/plugins && pwd

自分の環境に合わせます。 (例:/var/lib/redmine)
筆者環境は/home/www-data/redmineです

A-2.2:git cloneを行います。

sudo -u www-data git clone git_repository 

大概はgithubのURLをそのまま(https://込み)です。

→ ここを行ったらB以降に進みます。


B: 依存関係があるrubyプログラムをインストールする場合の手順(オプション)

B-1: redmineのrootディレクトリに移動します。

cd /redmine/root/directory/ && pwd

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

B-2. Bundle installを行います。

sudo -u www-data bundle install

Bundle complete!と出たらOKです。

→ ここを行ったらC以降に進みます。


B-1: redmineのrootディレクトリに移動します。

cd /redmine/root/directory/ && pwd

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

C: DBマイグレーションを行う場合の手順(オプション)

C-1: redmineのrootディレクトリに移動します。

cd /redmine/root/directory/ && pwd

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

C-2: DBのマイグレーションを行います。

sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production

エラーが出てこなければOKです。

→ ここを行ったらD以降に進みます。


D:Webサービスの再起動

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

active (running)を確認します。


E: 動作確認

  1. Redmineに管理者権限でログインします。
  2. 管理>プラグインに進みます。
  3. インストールしたプラグインがあることを確認します。
  4. 他の機能が動くことを確認します。

Page 10 of 50

Powered by WordPress & Theme by Anders Norén