投稿者: manualmaton Page 88 of 256

平日休みで遊んだボードゲーム。

お休みを利用して友人とボードゲーム。本数は少ないものの、充実した時間を過ごしました。

タッジーマッジー

すぐに理解していただいた作品。こちらは最後の最後でコンボが決まって逆転勝ちを収めた図です。

ぬくみ温泉開拓記

2戦連続。

1回目は麦酒売りvs湯もみ。ダイスボーナスによってぬくみ御殿を建てることができて勝利。

二戦目は白熱。互いに建物を建てきった総力戦。最終的にぬく丸の差が勝負を決めたという感じで惜敗でした。

ある程度ボードゲームを嗜んでる人との共通見解は

 ・選択肢がオープンであること
 ・資源がある限り邪魔されないこと
でラウンドを重ねるごとに一手が重くなること
 ・マップのスペースが有限である
 ・ダイスロールのランダム性
で更にジレンマが増すという点でした。

お茶と撮影。

2020年の12月頃より加速していった「お茶を飲む習慣」。

昨年は更にその度を増していき、恒例通りルピシアで福袋を購入するに至りました。

その中でちょっとした変化に気づきます。

このように、お茶とそれにちなんだフィギュアを並べて撮っていたのですが、

2021年末と2023年新年の一年で

  • より明るくなり
  • モチーフが明確になり
  • 構図も意識できるように

なったのは非常に大きいなと。

こちらでの広い背景も役に立ったようで。

それはさておき、これらのお茶は普段使いで消費しつつ、自分の推しのお茶を更に見つけられたらと思っています。

広がる背景での撮影。-百均グッズの撮影用小物(その38)-

より広くしたトレリスでの撮影、早速のトライです。

用いたレンズはいずれもM.ZUIKO DIGITAL ED 9-18mm。

想定通り、二人並べてピントが合う状態で撮影できました。

続けては年末に作成したこちら。

思った通り。髪の質感が見事なモデルなので、横に広がるツインテをある程度視界に入れられるのは非常にありがたく。

また、薔薇のライトもモデルを強調する補助光として役立ちます。

方向性は間違っていませんでした。他にも作っていきます。

広がる背景のメイキング。-百均グッズの撮影用小物(その37)-

今まで60mmマクロや80mmズームなどを利用していたところに広角ズームを入手。

今までと使い勝手が違うと同時に、新たな問題が浮かび上がりました。

「撮影できる部分が広い」→「より広い背景が必要になる」こと。

これでは、

これら、季節感をイメージしたトレリスだけでは物足りません。

そこで、根本的な解決策に打って出ました。

セリアにて、ワイドサイズのトレリス(木枠)を購入。そのほかに

  • ガーネット
  • フラワーリング
  • ワイヤつきの造花
  • 薔薇ライト

などをそろえました。これで背景を作っていきます。

まず、土台となる木枠にジャスミンの造花を大まかに配置し、薔薇のワイヤーライトを巻き付けていきます。

フラワーリングを置きつつワイヤーつきの造花で木枠に固定します。

隙間を埋めていき、完成。

サイズが広くなったので、ライトは2セットです。

ある程度の広さをカバーする背景となりました。

2023年のボードゲーム初め。

2023年のボードゲームはこちらから始まりました。

大鎌戦役

戸川幕府を率いてザクセン帝国と対戦。

悠々とファクトリーを先取りされますが、ファクトリーに陣取っている英雄がいるところに攻め入り

  • 戦闘勝利
  • メック4体目(移動後の展開)
  • 目的カード「機械は筋肉に勝る(手番終了時にファクトリーカードを所有し、ワーカーが3体以下、メックがいる)」達成

の、3星章を獲得。そのアドバンテージで押し切りました。

アグリコラ

2020年から習慣にしているアグリコラソロプレイの結果による「おみくじ」。

大工と壁職人の親方の強い職業を引きながらもプレイミス。なんとか挽回しましたが55点止まり。

トータル的にはやや残念な結果となりました。

年越しで組み立てたもの。(Figure-riseLABO 初音ミクV4X)

年越しに際し――

2年ぐらい前に作った南ことりの前身というべきモデルです。

樹脂の形成だけで顔の表情を作る技術は凄まじく。

デカール貼りに手間取りましたけれど、組み上げていくたびに「見慣れた姿」が浮かび上がってきます。

そして完成。このモデルが真価を発揮するのは光を当てたとき。

これにより、光沢感のある素材がより際立ちます。

当初の期待以上に撮影の被写体になりそうなモデルでした。

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

2022年のさっくりとしたまとめ。

気がつけば大晦日。今年の個人的な出来事を軽く振り返ってみます。

各月ごとの特記事項

1月

  • 新しいデジタルカメラE-PL7を購入
  • 電子書籍『Redmineで始める異世界人心掌握術』に大いに感銘を受ける

2月

  • redmineの運用を本格的に開始
  • iPad mini新調

3月

  • 検証機のredmineサーバを吹っ飛ばしたことをきっかけに自宅に専用サーバ立ち上げ

4月

  • redmineのバックアップ用などのために自宅サーバをもう1台追加
  • 仕事で苦しかった時期

5月

  • とても久しぶりのボードゲームオフ会
  • 仕事でとても苦しかった時期
  • AWSでredmine立ち上げ

6月

  • Chromebook新調
  • ちょっとした決断をする

7月

  • コロナ罹患、施設療養を体験

8月

  • E-PL7用のマクロレンズを購入
  • スマートフォン新調
  • 自宅サーバ3台目を追加

9月

  • 2年ぶりの旅行
  • 『ライザのアトリエ』コラボをきっかけに『アズールレーン』復帰

10月

  • NextCloud立ち上げ
  • ブロンプトンを修理に出す
  • ジブン手帳との再会

11月

  • メインの万年筆をLAMYに切り替え
  • 修理に出したブロンプトンの改修完了
  • 『アズールレーン』ライザのアトリエコラボ、予想以上の出来に驚愕と歓喜

12月

  • E-PL7用の広角レンズを購入
  • Dropbox→Nextcloudに移行
  • AWSインスタンスをもう一台追加

特に印象的だったこと

redmineの本格運用

これにつきます。元々は正月休みに軽く読んでみた『Redmineで始める異世界人心掌握術』を楽しく読むことができ、仕事でなんとなく使っていたredmineに可能性を見たことでした。

ここから

  1. 自分で実際に立ち上げて
  2. redmineの検証を開始し
  3. 検証DBを吹っ飛ばしたことで冗長化の大切さを学び
  4. 出先でも使いたいためにAWSを立ち上げ
  5. その過程でセキュリティ技術をかじり始める

と、「redmineと戯れた」一年でした。このツール、個人利用だけでもとても使い出があります。後述した療養生活でも体調を記録するために役立ちました。

コロナ感染

こちらもまた特筆すべきことです。検査→陽性確定→療養は気が気でありませんでした。これが徒となって

  • 夏休みの尾道旅行をキャンセル
  • ブロンプトンの改修が4ヶ月先送りになる

憂き目に遭います。軽症で済んだことと、家族や職場のサポートに感謝しました。

願わくば、2023年がよき年であるように。

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

Page 88 of 256

Powered by WordPress & Theme by Anders Norén