タグ: AWS Lightsail Page 1 of 2

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機能」が有用であるため、一番安いインスタンスを残しつつ他の用途に使っていきます。

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情報を削除します。
  • 削除されたことを確認します。

最後に

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

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

検証:AWS LightsailのUbuntuにWasabiクラウドストレージをマウント。

概要

(ほぼ)固定費でそれなりのスペックのサーバを運用できるAWS Lightsail。ストレージを増やすには

  • スペックの増強を図る
  • AWS S3などのクラウドストレージを増強する

といった策が必要です。ですが、もっと低価格で利用できるサービスはないものかと探していたところにみつけました。

クラウドストレージ:Wasabi

https://wasabi.com/ja

なかなか挑戦的な言葉が書かれています。

  1. 1TBでも6$程度
  2. データ転送料無料

は魅力的。(逆に言えば、たとえ1バイトのファイルしか保存しなくても最低1TB分は請求されます)

そして、S3と同じプロトコルが使えるとのこと。

無料トライアルもあるので、Linuxサーバにマウントできるかを検証してみます。

試した手順

環境

AWS上で動かしているUbuntu 20.04で利用しています。

さっくりとした流れ

  1. Wasabiのアカウントを作成します
  2. バケットを作成します
  3. アクセスキーを作成します
  4. Linuxサーバで必要なパッケージをインストールします
  5. アクセスキーを保存します
  6. マウントを確認します
  7. fstabを修正します

詳細の手順

Wasabiアカウント作成

上記URLから自身のアカウントを作成。確認メールからパスワードを設定します。

バケット作成

ログイン後、「バケット」をクリック。

任意のバケット名を入力し、地域を選択します。(ここでは大阪を選択)

バージョン管理などは全て無効の状態で「次」をクリック。

確認画面後に「バケットを作成」で作成できました。

アクセスキーの生成

アクセスキーをクリックし「新しいアクセスキーを作成する」からアカウントキーと秘密鍵を控えます。(この情報は全てのストレージへのアクセスに必要となるため、取り扱いは厳重にしてください)

Linuxサーバ上での動作

スナップショット取得

念のため、作業直前にAWSコンソールからスナップショットを作成します。

必要パッケージインストールします

sudo aptitude update
sudo aptitude install s3fs

パスワードファイルの作成

信仰・協議に従ってエディタを起動します。次のファイルを作成します。

.passwd-s3fs
# アクセスキー:秘密鍵 の順番で貼り付け

chmod 600 .passwd-s3fs

ls - ${HOME}/.passwd-s3fs
# ファイルがあることを確認します

マウントポイントの指定

sudo mkdir /mnt/wasabi
# /mntファイルに任意の名前を作成ください

udo s3fs 【wasabiで作成したバケット名】 /mnt/wasabi -o passwd_file/【上記作成したパスワードファイルのパス】/.passwd-s3fs -o url=https://【バケットのリージョン名】.wasabisys.com -o use_path_request_style -o endpoint=【バケットのリージョン名】 -o allow_other

これでマウントしたことを確認しました。

WasabiのWebインタフェースから任意のファイルをアップロード。

cd /mnt/wasabi 
# 作成したマウントポイントに移動します

ここから、アップロードしたファイルが確認できれば設定完了です。

fstabの設定

システムを再起動してもマウントできるようにfstabの設定を追記します。

sudo cp -pi /etc/fstab /path/to/directory/fstab.date +%Y%m%d
diff -u /etc/fstab /path/to/directory/fstab.date +%Y%m%d
# 差分がないことでバックアップを確認します

バックアップ後、協議・信仰に従ったエディタで末尾に追記します。

s3fs#【wasabiバケット名】 /mnt/wasabi fuse _netdev,allow_other,passwd_file=/【パスワードファイルのパス】/.passwd-s3fs,url=https://s3.バケットのリージョン名wasabisys.com,use_path_request_style,endpoint=バケットのリージョン名 0 0

マウント確認

sudo mount -a
# エラーが出ないことを確認します

