タグ: Ubuntu Page 4 of 16

WordPressの設定変更:Confファイルによるセキュリティ設定

apacheのバーチャルファイルにセキュリティ設定を追加します。

バーチャルサイトの設定ファイルバックアップ

  • バックアップ
sudo cp -pi /etc/apache2/sites-avaiable/wordpress.conf /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d)

ファイル及びバックアップディレクトリは自分の環境に合わせます。

  • diffによる差分確認
diff -u /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d) /etc/apache2/sites-avaiable/wordpress.conf

エラーがなければバックアップは成功です。

バーチャルサイトの設定ファイル編集

DocumentRootの項目に、以下のように編集します。/home/www-data/wordpressの部分は自分の環境に合わせます。

ここでは、サーバのリソースを食い潰し、robots.txtを無視するクローラーを止めることにしています。

また、こういったクローラーであることを隠し、ユーザーエージェントを偽装するIPもレンジでブロックしています。

    DocumentRoot /home/www-data/wordpress
    <Directory /home/www-data/wordpress>
        Options -Indexes
        Options FollowSymLinks
        AllowOverride All
        ## スパムクローラーを拒否
        SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" spam_crawler
        SetEnvIfNoCase User-Agent "SemrushBot/7~bl" spam_crawler
        SetEnvIfNoCase User-Agent "AhrefsBot" spam_crawler
        SetEnvIfNoCase User-Agent "MJ12bot" spam_crawler
        SetEnvIfNoCase User-Agent "DotBot" spam_crawler
        SetEnvIfNoCase User-Agent "Baiduspider" spam_crawler
        SetEnvIfNoCase User-Agent "YandexBot" spam_crawler
        SetEnvIfNoCase User-Agent "Sogou web spider" spam_crawler
        SetEnvIfNoCase User-Agent "Exabot" spam_crawler
        SetEnvIfNoCase User-Agent "MegaIndex.ru" spam_crawler
        SetEnvIfNoCase User-Agent "SeznamBot" spam_crawler
        SetEnvIfNoCase User-Agent "BLEXBot" spam_crawler
        SetEnvIfNoCase User-Agent "Bytespider" spam_crawler
        SetEnvIfNoCase User-Agent "DataForSeoBot" spam_crawler
        SetEnvIfNoCase User-Agent "serpstatbot" spam_crawler
        SetEnvIfNoCase User-Agent "SeekportBot" spam_crawler
        SetEnvIfNoCase User-Agent "index.community crawler" spam_crawler
        SetEnvIfNoCase User-Agent "PetalBot" spam_crawler
     <RequireAll>
      Require all granted
      ##スパムクローラーを拒否
      Require not env spam_crawler
        #偽装エージェントを拒否
        Require not ip 190.92.0.0/16
        Require not ip 159.138.0.0/16
        Require not ip 166.108.0.0/16
        Require not ip 124.243.0.0/16
        Require not ip 114.119.0.0/16
        Require not ip 119.8.0.0/16
        Require not ip 110.238.0.0/16
        Require not ip 217.113.194.0/24
        Require not ip 34.123.0.0/16
     </RequireAll>
    ## 設定ファイルのアクセス拒否
     <Files wp-config.php>
      Require all denied
     </Files>
     <Files xmlrpc.php>
      Require all denied
     </Files>
     ## キャッシュを有効
     ExpiresActive On
     ExpiresByType image/jpg "access plus 1 year"
     ExpiresByType image/jpeg "access plus 1 year"
     ExpiresByType image/gif "access plus 1 year"
     ExpiresByType image/png "access plus 1 year"
     ExpiresByType text/css "access plus 1 month"
     ExpiresByType application/pdf "access plus 1 month"
     ExpiresByType text/x-javascript "access plus 1 month"
     ExpiresByType application/x-shockwave-flash "access plus 1 month"
     ExpiresByType image/x-icon "access plus 1 year"
     ExpiresDefault "access plus 2 days"
    </Directory>
     <Files xmlrpc.php>
      Require all denied
     </Files>

は運用に合わせて無効化の可否を決めてください。

  1. モバイルアプリからのリモート投稿ができなくなります。
  2. ピンバックとトラックバックを受け付けることができなくなります。
  3. Jetpackの一部機能が動作しなくなります。
  4. その他、リモート投稿や自動投稿のプラグインが影響を受けます。

編集後、

diff -u /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d) /etc/apache2/sites-avaiable/wordpress.conf

