背景
私の目的は、 Packer を使用して、セキュリティを向上させるために、さまざまなファイルシステムにマウントされたいくつかの異なるパスを持つAmazonマシンイメージ(AMI)を作成することです。例えば。 /tmp
は、noexec
オプションを使用してファイルシステムにマウントする必要があります。
AMIを作成するための自動化されたプロセスを作成したいという事実は、インスタンス自体で再マウントコマンドを実行できないことを意味するため、代わりにPacker Amazon-chroot builder を使用しています。これは、EC2インスタンスを実行し、そのEC2インスタンスからPackerを実行することを意味します。次に、Packerは、「ソースAMI」で使用されるEBSスナップショットから取得したEBSボリュームをマウントします。マウントされたEBSボリュームでいくつかの操作を実行する必要があります。
私は このトピックに関する最近のプレゼンテーション そのスライドが http://wernerb.github.io/hashiconf-hardening にあることからインスピレーションを得ています。
私の質問
EBSボリューム(ブロックデバイス)が最初にマウントされたとき、gdisk -l /dev/xvdf
から表示されるパーティションは次のとおりです。
Disk /dev/xvdf: 16777216 sectors, 8.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 726A877B-31D7-4C00-99E4-5A2CCB8E0EAD
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 16777182
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 4096 16777182 8.0 GiB 8300 Linux
128 2048 4095 1024.0 KiB EF02 BIOS Boot Partition
次に、次の操作を実行します。
sgdisk --delete 1 /dev/xvdf
で「Linux」パーティションを削除しますlvm vgcreate -y main /dev/xvdf1
を使用してLVMボリュームグループを作成します/sbin/mkfs.ext4 -m0 -O ^64bit "/dev/main/lvroot"
のようなコマンドでそれぞれをフォーマットします/etc/fstab
を次のように更新します(これは、ホストシステムの観点からは/mnt/ebs-volume/etc/fstab
です)。/ etc/fstab/dev/xvdf1:に書き込みます
#
/dev/mapper/main-lvroot / ext4 defaults,noatime 1 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/mapper/main-lvvar /var ext4 defaults 0 0
/dev/mapper/main-lvvarlog /var/log ext4 defaults 0 0
/dev/mapper/main-lvvarlog/audit /var/log/audit ext4 defaults 0 0
/dev/mapper/main-lvhome /home ext4 defaults 0 0
/dev/mapper/main-lvtmp /tmp ext4 defaults 0 0
最後に、Packerは/dev/xvdf
をアンマウントし、そのEBSボリュームのコンテンツに基づいてAmazonマシンイメージ(AMI)を作成します。
これまでのところ、新しいAMIを起動しようとしても、実際には起動しないことを除けば、これまでのところ良好です。 SSH経由で接続できず、AWS経由の「システムログの表示」に何も表示されません。したがって、「BIOSブートパーティション」を含む「128」パーティションの周りで何かを台無しにしていると思います。また、新しいEC2インスタンスが起動したときに、LVMで作成された論理ボリュームがどのように「アクティブ化」されるのかについても混乱しています。
基本的に、そのブートパーティションに存在する必要があるものと、LVMを使用してルートボリューム自体を作成した場合にEC2インスタンスがLVMを起動して実行する方法についてのメンタルモデルがありませんか? /boot
に特別なパーティションを作成する必要があるかどうか疑問に思っていますが、それに何を入れますか?実際、/dev/xvdf
に3つのパーティション、「BIOSブートパーティション」、/boot
用の「従来の」(ext4フォーマット)パーティション、その他すべて用のLVM管理パーティションを用意する必要がありますか?
この問題はLVMとは無関係であることが判明しました。 この変更によりブロックデバイスが起動できなくなるのはなぜですか? で明らかにされているように、本当の問題は、/
と/boot
を2つの別々のパーティションに分割することにより、MBR構成がなくなったことです正しい。これを修正するためにGRUB構成ファイルを更新できなかったため、最終的には/
と/boot
を同じパーティションに保持し、他のパーティションを別々に追加する必要がありました。理想的ですが、機能します。
LVM論理ボリュームから起動するための鍵は、(もちろん)カーネルでLVMをサポートし、LVMサポートを含むinitrdで起動することです。 initrdの作成は簡単ではないため、LinuxディストリビューションがLVMから起動するように設定されているかどうかを調べることをお勧めします。また、EC2がinitrdを使用してカーネルを起動していることを確認してください。