タグ: Ubuntu Page 5 of 15

Ubuntu24.04サーバの初期設定。(ufwとfail2ban)

  • インターネット上に公開されたWebサーバを運営している
  • IPアドレスが固定されていない

場合に必要な措置となる、NW保護を行います。

環境

  • Ubunt 24.04

さっくりとした手順

  • ufwを有効化します。
  • fail2banをインストールします。
  • fail2banの設定をします。

SSHとWeb通信のみを有効化させます。

  • SSH接続を許可するが過度な接続を制限する
sudo ufw limit proto tcp from any to any port 22
  • http通信を許可
sudo ufw allow 80/tcp
  • https通信を許可
sudo ufw allow 443/tcp
  • ufwの設定を反映
sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)?はyで続けます。

  • 反映確認
sudo ufw status

以下を確認します。

状態: アクティブ

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

別ウィンドウで新たなSSH接続を行い、通信できるかを確認します。

  • 再起動後でもufwが有効であることを確認
sudo reboot

再起動後、SSH接続ができることを確認します。

sudo ufw status

上記、許可された設定が有効になっていることを確認します。

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

  • インストール
sudo aptitude update && sudo aptitude install fail2ban
  • インストール確認
systemctl status fail2ban.service 

active(running)を確認します。

fail2banを設定します。

  • jail.localの作成

教義と進行に沿ったエディタを用いて/etc/fail2ban/jail.localを管理者権限で編集します。

[ufw]
enabled=true
filter=ufw.aggressive
action=iptables-allports
logpath=/var/log/ufw.log
maxretry=1
bantime=-1
ignoreip = 127.0.0.0/8 ::1
# ignoreipは任意の(ある程度アクセス元が判明しているIPアドレス)を指定ください。スペース区切りで複数指定できます。

[sshd]
enabled=true
filter=sshd
mode=normal
port=22
protocol=tcp
logpath=/var/log/auth.log
maxretry=3
bantime=-1
ignoreip = 127.0.0.0/8 ::1
# ignoreipは任意の(ある程度アクセス元が判明しているIPアドレス)を指定ください。スペース区切りで複数指定できます。
  • ufw.aggressiveを作成
sudo tee /etc/fail2ban/filter.d/ufw.aggressive.conf > /dev/null << 'EOF'
[Definition]
failregex = [UFW BLOCK].+SRC=<HOST> DST
ignoreregex =
EOF
  • 設定反映
sudo systemctl restart fail2ban.service
systemctl status fail2ban.service 

active(running)を確認します。

  • 設定確認
sudo cat /var/log/fail2ban.log

この時点で、

2024-09-01 17:14:26,476 fail2ban.filter         [1720]: INFO    [ufw] Found xxx.xxx.xxx.xxx - 2024-09-01 17:14:26
2024-09-01 17:14:26,623 fail2ban.actions        [1720]: NOTICE  [ufw] Ban xxx.xxx.xxx.xxx
2024-09-01 17:14:44,198 fail2ban.filter         [1720]: INFO    [ufw] Found yyy.yyy.yyy.yyy - 2024-09-01 17:14:44
2024-09-01 17:14:44,647 fail2ban.actions        [1720]: NOTICE  [ufw] Ban yyy.yyy.yyy.yyy

と、fail2banが不審なアクセスを弾いています。

sudo fail2ban-client status ufw

設定して10分も経たないうちに100ほどのIPアドレスがブロックされていました。

WebARENA Indigo®を利用したUbuntu 24.04サーバへの立ち上げ。

概要

Ubuntu 20.o4サーバのEOLが近づいてきたため、現時点でのUbuntu最新版LTSサーバのvpsを立ち上げたときの記録です。

選定したサービス:WebARENA Indigo®

https://web.arena.ne.jp/indigo

今回は国産vpsを選定です。

  • 円安の影響下でAWS Lightsailが高額になった
  • 回線キャリアが運営しているだけあってNWが安定(アップロードも500Mbps/ベストエフォート)
  • Lightsailと同じく月額課金のため安心

が選定理由です。