として、上記の差分が出ることを確認します。

設定反映

  • 設定有効
sudo a2ensite wordpress.conf

→ 一時的に無効にしている場合

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache2再起動
sudo systemctl restart apache2.service

その後、Wordpressが正常に閲覧できることを確認します。

確認後、追加のセキュリティ設定を行わないのであれば、

sudo a2dissite wordpress.conf
sudo systemctl restart apache2.service

として、無用な攻撃を防ぎます。

Ubuntu 24.04にWordPressをインストール。

概要

CMSの代名詞、Wordpressをきちんとした手順で書いていなかったのでこの機会にメモを残します。

手順が比較的簡単なだけに狙われやすいのも納得。

なので、ここではインストールだけではなく、セキュリティ対策を含めて実施します。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL
  • PHP 8.3

前提

  • Apacheの初期設定は完了しています。
  • mod_securityが稼働しています。
  • 適切に名前解決できることが条件です。(DNS設定済み)
  • 証明書は適切なものを準備済みです。

さっくりとした手順

  1. WordPress用のデータベースを作成します。
  2. WordPressのプログラムを配置します。
  3. WordPressをWebサービスで動かす設定を行います。
  4. WordPressをブラウザでインストールします。
  5. インストール後、一度、設定を解除します。

※Wordpressは非常に狙われやすいWebアプリです。そのため、安定稼働するまでは設定をするたびにWebサービスから切り離します。

DB作成

  • MySQLログイン
mysql -u root -p
  • DB作成
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

DB名(mt)は自分の環境に合わせます。

  • ユーザー作成
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'your_password';

ユーザー(wpuser)やパスワードは自分の環境に合わせます。適正なパスワードを設定してください。

  • 権限委譲
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
  • 設定反映、MySQLログアウト
FLUSH PRIVILEGES;
exit

作成したDB確認

  • MovableTypeのユーザーでログイン
mysql -u wpuser -p
  • DB確認
SHOW DATABASES;

WordPressのDBがあることを確認します。

  • DB切り替え
use wordpress;
  • DBの文字コード確認
SHOW VARIABLES LIKE 'character_set_database';

Valueutf8mb4であることを確認

  • DBの照合順序確認
SHOW VARIABLES LIKE 'collation_database';

Valueutf8mb4_binであることを確認

exit

WordPress取得

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

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

  • wget
wget https://wordpress.org/latest.tar.gz
  • ファイルの解凍
tar -xzvf latest.tar.gz
  • ファイルの所有権変更
sudo chown -R www-data:www-data wordpress
  • www-dataディレクトリに移動
sudo mv wordpress /home/www-data/wordpress

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

WordPressWebサイト設定編集

ログ格納用のディレクトリ作成

  • ログ格納ディレクトリ作成
sudo mkdir -p /var/log/wordpress
  • ログ格納ディレクトリの所有者変更
sudo chown www-data:www-data /var/log/wordpress

WordPressのバーチャルサイト作成

  • /etc/apache2/site-available配下に、wordpress.confを管理者権限で作成し、以下のように編集していきます。
<VirtualHost *:80>
    # ドメイン名を指定します
    servername hoge.example.com
    # HTTPアクセスを強制的にHTTPSにリダイレクトします
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
    # ドメイン名を指定します
    ServerName hoge.example.com
    CustomLog /var/log/wordpress/wp_access.log combined
    ErrorLog /var/log/wordpress/wp_error.log


    # WordPressを配置したディレクトリを指定します。
    DocumentRoot /home/www-data/wordpress
    <Directory /home/www-data/wordpress>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    #セキュリティヘッダー付与

    Header always set Strict-Transport-Security "max-age=63072000"
    Header set X-Content-Type-Options "nosniff"
    Header always append X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"


#SSL設定
  SSLEngine on
    Protocols h2 http/1.1
    SSLCertificateFile /path/to/ssl/certificate.crt
    SSLCertificateKeyFile /path/to/ssl/private.key
   # 証明書と秘密鍵のパスを指定します

    # Mod_Security設定
    SecRuleEngine DetectionOnly
    # Webでインストールを行うため、最初は検知モードに設定します。
    ## ファイルのアップロードをできるようにします。
    SecRequestBodyInMemoryLimit 524288000
    SecRequestBodyLimit 524288000

    ## テスト用の検知パラメーター
    SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"


</VirtualHost>

