カテゴリー: PC Page 25 of 50

growi v6.0.15 → v6.1.0へのバージョンアップでハマったこと。

概要

日々の記録に、ブログ/redmineの下書きに、思考の整理にと役立っているgrowi。

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

で、growiの新しいバージョンを確認したので実施しましたが、ハマりましたのでメモとして残します。

アップデートした環境

  • growi 6.0.15
  • Ubuntu 20.04
  • mongodb 4.4.13
  • node 14.21.3 (後述するバージョンアップによりv18.16.0)

また、以下を実施済みです。

実施手順

https://atelier.reisalin.com/projects/zettel/knowledgebase/articles/28

こちらに沿って実施しました。

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

ハマったこと1:nodeのバージョンが合わない

  • 実行コマンド
sudo yarn
  • エラー
[1/5] Validating package.json...
error growi@6.1.0: The engine "node" is incompatible with this module. Expected version "^16 || ^18". Got "14.21.3"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

とあったので、nodeのバージョンアップが必要でした。

ハマったこと1への対処

以下の記事で、最新安定版のnode.jsに差し替えました。

https://manualmaton.com/2023/03/15/

nodeのアップデート後、正常にyarnを行うことができました。

ハマったこと2: 起動スクリプトが動作しない。

sudo systemctl start growi.service

を実行しても起動せず。

systemctl status growi.service

で状況を確認します。

/bin/sh: 1: turbo: not found

というエラーが出ました。

ハマったこと2への対処

1への対処時、付随するnpmパッケージを削除したことが原因です。

sudo npm install -g turbo

として、再度

sudo systemctl start growi.service

を実行。

systemctl status growi.service

起動を確認しました。

実行後

このバージョンアップは是が非でも行いたいものでした。

なぜなら、念願のmermaid.jsが実装されたからです。

これで、別のアプリを起動せず、growiのみでのmermaid記法が楽になりました。

Nextcloud管理画面での警告対応。(occ実行)

概要

Nextcloudをバージョンアップ後、以下のような警告が管理画面で出てきました。

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

環境

  • Ubuntu 20.04
  • PHP8.1
  • Nextcloud 26.0.1
  • Apache 2.4

での対応です。

実施内容

  • コマンド
cd /var/www/html/ && pwd
# Nextcloudのあるディレクトリに移動します
          
sudo -u www-data /bin/php occ db:add-missing-indices
# Webサービスの実行者(ここではwww-data)を指定します  
  • 処理例
Check indices of the share table.
Check indices of the filecache table.
Adding additional parent index to the filecache table, this can take some time...
Filecache table updated successfully.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.
Check indices of the oc_jobs table.
Check indices of the oc_direct_edit table.
Check indices of the oc_preferences table.
Check indices of the oc_mounts table.

実施後

Nextcloudの管理画面でリロードを行いました。

全てのチェックに合格しました。

と出たのでOKです。

プログラム自身がチェックを行ってくれるのがNextcloudの強み。

ChatGPTによるRubyスクリプト。(エラーログ検索)

割とシンプルながら、障害などの特定を効率よくするためのスクリプトを書いてもらいました。

質問

以下の通りです。

以下を満たすスクリプトを書いてください。

1. プロンプトにてエラーログをフルパスで質問
1-1. エラーログが見つからなければ「ファイルがありません」を返して終了
2. プロンプトにて検索したい単語を指定
3. 検索単語にて行数を表示
4. 「○件見つかりました。該当する行を表示しますか?」でy/n確認
4-1. nの場合は処理を終了
4-2. yの場合は該当行を表示して終了

結果

ほぼ一発で想定通りの動きを見せるスクリプトを書いてもらいました。

# 1. プロンプトにてエラーログをフルパスで質問
print "エラーログのフルパスを入力してください: "
error_log_path = gets.chomp

# 1-1. エラーログが見つからなければ「ファイルがありません」を返して終了
unless File.exist?(error_log_path)
  puts "ファイルがありません"
  exit
end

# 2. プロンプトにて検索したい単語を指定
print "検索したい単語を入力してください: "
search_word = gets.chomp

# 3. 検索単語にて行数を表示
line_numbers = []
File.open(error_log_path, "r") do |file|
  file.each_line.with_index(1) do |line, line_number|
    line_numbers << line_number if line.include?(search_word)
  end
end

puts "#{line_numbers.length}件見つかりました。"

# 4. 「○件見つかりました。該当する行を表示しますか?」でy/n確認
unless line_numbers.empty?
  print "該当する行を表示しますか? (y/n): "
  display_lines = gets.chomp.downcase
  if display_lines == "y"
    File.open(error_log_path, "r") do |file|
      file.each_line.with_index(1) do |line, line_number|
        if line_numbers.include?(line_number)
          puts "行 #{line_number}: #{line.chomp}"
        end
      end
    end
  else
    exit
  end
