タグ: Linux Page 1 of 18

Redmineの文字色変更を容易にするプラグイン導入(Redmine_wiki_text_colorizer)

概要

RedmineはMarkdwon準拠なので、タグによる文字色の変更が可能。

とはいえ、色指定や範囲が結構面倒です。それを解消するプラグインを導入します。

redmine_wiki_text_colorizer

動作確認環境

  • Ubuntu 22.04
  • Redmine 5.1
  • Apacheで稼働(実行ユーザはwww-data)

導入手順

例によって、SSH(または直接ターミナルに入っての)導入です。

ディレクトリ移動

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

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

プラグイン導入

  • git clone
 sudo -u www-data git clone https://github.com/sk-ys/redmine_wiki_text_colorizer
  • clone確認
ls -ld redmine_wiki_text_colorizer

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

  • apache(webサービス再起動)
sudo systemctl restart apache2.service

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

導入後の確認

Wiki、チケットやコメントの編集画面を表示します。

Wiki編集画面に、「A」のアイコンが2つ並んでいるボタンが追加されます。

文字を選択した後、このボタンを押すと文字色のパレットが表示されます。

任意の色を選ぶと、

選択した箇所がタグで囲まれます。(それと同時にボタンの色が選んだ文字色になります)

プレビュー/保存などで文字色が変わっていれば導入できています。

BookStack マークダウンエディタのチートシート(ショートカット)。

BookStackで記事を編集中、適当にキーボードを操作していたら、見出しが自動的に入ったので調べてみました。

https://www.bookstackapp.com/docs/user/markdown-editor

ショートカット一覧

ショートカット説明備考
Ctrl + S下書きを保存投稿して公開は下の機能を使います
Ctrl + Enterページを保存して公開
Ctrl + 1見出し(h2)## が入ります
Ctrl + 2見出し(h3)### が入ります
Ctrl + 3見出し(h4)#### が入ります
Ctrl + 4見出し(h5)##### が入ります
Ctrl + 5段落いわゆる\<p>です
Ctrl + 6段落いわゆる\<p>です
Ctrl + 7コードブロック```~```が入ります
Ctrl + Eコードブロック```~```が入ります
Ctrl + 8インラインコード`~`が入ります
Ctrl +O番号付きのリスト1. が入ります
Ctrl + P箇条書きリスト- が入ります
Ctrl + Kリンク挿入[]()が入ります
Ctrl + Shift + KBookStack内のリンク挿入ページ一覧がモーダル表示されます
Ctrl + Shift + IURL経由での画像挿入![](http://)が入ります

※Macを利用する方はCtrlをCommandに読み替えてください。

これらのショートカット、非常に便利。特に見出しとコードをシームレスに入力できるのは大きなアドバンテージでした。

Ubuntu 20.04のOpenSSLのEOL対応並びにOpenSSHの脆弱性対応

概要

  • Ubuntu 20.04をインターネットに公開している
  • 諸々の事情で22.04にアップグレードできない
  • 2023/09/11にサポート終了となったOpenSSLの1.1.1をアップグレードしたい。
  • OpenSSHの脆弱性、CVE-2024-6387 の対応を行いたい

方を対象としています。

参考環境

OS:Ubuntu 20.04

  • OpenSSLのバージョン確認
openssl version -a
OpenSSL 1.1.1f  31 Mar 2020
built on: Wed May 24 17:14:51 2023 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-mSG92N/openssl-1.1.1f=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific
  • OpenSSHのバージョン確認
ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.9, OpenSSL 1.1.1f  31 Mar 2020

参考とした手順

実施する前の留意点

  • コピペだけで済むように、エディタを使わない手順にしています。
  • 実際に筆者が実施した手順をそのまま載せています。typo等はご容赦ください。
  • 作業影響が極めて大きいため、作業時間の見積や日時調整は迅速かつ丁寧に行ってください。
    • 特にmake / make testは思っている以上に時間がかかります。
  • この手順では、sslのパスが変わります。同一サーバ内の他のプログラムがsslを参照している場合は、特に注意してください。

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

  1. システム全体のバックアップ
  2. 【OpenSSL】必要なライブラリをインストールします。
  3. 【OpenSSL】githubレポジトリから最新安定版のソースコードをダウンロードします。
  4. 【OpenSSL】ソースからインストールしていきます。
  5. 【OpenSSL】設定を行います。(コンフィグを反映させ、パスを通します)
  6. 【OpenSSL】バージョンアップを確認します。
  7. 【OpenSSL】自動アップデートを無効化します。
  8. システム全体の再起動を行います。(1回目)
  9. 【OpenSSH】コンフィグに必要なディレクトリの作成を行います。
  10. 【OpenSSH】インストールに必要なパッケージをインストールします。
  11. 【OpenSSH】作業用ディレクトリに移動します。
  12. 【OpenSSH】ソースをダウンロードします。
  13. 【OpenSSH】OpenSSHをソースからビルドします。
  14. システム全体の再起動を行います。(2回目)
  15. 【OpenSSH】バージョンアップを確認します。

実施した手順

全体のバックアップを取得します。

任意の方法でシステム全体のバックアップを取ります。とはいえ、EOL/脆弱性対応のため切り戻しは基本的に許されません。

必要なライブラリのインストール

sudo aptitude install build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev libkrb5-dev checkinstall zlib1g-dev git

aptitudeを用いています。必要に応じてaptを使ってください。

【OpenSSL】root昇格

OpenSSLをソースコードからコンパイルしてインストールする一連の作業は管理者権限で実行します。

sudo su -

【OpenSSL】ソースコードの取得

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

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

  • git clone
git clone https://github.com/openssl/openssl -b openssl-3.3.1

2024/07/03現在の最新版をダウンロードします。

※root昇格済みなのでsudoが不要であることにご注意ください

  • ディレクトリ移動
cd openssl

【OpenSSL】ソースからインストール

  • コンフィグ
./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlib
  • コンフィグ成功時の出力
Configuring OpenSSL version 3.3.1 for target linux-x86_64
Using os-specific seed configuration
Created configdata.pm
Running configdata.pm
Created Makefile.in
Created Makefile
Created include/openssl/configuration.h

**********************************************************************
***                                                                ***
***   OpenSSL has been successfully configured                     ***
***                                                                ***
***   If you encounter a problem while building, please open an    ***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:           ***
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL.md file first)      ***
***                                                                ***
**********************************************************************
  • make
