カテゴリー: Linux Page 9 of 46

ViewCustomizeによるガントチャートの修正

RedmineのViewCustomizeはいじりがいがあるプラグインです。

今回もまたちょっとした要望に応えるユースケースとなりました。

やりたいこと

攻略情報をRedmineのチケットとして載せています。

https://atelier.reisalin.com/projects/ryza3/issues/gantt

この、「アトリエ-全般」やチケットNo.が視認性を悪くしているので、これの表示を変えます。

具体的には

トラッカー名-チケット番号-チケットの件名

を、

チケットの件名-トラッカー名-チケット番号

に変える形です。

環境

  • Redmine 4.2
  • View_Customizeプラグインが入っていること

手順

※ 参考:Redmine View Customizeサンプルスクリプト:ガントチャートでトラッカー名・チケット番号を非表示にする

  1. Redmineの管理画面にログインします。
  2. 「管理」 > 「表示のカスタマイズ」に移動します。
  3. 「新しい表示のカスタマイズ」をクリックします。

以下の通り設定します。

  • 「パスのパターン」: /issues/gantt
  • 「プロジェクトのパターン」:空白
  • 「挿入位置
  • 「種別」:JavaScript
  • コード
$(function() {
$('div.issue-subject span').each(function() {
var $this = $(this);
var issue_link = $this.find('a.issue');
var issue_number = issue_link.text().trim();
var issue_title = $this.clone().children().remove().end().text().trim();
var new_html = issue_title + ' ' + issue_number;
// 新しいHTMLを設定
$this.html(new_html);
// リンクを再設定
$this.wrapInner('<a href="' + issue_link.attr('href') + '"></a>');
});
});
  • コメント:ガントチャートの並び順を変える
  • 有効:チェック
  • プライベート:チェックを外す

設定後、保存します。

修正確認

上記の設定を行ったプロジェクトのガントチャートを確認します。

このように、並び順が変われば設定OKです。

Nextcloud Ver.29.05(?)でのうれしい改良点。

バージョンアップしたNextcloudに、ある意味で待っていた機能が改善されました。

見出しのマルチバイト対応。

なぜか、今まで、

# で見出しタグを指定した後に文字を入力しようとすると日本語で文字が入力できないというかなり厳しい事象がありました。

そのため、Markdwonの文書の書き出しは

  • テキストエディタでMarkdwon直打ち
  • ローカル環境のGrowiをコピペする
  • その上で、一度、Redmineのチケットにする

ぐらいしか手はありませんでしたですが、今回(かは不明ですが)のバージョンアップによって

このように、見出しの後にそのまま日本語入力ができます。

「オンラインで気兼ねなくメモを取れる」環境がほしかったので、これは大きな改善。

モバイルアプリなどを利用してのメモ書きの効率化も図れそうです。

Nextcloud 29.05のバグをパッチ適用で修正。

Nextcloudのバージョンを29.05に上げたところ、以下のメッセージが出てきました。

One or more mimetype migrations are available. Occasionally new mimetypes are added to better handle certain file types. Migrating the mimetypes take a long time on larger instances so this is not done automatically during upgrades. Use the command occ maintenance:repair --include-expensive to perform the migrations.

「1つ以上のMIMEタイプの移行が利用可能です。特定のファイルタイプをより適切に処理するために、新しいMIMEタイプが追加されることがあります。大規模なインスタンスではMIMEタイプの移行に時間がかかるため、アップグレード時に自動的には行われません。移行を実行するには、occ maintenance:repair --include-expensiveコマンドを使用してください。」

とあるので、この警告に対処していきます。

自環境

  • Ubuntu 20.04
  • PHP 8.1
  • Apache 2.4
    • (www-dataとして実行)
  • Nextcloudを29.04→29.05にアップデート直後

1回目の手順:occ実行 → 失敗

Nextcloudがインストールされているサーバにログインしての作業です。

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

cd /var/www/html/nextcloud && pwd

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

occコマンドを実行します。 → 失敗

sudo -u www-data php occ maintenance:repair --include-expensive

Nextcloudの実行ユーザー(www-data)を付与した上でoccを実行します。

ですが、以下のエラーが出てきて問題は解決しませんでした。

WARNING: Failed to create filecache trigger (compatibility mode will be used): An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1419 You do not have the SUPER privilege and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)
- exiftool binary is configured: /var/www/html/nextcloud/apps/memories/bin-ext/exiftool-amd64-glibc
- go-vod binary is configured: /var/www/html/nextcloud/apps/memories/bin-ext/go-vod-amd64
- WARNING: ffmpeg binary could not be configured