# これらのセクションはSSL暗号化強度を高めるための記述です
# </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

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

設定ファイル有効化

  • コンフィグ読み込み
sudo a2ensite wordpress.conf
  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service

ブラウザから確認

ブラウザで設定したURLにログインします。

インストール画面が出てきます。言語を選びContinueをクリックします。

ボタンをクリックします。

設定したDB名、ユーザー、パスワードを入力します。

DBと接続されると、以下が表示されます。インストール実行をクリックします。

サイト名などを入れていきます。

ここまで出たらOKです。

インストール後の処理(一時停止)

圧倒的なシェアを誇るWordpressは攻撃者が真っ先に狙うサービスです。
そのため、安定稼働するまでは確認後に一度停止して、物理的なアクセスを防ぎます。

  • バーチャルサイトの設定ファイル無効化
sudo a2dissite wordpress.conf
  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service

無効化後、上記の設定ファイルで指定したURLにアクセスできないことを確認します。

ログ調査時にIPやステータスコードを抜き出すコマンド。

Apacheのアクセスログを調査するとき何かと使うのでメモです。

アクセスログからIPのみを抽出してカウント

 awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "/var/log/apache/access.log" | sort -u 

表示例

3 xxx.xxx.xxx.xxx
2 yyy.yyy.yyy.yyy
1 zzz.zzz.zzz.zzz

と、煩雑なその他のログを探すことなく件数とIPをカウントします。

更にステータスコードも表示

awk 'match($0, /[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { ip = substr($0, RSTART, RLENGTH) } match($0, /" [0-9]{3} /) { status = substr($0, RSTART+2, 3); print ip, status }' /var/log/apache/access.log | sort | uniq -c | sort -nr

表示例

5 xxx.xxx.xxx.xxx 200
3 yyy.yyy.yyy.yyy 404
2 zzz.zzz.zzz.zzz 500

ステータスコードが入るので、アクセス制御の有無やそれを突破してきたIPも調べられます。

Apacheにmod_dosdetector 導入

概要

過剰なWebクローラーによりサーバのパフォーマンスが落ちることがあるため、mod_dosdetectorを入れてみます。

mod_dosdetector は、Apache HTTP Server 用のモジュールで、DoS(Denial of Service)攻撃を検出し、対策を講じるためのものです。このモジュールは、特定のIPアドレスからの過剰なリクエストを監視し、しきい値を超えた場合にそのIPアドレスを一時的にブロックすることで、サーバーのリソースを保護します。

Ubuntu 20.04にはこちらを入れましたが、

  • ufwとの連携でサーバに負荷がかかる
  • 細かい設定が可能

ということで、こっちをUbuntu 24.04に入れてみます。

環境

  • Ubuntu 24.04
  • Apache 2.4
    • Apache2-devがインストールされていることが前提です。

さっくりとした手順

  1. gitでソースをダウンロードします。
  2. Makefileを書き換えた上でインストールします。
  3. 設定ファイルを作成します。
  4. 設定を有効化し、Apacheを再起動します。

mod_dosdetectorのダウンロード

  • ソース格納ディレクトリに移動
cd /usr/local/src && pwd

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

  • git clone
sudo git clone https://github.com/stanaka/mod_dosdetector.git
  • 展開したディレクトリに移動
cd mod_dosdetector && pwd

Makefileの書き換えとインストール

  • Makefile修正

デフォルトのMakefileは/usr/sbin/apxsとなっているため書き換えます。

sudo sed -i 's|^APXS=.*|APXS=/usr/bin/apxs|' Makefile
  • インストール
sudo make install
  • インストール確認
cat /etc/apache2/mods-available/dosdetector.load

LoadModule dosdetector_module /usr/lib/apache2/modules/mod_dosdetector.soと表示されます。

設定ファイル追加

参考: mod_dosdetectorを使ってみましょうよ。~挫折を乗り越え~