申し込みそのものは

  • サインイン
  • クレジットカード情報の入力
  • 携帯電話を利用した本人確認

で、アカウント作成後は

こんな形のダッシュボードができました。

ここからUbuntuサーバを立ち上げていくのですが、罠が待っていました。

Ubuntu24.04サーバの罠-rsa秘密鍵、再び-

上記ダッシュボードから

  1. サービス管理
  2. インスタンス管理
  3. SSH鍵

で鍵を作成後、

  1. インスタンス
  2. インスタンス作成

で、Ubuntu 24.04インスタンスを作成するとログインできません

過去にもこういう事例があったので、それに沿って対応します。

これと同じく、

(SSH-1アルゴリズムによるRSA認証が無効化されます)

に引っかかるので、

  1. Ubuntu 20.04でインスタンスを立ち上げる
  2. アクセスできるアカウントを作成する
  3. Ubuntu 22.04/24.04に対応した秘密鍵を作成する
  4. その上でUbuntuのアップグレードをする

回りくどい方法を採りました。

最初のインスタンスへのアクセス

  1. WebARENAのコンソールからSSH鍵を作ります。
    • SSH鍵の作成
    • SSH鍵名を入力して作成をクリック
    • ダウンロードされた秘密鍵を利用
  2. Ubuntu20.04でインスタンスを立ち上げます。
    • インスタンス管理>インスタンスに移動
    • イメージの選択「Ubuntu」>「Ubuntu20.04」を選択
    • 自分の運用に沿ったサイズを選択
    • SSH鍵は上記で作成したものを選択
    • インスタンス名は任意のものを入力
    • 「インスタンスの作成」をクリック
  3. インスタンスを起動します。OSがインストールされたら、「操作」から「インスタンスの起動」をクリックします。
    • AWSと違って、最初からグローバルのIPアドレスがアタッチされているのが利点です。
    • ドメインとDNS登録できる環境があれば、この時点で名前解決できるようにします。
  4. ターミナルクライアントソフトから、インポートされた秘密鍵を使ってアクセスします。
    • アクセス先:アタッチされたIPアドレス
    • ユーザー名:ubuntu
    • 秘密鍵を利用
    • パスワード:空白

Ubuntu 22.04以降に対応したアカウントの作成

  • root昇格
sudo su -

パスワードは設定されていないので空エンターです。

  • ユーザー作成
adduser hoge

hogeは任意のユーザー名です。その後、パスワードなどを設定していきます。

  • 作成したユーザーを管理者グループに入れる
usermod -G sudo hoge

hogeは自分が作成したユーザー名です。

  • 作成したユーザーに切り替え
su - hoge
  • ユーザー名確認
whoami

作成したユーザー名であることを確認します。

  • root昇格確認
sudo su -

パスワード入力後、作成したユーザーがrootに昇格できることを確認します。

  • 作成したユーザーに戻る
exit && whoami

作成したユーザーであることを確認します。

秘密鍵作成

  • edEd25519での秘密鍵作成
ssh-keygen -t ed25519

鍵の格納場所は初期値(/home/hoge/.ssh)なので空エンターです。特別な運用がない限りはパスワードを設定します。

  • 秘密鍵確認
cd .ssh && pwd

/home/hoge/.sshにいることを確認します。

  • ファイルの内容確認
ls -l
  1. id_ed25519
  2. id_ed25519.pub

の2つを確認します。

cat id_ed25519
cat id_ed25519.pub

とした上で内容をコピーし、ローカル環境に貼り付けて保管します。この、秘密鍵と公開鍵はサーバセキュリティの生命線です。管理と保管は厳密に行ってください。

  • サーバ上から秘密鍵を削除
rm id_ed25519

サーバにアクセスするための秘密鍵がサーバ上にあっては意味がありません。「ローカルに秘密鍵があることを再確認した上で」秘密鍵を削除します。

  • 公開鍵の名前と権限変更
mv id_ed25519.pub authorized_keys
chmod 600 authorized_keys

公開鍵の名前をauthorized_keysに変更して、所有者のみがアクセスできるようにします。