調査の結果、バグと判明

そこで、このエラーメッセージで探したところ、そのものズバリのバグが報告されていました。

[Bug]: Warning: One or more mimetype migrations are available #47359

どうやら、RepairMimeTypes.phpファイルがver29.0.5を正しく読んでいないようです。

そこで、改めての対処です。

2回目の手順:パッチ作成と適用 → ○

パッチファイルを作成します。

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

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

  • 修正前のファイルをバックアップ
sudo cp -pi /var/www/html/nextcloud/lib/private/Repair/RepairMimeTypes.php /hoge/RepairMimeTypes.php.$(date +%Y%m%d)

Nextcloudのルートディレクトリ (自分の環境に合わせます)から作業ディレクトリにコピーします。

  • 修正されたファイルを取得
wget https://raw.githubusercontent.com/nextcloud/server/stable29/lib/private/Repair/RepairMimeTypes.php -O RepairMimeTypes.php.fixed
  • パッチを作成
sudo -u www-data diff -u /var/www/html/nextcloud/lib/private/Repair/RepairMimeTypes.php RepairMimeTypes.php.fixed > RepairMimeTypes.patch
  • 作成したファイルの確認
cat RepairMimeTypes.patch
--- /var/www/html/nextcloud/lib/private/Repair/RepairMimeTypes.php      2024-08-20 17:56:22.000000000 +0900
+++ RepairMimeTypes.php.fixed   2024-08-26 14:14:11.568462741 +0900
@@ -424,7 +424,7 @@
                        $out->info('Fixed ReStructured Text mime type');
                }