sudo tee /etc/apache2/mods-available/dosdetector.conf > /dev/null <<EOF
<IfModule dosdetector_module>
DoSDetection on
DoSPeriod 60
DoSThreshold 5
DoSHardThreshold 10
DoSBanPeriod 60
DoSTableSize 100
DoSIgnoreContentType ^(image/|application/|text/javascript|text/css)
</IfModule>
EOF
  • DoSDetection on
    • 説明: DoS (Denial of Service) 検出を有効にします。
  • DoSPeriod 60
    • 説明: DoS攻撃を検出するための監視期間を秒単位で指定します。
  • DoSThreshold 5
    • 説明: DoS攻撃と見なすリクエストの閾値を指定します。
  • DoSHardThreshold 10
    • 説明: より厳しい閾値を指定します。
    • 60秒間に同一IPアドレスから10回以上のリクエストがあった場合、即座にそのIPアドレスをブロックします。
  • DoSBanPeriod 60
    • 説明: DoS攻撃と見なされたIPアドレスをブロックする期間を秒単位で指定します。
  • DoSTableSize 100
    • 説明: DoS検出のために保持するIPアドレスの最大数を指定します。
  • DoSIgnoreContentType ^(image/|application/|text/javascript|text/css)
    • 説明: DoS検出から除外するコンテンツタイプを正規表現で指定します。

設定有効化とApache再起動

  • mod有効化
sudo a2enmod dosdetector
  • Webサービス再起動
sudo systemctl restart apache2.service

まずはこれで様子を見てみます。

Firefly-iiiのアップデート。(6.1.2→6.2.1)

LAMP環境で動く財務管理システム、firefly-iiiを6.1.2→6.2.1にアップグレードしたときの手順メモです。

参考:Upgrade a self-managed server/Firefly III documentation

環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0.39
  • PHP 8.3.12
  • Composer 2.7.9
  • firefly-iii 6.1.2

さっくりとした手順

  1. DBのバックアップを取得します。
  2. 最新版のパッケージをダウンロードして展開します。
  3. 利用中のfirefly-iiiを待避させます。
  4. 待避させたfirefly-iiiからファイル/ディレクトリをコピーします。
  5. アップグレードを行います。

DBのバックアップ

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

任意の作業ディレクトリに移動します。

  • DBバックアップ
mysqldump --no-tablespaces --single-transaction -u username -h localhost -p database_name > DB_Backup.$(date +%Y%m%d).sql

usenamedatabase_name、及びDB_Backupは自分の環境に合わせます。

  • バックアップ確認
head -100 DB_Backup.$(date +%Y%m%d).sql

バックアップができていること、平文でSQLが読めることを確認します。

パッケージ取得

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

任意の作業ディレクトリに移動します。

  • wget
wget https://github.com/firefly-iii/firefly-iii/releases/download/v6.1.21/FireflyIII-v6.1.21.zip
  • ファイル所有者変更
sudo chown www-data:www-data FireflyIII-v6.1.21.zip
  • ファイル確認
ls -l FireflyIII-v6.1.21.zip

ファイルがあること、所有者がWebアプリ実行ユーザ(www-data)であることを確認します。

アップデート前のfirefly-iiiを待避

  • ディレクトリごと待避
sudo mv /home/www-data/firefly-iii /home/www-data/firefly-iii.$(date +%Y%m%d)

自分の環境に合わせます。firefly-iiiがインストールされているディレクトリをまるごと移動します。

  • 待避確認
ls -ld /home/www-data/firefly-iii

→ ディレクトリが無いこと

ls -ld /home/www-data/firefly-iii.$(date +%Y%m%d)

→ ディレクトリがあること

アップデートパッケージの解凍と配置

  • 解凍
sudo -u www-data unzip -o /hoge/FireflyIII-v6.1.21.zip -x "storage/*" -d /home/www-data/firefly-iii

/hogeは先ほど取得したパッケージがある場所です。アップデート前と同じ位置、名前に解凍します。

  • 解凍・配置確認
ls -l /home/www-data/firefly-iii

ファイル一式があり、www-dataが所有者になっていること

アップデート前のファイル・ディレクトリをコピー

  • 待避させたディレクトリに移動
cd /home/www-data/firefly-iii.$(date +%Y%m%d) && pwd

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

  • .envファイルをコピー
sudo cp -pi .env /home/www-data/firefly-iii/.env

コピー先のディレクトリは自分の環境に合わせます。

  • .envファイルコピー確認
ls -l /home/www-data/firefly-iii/.env

ファイルがあることを確認します。

  • storageディレクトリのコピー
sudo cp -pir storage /home/www-data/firefly-iii/
  • storageディレクトリのコピー確認
ls -l /home/www-data/firefly-iii/storage

ファイルやディレクトリがあることを確認します。

アップグレード

  • アップグレード後のディレクトリに移動
cd /home/www-data/firefly-iii && pwd

先ほど展開したディレクトリに移動します。

  • DBマイグレーション