ローカルPCからアクセスできることを確認します。

ターミナルクライアントソフトで

  • IPアドレス(設定していればドメイン名)
  • 作成したユーザー名とパスワード
  • ローカルに保管した秘密鍵

を用いてアクセスできることを確認します。

Ubuntuのアップグレード

Ubuntu 20.04から24.04まで上げるので、二段階に上げます。

また、OSの再インストールなので、休憩時間を一切挟まず、一気通貫で行ってください。

Ubuntu 20.04→22.04

  • root昇格
sudo su -

ここから全てroot権限で設定します。

  • パッケージの最新化とアップグレード前の再起動
apt update && apt upgrade && apt autoremove

パッケージを最新版にして不要パッケージを削除します。途中で不要パッケージを消すかを求められるので[y]で消去します。

reboot

再起動を行います。

  • 再ログインしてroot昇格
sudo su -
  • OSのアップグレード
do-release-upgrade

アップグレード中にプロンプトから質問されたこと

以下、主要な質問事項です。コメント(#の後)に概要を書いています。

Reading cache

Checking package manager

Continue running under SSH?

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

# SSHのポートを追加するか
# → y

Starting additional sshd 

To make recovery in case of failure easier, an additional sshd will 
be started on port '1022'. If anything goes wrong with the running 
ssh you can still connect to the additional one. 
If you run a firewall, you may need to temporarily open this port. As 
this is potentially dangerous it's not done automatically. You can 
open the port with e.g.: 
'iptables -I INPUT -p tcp --dport 1022 -j ACCEPT' 

To continue please press [ENTER]

# 設定を変更するか
# → Enter

Do you want to start the upgrade?


4 packages are going to be removed. 85 new packages are going to be
installed. 555 packages are going to be upgraded.

You have to download a total of 247 M. This download will take about
49 seconds with a 40Mbit connection and about 6 minutes with a 5Mbit
connection.

Fetching and installing the upgrade can take several hours. Once the
download has finished, the process cannot be canceled.

 Continue [yN]  Details [d]

# アップグレード前の最終確認
# → y

There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions of service for the system, you will     x
   x normally be prompted on each upgrade for the list of services you wish to restart.  You can choose this option to avoid being prompted; instead, all necessary restarts will be done for you automatically so you can avoid being   x
   x asked questions on each library upgrade.                                                                                                                                                                                            x
   x                                                                                                                                                                                                                                     x
   x Restart services during package upgrades without asking?

# アップグレード時、各種サービスを再起動前にプロンプトでy/nを確認するか
# → 質問されるのがめんどいので yes

# この間、SSH等の設定変更を行うか訊いてきます。プロンプトの選択を変えずに先に進みました
# keep the local version currently installed

Remove obsolete packages? 

# 不要パッケージの削除
# → Yes

System upgrade is complete.

Restart required

To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.

Continue [yN]

# アップグレード完了後にリブートするか
# → y
  • 22.04へのアップグレードを確認

再起動後、再びアクセスします。

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

となっていればまずはアップグレード完了です。

Ubuntu 22.04 → 24.04

  • root昇格
sudo su -
  • OSのアップグレード
do-release-upgrade

途中のプロンプトはほぼ同じなので割愛。再起動後、

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS"

にて成功です。

初期ユーザーの無効化

WebARENAのコンソールで作成された初期ユーザーはパスワードがない状態なので、無効化します。

  • root昇格
sudo su -
  • 初期ユーザーのsshディレクトリに移動
cd /home/ubuntu/.ssh
  • 公開鍵退避
mv authorized_keys ../

以上、仕様によって「すぐに立ち上げ」というわけには行きませんでしたが、クラウドでUbuntu24.04サーバを立ち上げることができました。

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 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に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 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. 既存機能が使えることを確認します。

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. 他のサービスが正常に稼働していることを確認します。

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. 既存のページにアクセスし、編集できること(編集画面が白くならないこと)を確認します。

Page 5 of 15

Powered by WordPress & Theme by Anders Norén