else
  exit
end

エディタに記述、保存後に

ruby search_log.rb

を実行。

これで、

  • 怪しそうな箇所の行数
  • その詳細

などを絞ることが可能になり、ここからの加工も容易になります。

ChatGPTによるシェルスクリプト(パッケージの自動更新)の問題点と修正。

この記事の更に続きとなります。

以前作成したスクリプトに問題点があったので修正します。

問題点詳細

アップデートするパッケージによってはコンフィグを残すか否かをアップデート中に聞いてきます。

このプロンプトが表示されるとスクリプトは停止。処理を手動で中断して実行する羽目になります。

これを回避するため、以下のように修正いたしました。

修正差分

-    aptitude -y full-upgrade | tee $upgraded_packages >/dev/null
+    DEBIAN_FRONTEND=noninteractive aptitude -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade | tee $upgraded_packages >/dev/null

修正した処理の詳細

※chatGPTの回答なので信頼性は各自ご判断ください。

  1. DEBIAN_FRONTEND=noninteractive : DEBIAN_FRONTEND 環境変数に noninteractive を設定し、aptitude コマンドを非対話モードで実行します。これにより、パッケージの更新時に表示される確認メッセージを自動的に承認することができます。
  2. aptitude -y : aptitude コマンドに -y オプションを指定して、すべての質問に対して自動的に yes を返答するようにします。
  3. -o Dpkg::Options::="--force-confdef" : dpkg コマンドに --force-confdef オプションを指定して、パッケージがインストールされる際に必要なデフォルトの設定値を使用するように指定します。
  4. -o Dpkg::Options::="--force-confold" : dpkg コマンドに --force-confold オプションを指定して、既存のコンフィグファイルを保持するように指定します。
  5. full-upgrade : aptitude コマンドの full-upgrade オプションを指定して、すべてのパッケージを最新バージョンに更新します。
  6. | tee $upgraded_packages >/dev/null : 更新されたパッケージのリストを一時ファイルに保存します。パイプライン演算子 | を使用して、aptitude コマンドの出力を tee コマンドに送信し、同時に一時ファイルに書き込むように指定します。>/dev/null を追加することで、標準出力を無効化し、結果を表示しないようにします。

修正後のスクリプト全文

#!/bin/bash

# インストールされているパッケージの一覧を取得して別ファイルに出力します。
now1=$(date +%Y%m%d)
dpkg-query -W > installed_packages_$now1.txt

# aptitude updateを行います。
aptitude update

# updateの結果:
if aptitude search '~U' | grep -q '^i'; then
    # 対象パッケージ,変更前バージョン,変更後のバージョン を記入した日付付きのファイルを作成。
    now1=$(date +%Y%m%d)
    upgraded_packages=$(mktemp)

    # パッケージのキャッシュをクリアした上でパッケージアップグレードを実施。
    aptitude clean
    DEBIAN_FRONTEND=noninteractive aptitude -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade | tee $upgraded_packages >/dev/null

    # パッケージ一覧からの差分を別ファイルで作成。(実行日の日付を付与)
    new_packages=$(mktemp)
    dpkg-query -W > $new_packages
    diff -u installed_packages_$now1.txt $new_packages > package_diff_$now1.txt

   # 新しいパッケージ名を取得
   DIFF_FILE="package_diff_$now1.txt"
   NEW_PACKAGES=$(grep -E "^\+[^+]" $DIFF_FILE | awk '{print $1}' | cut -c 2-)

   # 変更されたパッケージの数と、新しいバージョンのパッケージ名のリストを表示
   UPDATED_PACKAGES=$(echo "$NEW_PACKAGES" | wc -l)
   echo "$UPDATED_PACKAGES 件のパッケージに変更がありました。以下のパッケージが更新されました:"
   echo "$NEW_PACKAGES"

    # checkrestartを実行して結果を取得
    now=$(date +%Y%m%d)
    checkrestart_output=$(checkrestart)

    # サービスを再起動する必要のあるプロセスを抽出してファイルに出力
    restart_services=$(echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | awk '{print $NF}' | sort -u)

    if [[ -n "$restart_services" ]]; then
        # ファイル名に日付を追加
        now2=$(date +%Y%m%d)
        filename="restart_services_$now2.txt"

        echo "以下のサービスを再起動してください:" >> "$filename"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep -v "restart$" >> "$filename"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep "restart$" >> "$filename"

        echo "以下のサービスを再起動してください:"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep -v "restart$"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep "restart$"


    else
        echo "再起動するサービスはありません"
    fi
fi