make

makeは時間がかかります。状況を時折確認しながら待ちましょう。

  • 整合性確認
make test

make 同様に時間がかかります。

  • インストール
make install

【OpenSSL】インストール後の設定

  • 設定ファイル追記
cat <<- __EOF__ | tee -a /etc/ld.so.conf.d/openssl-3.3.1.conf
/usr/local/ssl/lib64
__EOF__
  • 設定反映
ldconfig -v
  • 既存プログラムの退避
mv /usr/bin/c_rehash /path/to/backup/c_rehash.$(date +%Y%m%d)

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

mv /usr/bin/openssl /path/to/backup/openssl.$(date +%Y%m%d)

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

  • パスを通す
cat <<- __EOF__ | tee -a /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/ssl/bin"
__EOF__
  • 通したパスを反映
source /etc/environment
  • パス確認
echo $PATH

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/ssl/bin"

と表示されることを確認します

【OpenSSL】バージョンアップ後の確認

openssl version -a
OpenSSL 3.3.1 4 Jun 2024 (Library: OpenSSL 3.3.1 4 Jun 2024)
built on: Wed Jul  3 02:04:25 2024 UTC
platform: linux-x86_64
options:  bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/ssl/lib64/engines-3"
MODULESDIR: "/usr/local/ssl/lib64/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0xfffa3203578bffff:0x7a9

これで、Ubuntu20.04でもOpenSSL3.3.1を利用することが可能になりました。

システム全体の再起動(1回目)

  • システムの再起動を行います。
sudo reboot

【OpenSSL】自動アップグレード無効

強制的に3.3系に上げるので、その後、1.1.xがアップグレードされる可能性を防ぎます。

  • apt を使用する場合
