とりあえず触ってみないと始まらない。
ということで、今回はBGMを作ってみた。
音楽：SUNO AI
右上のMake a songを押して、好きなアカウントからソーシャルログイン
Song Descriptionに作成したい曲のイメージなどを入力し、Createを押すだけ。
一回の作成で２曲生成されます。
Passkey: 未来の認証方法
新しい認証方法、「Passkey（パスキー）」
パスキーとは：
パスワードに置き換わるFIDO認証資格情報です。
ユーザーのデバイスを問わず、ウェブサイトやアプリケーションへのより速く、簡単、安全なサインインを提供するパスワードの代替品です。
仕組み：
パスキー認証は公開鍵暗号方式に基づいています。パスキーでウェブサイトにサインインする際には、サーバーからのチャレンジをデバイス内に保存された秘密鍵で署名し、サーバーに送信します。サーバーは事前に登録してあった、署名に用いた秘密鍵の対となる公開鍵で署名を検証を行うことで認証します。
デバイス内に保存された秘密鍵で署名する際に、PCやスマホであればそのデバイスにロック解除機能（Windows Hello、FaceIDなど）で本人確認を行うため、本人検証はローカルで行い、サーバー側では署名検証のみを行うため、認証資格情報を窃取するようなフィッシング攻撃に耐性があります。
課題
パスキーの欠点は、パスキー利用はデバイスに依存するということです。認証情報はデバイスに格納されているので、デバイスを紛失した場合は認証情報が漏え いする可能性があります。
まとめ
パスキーはパスワードの代わりとなる認証情報です。フィッシング詐欺などにも強く、セキュリティと利便性の両面で優れた選択肢となっています。パスワードの問題点を解消し、多要素認証と組み合わせることでセキュリティを向上させられるのが大きなメリットです。
設定方法も簡単で、すでに多くのサービスがパスキーに対応しています。パスキーの利用にはデバイスに依存する点や共有デバイスでの使用といった注意が必要ですが、解除・削除は簡単に行えます。
パスキーはパスワードの問題点を解消し、セキュリティと利便性を高める重要なツールとして有効です。まだ設定していない人は、この機会に設定してみてはいかがでしょうか。
EC2 EBS ボリュームサイズ拡張の方法
tl;dr
EC2 でディスク使用量がパンパンになってきて
ボリュームをオンラインで拡張したくなったときのやりかたメモです。
基本的に公式ガイドに沿えば OK
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
のようですが、今回のケースではうまくいかなかったため、別の方法で実施したましあので、その内容をシェアします。
チェック
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.7G 6.7G 1.1G 87% /
(※ルート以外省略してます)
ここのルート / の容量を拡張したいとします。
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
ボリュームの容量をチェックしておきます。
ボリュームの容量を変更する
コンソールだとボリュームの編集でかんたんに変更できます:
(少しだけ時間かかります。5分くらい？)
パーティションの拡張
で lsblk でサイズを再度確認してみます:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 12G 0 disk
└─xvda1 202:1 0 8G 0 part /
ボリューム全体のサイズは拡張されていますが、
ルートのパーティションのサイズは変わってません。
なので growpart で xvda1 のサイズを拡張します:
sudo growpart /dev/xvda 1
CHANGED: partition=1 start=2048 old: size=16775135 end=16777183 new: size=25163743,end=25165791
CHANGED とか出たら変わってます。
容量がカツカツのときはこの操作に必要な一時ファイルを/tmp に作成することもできないので、いくらか空き容量を空けておきます。
ふたたび lsblk してパーティションが拡張されていれば OK です:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 12G 0 disk
└─xvda1 202:1 0 12G 0 part /
ファイルシステムの拡張
ここで df -h をしてみて、まだ容量が変化してないことに気づいたときは:
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.7G 6.7G 1.1G 87% /LVの拡張まで行って、最後にファイルシステムを拡張しようとするときに、CentOS 6の時代と同じくresize2fs とやると以下のエラー
[root@localhost ~]# resize2fs /dev/xvda1
resize2fs 1.42.9 (28-Dec-2013)
resize2fs: Bad magic number in super-block while trying to open /dev/centos/root
Couldn't find valid filesystem superblock.
調べていくと、CentOS 7 からデフォルトになっているXFSではresize2fsは利用できないということ。
XFSではresize2fs の代わりに xfs_growfs を使えばＯＫ
[root@localhost ~]# xfs_growfs /dev/centos/root
meta-data=/dev/mapper/centos-root isize=256 agcount=4, agsize=3276800 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0
data = bsize=4096 blocks=13107200, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=6400, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 13107200 to 39321600
[root@localhost ~]# echo $?
0
うまくいきました。