sudo -u www-data php artisan migrate --seed

Yesが見えるようにして実行します。

  • 一時複合化
sudo -u www-data php artisan firefly-iii:decrypt-all
  • アプリケーションキャッシュクリア
sudo -u www-data php artisan cache:clear
  • コンパイルされたビューのキャッシュクリア
sudo -u www-data php artisan view:clear
  • DBアップグレード
sudo -u www-data php artisan firefly-iii:upgrade-database
  • Laravel assportのキー生成
sudo -u www-data php artisan firefly-iii:laravel-passport-keys

アップグレード反映・確認

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service
  • アップデート確認
  1. アップデートを行ったfirefly-iiiサイトにブラウザでアクセスします。
  2. ログインできることを確認します。
  3. バージョンが上がっていることを確認します。
  4. 登録操作などができることを確認します。

アップデート後の処理:mysqldumpの削除

  • バックアップしたDBの削除
cd /hoge && pwd

mysqldumpを実行したディレクトリに移動します。

  • dump削除
rm DB_Backup.$(date +%Y%m%d).sql
  • バックアップ削除確認
head -100 DB_Backup.$(date +%Y%m%d).sql

ファイルが読めないことを確認します。

アップデート後の処理待避させたディレクトリの削除

  • 削除前:待避ディレクトリ確認
ls -ld /home/www-data/firefly-iii.$(date +%Y%m%d)

ディレクトリがあることを確認します。(自分の環境に合わせます。)

  • 待避させたディレクトリの削除
[ -d "/home/www-data/firefly-iii.$(date +%Y%m%d)" ] && sudo rm -rf "/home/www-data/firefly-iii.$(date +%Y%m%d)"

それぞれ、待避させたディレクトリであることを入念に確認してから行ってください。

  • 削除前:待避ディレクトリ確認
ls -l /home/www-data/firefly-iii.$(date +%Y%m%d)

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

Nextcloudのメンテナンス時に出てきたエラーに対処。

環境

  • Ubuntu 24.04
  • Nextcloud 29.8
  • PHP 8.3
  • MySQL 8.0.39
  • Apache 2.4

警告内容

Nextcloudのメンテナンスのため、以下のコマンドを実行。

sudo -u www-data php occ maintenance:repair

この警告が出たので対処をしていきます。

WARNING: Failed to create filecache trigger (compatibility mode will be used): Anng a query: SQLSTATE[HY000]: General error: 1419 You do not have the SUPER privilege andmight* want to use the less safe log_bin_trust_function_creators variable)
WARNING: ffmpeg binary could not be configured

DBのトリガー修正

mysqlの設定ファイルのバックアップ

サーバの要となるサービスです。バックアップは確実に行ってください。

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

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

  • ファイルのバックアップ確認
diff -u /path/to/backup/directory/mysqld.conf.$(date +%Y%m%d) /etc/mysql/mysql.conf.d/mysqld.cnf

エラーがなければバックアップは成功です。

設定ファイル書き換え

  • sedによるファイル書き換え
sudo sed -i '/\[mysqld\]/a log_bin_trust_function_creators = 1' /etc/mysql/mysql.conf.d/mysqld.cnf
  • 書き換え後の差分確認
diff -u /path/to/backup/directory/mysqld.conf.$(date +%Y%m%d) /etc/mysql/mysql.conf.d/mysqld.cnf
  • 差分
 [mysqld]
+log_bin_trust_function_creators = 1

設定反映

  • 反映前のサービス確認
systemctl status mysql.service

active(running)を格納します。

  • サービス再起動
sudo systemctl restart mysql.service
  • 反映後のサービス確認
systemctl status mysql.service

active(running)を格納します。

ffmgetのインストール

そもそもこのパッケージがインストールされていなかったので、

sudo aptitude install ffmpeg

として、パッケージをインストールします。

設定反映確認

  • Nextcloudのルートディレクトリに移動
cd /nextcloud/root/directory

自分の環境(/var/www/html/nextcloudなど)を指定します。

  • 設定確認
sudo -u www-data php occ maintenance:repair

冒頭のエラーがなければOKです。

証明書-中間証明書の整合性を確かめるワンライナー。

SSLサーバ証明書の発行/更新時のチェック方法のメモです。

今まではissuerとsubjectのハッシュ値が同じことを確認していましたが、より確実な方法を調べました。

前提

Let's Encryptのように、証明書と中間証明書が結合されている状態の証明書です。