df -h
# マウントしたバケットが見えているかを確認します

今後の検証

トライアルの間、

  • マウントしたディレクトリに保存されたファイルをWebに公開できるか
  • 遜色なく利用できるか
  • 転送速度などに問題ないか

を確認後、本格的に使っていこうと思います。

AWS LightsailにSwap領域を確保。(Ubuntuでの設定)

概要

筆者が用いているAWS Lightsail。自動起動サービスやWebサービスの追加のためメモリが心許なくなりました。

インスタンスの底上げを図る前にいったんSwap領域を確保して、メモリの枯渇に備えます。

環境

  • Ubuntu 20.04
  • 2GBメモリ/60GBディスクのインスタンスを利用

実施した手順

さっくりとした手順

  1. 現在のメモリとディスク容量を確認します。
  2. Swap領域を確保します。
  3. 確保したSwap領域を有効化します。
  4. Swap領域が増えたことを確認します。
  5. fstabを修正します。
  6. fstab修正後にシステムを再起動し、Swap領域有効化を確認します。

作業の前に

ディスク起動時のオプションなど、特に重要なシステム領域の設定ファイルを修正する作業です。
失敗時に復旧できるようシステム全体のバックアップを取ることを強く推奨します。

現在のメモリ情報を確認

free -h
# -hオプションは(human readableの略だそうです)
  • ○実行結果
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.6Gi       114Mi        58Mi       209Mi       109Mi
Swap:            0B          0B          0B

Swapが全く作成されていません。

現在のディスク容量の確認

df -h
  • ○実行結果
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        59G  7.6G   51G  13% /
(後略)

まだ容量的に問題なさそうなので、2GBのディスク領域をSwapとして割り当てます。

Swap領域の確保

sudo fallocate -l 2G /swap

ls -ldh /swap
# 指定ディレクトリに2GBのファイルがあることを確認します

Swapの有効化

  • ★/swapのパーミッション変更
sudo chmod 600 /swap

ls -ldh /swap
# rootのみが読み書き可能なことを確認します
  • ★/swapの設定
sudo mkswap /swap
  • ○実行結果
スワップ空間バージョン 1 を設定します。サイズ = 2 GiB (2147479552 バイト)
ラベルはありません, UUID=f6d01f7d-6a48-45e9-a483-5757ec47cd8e
  • ★/swapの有効化
sudo swapon /swap

Swap有効化確認

free -h
  • ○実行結果
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.2Gi       430Mi        58Mi       283Mi       499Mi
Swap:         2.0Gi          0B       2.0Gi

2GBのSwap領域が確保されました。まずは一安心です。

fstab設定

  • ★/etc/fstabのバックアップ
sudo cp -pi /etc/fstab /path/to/backup/directory/fstab.$(date +%Y%m%d)

diff -u /etc/fstab /path/to/backup/directory/fstab.$(date +%Y%m%d)
# 差分が無いことでバックアップが取れていることを確認します。
  • ★/etc/fstab追記
cat <<- __EOF__ | sudo tee -a /etc/fstab
/swap none swap sw 0 0
__EOF__
  • ○差分確認
diff -u /path/to/backup/directory/fstab.$(date +%Y%m%d) /etc/fstab
  • ●差分
+/swap none swap sw 0 0

再起動後の修正確認

  • ★システム再起動
sudo reboot
  • ★再起動後の確認

以下が確認できれば作業完了です。

  1. サーバにログインできること
  2. Webサービスなど既存システムが設定前と同様に稼働すること
  3. free -h を実行し、Swap領域が確保されていること

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はアタッチされていないと料金が発生します。面倒ですが、都度、デタッチしておくと良いでしょう。

Fail2Banによるセキュリティ対策。(SSH保護)

概要

AWSはメジャーなサービスのため、ここで使われているIPアドレスは攻撃のリスクがとても高くなります。
ここでSSH権限を乗っ取ろうとする攻撃に備え、Fail2Banを導入しました。

Fail2Banとは

