カテゴリー: ガジェット Page 37 of 85

アクセス解析システム:matomoのインストール。

概要

オープンソースの解析システムであるmatomoをAWS Lightsail上にインストールしました。

参考としたURL

本記事で実施すること

  • AWSサーバに導入されているPHPがサポート終了しているため、7.4から8.1にアップグレードする。
  • Ubuntu 20.04にアクセス解析システム「matomo」をインストールする。
  • その際に常時SSL化を行う。
  • Web画面から初期設定を行う。

※アクセス対象のシステムへの設定は別の記事で紹介します。

前提

  • 既に以下のシステムがWAN環境に揃っていること。
  • Ubuntu 20.04
  • Apache 2.4
  • mysql 8
  • PHP 7.4
  • matomo用のサブドメインを取得していること。
  • それに即した証明書があること。

手順

さっくりとした手順

  1. PHPを7.4から8.1にアップグレードする。
  2. MySQLのDBとユーザを作成する。
  3. ディレクトリにmatomoプログラムを配置する。
  4. Apache設定ファイルを作成し、常時SSLで接続できるようにする。
  5. matomoサイトにログインできることを確認する。
  6. matomo Web画面で初期設定をする。

PHPのアップグレードを行います。

sudo apt-get --purge autoremove php*

sudo aptitude install php8.1
sudo aptitude install php8.1-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,mysqli,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev}
sudo aptitude install php8.1-apcu
sudo aptitude install php8.1-memcached

sudo systemctl restart apache2.service

php -v
# PHP 8.1.14を確認しました。

PHPアップグレード後、PHPを動かしているサーバ内のサイトが正常に動くことを確認しました。

データベースを作成します。

sudo mysql -u root -p
CREATE DATABASE matomodb;
CREATE USER 'matomouser'@'localhost' IDENTIFIED BY 'password';
/* パスワードは自身の環境に合わせ、強固なものを設定してください */
GRANT ALL ON matomodb.* to 'matomouser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

matomoプログラムをディレクトリに配置します。

cd /tmp &&pwd
# tmpにいることを確認します

wget https://builds.matomo.org/matomo-latest.zip

unzip matomo-latest.zip

sudo chown -R www-data:www-data matomo

sudo mv matomo /var/www/html/
# 今回は/var/www/htmlに配置します。

ls -ld /var/www/html/matomo
# 該当ディレクトリにファイル一式があることを確認します

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

  • 【】内を自分の環境に合わせます。
  • コマンド一式をコピー → 別のエディタにペースト
  • その後、【】内を自分の環境に修正してコピー
  • コマンド一式をSSHクライアントに貼り付ける
cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/matomo.conf
<VirtualHost _default_:80>
ServerName 【設定したドメイン名】
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName 【設定したドメイン名】
    CustomLog 【/var/log/matomo/matomo_access.log combined】
    ErrorLog 【/var/log/matomo/matomo_error.log】
    # アクセスログとエラーログは自分の環境に合わせて設定します。

    DocumentRoot /var/www/html/matomo
    <Directory /var/www/html/matomo>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require all granted
    </Directory>

  SSLEngine on

    Protocols h2 http/1.1
    Header always set Strict-Transport-Security "max-age=63072000"

SSLCertificateFile 【SSL証明書のファイルパス】
SSLCertificateKeyFile 【SSL秘密鍵のファイルパス】
# SSLCACertificateFile 【SSL中間証明書のファイルパス】
# 中間証明書が発行元から別ファイルで提供されている場合は、この直上をコメントアウトして中間証明書を指定します

</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          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
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
# これらのセクションはSSL暗号化強度を高めるための記述です
# </VirtualHost>の外側に書くことにご注意ください
__EOF__

設定を反映します。

cd /etc/apache2/sites-available && pwd
# 対象ディレクトリにいることを確認します

sudo a2ensite matomo.conf

sudo apache2ctl configtest
# Syntax OKを確認します