コマンド

openssl crl2pkcs7 -nocrl -certfile /etc/certs/hoge.example.com.crt | openssl pkcs7 -print_certs -outform PEM | awk 'BEGIN {c=0;} /BEGIN CERTIFICATE/ {c++} { print > "cert" c ".pem"}' && openssl verify -CAfile cert2.pem cert1.pem

/etc/certs/hoge.example.com.crtは、サーバにある証明書をフルパスで指定します。

  1. 証明書をCRL(証明書失効リスト)を含めずにPKCS#7形式に変換。
  2. PKCS#7形式からPEM形式で出力。
  3. awkによって証明書と中間証明書に分解。
  4. サーバ証明書と中間証明書を分割。

を含めています。

実行結果

openssl verify -CAfile cert2.pem cert1.pem
cert1.pem: OK

と出れば、cert1.pem(サーバ証明書)がcert2.pem(中間証明書)によって正しく署名されていることを示しています。

主なエラーの意味と対策

unable to get local issuer certificate
  • 意味:中間証明書またはルート証明書が見つからないか、信頼されていない。
  • 対策:CAファイルに必要な中間証明書とルート証明書が含まれていることを確認します。
certificate signature failure
  • 意味:証明書の署名が無効であるか、改ざんされている可能性がある。
  • 対策:証明書が正しく署名されていることを確認し、証明書ファイルが改ざんされていないかチェックします。
unable to verify the first certificate
  • 意味:証明書チェーンの最初の証明書(通常はサーバ証明書)が検証できない。
  • 対策:CAファイルに正しい中間証明書とルート証明書が含まれていることを確認します。
self signed certificate in certificate chain
  • 意味:自己署名証明書が証明書チェーンに含まれている。
  • 対策:自己署名証明書が適切に信頼されているか確認します。

AWS Lightsail → WebARENAへの移行完了。

はじめに

個人的に用いているVPSのコンテンツを、AWS LightsailからWebARENAへと移行完了。

今までUbuntu 20.04で動いていたサーバがUbuntu 24.04へと変わったことにより、Ubuntu 20.04のEOL対応を済ませたという形。

それぞれが、URLもそのままに、バージョンが上がった状態で表示されているという形です。

移行のきっかけ

Ubuntu 20.04のEOLが近づいてきた

これが一番の理由。Lightsailを最初に使い始めた頃は2022年5月だったので、まだ余裕があったのですが、そこから2年も経つとさすがに対応するしかないという形。

Lightsailにそのままインスタンスを移行させても良かったのですが

円安によるLightsail利用料高騰

という立ちはだかる壁があり、

  • 4GB Memory
  • 80 GB SSD

をもう一つ作り維持して行くには結構辛いものがありました。その上、

IPv4アドレスに追加料金

という更に手痛い値上げも発表されます。

迫るEOLに維持費の高騰、それをどうにかするために選んだのがWebARENAです。

WebARENAに切り替えた理由

利用費の安さ

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

2024/10/12現在、

  • 4vCPU
  • 4GB Memory
  • 80GB SSD

で月額1630円。(筆者がサインアップしたときは1年間有効のクーポン付きでした)

Lightsailの24USD/月より安価なのは魅力的でした。

キャリア運営による回線の安定。

今回はNextcloudを使うと決めているだけに、回線が安定しているキャリア(docomo)のvpsを利用しました。

移行が思ったよりスムーズだった理由

元からデータをクラウドストレージに保存していた

これが一番大きかったです。クラウドストレージWasabiをs3でマウントしていたために、他のサーバに画像を転送する必要すらありませんでした。

また、mysqldumpの転送も、同じようにs3経由で引っ張るだけです。

サービス構築のメモを最初に残していた

冒頭の外部サイトやこのブログに

  • うまくいった手順
  • ハマったこと
  • 失敗した理由

など書いていたのが助かりました。手順を基本的にコピペで済むように済ませていたのも自賛する点です。

事前検証

この検証のように、別サーバに移行することをやっていたのもまた助かりました。

今後

最小限構成でのLightsailの転用

とはいえ、「LightsailのDNS機能」が有用であるため、一番安いインスタンスを残しつつ他の用途に使っていきます。

Ubuntu 20.04で動いていた Redmine 4.2のデータを Ubuntu 24.04上のRedmine 5.1に移行。

概要

