で、このサーバはGCEなのだけど、今日になって知った驚愕の事実はこれ。
```
[h12o@mastodon-000a]~% hostname
mastodon-000a
[h12o@mastodon-000a]~% ip a
....
2: eth0: <BROAD...
link/ether 42:01:XX:XX:00:0a ....
inet XXX.XXX.0.10/32 ....
....
```
GCEのネットワークインタフェースのMACアドレスが逆にIPv4アドレスをベースにして生成されていることだった。
悩んで損した気分である。

Show thread

そろそろひとりでGCPにまつわる問題を解決するのも難しくなってきたので、GCPUGに入るかな…
gcpug-tokyo.connpass.com/

SQLは静的プライベートIPアドレスの予約ができないのか…残念。

この サーバで障害を起こしました…。

1. Mastodonを3.1.3にアップデートしようとした。
2. アップデートしたら が4.0以上を要求されていた。
3. redis-4.0を )で入れた。
4. も2.7がwarning出しまくるので2.6にダウングレードした。
5. ところがgemがライブラリまわりでエラーになったので、面倒くさがって/etc/ld.so.conf.d/linuxbrew.confを作成してld.so.cacheを作った

→ELFエラーで詰んだ。

というわけで、 というかGCEのディスクスナップショットから書き戻したインスタンスを新たに生成しました。

正直気に入らなかったので、直接ソースをいじって修正。`gcloud components update`すると戻る可能性が大きいが、diffはとっておいて、パッチ当て一発で済むようにはしておいた。

Show thread

そこで~/google-cloud-sdkを調べたのだけど、
google-cloud-sdk/lib/googlecloudsdk/command_lib/util/ssh/ssh.pyの556〜558行目にその答えがあった。
```python:
# TODO(b/33467618): Rename the file itself
DEFAULT_PATH = os.path.realpath(files.ExpandHomeDir(
os.path.join('~', '.ssh', 'google_compute_known_hosts')))
```

いわゆるfixmeだった(笑)。

Show thread

そういえば`gcloud config-ssh`で のconfigファイルに へのログイン設定を挿入してくれるのだけど、鍵ペアがgoogle_compute_engine{,.pub}なのにknown_hostsファイルがgoogle_compute_known_hostsで、違和感を感じていた。

以前 CentOS 7 VMのカーネルを更新したらSheilded VMの完全性エラーが出たが、このインスタンスでやってみたら問題なく新しいカーネルでブートした。もちろんこちらもSheilded VMなのだが、なぜ…
QT: blessedgeeks.social/@h12o/1039

h12o(β)  
結局VMを作り直した。なお、1時間ほどでVM削除→ディスクのスナップショット作成→VM再作成→スナップショットから追加ディスクを作成してマウント→etcとhomeの必要な中身を取り出しまで成功した。 #GoogleCloud

補足。「実際には だとリージョンごとに/20で切られている」のは自動モードのVPCネットワークで自動的に作成されるサブネットで、リージョンごとに 1 つのサブネットとして構築されている。

Show thread

もっというと、VPCのアドレスレンジも多くてせいぜい/16で、実際には だとリージョンごとに/20で切られているので、下3桁を使えば確実に一意になる(内部FQDNはリージョン名が入るので、リージョンのネットマスク(?)部分を考慮する必要はない)。

Show thread

結局VMを作り直した。なお、1時間ほどでVM削除→ディスクのスナップショット作成→VM再作成→スナップショットから追加ディスクを作成してマウント→etcとhomeの必要な中身を取り出しまで成功した。

Show thread

うーん。

`gcloud compute instances update "${INSTANCE_NAME}" --shielded-learn-integrity-policy`してから`gcloud compute instances stop "${INSTANCE_NAME}"`→`gcloud compute instances start "${INSTANCE_NAME}"`を順にやったら、エラーは出なくなったものの、`Kernel Offset: 0x9e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)`から先に進まなくなってしまった。

正直よく分からないのだけど、インスタンスを作り直した方がよさそうだ。ディスクの中身は拾えたらラッキーか。

Show thread

Shielded VM、めんどくさくなってきた…

ここで止まっている。
```
[ 1.761139] [<ffffffff8b569c10>] ? rest_init+0x80/0x80
[ 1.761883] [<ffffffff8b569c1e>] kernel_init+0xe/0x100
[ 1.762671] [<ffffffff8b58dd37>] ret_from_fork_nospec_begin+0x21/0x21
[ 1.763616] [<ffffffff8b569c10>] ? rest_init+0x80/0x80
[ 1.765624] Kernel Offset: 0x9e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
```

Show thread

なお、シリアルポートの出力は
```
[ 1.756473] [<ffffffff8bb89790>] mount_block_root+0x291/0x2a0
[ 1.757693] [<ffffffff8bb897f2>] mount_root+0x53/0x56
[ 1.758484] [<ffffffff8bb89931>] prepare_namespace+0x13c/0x174
[ 1.759348] [<ffffffff8bb8940e>] kernel_init_freeable+0x222/0x249
[ 1.760232] [<ffffffff8bb88b1f>] ? initcall_blacklist+0xb0/0xb0
```

Show thread

さらに
cloud.google.com/compute/docs/
によると
>>
整合性ポリシー ベースラインを更新するには、setShieldedInstanceIntegrityPolicy 権限が必要です。

整合性ポリシー ベースラインを更新する手順は次のとおりです。
<<

`gcloud compute instances update my-instance --shielded-learn-integrity-policy`
を実行する必要があるとのこと。

Show thread

`json.jsonPayload.lateBootReportEvent.actualMeasurements = [];`

`json.jsonPayload.lateBootReportEvent.policyMeasurements = [];`
を比較すると確かに違っている。

cloud.google.com/compute/docs/
>>
actualMeasurements セクションと policyMeasurements セクションの PCR 値を比較して、前回のブート シーケンスと整合性ポリシー ベースラインとの間の差異がどこにあるのかを判断します。どちらの比較であっても、異なる値を示したものが検証を失敗させた原因です。
<<

Show thread
Show more