sudo apt-mark hold openssl
  • aptitude を使用する場合
sudo aptitude hold openssl

これに続けて、CVE-2024-6387の対応を行います。

【OpenSSH】ディレクトリ作成と設定

sudo mkdir /var/lib/sshd && sudo chmod -R 700 /var/lib/sshd/ && sudo chown -R root:sys /var/lib/sshd/

【OpenSSH】作業用ディレクトリ移動

cd /hoge && pwd

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

【OpenSSH】ソースのダウンロードと展開

  • ソース取得
wget -c http://mirror.exonetric.net/pub/OpenBSD/OpenSSH/portable/openssh-9.8p1.tar.gz

上記CVEの脆弱性に対応したバージョンを用います。

  • ソース展開
tar -xzf openssh-9.8p1.tar.gz
  • ディレクトリ移動
cd openssh-9.8p1

【OpenSSH】展開したソースコードをインストール

  • OpenSSLの位置を確認
which openssl
  • 結果確認
/usr/local/ssl/bin/openssl

本手順でSSLのバージョンアップを行った場合の環境となります。

  • コンフィグ
./configure --with-kerberos5 --with-md5-passwords --with-pam --with-selinux --with-privsep-path=/var/lib/sshd/ --sysconfdir=/etc/ssh --with-ssl-dir=/usr/local/ssl

--with-ssl-dir=/usr/local/sslは、opensslがあるディレクトリを指定します。

  • make
make
  • インストール
sudo make install

システム全体の再起動(2回目)

  • システムの再起動を行います。
sudo reboot

【OpenSSH】バージョンアップ確認

  • バージョン確認

この時点でSSH接続できていれば、ほぼ設定完了です。

ssh -V
OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024

バージョンアップされていることを確認します。

自動アップグレード無効

強制的に9.x系に上げるので、その後、8.xがアップグレードされる可能性を防ぎます。

  • apt を使用する場合
sudo apt-mark hold openssh-server
  • aptitude を使用する場合
sudo aptitude hold openssh-server

システム全体の確認

  1. ログインできることを確認します。
  2. 他のサービスが正常に稼働していることを確認します。

検証結果:ノートPCへの単体Growi導入。

これの結果となります。

  • 中古PCに
  • NWに繋げず(つまり、クライアントLinuxのみで)
  • アプリを動かす

限定環境での感想です。

結論:モバイル環境下でのGrowi単体運用は難しい。

結論から言ってしまうと、この形。以下、理由を述べていきます。

理由1:重い

昨今のWebアプリの宿命と言えます。特にサーバーサイドレンダリングを重視しているGrowi v7以降は、低電圧版CPUでは満足に動かせません。(ビルドに15分以上かかりました)

理由2:スペックが低い機器は重いため、すぐ書ける・気軽に書ける特性が損なわれている。

Chromebookを選んでいた理由でもあります。

紙と同じぐらいの速度や携帯性を求めているので、重くしたのでは本末転倒です。

理由3:バッテリー消費。

これも、小さくない欠点でした。クライアントとサーバを兼ねるため、CPUにかかる負荷は増大。それにつれてバッテリーも消費してしまいます。

理由4:検証機を兼ねているノートPC

こちらは個人的な所見。

検証を兼ねているので、かなり頻繁にOSの再インストールを行います。そのたびにバックアップやリストアをするのは面倒です。

そういうわけで、「PCに沿ったアプリを選定する」大切さを学びました。

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

概要

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

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

環境

さっくりとした手順

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

nodeのアップグレード

node -v

OSが少々古いため、Ubuntu 20.04のnodeは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 /var/log/nginx/growi/ssl_access.log;
        error_log /var/log/nginx/growi/ssl_error.log 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

バージョンアップ確認

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

Ubuntu 22.04にGrowi v7.xをインストール。

Dockerを用いない方法でGrowiのv7.xをUbuntu22.04がインストールできたので、その手順を示します。

環境

  • Ubuntu 22.04
  • Apache 2.4

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

前提

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

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