Redmine 4.2 を動かしている Ubuntu 20.04 が2025年4月にEOLを迎えるため、Redmine 5.1 (Ubuntu 24.04)にリプレースをしました。

最初に

  • 「この手順で上手くいった」という筆者のメモ書きです。
  • Rubyのバージョン違いなどで動かないプラグインがいくつかあります。代替手段は別途考慮してください。

動かなかったプラグインとワークアラウンド

redmine_knowledgebase です。

5.xで動くフォークを試したものの、rubyの兼ね合いで動きませんでした。

そのため、記事をこのBookStackに移行させています。

環境

移行前環境

  • Ubuntu 20.04
  • Redmine 4.2
  • Ruby 2.7
  • Apache 2.4
  • MySQL 8.0.39

移行後環境

  • Ubuntu 24.04
  • Redmine 5.1
  • Ruby 3.2
  • Apache 2.4
  • MySQL 8.0.39

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

  1. 【移行先】空のRedmineを構築します。
  2. 【移行元】DBのダンプファイルを作成し、移行先に転送します。
  3. 【移行元】ファイル、メール設定ファイルなどを移行先に転送します。
  4. 【移行先】DBをリストアします。
  5. 【移行先】gemのアップデートを行います。
  6. 【移行先】移行元で稼働していたプラグインを入れていきます。
  7. 【移行先】動作確認を行います。
  8. 【移行元】移行元のredmineを停止します。
  9. 【移行先】必要に応じてDNSの切り替えと移行先のサイト設定を行います。

【移行先】Redmineを構築していきます。

  • こちらのページに従って、移行先のUbuntu 24.04サーバに、Redmineを構築していきます。
  • 構築したてのRedmineのアカウントとパスワードは admin /admin なので、仮パスワードを設定しておきます。

【移行元】DBのダンプファイルを作成して転送します。

  • ディレクトリ移動
cd /hoge && pwd

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

  • ダンプファイル取得
mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql

ユーザー名(-uの後)とDB名(>の前)は自分の環境に合わせます。

  • ダンプファイル内容確認
view redmine_backup.$(date +%Y%m%d).sql

SQL文が平文で読めることを確認します。

作成後、任意の安全な方法で移行先に転送します。

【移行元】各種ファイルを転送します。

以下のディレクトリやを任意の安全な方法で転送します。

/path/to/redmine/root/directory配下(移行前のRedmineルートディレクトリ)の

  • files ディレクトリ(添付ファイル一式)
  • config/configuration.yml ファイル(メール設定がある場合)
  • public/thme/配下のテーマディレクトリ

これらのファイルは転送後、移行後のRedmineに対応するディレクトリ/ファイルに、そのまま上書きます。

【移行先】DBのリストアを行います。

  • ダンプファイル格納ディレクトリに移動
cd /hoge && pwd
  • ダンプファイル確認
ls -l redmine_backup.$(date +%Y%m%d).sql

ファイルがあることを確認します。

  • DBリストア
mysql -h localhost -u redmine -p redmine < redmine_backup.$(date +%Y%m%d).sql

このときのパスワードは、「移行先のRedmineのDBユーザのパスワード」です。

  • Webサービス再起動
sudo systemctl restart apache2.service

Webサービス再起動後に

  1. 移行後のRedmineサイトが移行元と同じ見た目であること
  2. ログインできること
  3. プロジェクト一覧が見られること

までは確認しましたが、チケットを確認しようとすると

500 internal server error

が発生し、閲覧も編集もできない事態が発生しました。

【移行先】gemのアップデートを行います。

こちらの、チケット表示でinternal server errorを解消するため、

Has 500 Internal Server Error when upgrade 4.1.1 to 4.2.7, please help.
https://www.redmine.org/boards/2/topics/67435

この手順を追加します。

  • Redmineのルートディレクトリに移動
cd /path/to/redmine/root/directory && pwd

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

  • gem update
 sudo gem update

しばらく時間がかかります。

  • Webサービス再起動
sudo systemctl restart apache2.service

gemのアップデート後、今度はエラーが出ないことを確認です。

【移行先】各種プラグインを入れていきます。

移行前に動いていたプラグインを確認しながら、プラグインを入れていきます。

DBマイグレーション中にrake abortedが出た場合は、そのプラグインはRedmine/Rubyのバージョンが合わないので、動かないプラグインです。

【移行先】動作環境を行っていきます。

プラグインを入れながら、既存の機能(別のユーザーがログインできるか、アクセス権は合っているか、チケットの作成や更新ができるか)などを見ていきます。