-               if (version_compare($mimeTypeVersion, '30.0.0.0', '<') && $this->introduceExcalidrawType()) {
+               if (version_compare($mimeTypeVersion, '29.0.5.0', '<') && $this->introduceExcalidrawType()) {
                        $out->info('Fixed Excalidraw mime type');
                }

差分(プラスマイナス)が2行のみを確認します。

パッチを適用します。

  • パッチ適用
sudo patch -d /var/www/html/nextcloud/lib/private/Repair  < /hoge/RepairMimeTypes.patch 

/hogeはパッチを作成したディレクトリをフルパスで指定します。

  • 差分確認
sudo -u diff -u /hoge/RepairMimeTypes.php.$(date +%Y%m%d) /var/www/html/nextcloud/lib/private/Repair

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

-               if (version_compare($mimeTypeVersion, '30.0.0.0', '<') && $this->introduceExcalidrawType()) {
+               if (version_compare($mimeTypeVersion, '29.0.5.0', '<') && $this->introduceExcalidrawType()) {
  • 権限確認
ls -l /var/www/html/nextcloud/lib/private/Repair/RepairMimeTypes.php

念のため、パッチを当てても所有者が変わっていない(www-data)ことを確認します。

改めてoccを実行し、Webサービス再起動の上で修正を確認します。

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

cd /var/www/html/nextcloud && pwd

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

occコマンドを実行します。 → 成功

sudo -u www-data php occ maintenance:repair --include-expensive

今度は通ります。

  • Webサービス(apahce)再起動
sudo systemctl restart apache2.service
  • 再起動後のステータス確認
systemctl status apache2.service

active(running)を確認します。

  • 事象の解消を確認
  1. 作業を行ったサーバで稼働するNextcloudに管理者権限でログインします。
  2. 管理者メニューで以下の通りWarningが解消されていることを確認します。

ufwの過剰設定によるサーバの暴走とufwの設定リセット。

「やらかしてしまった」メモです。

起こしてしまったこと

事象

aws lightsailで動かしているUbuntu20.04サーバにアクセスできない事象が発生しました。

Webサイトはもちろん、sshにもつながりません。

確認と一時対処。

awsの管理画面にログインしてリソース状況を確認したら、CPUがバースト。いわゆる暴走状態なのでこの状態を止めます。

「停止」→「起動」を選択。(再起動では完全に暴走が止まりませんでした)

それから程なくしてssh接続ができるまでは回復。ですが、

netstat -lntp

を実行してもWebサービスがリッスンしていません。

systemctl status apache2.service

でサービスは動いていることを確認。状態を確認できたところで原因を特定します。

事象発生前に何をしていたか?

バーストが発生しているサーバで、ufwの作業をしていました。これ以外に設定は特にやっていないので、ほぼおおそらくこれが問題だろうと判断。

取り急ぎ、

sudo ufw disable

を行い

サイトが見られることを確認しました。判断するに

  • ルールの数を増やしすぎて処理性能が追いつかなくなった。
  • 増やしたルールがコンフリクトやループを起こしハングアップ。

等でバースト、暴走したと考えられます。

不審なアクセスを無計画に弾いていたことが徒になった形です。

対処

ufwの強制リセットと最小限の設定

ufwが原因だと特定したものの、サーバ内のFWが有効化されていないのは危険です。そこで、以下のようにして設定を強制リセットしました。

  • 設定の強制リセット
sudo ufw --force reset
  • sshとweb通信のみを有効化
sudo ufw limit proto tcp from any to any port 22
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
  • 設定反映
sudo ufw enable

設定確認

  • ステータス確認
sudo ufw status
状態: アクティブ

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
443/tcp                    ALLOW       Anywhere                  

を確認しました。

  • 通信確認
  1. ssh接続ができること
  2. このサーバで稼働しているWebサイトが見られること

を確認し、対処完了です。

本件の教訓

「FWをいじるだけだから、特に作業履歴をやらなくてもいいだろう」という慢心から起きたものでした。

個人で運営しているサーバだったことに救われた形です。

また、この程度の作業ということで、システム全体のバックアップを取らなかったことも冷や水でした。

  • 自分の作業によって起きる影響
  • ufwの効率的な管理
  • 作業前のバックアップ確認

といった基本的な運用の管理への意識を改める自戒の出来事でした。

Ubuntu20.04サーバにApacheのDoS対策モジュール(mod_evasive)を導入。

概要

DoS/DDoS対策ができるモジュールをApacheに導入したときのメモです。

環境

  • Ubuntu 20.04
  • Apache 2.4系
  • FWにufwを利用

さっくりとした手順

  1. mod_evasiveモジュールをインストールします。
  2. apache2実行ユーザー(www-data)がufwを利用できるように設定します。
  3. mod_evasiveモジュールの設定をします。
  4. 設定の反映を行います。

まずはサーバにターミナルログインするところから始めます。

mod_evasiveのインストール

sudo aptitude install libapache2-mod-evasive

このとき、postfixが依存関係でインストールされる場合があります。メール機能が使えない(AWS等で送信が制限されているなど)は、途中の設定で「何もしない」を選択します。

apache2実行ユーザーの権限変更

これは、www-dataがufwを実行する場合の処理です。権限昇格の危険性を承知した上で、慎重に作業を行ってください。

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

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

  • diffによるバックアップ確認
sudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers

差分がないことを確認します。

  • ファイル追記
echo 'www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw' | sudo tee -a /etc/sudoers
  • ファイル追記確認
sudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers

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

+www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw

evasiveの設定変更

  • ファイルバックアップ
sudo cp -pi /etc/apache2/mods-available/evasive.conf /path/to/backup/directory/evasive.conf.$(date +%Y%m%d)
  • diffによるバックアップ確認
sudo diff -u /path/to/backup/directory/evasive.conf.$(date +%Y%m%d) /etc/apache2/mods-available/evasive.conf

差分がないことを確認します。

  • 以下のファイルを教義・信仰に沿ったエディタで編集していきます。
    • /etc/apache2/mods-available/evasive.conf
  • 編集例
    DOSHashTableSize    3097
    DOSPageCount        100
    DOSSiteCount        100
    #かなり緩く設定して、後で狭めていった方が偽陽性を防げます。
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10

    #DOSEmailNotify      you@yourdomain.com
    #メール通知を行わないため、ここを省いています
    DOSSystemCommand    "sudo ufw deny proto tcp from %s to any port 80,443"
    # 検証時に自分のサイトがブロックされるのを防ぐため、ポートは80/443に絞っています
    DOSLogDir           "/var/log/mod_evasive"
    DOSWhitelist        127.0.0.1
    DOSWhitelist        xx.xx.xx.xx
    # 対象外としたいIPアドレス(自分の環境など)

参考:Apache の DoS攻撃対策モジュール mod_evasive

  • 設定編集確認
sudo diff -u /path/to/backup/directory/evasive.conf.$(date +%Y%m%d) /etc/apache2/mods-available/evasive.conf
  • 差分例
-    #DOSHashTableSize    3097
-    #DOSPageCount        2
-    #DOSSiteCount        50
-    #DOSPageInterval     1
-    #DOSSiteInterval     1
-    #DOSBlockingPeriod   10
+    DOSHashTableSize    3097
+    DOSPageCount        100
+    DOSSiteCount        100
+    DOSPageInterval     1
+    DOSSiteInterval     1
+    DOSBlockingPeriod   10

     #DOSEmailNotify      you@yourdomain.com
-    #DOSSystemCommand    "su - someuser -c '/sbin/... %s ...'"
-    #DOSLogDir           "/var/log/mod_evasive"
+    DOSSystemCommand    "sudo ufw deny proto tcp from %s to any port 80,443"
+    DOSLogDir           "/var/log/mod_evasive"
+    DOSWhitelist        127.0.0.1
+    DOSWhitelist        xx.xx.xx.xx
 </IfModule>

設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apache再起動
sudo systemctl restart apache2.service

これで、不審なアクセスが大量にあったときにufwで弾く体制が整いました。

検証:Ubuntu20.04にredmine5.1をインストールする。

概要

Redmineとrubyのバージョン対応を見る限りですと、

Redmine 5.1はruby2.7で動きます。

Ubuntu 20.04で標準的にインストールされるrubyは2.7です。そこで、EOLが迫っているUbuntu 20.04で、敢えてRedmine 5.1がインストールできるかを検証しました。

前提

  • Ubuntu20.04サーバの初期設定が終わった直後の状態を想定します。
  • DNSでドメインの名前が解決できることを前提としています
  • 環境は以下の通りです。
  • Apache系
  • MySQL
  • Ruby 2.7
  • また、パッケージ管理としてaptitudeを用いています。aptが好みの方はこちらに読み替えてください。

特記事項

  • 本手順ではRedmine 5.1をインストールします。
  • 2025年4月にEOLが迫っているUbuntu 20.04で動かすという検証が目的であることを重ねて追記します。
  • 本記事のredmineの格納ディレクトリは/home/www-data/redmineです。一般的なディレクトリ(/var/lib/redmine)と異なることを最初に注記します。
  • ほぼコピペだけで済むような構成にしていますが、一部、テキストエディタを使用する箇所があります。
  • また、自身の環境に合わせたりパスワードを設定する項目がありますのでそこは注意してください。
  • Redmineのインストールができたという検証のみです。動作やプラグインと合わせては未検証です。

手順

Apacheのレポジトリを追加します。

sudo add-apt-repository ppa:ondrej/apache2

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

  • パッケージ全体のアップデート
sudo aptitude update
  • 必要なパッケージのインストール
sudo aptitude install build-essential zlib1g-dev libssl-dev libreadline-dev libyaml-dev libcurl4-openssl-dev libffi-dev mysql-server mysql-client apache2 apache2-dev libapr1-dev libaprutil1-dev imagemagick libmagick++-dev fonts-takao-pgothic subversion git ruby libruby ruby-dev libmysqlclient-dev

apacheの追加モジュールをインストールします。

sudo aptitude install libapache2-mod-passenger

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

apache2ctl -v

Apache/2.4.59以降であることを確認します。2.4.58には、http/2プロトコルへの脆弱性があるので、左記のバージョンであることを確認します。

rubyのパッケージ管理(gem)を用いて必要なライブラリをインストールします。

sudo gem install bundler racc mysql2

「3 gems installed」が表示されればインストール成功です。

必要に応じてmysqlの初期設定を行います。

mysql_secure_installationによる初期設定を行います。

うまくいかない場合は以下を参照してください。

https://barrel.reisalin.com/books/bbf94/page/mysql-secure-installation

mysqlでDBとユーザーを設定します。

sudo mysql -u root -p

上記で設定した「mysqlのrootパスワード」を入力し、mysqlにログインします

CREATE DATABASE redmine character set utf8mb4;

DB "redmine" を作成します

CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'password';

ユーザ "redmine"を作成し、パスワードを設定します。
この'password'は任意のパスワードに変更してください

GRANT ALL ON redmine.* TO 'redmine'@'localhost';
flush privileges;
exit

設定したDBでログインできることを確認します。

mysql -u redmine -p
SHOW DATABASES;
exit
  • 配置ディレクトリ作成
sudo mkdir -p /home/www-data/redmine

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

  • 所有者変更
sudo chown -R www-data:www-data /home/www-data
  • Redmine 5.1を入手
sudo -u www-data svn co https://svn.redmine.org/redmine/branches/5.1-stable /home/www-data/redmine

Redmineのコンフィグを設定します。

  • サンプルファイルをコピーしてコンフィグを編集
sudo cp -pi /home/www-data/redmine/config/database.yml.example /home/www-data/redmine/config/database.yml

/home/www-data/redmine/config/database.yml

このファイルを教義・信仰に従ったエディタで編集してください。

database.yml 編集内容

production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  # rootからredmineに変更します
  password: "redmine用のパスワード"
  encoding: utf8mb4
# 本番環境(production)のみ設定を行います

Redmineのマイグレーションを行います。

  • Redmineのルートディレクトリに移動
cd /home/www-data/redmine/ && pwd

/home/www-data/redmine/ (Redmineを配置したディレクトリ)であることを確認します

  • bundle install
sudo -u www-data bundle install --without development test --path vendor/bundle
  • シークレットトークンの発行(※Ubuntu 20.04の場合)
sudo -u www-data bundle exec rake generate_secret_token

を実行すると、

Could not find date-3.3.4, timeout-0.4.1 in any of the sources
Run `bundle install` to install missing gems.

というメッセージが出てきます。このエラーに対処します。

  • dateのアップデート
sudo -u www-data bundle update date
  • エラー修正後のシークレットトークンの発行
sudo -u www-data bundle exec rake generate_secret_token

今度は通ります。

  • DBマイグレーション
sudo -u www-data RAILS_ENV=production bundle exec rake db:migrate
  • 日本語化
sudo -u www-data RAILS_ENV=production REDMINE_LANG=ja bundle exec rake redmine:load_default_data

Apacheの設定ファイルを作成します。

【】を自分の作成したRedmineのサーバ名/ドメイン名に変更します。

cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/redmine.conf
<VirtualHost *:80>
    ServerName 【hoge.example.com】
    # ServerNameは自身が設定したredmineに読み替えてください。
    DocumentRoot /home/www-data/redmine/public
    <Directory /home/www-data/redmine/public>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
__EOF__

設定を反映させます。

  • ファイル作成確認
ls -l /etc/apache2/sites-available/redmine.conf
  • 設定ファイル有効化
sudo a2ensite redmine.conf
  • 初期サイト設定を無効化
sudo a2dissite 000-default.conf
sudo a2dissite default-ssl.conf
  • コンフィグファイル整合性確認
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)を確認します

Webページの表示を確認します。

http://設定したRedmineドメイン

でRedmineのトップページが表示されれば成功です。

直ちにadmin/adminでログインし、強固なパスワードを設定し直します。

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つ並んでいるボタンが追加されます。

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

任意の色を選ぶと、

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

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

Redmineに「元に戻す」「やり直し」追加(Redmine Wiki Historyプラグイン)

概要

RedmineにWord / Excel等にある「アンドゥ」「リドゥ」を追加するプラグインで、誤消去などを防ぎます。

Redmine Wiki History

動作確認環境

  • 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_history
  • clone確認
ls -ld redmine_wiki_history

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

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

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

導入後の確認

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

このようにアンドゥ(元に戻す)、リドゥ(やり直し)ボタンが表示されます。

入力した後に取り消し/やり直しができていれば導入成功です。

Growiサーバのnodeバージョンアップ。(18系→20系)

概要

Growi v7系の動作が安定してきたので、サーバのnodeのバージョンを18系から20系に切り替えます。

バージョンアップ前の環境

  • Ubuntu 22.04
  • Growi v7.0.12
  • node v18.20.3
  • npm 10.7.0
  • yarn 1.22.21

Dockerを利用していないオンプレ環境です。

さっくりとした手順

  1. 作業前に周知を行います。(複数ユーザーで運用している場合)
  2. メンテナンスモードに切り替えます。(またはサービスを停止します)
  3. n packageをインストールします。(インストールしていない場合)
  4. n packageを用いてnodeをバージョンアップします。
  5. nodeのバージョンアップを確認します。
  6. growiを再起動します。
  7. メンテナンスモードを解除します。(実行していた場合)

作業前の周知

単独で利用している場合はこれは不要です。

メンテナンスモードの切り替え

以下のいずれかを選んでください。

  • Growiに管理者権限でログイン後に設定→アプリ設定→「メンテナンスモードを開始する」
  • サーバでsudo systemctl stop growi.serviceを実行する(systemdに登録している場合)

n packageをインストール (インストールしていない場合)

sudo npm install n -g

これを用いてnode.jsをインストールしていきます。

n packageを用いてのバージョンアップ

  • node 20系にバージョンアップ
sudo n 20

バージョンアップ確認

node -v

v20.15.1を確認しました。(2024/07/12現在)

growiサービスの再起動

systemdに登録している場合の手順です。

sudo systemctl restart growi.service

再起動後、Growiにアクセスできることを確認します。

nodeバージョンアップ後の対応

  1. Growiに管理者権限でログインします。
  2. 設定を開き、システム情報でnodeがバージョンアップされていることを確認します。
  3. メンテナンスモードの切り替えを行った場合は、設定から解除します。
  4. 既存機能が使えることを確認します。

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に読み替えてください。

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

Page 9 of 46

Powered by WordPress & Theme by Anders Norén