sudo systemctl restart apache2.service

ブラウザで

https://【matomoを設定したドメイン名】

にアクセスし、初期画面が出ることを確認します。

初期インストール画面の設定

「次へ」をクリックします。

全てチェックされていることを確認して「次へ」をクリックします。

◎データベースを設定します。

  • ログイン: MySQLのユーザー(matomouser)
  • パスワード: 設定したパスワード
  • データベース名:作成したDB (matomodb)

をそれぞれ入力し、「次へ」をクリックします。正常に入力されれば「テーブルを作成されました」とデルので「次へ」をクリックします。

◎スーパーユーザーを設定します。

  • スーパーユーザーログイン:ログインするユーザー名
  • パスワード:ログイン時のパスワード
  • パスワード(再入力)
  • メールアドレス

をそれぞれ入力して「次へ」をクリックします。

◎アクセス解析を行うウェブサイトを設定します。

  • アクセス解析対象のウェブサイトの名前
  • ウェブサイトのURL (このmatomoサイトではなく、アクセス解析を行いたいWebサイト)
  • ウェブサイトのタイムゾーン
  • eコマースか否か

を設定して「次へ」をクリックします。

これらを設定後、トラッキングタグが表示されます。これらを控えて「次へ」をクリックします。

「おめでとうございます!」と表示されればインストールの一連の作業は完了します。

Redmineへの不正ログインをfail2banで制御する。

概要

インターネット環境にあるRedmineを不正ログインから防ぐため、不正ログイン対策パッケージfail2banと連携させました。

参考としたURL

https://www.redmine.org/projects/redmine/wiki/HowTo_Configure_Fail2ban_For_Redmine

環境

2023年1月現在、以下の環境で動かしています。

  • AWS Lightsailに立てているUbuntu20.04インスタンス

前提(導入済みパッケージ)

以下、既に導入済みです。

  • Redmine 4.2
  • fail2ban 0.11.1

本記事ではproduction.logの格納場所を

/var/log/redmine/production.log

としています。ご自身の環境に合わせてください。(通例は/var/lib/redmine/log の場合が多いです)

手順

さっくりとした手順

  1. fail2banの設定ファイルにredmine用の設定ファイルを作成します。
  2. jail.localファイルに上記設定ファイルを読み込ませます。(ファイルに追記します)
  3. fail2banサービスを再起動します。

稼働サービス(fail2ban)に修正を加えるので、必ずバックアップは取りましょう。

詳細手順

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

