タグ: Ubuntu Page 4 of 10

Ubuntu20.04のOpenSSLを1.1.1から3.1.1にアップデート。

概要

2023/09/11にサポート終了を迎えるOpenSSL1.1.1。

2023年6月現在の最新安定版である3.1.1にアップデートを行います。

https://www.openssl.org/blog/blog/2023/06/15/1.1.1-EOL-Reminder/

環境

  • OS:Ubuntu 20.04
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

参考とした手順

https://nextgentips.com/2022/03/23/how-to-install-openssl-3-on-ubuntu-20-04/

さっくりとした手順

  1. システム全体のバックアップ
  2. 必要なライブラリをインストールします。
  3. githubレポジトリから最新安定版のソースコードをダウンロードします。
  4. ソースからインストールしていきます。
  5. 設定を行います。(コンフィグを反映させ、パスを通します)
  6. バージョンアップを確認します。

実施した手順

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

  • Webアクセスの根幹となるプログラムであること
  • 重要なデータが格納されている

ことから、AWS Lightsailのスナップショットを利用して全体のバックアップを取りました。

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

sudo aptitude install build-essential checkinstall zlib1g-dev
# 筆者はaptitudeを用いています。必要に応じてaptを使ってください。

ソースコードの取得

sudo su -
# 以下、管理者権限で実施します

cd /hoge
# 任意のディレクトリを指定します

git clone https://github.com/openssl/openssl -b openssl-3.1.1
# 2023/06/20時点での最新安定版を指定します

cd openssl

ソースからインストール

./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlib

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

make test

make install

インストール後の設定

  • 設定ファイル追記
cat <<- __EOF__ | tee -a /etc/ld.so.conf.d/openssl-3.1.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 version -a
OpenSSL 3.1.1 30 May 2023 (Library: OpenSSL 3.1.1 30 May 2023)
built on: Tue Jun 20 01:47:24 2023 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=0x7ffaf3ffffebffff:0x27ab

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

必要に応じて

  • システムの再起動を行います。
  • 既存サービスが正常に動くことを確認します。

作業日

2023/06/22

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』で無垢の鍵から秘密の鍵を抽出しているようだなと益体もないことが脳裏をよぎりました。

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分おきに実行としています。

今後の課題

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

ChatGPTが各シェルスクリプト。(motdに一文をランダムで表示)

「ちょっとしたことを試したいけど方法が分からない」時のChatGPTは本当に頼りになります。

やりたいこと

こちらの発展系。サーバログイン時にランダムに一文を書いてほしいと思い立ちました。

スクリプト

管理者権限で以下のファイルを作成します。

/etc/update-motd.d/20-quote

#!/bin/bash

# 20-quote - MOTDにquote.txtからランダムな引用を表示するスクリプト

# quote.txtファイルのパス
QUOTE_FILE="/hoge/quote.txt"

# quote.txtファイルの行数を取得する
NUM_LINES=$(wc -l < "${QUOTE_FILE}")

# ランダムな行番号を生成する
RANDOM_LINE=$((1 + RANDOM % NUM_LINES))

# ランダムな行番号に該当する引用を表示する
sed "${RANDOM_LINE}q;d" "${QUOTE_FILE}"

作成後、実行権を付与。

sudo chmod +x /etc/update-motd.d/20-quote

引用文も書いてもらいました。

quote.txt

A penny saved is a penny earned / 節約した1ペニーは1ペニー稼いだのと同じ
Actions speak louder than words / 言葉より行動
All good things come to those who wait / 望むことは遠くにあり、我慢して待てば必ず手に入る
An apple a day keeps the doctor away / 1日にリンゴを食べると医者は遠ざかる
Don't count your chickens before they hatch / 卵を孵す前に小鳥を数えるな
Every cloud has a silver lining / 苦しいことの中にも良いことがある
Fortune favors the brave / 運は勇気ある者に付きもの
Honesty is the best policy / 誠実は最高の策略
If at first you don't succeed, try, try again / 失敗してもくじけずに何度でも挑戦せよ
Necessity is the mother of invention / 必要は発明の母
No pain, no gain / 苦労なくして報酬なし
Penny wise, pound foolish / 1を惜しんで100失う (木を見て森を見ず)
Practice makes perfect / 習うより慣れろ
Rome wasn't built in a day / ローマは一日にして成らず
The early bird catches the worm / 早起きは三文の徳
The grass is always greener on the other side of the fence / 隣の芝は青く見える
The squeaky wheel gets the grease / うるさい方が注目を集める
There's no such thing as a free lunch / 無料の昼食は存在しない
Time is money / 時間は金
Where there's smoke, there's fire / 煙のあるところには火がある