様々なログファイルを読み込み、何度もアクセスを繰り返すようなアクセス元を遮断するプログラムです。

前提

  • AWS Ligthsailで動かしているUbuntu 20.04サーバ/Ubuntu22.04サーバで動作を確認しています。
  • (当然のように)SSHが導入されていることが大前提です。

手順

  • 全て管理者権限で実施しています。
  • パッケージ管理にaptitudeを利用しています。必要に応じてaptに読み替えてください。

参考:
https://www.kkaneko.jp/tools/server/fail2ban.html

https://github.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning

Fail2Banのインストール

aptitude update
aptitude install fail2ban

wget https://raw.githubusercontent.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning/master/filter.d/blacklist.conf -O /etc/fail2ban/filter.d/blacklist.conf

wget https://raw.githubusercontent.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning/master/action.d/blacklist.conf -O /etc/fail2ban/action.d/blacklist.conf

systemctl restart fail2ban
systemctl status fail2ban
# active (running) を確認します

Fail2Banのログローテーション変更

mv /etc/logrotate.d/fail2ban /backup/directory/path/fail2ban.bak
vi /etc/logrotate.d/fail2ban
設定内容
/var/log/fail2ban.log {
                monthly
                rotate 13
                compress
                delaycompress
                missingok
                notifempty
                postrotate
                fail2ban-client flushlogs 1>/dev/null
                endscript
                create 640 root adm
                }

設定反映

fail2ban-client reload
# OKを確認します

fail2ban-client status sshd

#以下のように表示されました

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list: 

systemctl enable fail2ban
# 自動起動を行います

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

vi /etc/fail2ban/jail.local 
設定内容
[DEFAULT]
port = 0:65535

filter = %(__name__)s
[blacklist]
enabled = true
logpath  = /var/log/fail2ban.*
filter = blacklist
banaction = blacklist
action = %(action_)s
bantime  = 31536000   ; 1 year
findtime = 31536000   ; 1 year
maxretry = 10

追加した設定を反映させます

touch /etc/fail2ban/ip.blacklist
chmod 775 /etc/fail2ban/ip.blacklist
systemctl restart fail2ban
fail2ban-client reload
systemctl restart sshd

systemctl enable fail2ban

導入後に注意する内容

cat /var/log/fail2ban.log
cat /etc/fail2ban/ip.blacklist

AWSで運用しているだけあって、かなりのログが引っかかっています。

AWS LightsailでのUbuntu20.04立ち上げとUbuntu22.04へのアップグレード。

概要

定額でAWSのインスタンスを利用できるLightsail。

Ubuntu系OSを利用できるものの、2022年12月時点ではUbuntu22.04に対応していません。

20.04は選べますので、

  1. Ubuntu20.04で新たなインスタンスを立ち上げる
  2. Ubuntu22.04にアップグレードする

方法を紹介します。

どハマりしたこと

結論を言うと、Ubuntu 22.04にアップグレードするとLigtsailの管理画面から直接SSHすることはできません。
(SSH-1アルゴリズムによるRSA認証が無効化されます)

つまり、 何も設定せずWeb画面のSSH接続で最初にアップグレードをすると、再起動した瞬間にログインできず詰みます。

これに気づかず、アップグレード後に全くログインできずインスタンスを作り直す羽目になりました。以下はメモとして残しておきます。

成功した手順(さっくりした手順)

以下、ある程度の知識がある方ならこの手順を行えば問題ないと思います。

  1. Lightsail上でUbuntu 20.04のインスタンスを立ち上げる。
  2. 静的IPを付与してIPを固定化する。
  3. 必要に応じてDNSレコードに登録する。
  1. Lightsail管理画面から初期ユーザーでログインする。
  2. 初期ユーザー以外のrootに昇格可能なユーザーを作成する。
  3. そのユーザーで強力な暗号による秘密鍵/公開鍵を設定する。
  4. Ubuntu 20.04 → 22.04にアップグレードする。

成功した手順(より詳細な記述)