太字部分はv7で必要になる手順です。

  1. 必要なパッケージをインストールします。
  2. Node.js/npmをインストールします。
  3. Redis-serverをインストールします。
  4. Javaをインストールします。
  5. ElasticSearch 8をインストールします。
  6. ElasticSearchの設定変更を行います。
  7. ElasticSearchのプラグインをインストールします。
  8. ElasticSearchの設定変更を反映します。
  9. MongoDBをインストールします。
  10. MongoDBのデータ格納先を変更します。
  11. MongoDBのアップデートを防ぎます。
  12. MongoDBの設定変更を反映します。
  13. yarnのインストールを行います。
  14. 必要パッケージをインストールします。
  15. turboパッケージをインストールします。
  16. Growiのインストールを行います。
  17. yarnを用いてインストールします。
  18. アプリのビルドを行います。
  19. 自動起動のスクリプトを作成します。
  20. Apacheのリバースプロキシの設定を行います。
  21. ブラウザで起動します。

手順

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

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

※v6系と異なり、git-lfsをインストールしない状態でgit-cloneを行うと正しくビルドが行えません。

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

  • レポジトリ追加
sudo curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash
  • パッケージアップグレード
sudo aptitude update
  • Node.jsインストール
sudo aptitude install nodejs
  • Node.jsバージョン確認
node -v

2024/06/27現在:v18.20.3

  • npmバージョン確認
npm -v

2024/06/27現在:10.7.0

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

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

  • 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/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.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-isu インストール
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://pgp.mongodb.com/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-org-server mongodb-org-shell mongodb-org-mongos mongodb-org-tools
MongoDBバージョン固定

※2024/04/03現在、GrowiはMongoDBのバージョンが固定されているので、自動更新されないようにします。

sudo aptitude hold mongodb-org
sudo aptitude hold mongodb-org-server
sudo aptitude hold mongodb-org-shell
sudo aptitude hold mongodb-org-mongos
sudo aptitude hold mongodb-org-tools
保存先変更(オプション)

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

  • 格納ディレクトリ作成
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/mongodb.conf
  • 差分
-  dbPath: /var/lib/mongodb
+  dbPath: /home/mongodb
自動起動有効
  • mongodサービス起動
sudo systemctl start mongod
  • サービス起動確認
systemctl status mongod

active (running)を確認します

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

yarnインストール

  • npmでyarnインストール
sudo npm install -g yarn
  • turboインストール

※Growi v6.1.0から必須パッケージとなりました。

sudo yarn global add turbo

Growiインストール

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

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

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

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

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

2024/06/27現在の最新版をチェックアウトします。

  • yarnによるインストール
sudo yarn

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

  • ビルド
sudo yarn app:build

v7からこの操作が必要です。やはり時間がかかります。

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

  • systemd作成
cat <<- __EOF__ | sudo tee -a /etc/systemd/system/growi.service
[Unit]
Description = growi
After=network-online.target mongod.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
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=[任意の文字列] \
FILE_UPLOAD=local \
npm start

※【】内を、git cloneしたディレクトリにします。
[]内には任意の文字列を入れます。 例:PASSWORD_SEED=GOLDEN_SEED

また、オプションなどは好みに応じて指定してください。(FILE_UPLOAD=localは添付ファイルの保存先をDBではなくローカルに保存するオプションです)

  • 権限変更
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 rewrite header
  • apache再起動
sudo systemctl restart apache2.service
  • ログ保存ディレクトリ作成
suod 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
  # SSLを有効化します

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

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

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

</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:EC6-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off
__EOF__

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

※v6とはWebSocketの書き方が異なります。ご注意ください。特に、Apacheのリバースプロキシ環境でWebSocket周りを適切に指定しないとページを編集しようとすると編集画面が空白になってしまいます。

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

Syntax OKを確認します。

  • Apache2再起動
sudo systemctl restart apache2.service

Growiインストール確認

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

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

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アプリはミドルウェアとの兼ね合いでハマることが多いんで注意です。

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で設定可能

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

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

Page 1 of 18

Powered by WordPress & Theme by Anders Norén