SSL証明書と秘密鍵のペアの確認
SSL証明書と秘密鍵のペアを確認するコマンドを毎回忘れてしまうのでメモしておく。
- 証明書
$ openssl x509 -noout -modulus -in hogehoge.cer | openssl md5 b1468e24045016fe4e185d30ac363b47
$ openssl rsa -noout -modulus -in hogehoge.pem | openssl md5 b1468e24045016fe4e185d30ac363b47
ハッシュ値が一致していればペアの可能性が高い。
awsのacmへ証明書をimportする際は、秘密鍵をバックアップしておかないとコンソールからもaws acmコマンドからでも取得出来ないので注意が必要。
読書の見直し
本の積読が増えてきたので、読書方法を見直してみる。
今後実施していく内容
- メルカリを活用した読書術を実践してみる。
- 購入してから出品までの読書可能期間を設定する。
- ビジネス本: 2週間
- 技術本, 小説: 3週間
内容
以下の項目に対して、現状の記録や振り返りをしてみる。
- 読書の目的
- 購入する本の量やタイミングが適切かどうか
- 読書の機会を作れているかどうか
- 読書の方法
- 本を読んで目的が達成されているか
読書の目的
気づきを得たり、知識を深めるために読書を行なっている。
ビジネス本であれば、トレードオフに対する解消 が根拠とともに説明されていることが良い本だと考えている。
なので
- 知識を深めることができる
- 新しい発見や気づきを得ることができる
- トレードオフに対する解消ができる
できるものを読書の目的とする。
本を購入する量は適切なのか
現在は興味があれば、読んでいる本があったとしてもアマゾンや書店などで購入をしている。
一旦は読書の目的さえ達成できれば問題がないため、何かしらの対策は行わないで経過観察を行う。
本を読む機会を適切に作れているのか
意識的には作れてはいない。 現状は、以下のスペースで読む機会が多い。
- 土曜日の朝のカフェ
- 平日夜の湯船に浸かりながら
- 部屋で気が向いた時
本をどのように読んでいるのか
気分がのらなくなったらやめる。
ダラダラと読んでも時間が勿体無い。
積読される本も増えると邪魔にもなるので、一定の期限を設けて超過することがあればメルカリに出品する。
本を読んで目的が達成されているのか
基本的にはその時々で達成はされるものの、後々振り返ると忘れることも多いので記録には残しておきたいと思うことが度々ある。
そのため、本を読んだらブログに記録を行う。
以下の本を読んでいく予定。
12月に購入した本
毎月購読している技術本のSoftware Design。
アメリカの大統領選挙を調べていくうちに中国との関係とトランプの実施したことを整理するために購入した本
香港の一国二制度を破った中国を調べる中で台湾にも興味を持ったので購入した本。
日本国憲法への理解を深めるために購入した本。
小説読めていなかったので有名どころの本を一冊友人の薦めもあり購入した本。
daemontools管理サービスに対してTERMシグナルが効かなくなった時の対応
Overview
TERMシグナルを送ってもpidが変わらない場合は、Killシグナルをpidに送ってプロセス自体を落とす。- サービス自体はdaemontoolsで管理しているためkillされたサービスは自動で上げてくれるため再起動となる。
内容
daemontoolsに対してTERMシグナルを送っても効かなかったためその対応の記録です。
strace コマンドを利用し、特定プロセスのシステムコールレベルの処理をトレースしてみる
# strace -p 18043
Process 18043 attached - interrupt to quit
clock_gettime(CLOCK_MONOTONIC, {21942263, 214411873}) = 0
clock_gettime(CLOCK_MONOTONIC, {21942263, 214454654}) = 0
epoll_wait(17, {}, 64, 9) = 0
clock_gettime(CLOCK_MONOTONIC, {21942263, 223633781}) = 0
clock_gettime(CLOCK_MONOTONIC, {21942263, 223668174}) = 0
epoll_wait(17, {}, 64, 1) = 0
clock_gettime(CLOCK_MONOTONIC, {21942263, 224836558}) = 0
clock_gettime(CLOCK_MONOTONIC, {21942263, 224875851}) = 0
epoll_wait(17, {}, 64, 999) = 0
clock_gettime(CLOCK_MONOTONIC, {21942264, 225003708}) = 0
clock_gettime(CLOCK_MONOTONIC, {21942264, 225060544}) = 0
epoll_wait(17, {}, 64, 999) = 0
clock_gettime(CLOCK_MONOTONIC, {21942265, 225225110}) = 0
clock_gettime(CLOCK_MONOTONIC, {21942265, 225266000}) = 0
epoll_wait(17, {}, 64, 999) = 0
clock_gettime(CLOCK_MONOTONIC, {21942266, 225429915}) = 0
clock_gettime(CLOCK_MONOTONIC, {21942266, 225469449}) = 0
epoll_wait(17, {}, 64, 998) = 0
clock_gettime(CLOCK_MONOTONIC, {21942267, 224646569}) = 0
clock_gettime(CLOCK_MONOTONIC, {21942267, 224699790}) = 0
futex(0x7ff830810644, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7ff830810640, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7ff83081067c, FUTEX_WAIT_PRIVATE, 5703703, NULL) = -1 EAGAIN (Resource temporarily unavailable)
write(6, "!", 1) = 1
EAGAIN (Resource temporarily unavailable) なので、システムのプロセステーブルが多くなり fork(2) システムコールが失敗した、あるいはメモリーまたはスワップ空間が足りないためにシステムコールが失敗した可能性が高い。
svc -du を行なったも同様の結果になる。
そのためTERMシグナルを送ってもpidが同様の場合は、daemontools管理のサービスpidを終了させる対応を入れる。
対象サービスは親プロセスに紐づいて子プロセスがいる。
$ pstree -A
init-+-abrtd
|-svscanboot(1681)-+-readproctitle(1713)
| |-supervise(1724)---ruby(26456)-+-ruby(26473)-+-{ruby}(26475)
| | | |-{ruby}(26483)
| | | |-{ruby}(26485)
| | | |-{ruby}(26487)
| | | `-{ruby}(27879)
| | `-{ruby}(26474)
親プロセス(26456) だけをkillすると子プロセスがゾンビ化してしまう。
$ kill -9 26456
$ pstree -A
|-ruby(26473)-+-{ruby}(26475)
| |-{ruby}(26483)
| |-{ruby}(26485)
| |-{ruby}(26487)
| `-{ruby}(27879)
親プロセスと子プロセスを一括で終了してくれるコマンドを探してみたが良さそうなのは見つけられなかった。
kill -SIGTERM -- -<PID>
=> 子は死なずにゾンビプロセスとなる。ルートに移行されるので利用できない。
pgrep を利用すると子プロセス一覧を取得できるため
$ sudo ps auxf | grep fluentd root 1724 0.0 0.0 3992 476 ? S Jun17 0:01 | \_ supervise fluentd-audit root 11923 0.4 0.6 103484 23944 ? Sl 13:51 0:00 | | \_ /opt/td-agent/embedded/bin/ruby /usr/sbin/td-agent --use-v1-config -c /data/daemon/fluentd-audit/td-agent.conf -p /data/daemon/fluentd-audit/plugin root 11944 0.9 1.2 188112 51708 ? Sl 13:51 0:00 | | \_ /opt/td-agent/embedded/bin/ruby /usr/sbin/td-agent --use-v1-config -c /data/daemon/fluentd-audit/td-agent.conf -p /data/daemon/fluentd-audit/plugin root 12560 0.0 0.0 103304 1992 pts/1 S+ 13:52 0:00 \_ grep fluentd
親プロセスから子プロセス一覧を取得（pgrep -P <親プロセス>）させ、svc -t でも子プロセスが死なない場合は、子プロセスをkillする実装方針でコーディングを行い対応した。
default packageのファイルかどうかの確認
掲題の通りで、デフォルトパッケージによるファイルなのかどうか調べることがあったのでメモ。
調べたいファイルのパッケージを確認。
$ cat /etc/issue Ubuntu 18.04.4 LTS \n \l $ dpkg -S /etc/snmp/snmp.conf snmp: /etc/snmp/snmp.conf
パッケージに入っているファイルの確認。
$ dpkg -L snmp | grep /etc/snmp/snmp.conf /etc/snmp/snmp.conf
以下のサイトでsnmpパッケージの検索。
存在を確認したのでデフォルトのパッケージで入るファイルと確認できる。
EBS Volumes SSD (gp3) - Throughput でおかしな金額の請求が来た話
Overview
内容
EBS Volumesの SSD (gp3) - Throughput の料金表を確認すると
General Purpose SSD (gp3) - Throughput 125 MB/s free and $0.048/provisioned MB/s-month over 125
125MBまでは無料で超過分は1MB毎に月0.048ドルかかる。 なので、1volume 500MB利用であれば
(500 - 125) * 0.048 * 1volume = 月当たり18ドル
ところが請求書を確認するとSSD (gp3) - Throughput項目にやたらと大きな数字があったため他にも同じような人がいないのか調べてみると
mobile.twitter.comAnyone muck around with the gp3 volumes, changing throughput, and got a very unpleasant bill surprise? I think there's a bug in the calculation there...set up a 500 MB/s Gp3 drive for <24 hours and got a 42k bill. #aws #awsreinvent2020
— Chris Pollard (@Chrisp1516) December 2, 2020
24時間未満で42kの請求が来ている人もいたみたい。
Following up on this - the EBS team has identified the issue and will fix the billing. If anyone was impacted by this, please open a support request. Feel free to DM me the case ID and I could help to confirm it's resolved.
awsの従業員の返信にも請求書を修正するためサポートケースを切って対応とあるのでケースを切ってリクエストしてひとまず一安心できそう。