インスタンスの作成

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

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

「インスタンスの作成」をクリックします。

インスタンス作成

自分は以下のように選択しました。

  • リージョン:東京
  • インスタンスイメージの選択:Linux (OSのみ)
  • Ubuntu 20.04 LTSを選択。
  • 月次料金:10USD/月
  • インスタンス名:任意のもの
  • そのほかは空白

→設定後、「インスタンスの作成」をクリックします。
 → 作成後、「ネットワーキング」から静的IPを付与します。
  → 必要に応じてDNSを設定し、名前解決できるようにします。

管理画面のWebコンソール(SSH)操作

Web画面からログインし、rootに昇格します。

sudo su -
# この時、パスワードは設定されていないのでそのまま昇格できます。

ここから、ローカルのターミナルクライアントから接続できるようにユーザーを作成し、設定します。

ここではhogeとしていますので、任意のユーザーを指定して下さい。

adduser hoge
# パスワードなどを設定します

usermod -G sudo hoge
# ユーザーhogeを管理者グループに入れます

su - hoge
# ユーザーhogeに変われることを確認します

sudo su -
# パスワード入力後にrootに昇格できることを確認します

exit
# ユーザーhogeに戻ります

whoami
# ユーザーhogeであることを確認します

ssh-keygen -t ed25519
# 鍵の格納場所は初期値でいいので空Enter。(/home/hoge/.ssh/
# パスワードを設定します。

cd .ssh
ls -l
# 以下のファイルを確認します
# └id_ed25519
# └id_ed25519.pub
# ※これらのファイルはscp等で自分のクライアントにコピーします

rm id_ed25519
# sshサーバ上でそのまま鍵を作成したので秘密鍵は*クライアントにコピー後*削除します

mv id_ed25519.pub authorized_keys
chmod 600 authorized_keys
# 公開鍵をauthorized_keysに変更し、パーミッションを厳密にします

この後、ローカルにコピーしたid_ed25519をSSHターミナルクライアントに保存して設定し、接続確認を行います。

接続ができたらいよいよUbuntu 20.04→Ubuntu22.04へのアップグレードです。

ローカルPC(ターミナルクライアント)からの操作

whoami
#上記、作成したユーザーであることを確認します

sudo su -
# rootに昇格できることを確認します

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

reboot
# 一度再起動をします
# 再起動後、ログインします

Ubuntu20.04→22.04へのアップグレード

whoami
#上記、作成したユーザーであることを確認します

sudo su -
# rootに昇格できることを確認します

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

こうして、再起動後、無事にアップグレードが完了です。

cat /etc/lsb-release

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

アップグレード後の操作

以下、速やかに行います。

管理者に昇格できることを確認します。

sudo su -

rootのパスワードを設定します。

passwd root

初期ユーザー(ubuntu)が物理的にログインできないようにします。

cd /home/ubuntu/.ssh

rm authorized_keys

Let’s Encryptワイルドカード証明書によるredmineのSSL化対応。

先だって、AWS Lightsail上で2つめのredmineを構築する手順について触れました。

こちらをLet's Encryptで常時SSL化します。

前提

  • Ubuntu 20.04、Apache2での記録です。
  • 以下、sample.comで証明書を発行するための記録です。ドメインはお持ちのものを使ってください。(自環境で実施する際は必ず書き換えてください)
  • certbotで定期的に更新を行うのではなく、多目的に用いるために手動でワイルドカード証明書を発行する手順です。
  • 既にcertbotはインストールされていることと、DNSの更新権限を持っていることが前提です。

また、管理者権限で実施します。

ワイルドカード証明書発行

sudo certbot certonly --manual \
    --preferred-challenges dns-01 \
    --server https://acme-v02.api.letsencrypt.org/directory \
    -m メールアドレス \
    -d *.sample.com
TXTレコード登録
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y
# IPは記録される旨を訊かれるので了承のためY

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.sample.com with the following value:

「文字列」