ChatGptが提供したイギリスのことわざ

これで、SSHログイン時に上記の文章がランダムで表示されるようになりました。

ChatGPTによるシェルスクリプト。(続:Ubuntuサーバのパッケージ全体の更新とサービス再起動の有無) 

こちらのスクリプトを修正しました。(正確にはChatGPTに修正してもらいました)

修正版スクリプト

#!/bin/bash

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

# aptitude updateを行います。
aptitude update

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

    # パッケージのキャッシュをクリアした上でパッケージアップグレードを実施。
    aptitude clean
    aptitude -y full-upgrade | tee $upgraded_packages >/dev/null

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

   # 新しいパッケージ名を取得
   DIFF_FILE="package_diff_$now.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
        # ファイル名に日付を追加
        now=$(date +%Y%m%d)
        filename="restart_services_$now.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

差分

+   # 新しいパッケージ名を取得
+   DIFF_FILE="package_diff_$now.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"

これによって、アップグレードするパッケージを明確化させました。

次の展望

「どこまで自動化できるか」が課題となります。パッケージによっては設定ファイルを残すかどうかのウィザードが表示されるので、それに対する自動実行までいけたらと思います。

ChatGPTによるシェルスクリプト。(Ubuntuサーバのパッケージ全体の更新とサービス再起動の有無)

脆弱性などに対応するため、Linuxサーバのパッケージを最新に保つことは重要です。

ですが、どこかでトラブルが発生した際に「どのパッケージを更新してから異常が発生したか」の履歴を追うことも必要。

そこで、以下のシェルスクリプトをChatGPTに尋ねながら作ってみました。

動作確認環境

  • Ubuntu 20.04で動作を確認しました。
  • 筆者の好みの関係上、パッケージ管理はaptitudeを用いています。
  • また、サービス再起動の有無を確認するため、checkrestartをインストールします。(debian-goodiesをインストール)

要件

ChatGPTに要求した要件は以下の通りです。

  • パッケージ一覧のリストを作成する。
  • パッケージ全体のupdateを行う。
  • そのupdateで差異があった場合はファイルに出力して更新を行う。
  • サービス再起動があったらそれを標準出力とファイルに出力する。

かなりの試行を重ねて以下のスクリプトができあがりました。

スクリプト内容

  • update-packages.sh
#!/bin/bash

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

# aptitude updateを行います。
aptitude update

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

    # パッケージのキャッシュをクリアした上でパッケージアップグレードを実施。
    aptitude clean
    aptitude -y full-upgrade | tee $upgraded_packages >/dev/null

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

    # 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
        # ファイル名に日付を追加
        now=$(date +%Y%m%d)
        filename="restart_services_$now.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

記入後、以下を実施します。

sudo chown root:root update-packages.sh
# root権限で実施するため

sudo chmod 744 update-packages.sh

確認結果

sudo bash update-packages.sh

を実行後、

  • 現在インストールされているパッケージのバージョンを別ファイルに出力
  • パッケージのアップデート
  • その際に差分があればアップグレード
  • サービス再起動の有無を判断し、あればそのサービスを表示

という結果が出ました。

今後の展望

  • 可読性を高くする
  • 自動実行を行う
  • ログ化してローテーションを行う

等は実施したいです。

Redmine脆弱性対応。(4.2.x→4.2.10へのバージョンアップ)

これを行うきっかけ

こちらの記事:

https://blog.redmine.jp/articles/redmine-security-scanner/

で運用中のRedmineに既知の脆弱性がないかをチェックできるWebサービスの存在を知ったからでした。

で、現在のRedmineのURLを調べてみたら

E。

何度見てもEです。多少自信はあったので、この結果はその鼻っ柱を打ち砕くものでした。

そこで、現在運用中のRedmineのバージョンアップを図り脆弱性に対応します。

環境

  • Ubuntu 20.04 (AWS Lightsailで稼働中)
  • 動かしていたRedmine:4.2.9
  • Apache 2.4 / mod-passangerでRubyアプリを使用(Ruby 2.7系)
  • MySQL 8.0.3

作業に備えての前提

  • 本手順では「使用するDBの削除」を伴います。作業の際には慎重に行って下さい。
  • Webサービスを止める/何も入っていないRedmineが途中でできるため、ユーザアクセスができない状況が発生します。
  • また、筆者環境はfiles配下をクラウドストレージにマウントしています。手順は自身の環境に合わせてください。