これでコンフィグを残すか否かのアップデートでも停止することなく動きましたが、肝心の

  • どのパッケージがコンフィグを残すか否か求められたか
  • その差分は何か

などが不明。なので、改善点はまだまだです。

Redmine Addtional Tagsによる一括タグ付け。

こちらを更に発展させました。

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

こうして、ゲーム『ライザのアトリエ3』の見聞録などの情報をチケットかできたものの、もっと付与したい情報がありました。

「タグ付け」による分類です。

既にあるプラグイン「Additonal Tags」でどうにかなりました。(というよりも使っている内に気づきました)

こんな形のタグ付けされていないチケット。

全て選択して

右クリックから「tags」を選択。

付与したいタグを入れていき、「追加」をクリック。

追加後、しっかりとチケットにタグが付与されていることを確認。

これで、諸々の整理がもっと楽になります。

『ライザのアトリエ3』三周目の記録と高難易度の挑戦。

一周目と二周目の概要

  1. 1周目は実績全解除を目指しました。(リンク先ネタバレあり)
  2. 2周目は各地に存在する見聞録を集めました。(リンク先ネタバレあり)

三周目の挑戦

そこで、3周目は「各地のランドマーク」をRedmineに重点的に記録していきます。

https://atelier.reisalin.com/issues/162

と、今後の調合の際に「どこに行けどの超素材が手に入るか」を記録しようというわけです。

難易度『LEGEND』追加

そんな中、待望のアップデート実施。

最高難易度「LEGEND」追加。折しも三週目に入ったばかり。引き継ぎ時に作成していたコアアイテムがどこまで通用するかを試す絶好の機会です。

結果は圧勝というか鎧袖一触。

コアアイテムを調整していないのでアイテムが使えるようなCCが溜まる前に殲滅するケースがほとんど。

こちらに関してはストーリー進行に合わせて挑戦しがいが出てくればと思います。

Let’s Encryptの証明書整合でハマったこと。(ECDSA方式での整合性確認)

概要

更新サイクルが3ヶ月と短いものの、無料で利用できるということで愛用しているLet's Encrypt。
デフォルトの暗号化形式がRSAからECDSA方式に変わったようで確認方法でハマりました。

なんとか解決したのでメモを残します。

従来の確認方法

RSA方式での証明書は、以下の

openssl x509 -in /etc/certs/hoge.example.com.crt -noout -modulus | md5sum
# SSL証明書ファイル

openssl rsa -in /etc/private/hoge.example.com.key -noout -modulus | md5sum
# 秘密鍵ファイル

を実行し、それぞれのハッシュ値が合致していることで証明書と秘密鍵の整合性の確認を取ることができています。

ECDSA方式に変わったことでの問題

2023年4月時点で、Let's Encryptのデフォルト暗号化形式がRSA→ECDSA方式に変わっていました。

openssl rsa -in /etc/private/hoge.example.com.key -noout -modulus | md5sum
# 秘密鍵ファイル

を実行すると

139945929635648:error:0607907F:digital envelope routines:EVP_PKEY_get0_RSA:expecting an rsa key:crypto/evp/p_lib.c:469:

といったエラーが出ます。

これでは証明書と秘密鍵の整合性が確認できません。

しばらくGoogleと格闘し、なんとか解決策を見つけました。

https://security.stackexchange.com/questions/73127/how-can-you-check-if-a-private-key-and-certificate-match-in-openssl-with-ecdsa

ECDSA方式でも証明書と秘密鍵の整合性が確認できるコマンド

まず、鍵がECDSA方式であることを確認。

  • 確認コマンド
openssl ec -in /etc/private/hoge.example.com.key -text -noout
# 秘密鍵のパスを指定します
  • 確認結果
(略)
ASN1 OID: prime256v1
NIST CURVE: P-256
# 上記が表示されればECDSA方式であると確認できます。

次に、以下のようにして公開鍵を抽出してハッシュ値を割り出します。

openssl x509 -pubkey -in /etc/certs/hoge.example.com.crt -noout | openssl md5
(stdin)= ハッシュ値
# SSL証明書ファイル

openssl pkey -pubout -in /etc/private/hoge.example.com.key | openssl md5
(stdin)= ハッシュ値
# 秘密鍵ファイル

### 2つのハッシュ値が合っていれば証明書と秘密鍵の整合性は取れています

以上、ECDSA方式でも整合性を確認することができました。

余談

この、「鍵を用いて鍵を取り出す」って、『ライザのアトリエ3』で無垢の鍵から秘密の鍵を抽出しているようだなと益体もないことが脳裏をよぎりました。

Redmineのチケットによるゲーム情報管理と一括登録。(『ライザのアトリエ3』ネタバレ要素あり)

