h12o(β) boosted

大変残念ですが、育児インスタンス「Babuu」が閉鎖されることとなったそうなので、このたび育児インスタンスを作成しました
育児や子育てにかかわる方であればどなたでも登録できますので、よろしければいらしてください
t.co/CKADmgfqZ8

結局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
h12o(β) boosted

@h12o たぶん初めて知りました、行ごとに冗長な表現にして、grep-ableにすると。いいっすね。 github.com/tomnomnom/gron/blob

@tadd そうなんですよ。しかも出力はJavaScriptとして解釈可能なんですよね。

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

復旧はできるようになったとして、予防策を知りたいな。

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

cloud.google.com/compute/docs/
に沿って
lateBootReportEventで`json.jsonPayload.lateBootReportEvent.policyEvaluationPassed = false;`になっていることを確認。
```js:
json = {};
json.insertId = "2";
json.jsonPayload = {};
json.jsonPayload.bootCounter = "7";
json.jsonPayload.lateBootReportEvent = {};
json.jsonPayload.lateBootReportEvent.policyEvaluationPassed = false;
```

Show thread

CentOS 7 VMのカーネルを更新したらSheilded VMの完全性エラーが出た…

Google Cloud VMのログはJSONなので、gronで解読していく。
```js:
json = [];
json[0] = {};
json[0].jsonPayload = {};
json[0].jsonPayload["@type"] = "type.googleapis.com/cloud_integrity.IntegrityEvent";
json[0].resource = {};
json[0].resource.labels = {};
json[0].resource.type = "gce_instance";
json[0].severity = "ERROR";
```

あと、悲しいことに
`if [ -v HOMEBREW_PREFIX ]; then`という書き方が通用するのは 5.3からで、 のzsh 5.0.2には通用しない…

Show thread
Show more