さっくりとした手順

  1. スナップショットのバックアップ
  2. DBのバックアップ
  3. redmineのディレクトリを一度mvでリネームしてバックアップ。
  4. apache停止
  5. redmineのDBを消す。
  6. redmineのDBを新たに作る。(ユーザは全て権限があるので問題なし)
  7. apache再開
  8. ディレクトリを再作成し、新しい空のRedmineを作る。
  9. themesとpluginを再配置。filesのシンボリックリンクを貼り替える。
  10. themesとpluginを再配置した状態でDBマイグレーション。
  11. DBリストア。

データバックアップ

万一に備え、AWSからインスタンスのスナップショットを取得します。

mysqlによるDBバックアップ

mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql
# DB名やDBユーザは自信の環境に合わせます

データ退避

cd /var/lib
# Redmineが格納されているディレクトリの親ディレクトリに移動します

ls -ld redmine
# 退避対象のディレクトリがあることを確認します

sudo mv redmine redmine_$(date +%Y%m%d)

ls -ld redmine_$(date +%Y%m%d)

apache停止

ここでWebサービスを停止するのは、DBを削除するためです。

systemctl status apache2.service

sudo systemctl stop apache2.service

systemctl status apache2.service

DB削除

慎重に行って下さい。

sudo mysql -u root -p
show databases;
/* redmineのDBがあることを確認 */

drop database redmine;

show databases;
/* redmineのDBがないことを確認 */

CREATE DATABASE redmine character set utf8mb4;

show databases;
/* redmineのDBがあることを確認 */

exit

Redmine再インストール

ソースダウンロード

sudo mkdir /var/lib/redmine

sudo chown -R www-data:www-data /var/lib/redmine

sudo -u www-data svn co https://svn.redmine.org/redmine/branches/4.2-stable /var/lib/redmine
# 4.2系の最新安定版をダウンロードします

退避させたディレクトリからconfigファイルコピー

sudo cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/database.yml /var/lib/redmine/config/database.yml

cat /var/lib/redmine/config/database.yml
#中身確認

sudo cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/configuration.yml /var/lib/redmine/config/configuration.yml

cat /var/lib/redmine/config/configuration.yml
#中身確認

Redmineインストール

cd /var/lib/redmine

sudo -u www-data bundle install --without development test --path vendor/bundle

sudo -u www-data bundle exec rake generate_secret_token

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再開

systemctl status apache2.service

sudo systemctl start apache2.service

systemctl status apache2.service

再開後の仮パスワード作成

対象のRedmineにアクセスします。

IDとパスワードがadmin / admin に戻っている状態のため、仮パスワードを発行します。

退避したディレクトリからデータを再配置

cd /var/lib/redmine_$(date +%Y%m%d)/plugins