cat <<- __EOF__ | sudo tee -a /etc/fail2ban/filter.d/redmine.conf
# redmine configuration file
#
# Author: David Siewert
#
# $Revision$
#
[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

datepattern = %%Y-%%m-%%d %%H:%%M:%%S %%Z$
failregex = Failed [-/\w]+ for .* from <HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

# Source:
#http://www.fail2ban.org/wiki/index.php/MANUAL_0_8
__EOF__
作成確認
ls -l /etc/fail2ban/filter.d/redmine.conf
# rootユーザで上記ファイルが作成されていることを確認します。

jail.localファイルのバックアップを取ります。

sudo cp -pi /etc/fail2ban/jail.local /etc/old/jail.local.$(date +%Y%m%d)
# バックアップの格納ディレクトリは自分の環境に合わせます。

diff -u /etc/fail2ban/jail.local /etc/old/jail.local.$(date +%Y%m%d)
# バックアップ元とバックアップ先の差分が無いことでバックアップが取れていることを確認します。(何も返ってこなければ正常にバックアップできています)

jail.localファイルに追記を行います。

cat <<- __EOF__ | sudo tee -a /etc/fail2ban/jail.local

[redmine]
enabled  = true
filter   = redmine
port     = 80,443
#backend  = polling
# 動作がうまくいかない場合は上記「backend」をコメントアウトしてください。
action   = iptables-allports[name=redmine]
logpath  = /var/log/redmine/production.log
# production.logの格納位置です。ここは自分の環境に合わせます。
maxretry = 3
# ログイン試行に3回失敗した場合、アクセスを拒否します。
findtime = 86,400
# 1日アクセスを禁止します。
bantime  = 20
# ログイン試行の判定です
# トータルで「20秒の間、ログインに3回失敗したときに1日アクセスを禁止する」設定です
__EOF__

追記した内容の差分を確認します。

diff -u /etc/old/jail.local.$(date +%Y%m%d) /etc/fail2ban/jail.local
差分内容
+
+[redmine]
+enabled  = true
+filter   = redmine
+port     = 80,443
+#backend  = polling
+# 動作がうまくいかない場合は上記「backend」をコメントアウトしてください。
+action   = iptables-allports[name=redmine]
+logpath  = /var/log/redmine/production.log
+# production.logの格納位置です。ここは自分の環境に合わせます。
+maxretry = 3
+# ログイン試行に3回失敗した場合、アクセスを拒否します。
+findtime = 86,400
+# 判定失敗時、1日アクセスを禁止します。
+bantime  = 20
+# ログイン試行の判定です
+# トータルで「20秒の間、ログインに3回失敗したときに1日アクセスを禁止する」設定です。

設定ファイルの動作確認を行います。

まず、自分のredmineのログイン画面でわざとログインを失敗させます。

このとき、

cat /var/log/redmine/production.log |grep Failed
# production.logのパスは自分の環境に合わせます。

とすることで、

Failed login for 'ユーザ名' from IPアドレス at 2023-01-01 00:00:00 UTC

のように、失敗させたときのログが表示されます。

次に、

fail2ban-regex /var/log/redmine/production.log /etc/fail2ban/filter.d/redmine.conf
# production.logのパスは分の環境に合わせます。

を実行します。

Results
=======

Failregex: 1 total
|-  #) [# of hits] regular expression
|   1) [1] Failed [-/\w]+ for .* from <HOST>
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [2] Year-Month-Day 24hour:Minute:Second Zone name$
`-

Lines: 4281 lines, 0 ignored, 1 matched, 4280 missed
[processed in 0.08 sec]

と、ログイン失敗時の行数分「X matched」と表示されます。これで、設定ファイルとログのパス設定に問題がないと確認が取れました。

設定を反映します。

sudo systemctl restart fail2ban.service

systemctl status fail2ban.service
#active (running)であることを確認します。

以上で、設定は完了です。

Redmineのチケットをダイレクトに編集するプラグインを追加。 (redmine_issue_dynamic_edit)

概要

Redmineのチケット、作成した後に細部を修正することは多々あると思います。
そういうとき、Jiraのように修正したい箇所をクリックするだけで修正できるプラグインを導入しました。

プラグイン名

redmine_issue_dynamic_edit

動作を確認した環境

Redmine 4.2

導入時

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

手順

さっくりとした手順

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

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

cd /var/lib/redmine/plugins
# 自分の環境に合わせます。

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

sudo -u www-data git clone https://github.com/Ilogeek/redmine_issue_dynamic_edit

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

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

sudo systemctl restart apache2

動作

Redmineで任意のチケットを開きます。

エディットアイコンが出てくるのでそれをクリックします。

項目を編集し、チェックをクリックします。

修正内容が反映されています。

NextcloudサーバのPHPアップグレードとエラー解消、そして再設定。(PHP7.4→PHP8.1)

Nextcloudを動かしている自宅サーバでPHPをアップグレード。

ちょっとだけハマったのでメモを残します。

環境

以下の環境でNextcloudを動かしています。

  • Ubuntu 20.04
  • Apache
  • MySQL
  • PHP 7.4

さっくりとした手順

  1. PHP7.4をアンインストールします。
  2. PHP8.1をインストールします。
  3. 追加モジュールを有効化します。
  4. NextCloudの追加設定を行います。

手順

  • 今回は全て通常ユーザで作業をします。
  • また、viを使わずコマンドを用いて設定を置き換えています。
  • 設定をするのはPHPのみです。他は設定の変更をしていません。
  • パッケージ/モジュールのインストールにaptitudeを用いています。好みに合わせてaptをご利用ください。

PHPの削除を行います。

sudo apt-get --purge autoremove php*

PHP8.1をインストールします。

sudo aptitude install php8.1

sudo aptitude install php8.1-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml}

sudo aptitude install php8.1-apcu

sudo aptitude install php8.1-memcached

php -v
# PHP 8.1.14 (cli)を確認しました。(2023/01/19)

apache再起動を行います。

sudo systemctl restart apache2.service

アップグレード後にエラー。

PHPアップグレード後、Nextcloudにアクセスするとこうなりました。

前の設定が全て消えたので、エラーが発生しました。

こちらを解消していきます。

エラーチェック

cd /var/www/html/nextcloud/
# Nextcloudの格納ディレクトリに移動します。自分の環境に置き換えてください。

sudo -u www-data php ./occ
# NextcloudのCLIインタフェースです
エラー内容
An unhandled exception has been thrown:
OCP\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

memcacheとAPCuが読み込まれていないと怒られましたので、有効化していきます。

memcacheとAPCuの有効化

cd /etc/php/8.1/cli/conf.d
cat <<- __EOF__ | sudo tee -a /etc/php/8.1/cli/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
cat <<- __EOF__ | sudo tee -a /etc/php/8.1/cli/conf.d/20-apcu.ini
[apcu]
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200
apc.enable_cli=1
apc.serializer=php
__EOF__
sudo systemctl restart apache2.service

再設定後の確認

cd /var/www/html/nextcloud/
# nextcloudの格納ディレクトリに移動します

sudo -u www-data php ./occ
# エラーが出ず、occのオプションが表示されることを確認しました。

この後、Nextcloudにアクセスし、画面が表示されることを確認しました。

管理者画面確認

Nextcloudに管理者アカウントでログインし、管理者設定を確認すると

  • PHPのメモリ制限が推奨値の512MB以下です。
  • テーマ別アプリは有効ですが、PHPモジュール「imagick」が有効ではありません。ファビコン生成を正しく行うには、このモジュールをインストールし、有効化する必要があります。
  • PHP モジュール "gmp" および "bcmath" が有効になっていない。WebAuthnパスワードレス認証を利用する場合は、これらのモジュールが必要です。

が出てきました。これを修正していきます。

php.ini修正

sudo cp -pi /etc/php/8.1/apache2/php.ini /etc/old/php.ini.$(date +%Y%m%d)
# /etc/oldがなければディレクトリを作成するか、任意のバックアップパスを指定してください

diff -u /etc/php/8.1/apache2/php.ini /etc/old/php.ini.$(date +%Y%m%d)
# 差分が存在しないことにより、バックアップが取れていることを確認します。

sudo sed -i 's/memory_limit = 128M/memory_limit = 512M/g' /etc/php/8.1/apache2/php.ini
# memory_limitを推奨値の512Mに置き換えます。
差分確認
diff -u  /etc/old/php.ini.$(date +%Y%m%d) /etc/php/8.1/apache2/php.ini
# 取得したバックアップと置き換えたファイルの差分を確認します
  • 差分
-memory_limit = 128M
+memory_limit = 512M

不足モジュールのインストール

sudo aptitude install php8.1-{imagick,gmp}

設定反映と確認

sudo systemctl restart apache2.service

Nextcloudに管理者アカウントでログインし、管理者設定を確認。

「すべてのチェックに合格しました」

と出たので設定完了です。

redmineのテーブルをタブ区切りで書くプラグイン導入。(redmine_tsv_macro)

これで、Redmineでの記事やチケットの作成作業が更に捗ります。

プラグイン概要

こういうエクセルファイルのテーブルをredmineのMarkdownに書き写す場合、TyporaやGrowiのテーブル機能を経由して変換する必要がありました。

これをほぼコピペだけで完結させるプラグインです。

参照URL

  • https://taikii.net/posts/2019/12/redmine-plugins-2019/
  • https://github.com/taikii/redmine_tsv_macro

手順

全て管理者権限で実施しています。

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

cd /var/lib/redmine/plugins
# 自分の環境に読み替えます

プラグインをインストールします。

sudo -u www-data git clone https://github.com/taikii/redmine_tsv_macro.git
# Webサービスを実行するユーザに合わせます(apache,nginxなど)

システムに反映させます。

systemctl restart apache2.service
# 自身の環境に合わせます

使い方

テーブルを作りたいところに{{tsv_h }}と入力し、その間にエクセルのブックをコピーしてペーストするだけです。

入力例

{{tsv_h
日付    曜日  天気  朝   朝:場所    昼   昼:場所    夜   夜:場所    備考
2023/1/1    日   晴れ  おせち 自宅  おせち 自宅  カレー 自宅  
2023/1/2    月   晴れ  明太釜玉うどん 自宅  クリームパスタ 自宅  餃子雑煮    自宅  
2023/1/3    火   晴れ  鳥オムレツ   自宅  ソーセージ定食 自宅  カツ丼 自宅  
2023/1/4    水   晴れ  ハンバーグ定食 自宅  春巻き弁当   自宅  雑煮  自宅  
2023/1/5    木   晴れ  ソーセージ定食 自宅  チャーシュー麺セット  ぎょうざの満洲 プラウンマサラ 自宅  
}}

出力結果

Excelのみならず、Googleスプレッドシート経由でも他のアプリを利用することなく、ブラウザ間のみでシートの貼り付けが可能になります。

また、{{tsv_h }}{{tsv }}とすることで、ヘッダを用いないテーブルが作成可能です。

注意点

  • ヘッダは空白行を作らないようにしてください。そうしないと全体のテーブルがずれます。
  • また、セルに改行があったり記号などでも崩れるようです。
  • 崩れないテーブルを作りたい場合は素直に他のツールを使います。

mod_securityが検知した不審なアクセスをufwで一括遮断。

あらまし

apacheにmod_securityを導入後、以下を実施しました。

  1. Mod_Securityが検知した不審なアクセスのうち、IPアドレスのみを抜き出す
  2. その抜き出したIPアドレスをMod_securityによってブロックする
  3. これを日次で追加していく

この方法はそこそこうまくいっています。ですが、「これら不審なアクセス元はWebだけでの攻撃だけか? メールやSSHへの攻撃もしているだろう」と思い立ち、不審なアクセスを元から絶つ方法を採りました。

環境

AWS Lightsailで以下を動かしています。

  • Ubuntu 20.04
  • いわゆるLAMP環境

前提

以下が準備済みです。

  • Mod_Security導入済み
  • 前述したmod_securityから不審なアクセス元のみを抜き出したIPアドレスのリストがある
    • このリストをnegativelist.txtとして用意しています。
リスト形式
192.168.0.1
192.168.1.123

のように、一行ずつIPアドレスだけが記述されているファイルです。

さっくりとした手順

  1. ufwを有効化します。
  2. 不審なアクセス元のIPアドレスのみを抜き出したnegativelist.txtを一行ずつ読み込みアクセスを遮断するシェルスクリプトを作成します。
  3. 作成したスクリプトを実行します。

実行の前の注意事項

  • 自環境のアクセスが遮断される可能性があることに注意してください。
  • 事前にスナップショットやバックアップを取り、失敗した時に備え切り戻しができる準備を強く推奨します
  • この方法によりアクセスができなくなった等に対し、筆者は責任を負いかねます。

手順

全て管理者権限で実施しています。

ufwがインストールされていることを確認します。(導入済みの場合はスキップ)

apt list ufw
#  [インストール済み] となっていることを確認します。

ufwを有効化します。(導入済みの場合はスキップ)

ufw enable

許可するサービスを指定します。(導入済みの場合はスキップ)

ufw limit ssh
# 連続したSSHアクセスを遮断します
ufw allow http
ufw allow https
# その他の許可するサービスは必要に応じて指定してください

この段階で、以下を確認します。

  • ターミナルクライアントからSSH接続ができること
  • 既存のサービスが外部NWからアクセスできること

サービス確認

ufw status
実行例
状態: アクティブ

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

シェルスクリプトを作成します。

vi /hoge/add_ufw.sh
スクリプト内容
#!/bin/bash

# UFWを念のため事前に有効化します
ufw enable

# ファイルに書かれたIPアドレスを一行ずつ読み込みアクセスを遮断します。
while read line; do
    ufw deny from $line
# 読み込むファイルを指定します
done < /path/to/negativelist.txt

シェルスクリプトに実行権限を与えます。

chmod +x /hoge/add_ufw.sh

シェルスクリプトを実行します。

./hoge/add_ufw.sh
# 行数によっては相当な時間がかかります

実行後の確認を行います。

ufw status
実行例(抜粋)
Anywhere                   DENY        192.168.0.1              
Anywhere                   DENY        192.168.1.111              

まとめ

これで、「Webサイトに対して不審なアクセスを行ったIPをまるごと遮断する」ことが可能になりました。相当乱暴な方法ではあることにご注意ください。

exitの恐怖。(systemctlの罠)

かなりのヒヤリハットが起きました。

現象:突然のアクセス不可

AWS Lightsailで動かしているUbuntu。その設定変更を終えたときです。

突然、SSH接続が切れました。Webブラウザ上からも接続できず。これは一体と思いながらAWSコンソールを確認するとインスタンスは停止状態。

取り急ぎ、再度起動してログインできることを確認し、「なぜ、こうなってしまったのか」を確認します。

原因と思われるコマンド

さっそく、historyを追ってみます。その中に

systemctl exit

と入力していたことがわかりました。

  • 一度、systemctlでサービスの状態を確かめようとする
  • でも、普通に起動していたことは確認できていた。
  • Ctrl + Cでコマンドをキャンセルするのを忘れ
  • そのままログアウト感覚で「exit」を入力

が、このコマンドを発行した経緯だと推測。そこで、もう一つの仮説です。

systemctl exitのコマンド結果

「このコマンドを発行することでシャットダウンとなるのではないか」と推測し、物理環境のUbuntu 20系Linuxで試してみました。

systemctl exit

結果、ものの見事にシャットオフ。Webの記事などで乗っていない挙動だっただけに焦りましたけど、文脈としては腑に落ちます。

今後、systemctl系を触るときはもっと注意が必要だと改めて悟りました。

Ubuntu 22.04系にRuby2.7をインストール

結論から言えば、Ubuntu 22.04系は普通にやったのではRuby 2.7はインストールできません。

なぜならRuby 2.7が必要とするOpenssl1.1.1系をUbuntu 22.04系がサポートしていないからです。

そんな中で、どうしてもこのバージョンを入れたいというケースがあったので対応を行いました。

手順

参考
https://github.com/rbenv/ruby-build/discussions/1940#discussioncomment-2663209

依存関係をインストールします。

sudo apt install git build-essential checkinstall zlib1g-dev

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

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
rbenvのパスを通します。
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc

source ~/.bashrc

ruby-buildをインストールします。

git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

OpenSSL 1.1.1をインストールします。

cd ~/Downloads
wget https://www.openssl.org/source/openssl-1.1.1q.tar.gz
tar xf openssl-1.1.1q.tar.gz

cd ~/Downloads/openssl-1.1.1q
./config --prefix=/opt/openssl-1.1.1q --openssldir=/opt/openssl-1.1.1q shared zlib
make
make test
sudo make install

シンボリックリンクを張り替えます。

sudo rm -rf /opt/openssl-1.1.1q/certs
sudo ln -s /etc/ssl/certs /opt/openssl-1.1.1q

ruby 2.7系をインストールします。

RUBY_CONFIGURE_OPTS=--with-openssl-dir=/opt/openssl-1.1.1q
RUBY_CONFIGURE_OPTS=--with-openssl-dir=/opt/openssl-1.1.1q rbenv install 2.7.6

rbenv global 2.7.6

インストールされていることを確認します。

ruby -v
ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux]

rootが参照できるようにパスを通します。

which ruby
# /home/user1/.rbenv/shims
# 結果を控えておきます
sudo su -

# ↓以下、rootでの作業↓
echo "export PATH=$PATH:/home/user1/.rbenv/shims" >> ~/.bashrc
source ~/.bashrc
which ruby
# /home/user1/.rbenv/shims
# 控えておいたパスであることを確認します
ruby -v
# ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux]
# 2.7系であることを確認します

と、ここまで書きましたがきっとDockerなどのコンテナを使ったほうが楽かと思います。

Ubuntuのログイン画面編集。(Update-Motd修正)

UbuntuにSSHでログインしたときに出てくるこの画面を修正します。

Ubuntu 20.04 / 22.04共に同じ手順で実施できました。

手順

motd配下の全てのアクセス権を一時剥奪します。

sudo chmod -x /etc/update-motd.d/*

Welcomeメッセージに入れるパッケージをインストールします。

sudo apt install ansiweather
# 都市の天気予報をコマンドラインで答えるコマンドです

独自のWelcomeメッセージを作成します

sudo vi /etc/update-motd.d/01-custom
メッセージ内容
#!/bin/bash
echo "NOBODY EXPECTS THE SPANISH INQUISITION!"
echo "まさかの時のスペイン宗教裁判!"
echo " "

ansiweather -l tokyo
ansiweather -l penzance

# -l の後に都市名を入力することで、その都市の天気予報が表示されます

fail2ban-client status sshd
# fail2banでのブロック状況を確認

作成したWelcomeメッセージに実行権をつけます

sudo chmod +x /etc/update-motd.d/01-custom

変更後、このように表示されることを確認。

ログイン時のWelcomeメッセージ(motd)が修正されました。

AWS Ligthsailインスタンスのバックアップとリストア。(及び別リージョンへのコピー)

概要

AW Lightsailのインスタンスをまるごとコピーすることでバックアップと復元を行います。

この作業の目的

  • (作業失敗や攻撃を受けてなど)データ損壊時でもサービス継続が行えるようにします。
  • 新たなサービスを追加するとき、検証環境として新たに立ち上げます。

さっくりとした手順

  1. スナップショットを作成する
  2. 作成したスナップショットから新しインスタンスを立ち上げる
  3. DNS情報を差し替える

手順

インスタンスのバックアップ

AWS Lightsailの管理画面にログインします。

https://lightsail.aws.amazon.com/ls/webapp/home/instances

スナップショットを作成します。

スナップショットをクリックします。

手動スナップショットの「+スナップショットの作成」をクリックします。

任意の名前をつけて「作成」をクリックします。

作成が完了するまで待ちます。(なお、10 USD/月のインスタンスのスペックだと最初に10~15分ほどかかりました

日付、時間、スナップショットの名前が表示されれば作成完了です。

スナップショットからのインスタンスリカバリ

AWS Lightsailの管理画面にログインします。

https://lightsail.aws.amazon.com/ls/webapp/home/instances

スナップショットをクリックします。

同一リージョンからのインスタンス作成 → (自分の環境では失敗)

作成済みのスナップショットの左の矢印をたどっていき、右メニューから「新規インスタンスの作成」をクリックします。

  • スナップショットソース
    • バックアップしたスナップショット
  • インスタンスロケーション
    • 変更なし
  • オプション
    • 変更なし
  • 新規インスタンスプランの選択
    • 変更なし (場合によっては、この段階でスケールアップが可能です)
  • インスタンスを確認
    • 一意の名前をつけます。
  • キーオンリータグ
    • 変更なし
  • キー値タグ
    • 変更なし

全てを設定したら「インスタンスの作成」をクリックします。

失敗

通常ならここで大丈夫だと思うのですが

CreateInstancesFromSnapshot[ap-northeast-1]

Sorry, you've reached your maximum limit of Lightsail Instances : 2. 

と出ました。

そこで、別の手段を執ります。

別リージョンにコピーしてのインスタンスリカバリ

AWS Lightsailの管理画面にログインします。

https://lightsail.aws.amazon.com/ls/webapp/home/instances

スナップショットをクリックします。

別リージョンへのコピー

作成済みのスナップショットの左の矢印をたどっていき、右メニューから「別リージョンへのコピー」をクリックします。

  • コピーするスナップショット
    • バックアップしたスナップショット
  • 新しいスナップショットの送信先を選択する
    • 別のリージョン(ここではロンドンを選択)
  • コピーされたスナップショットの新しい名前を選択する
    • 任意の名前をつけます。

全て設定したら「スナップショットのコピー」をクリックします。

インスタンスが別リージョン(東京→ロンドン)にコピーされたことを確認します。

インスタンスからの復元

Lightsail管理画面 → スナップショット → バックアップしたスナップショット→新規インスタンスの作成をクリックします。

  • スナップショットソース
    • バックアップしたスナップショット
  • インスタンスロケーション
    • 変更なし
  • オプション
    • 変更なし
  • 新規インスタンスプランの選択
    • 変更なし (場合によっては、この段階でスケールアップが可能です)
  • インスタンスを確認
    • 一意の名前をつけます。
  • キーオンリータグ
    • 変更なし
  • キー値タグ
    • 変更なし

全てを設定したら「インスタンスの作成」をクリックします。

リカバリしたスナップショットのネットワーク設定

同一リージョンからのリカバリならネットワークの割当先を変えるだけですみますが、別リージョンは当然IPアドレスのレンジが異なるので、DNSの差し替えも必要になります。

AWS Lightsailの管理画面にログインします。

https://lightsail.aws.amazon.com/ls/webapp/home/instances

新たにコピーされたスナップショットをクリックします。

ネットワークを変更します。

ネットワーキングをクリックします。

「静的IPをアタッチする」をクリックします。

任意の名前をつけて「作成およびアタッチ」をクリックします。

DNSを変更します。

前提

ここでは、LightSailのDNSを用いてのDNSでの手順です。他のDNSサービスを利用している場合はそれに準じてください。

AWS Lightsailの管理画面にログインします。

https://lightsail.aws.amazon.com/ls/webapp/home/instances

DNSを差し替えます。

※ 検証環境として立ち上げる場合は、DNSレコードの追加を行ってください。

ドメインとDNSをクリックします。

割り当てをクリックします。

ドメイン名を選択し、バックアップしていたドメインを入れます。

入力後、「割り当てる」をクリックします。

割り当て後、「バックアップ時のIPとリカバリ後のIPアドレス」2つがDNSに割り当てられてしまいます。これを解消します。

管理画面 → ドメインとDNS → 対象ドメイン → DNSレコードに進みます。

複数あるうち、「バックアップ時のDNSレコード(前のDNSレコード)」を削除します。
→ 新しいIPのみがある状態にします

差し替え確認

nslookup 設定したドメイン

とし、差し替えたIPアドレスのみがあることを確認します。

リカバリ確認

SSHターミナルクライアントからログインします。

(ネットワーク情報が変わるので鍵の差し替えなどが発生しますのでそれに従います)

正常にログインできることを確認します。

注意点

  • 一度追加した静的IPはアタッチされていないと料金が発生します。面倒ですが、都度、デタッチしておくと良いでしょう。

Page 37 of 85

Powered by WordPress & Theme by Anders Norén