# 上記文字列をDNSのテキストレコードに登録します
# 登録後、
# nslookup -type=TXT _acme-challenge.sample.comを入力し、「文字列」が返ってくるまで少し待ちます

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

# TXTレコードが返ってくるのを確認したらEnter
発行完了
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/sample.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/sample.com/privkey.pem
   Your cert will expire on 2023-03-24. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

発行確認

cd /SSL一時格納ディレクトリ

cp -pi /etc/letsencrypt/live/sample.com/fullchain.pem ./sample.com.crt.$(date +%Y%m)
cp -pi /etc/letsencrypt/live/sample.com/privkey.pem ./sample.com.key.$(date +%Y%m)
# 一時格納ディレクトリにコピーします


openssl x509 -noout -dates -subject -in ./sample.com.crt.$(date +%Y%m)
# 証明書の発行期限を確認します

openssl x509 -in sample.com.crt.$(date +%Y%m) -noout -modulus | md5sum
openssl rsa -in sample.com.key.$(date +%Y%m) -noout -modulus | md5sum
# 証明書と秘密鍵のハッシュがそれぞれ一致していることを確認します

openssl x509 -issuer_hash -noout -in sample.com.crt.$(date +%Y%m)
sed -n -e'1d' -e'/BEGIN/,$p' sample.com.crt.$(date +%Y%m) | openssl x509 -subject_hash -noout
# 証明書と中間証明書のハッシュがそれぞれ一致していることを確認します

SSL格納、リンク貼り替え

mkdir /etc/certs
cp -pi sample.com.crt.$(date +%Y%m) /etc/certs
# 証明書ディレクトリ

cd /etc/certs
ln -sf sample.com.crt.$(date +%Y%m) sample.com.crt
# Let's Encryptは有効期限が3ヶ月と短いため、メンテナンスしやすいようにリンクを貼り替えるだけで更新できるようにします
ll
# シンボリックリンクが張られていることを確認します

mkdir /etc/private
cp -pi sample.com.key.$(date +%Y%m) /etc/private
# 秘密鍵ディレクトリ

cd /etc/private
ln -sf sample.com.key.$(date +%Y%m) sample.com.key
# Let's Encryptは有効期限が3ヶ月と短いため、メンテナンスしやすいようにリンクを貼り替えるだけで更新できるようにします
ll
# シンボリックリンクが張られていることを確認します
リリースファイル

cd /etc/sites-available/redmine2.conf

<VirtualHost *:80>
servername redmine2.sample.com
# 常時SSL化の設定
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
  ServerName redmine2.sample.com
  ErrorLog /var/log/apache2/atlier/redmine2.sample.com_error.log
  CustomLog /var/log/apache2/atlier/redmine2.sample.com_access.log combined

Alias /redmine2 /var/lib/redmine2/public
<Location /redmine2>
PassengerBaseURI /redmine2
PassengerAppRoot /var/lib/redmine2
Require all granted
</Location>


#SSL対応
  SSLEngine on
    Protocols h2 http/1.1
    Header always set Strict-Transport-Security "max-age=63072000"

# 先に指定したLet's Encryptの格納先
SSLCertificateFile /etc/certs/sample.com.crt
SSLCertificateKeyFile /etc/private/sample.com.key

        # redmine2.sample.comでアクセスしてきた場合、強制的に/redmine2サブディレクトリに遷移します
        RewriteEngine On
        RewriteCond %{HTTP_HOST} ^redmine2\.sample\.com
        RewriteRule ^/$ https://redmine2.sample.com/redmine2/ [R]

</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE6-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

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

動作確認

http://redmine2.sample.com (自分が設定したドメイン名)にアクセスして

  • redmineの画面が表示されること
  • SSl通信に置き換わること

を確認します。また、こちらの設定は可能な限りSSLの強度を高めています。

https://www.ssllabs.com/ssltest/analyze.html

こちらの暗号化強度チェックで

A+となっています。(2022年12月現在

Page 1 of 2

Powered by WordPress & Theme by Anders Norén