Redmineのチケット機能、プライベートでも活躍。

こんな感じで一つの事柄に対してコメントを足していくことで、「1つの目的で必要な要素」を網羅しました。

今回は逆に「多数の要素を一つの目的に落とし込む」ための機能を用いました。

攻略時のメモ記載。

『ライザのアトリエ3』での攻略メモ、(2周目に入ってから)見落としがちな見聞録や料理のレシピなどを残しておきました。

https://atelier.reisalin.com/issues/46

これを加工していきます。

インポート用データ作成。

  • チケットのステータス
  • 対象バージョン
  • カスタムフィールド(見聞録入手条件)

等、

スプレッドシートに書いていきます。「説明」欄にマークダウンを記入できるのである程度テンプレ化できるのも強み。

ゲーム中に取得したスクリーンショットはコメントへのリンクを張っていきます。

CSVインポート

こうして作ったデータをCSVインポートでそのまま取り込み。

バージョン管理

ここでは、ゲーム中に訪れる地方を「バージョン」と位置づけました。

なので、インポートされた見聞録のデータはこのように一瞥できるようになります。

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

チケットの詳細をクリックするとこんな形になりました。

Redmine4.2にissue_importerをインストール。

概要

基本的に:「Excelが大嫌いなのでRedmineを使っている」というのがスタンスです。
ですが、「大嫌いなExcelシートで加工した方が効率がいい状況」は多々発生します。

そんな加工したデータをチケットとして登録するためのプラグインを導入しました。

RedmineにはCSVインポート機能が備えられているものの、本項で紹介するプラグインはチケットの更新も行えるのが特徴です。

プラグイン名

  • redmine_importer
    • https://github.com/agileware-jp/redmine_importer

動作を確認した環境

  • Ubuntu 20.04
  • Redmine 4.2
  • Apache 2.4
  • Mod_passanger

導入時

Gem追加:不要
DBマイグレーション:要

手順

さっくりとした手順

  1. SSHログイン後、Redmineプラグインに移動
  2. gitでレポジトリをダウンロード
  3. DBマイグレーション
  4. Webサービス再起動

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

cd /home/www-data/redmine/plugins
# 自分の環境に合わせます。

プラグインを配置します。

sudo -u www-data git clone https://github.com/agileware-jp/redmine_importer

ls -ld redmine_importer
# このディレクトリがあることを確認します

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

cd /home/www-data/redmine
# 自分の環境に合わせます。

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

Webサービスを再起動します。

sudo systemctl restart apache2

設定後の動作

  1. 管理者権限でRedmineにログインします。
  2. プロジェクト > 設定>モジュールに進み「importer」にチェックを入れます。
  3. プロジェクトのタブに「インポート」が表示されれば動作完了です。

こちらではインストールまで実施。具体的な使い方は別途紹介します。

動作確認日

2023/04/13

Webサーバ:メモリ漸増への対処。(cronによる監視とWebサービス再起動)

概要

AWSで使っているWebサーバのメモリ使用量が漸増していくため、以下の処置を施しました。

実行環境

  • Ubuntu 20.04を稼働しているWebサーバ
  • メモリは4GB

さっくりとした手順

  1. メモリ使用量をトリガーとして、閾値を超えたらWebサービスの再起動を行うスクリプトを作成。
  2. このスクリプトをCron化。

スクリプト作成

管理者権限で以下を作成します。

  • memory_monitor.sh
#!/bin/bash

# メモリ使用量の閾値を設定する(ここではメガバイト単位で指定)
threshold=3584

# ログの保存パスと名前を設定する
log_path="/var/log/"
log_name="restart.log"

# 現在のメモリ使用量を取得する
mem_used_before=$(free -m | awk 'NR==2{print $3}')

# メモリ使用量が閾値を超えた場合にWebサービスの再起動を行う
if [ "$mem_used_before" -gt "$threshold" ]; then
    systemctl restart httpd
    # 極端な話、reboot と指定することでシステムそのものの再起動も可能です
    mem_used_after=$(free -m | awk 'NR==2{print $3}')
    mem_used_diff=$((mem_used_after - mem_used_before))
    echo "httpd service restarted on $(date). Memory usage difference: $mem_used_diff MB" >> "${log_path}${log_name}"
fi

作成後、実行権限を付与します。

sudo chmod 744 memory_monitor.sh

cron登録

sudo crontab -e -u root
  • 登録内容
*/15 * * * * /path/to/directory/memory_monitor.sh
# 格納したパスを指定します
# 15分おきに実行としています。

今後の課題

これはあくまでも対処療法。根本的なボトルネックの究明は継続して行います。

Page 25 of 50

Powered by WordPress & Theme by Anders Norén