sudo cp -pir ./* /var/lib/redmine/plugins/
# プラグイン一式をコピーします

cd /var/lib/redmine_$(date +%Y%m%d)/public/themes

sudo cp -pir ./* /var/lib/redmine/public/themes/
# テーマ一式をコピーします

シンボリックリンク貼り替え

これは筆者の環境が

  • logディレクトリとfilesディレクトリを別の場所にリンクを張っているための措置です。
  • それ以外の場合は上述した /var/lib/redmine_$(date +%Y%m%d)からfilesやlogをコピーして下さい。
cd /var/lib/redmine

sudo rm -rf files

sudo rm -rf log

sudo ln -sf /mnt/wasabi/redmine/files files
# wasabiクラウドストレージを利用しています。

sudo chown -h www-data:www-data files

sudo ln -sf /var/log/redmine log
# ログは/var/log配下で一括管理しています。

sudo chown -h www-data:www-data log

データ再マイグレーション

プラグイン再マイグレーション

cd /var/lib/redmine

sudo -u www-data bundle install

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

apacheリスタート

systemctl status apache2.service

sudo systemctl restart apache2.service

systemctl status apache2.service

DBリストア

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

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

apacheリスタート

systemctl status apache2.service

sudo systemctl restart apache2.service

systemctl status apache2.service

動作確認

この状態でRedmineに管理者権限でログインします。手順通りなら

  • テーマ
  • 添付ファイル
  • プラグイン

などが正常に動いていると思います。

バージョンアップ後の診断

2023/03/18現在のRedmine4.2系の最新安定版:4.2.10がインストールされ、A+ と診断されました。

AWS LightsailからNextcloudをアンインストール。

AWS Lightsailで検証したNextcloudをアンインストールします。

導入していた環境

以下の環境で動かしていたNextcloudをアンインストールします。

  • Ubuntu 20.04
  • Apache 2.4
  • PHP 8.1
  • MySQL 8.0.3

そもそも:なぜアンインストールを行ったか?

スペック不足。

外部公開を目指しAWSのLightsailインスタンスで立ち上げましたが、

  • 表示速度
  • 処理能力

その他が納得いくものではありませんでした。

機能が被っている

  1. タスク管理/文書管理としてRedmine
  2. フォトアルバムとしてPiwigo

をインストールしているため、これらと機能が被るものを同一サーバにインストールするには望ましくありません。

ローカル環境との混同

これが一番の問題でした。ローカル(自宅環境)で既に運用しているNextcloudにはかなりのセンシティブ情報が含まれています。これが外部環境に誤ってアップロードされてしまうのはセキュリティポリシー上問題があると判断。

実施した手順

さっくりとした手順

  1. 本当にアンインストールしていいかいったん深呼吸します。
  2. クライアントからアカウントを削除します。(PCを利用している場合)
  3. バーチャルファイルを無効にします。
  4. DBを削除します。
  5. バーチャルファイルを削除します。
  6. ファイルを削除します。

アンインストールでも残すもの

  • PHPは既に他のサービスで動かしているので残します。
  • MySQL/Apacheについても同様です。

削除対象の確認

  1. 深呼吸する
  2. お茶を入れて飲みながらじっくり考え

削除を決意。

重要なファイルがあるかを確認

もう一度確認します。

PCクライアントから設定削除

WindowsなどでNextcloudのアカウントを設定していたので、こちらを削除します。

バーチャルファイル無効化

  • バーチャルファイル無効化
cd /etc/apache2/sites-available && pwd

sudo a2dissite nextcloud.conf
# 自分が設定した環境に合わせます。
  • 無効化反映
sudo systemctl restart apache2.service

この時点でアクセスできないことを確認です。

DB削除

mysql -u root -p
# mysqlのrootパスワードでログイン
SHOW DATABASES;
/* 削除対象を確認します */

DROP DATABASE nextcloud;
/* DB名を再度確認します */
/* 容赦なく削除されるので慎重に行ってください */

SHOW DATABASES;
/* DBがないことを確認します */

EXIT

プログラム一式を削除

  • nextcloud配置ディレクトリ削除
cd /var/www/html && pwd
# nextcloudが格納しているディレクトリ

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

sudo rm -rf nextcloud

ls -ld nextcloud
# ディレクトリがないことを確認します
  • nextcloudバーチャルファイル削除
cd /etc/apache2/sites-available && pwd
# 対象ディレクトリにいることを確認します

sudo rm nextcloud.conf 

後始末

  • 独自ドメインで運用していたのであれば、Nextcloudのために設定していたDNS情報を削除します。
  • 削除されたことを確認します。

最後に

スペックや機能の面でほぼほぼ「こうなるだろうな」という予感はありました。
ですが、一応、やってみるだけの価値はありました。(ローカル環境と比べ著しく遅いと体感でき、後の未練を断つことができました)

ChatGPTによるシェルスクリプト。(日時を指定してのシャットダウン)

概要

「要件は定義できるけどそれを実行する術を知らない」とき、ChatGPTは非常に有用です。

そこで、以下のスクリプトを書いてもらいました。

ChatGPTへの要件

  • 指定時刻にはLinuxサーバのシャットダウンを行いたい。
  • 検証機なので、副系への切り替えなどは考慮しない。
  • 後々を考えて、スクリプトとして残し、思い立ったときには実行できるようにしたい。

ということで、以下の質問をしました。

計画停電に備え、指定時刻にLinuxサーバのシャットダウンをしたいと思います。
そこで、以下のシェルスクリプトを書いてください。

  1. 対話式で日付(YYYYMMDD)と時刻(HHMM)の入力プロンプトを出す
  2. 形式が違う場合はエラーを出し、再度の入力を求める
  3. 入力後、指定日時を表示しy/nで確認
  4. 受付後、バックグラウンドで常駐
  5. 指定時刻になったらシャットダウンを行う

ChatGPTからの回答

以下が、示したスクリプトです。

  • スクリプト名:shutdown.sh
#!/bin/bash