【移行元】稼働していたRedmineサイトを停止します。

移行元のサーバにSSHログインし、

sudo a2dissite redmine.conf

redmine.confは自分の環境に合わせます。

で設定ファイルを無効化後、

  • Webサービス再起動
sudo systemctl restart apache2.service

として、稼働していた移行元のサイトにアクセスできないことを確認します。

【移行先】必要に応じてDNSの切り替えと移行先のサイト設定を行います。

これは、移行元でも同じURL(ドメイン)を使いたい場合の措置です。

  • DNS向き先変更

DNを利用して、ドメインを移行先のIPアドレスへと付け替えます。

各種DNSサービスによって異なるので、そちらを参照してください。

  • apacheバーチャルサイトの設定変更

/etc/apaches/site-available/redmine.conf (自分の環境に合わせます)

の以下の箇所を編集していきます。

<VirtualHost *:80>
servername hoge.example.com
# 今まで動いていたドメイン名

<VirtualHost *:443>
    ServerName hoge.example.com
# 今まで動いていたドメイン名
  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service

切り替え後

  1. 前と同じドメインで、新しいRedmineサイトにログインできる
  2. (プラグインが廃止していなければ)同じ機能を使える

ことを確認できれば作業完了です。

移行後の処理

  1. DB移行時に利用したダンプファイルを削除します。
  2. 時期を見て旧サーバのデータの削除を行います。

Ubuntu 24.04に設定したMod_Securityでファイルアップロードエラーを退避。

事象

Redmineでクリップボードの画像を貼り付けようとした際、画像のアップロードができませんでした。

そこで、エラーログを確認したところ、以下のメッセージが表示されました。

ModSecurity: Request body no files data length is larger than the configured limit (131072). [hostname "redmine-url"] [uri "/uploads.js"] [unique_id "Zv0wom0FwSak1tXDUgFRLAAAAAw"], referer: https://redmine-url/issues/3

環境

  • Ubuntu 24.04
  • Apache 2.4
  • Mod_Security 2
  • Redmine 5.1

確認したこと

バーチャルサイトのMod_Securityの設定

SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000

と、50MBはアップロードできるようになっています。

Redmineでアップロード可能なファイル容量

管理> 設定 > ファイルの「添付ファイルサイズの上限でも`51200KB`を確認。

Mod_Security Confファイル確認

`cat /etc/modsecurity/modsecurity.conf |grep Limit` の結果、以下を確認しました。

SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 131072
SecRequestBodyLimitAction Reject
SecRequestBodyJsonDepthLimit 512
SecPcreMatchLimit 100000
SecPcreMatchLimitRecursion 100000
SecResponseBodyLimit 524288
SecResponseBodyLimitAction ProcessPartial

原因

`/etc/modsecurity/modsecurity.conf`の設定がバーチャルサイトの設定にオーバーライドしたため、こちらの設定が上書きされた模様です。

これを変更していきます。

対応手順

ファイルバックアップの作成

sudo cp -pi /etc/modsecurity/modsecurity.conf /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d)

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

バックアップ作成確認

diff -u /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d) /etc/modsecurity/modsecurity.conf

バックアップできていること(差分がないこと)を確認します。

sedによる書き換え

sudo sed -i 's/SecRequestBodyNoFilesLimit 131072/SecRequestBodyNoFilesLimit 52428800/; s/SecRequestBodyInMemoryLimit 131072/SecRequestBodyInMemoryLimit 52428800/; s/SecRequestBodyLimit 13107200/SecRequestBodyLimit 52428800/' /etc/modsecurity/modsecurity.conf

ファイル書き換え確認

diff -u /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d) /etc/modsecurity/modsecurity.conf

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

-SecRequestBodyLimit 13107200
-SecRequestBodyNoFilesLimit 131072
+SecRequestBodyLimit 52428800
+SecRequestBodyNoFilesLimit 52428800
 
 # Store up to 128 KB of request body data in memory. When the multipart
 # parser reaches this limit, it will start using your hard disk for
 # storage. That is slow, but unavoidable.
 #
-SecRequestBodyInMemoryLimit 131072
+SecRequestBodyInMemoryLimit 52428800

設定反映

sudo systemctl restart apache2.service

書き換え後、無事にファイルのアップロードができることを確認しました。

Page 4 of 16

Powered by WordPress & Theme by Anders Norén