# 1. 日付と時刻の入力プロンプトを出す
read -p "シャットダウンする日時を指定してください(YYYYMMDD HHMM): " shutdown_time

# 2. 形式が違う場合はエラーを出し、再度の入力を求める
until [[ $shutdown_time =~ ^[0-9]{8}\ [0-9]{4}$ ]]; do
    echo "日付と時刻の形式が正しくありません。再度入力してください。"
    read -p "シャットダウンする日時を指定してください(YYYYMMDD HHMM): " shutdown_time
done

# 3. 入力後、指定日時を表示しy/nで確認
echo "指定された日時は ${shutdown_time:0:4}/${shutdown_time:4:2}/${shutdown_time:6:2} ${shutdown_time:9:2}:${shutdown_time:11:2} です。"
read -p "この日時でシャットダウンを行いますか? (y/n): " confirm

# 4. 受付後、バックグラウンドで常駐
if [[ $confirm =~ ^[Yy]$ ]]; then
    shutdown_sec=$(date -d "${shutdown_time:0:8} ${shutdown_time:9:4}" +%s)
    current_sec=$(date +%s)
    if [[ $shutdown_sec -lt $current_sec ]]; then
        echo "指定された日時は過去のため、シャットダウンは行われません。"
    else
        wait_sec=$(( shutdown_sec - current_sec ))
        echo "シャットダウンまでの待機時間は $wait_sec 秒です。"
        sudo sleep $wait_sec && sudo shutdown -h now &
        echo "シャットダウンを開始しました。"
    fi
else
    echo "シャットダウンを中止しました。"
fi

動作確認

上記スクリプトを対象サーバに保存後、以下の処理を行いました。

sudo chown root:root shutdown.sh
# shutdownコマンドは管理者ユーザのみ実行権限があるので所有者もrootにします

sudo chmod 744 shutdown.sh
# rootのみに実行権限を与えます
sudo bash shutdown.sh

と入力後、想定通りYYYYMMDD形式とHHMM形式で日付と時間を入力するよう求められました。なので、30分後などの日時を指定して実行します。

バックグラウンドで実行されているか、以下を確認しました。

ps aux |grep shutdown

# 下記の表示を確認。
# root      107296  0.0  0.0  10536   280 pts/0    S    14:27   0:00 bash shutdown.sh

その後、実行時間になってシャットダウンを確認。

動作確認日

2023/03/14

Ubuntu 20.04に最新安定版のnodejsのインストール。

ふと思い立ったので、AWS Lightsailで稼働するUbuntuに最新安定版のnodejsを入れてみました。

動作確認環境

  • Ubuntu 20.04

実施した手順

さっくりとした手順

  1. aptitude(apt)を用いてnodejsとnpmをインストールします。
  2. n packageシステムをインストールします。
  3. n packageで最新安定版のnodejsをインストールします。
  4. 最初に入れたnodejsとnpmをアンインストールします。
  5. nodeとnodejsが同じコマンドを参照するようにシンボリックリンクを張ります。

aptitudeによるnodejsとnpmのインストール

パッケージインストール

こちらではaptitudeを用いています。好みなどに合わせてaptに読み替えてください。

sudo aptitude update

sudo aptitude install nodejs

sudo aptitude install npm
# 300近いパッケージが一気にインストールされます

インストール後の確認

nodejs -v
# v10.19.0が表示されることを確認

npm -v
# 6.14.140が表示されることを確認

n packageのインストール

sudo npm install -g n

n packageによる最新版安定版のインストール

sudo n stable

表示確認

node -v
# 18.15.0が表示されることを確認
nodejs -v
# 10.19.0が表示されることを確認

と、両者のバージョンが異なります。aptitude(apt)でインストールしたパッケージが残っているために発生しているようです。

そこで、最初にインストールしたパッケージをアンインストールします。

最初に入れたnodejsとnpmをアンインストール

sudo apt purge nodejs npm

その後、一度シェルから抜けます。

シンボリックリンク実行

再ログイン後、nodejsのパスが通っていませんでした。

which node
# /usr/local/bin/nodeと表示


which nodejs
# 何も表示されず

コマンドが見つからないので、これも修正します。

sudo ln -s /usr/local/bin/node /usr/local/bin/nodejs
node -v
# 18.15.0が表示されることを確認

nodejs -v
# 18.15.0が表示されることを確認

両方で同じバージョンが表示されるようになりました。

動作確認日

2023/03/13

Page 4 of 10

Powered by WordPress & Theme by Anders Norén