web-dev-qa-db-ja.com

AmazonLinux用の起動可能なEBSボリュームを作成する方法

背景

私の目的は、 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ボリュームグループを作成します
  • 一連のLVM論理ボリュームを作成し、/sbin/mkfs.ext4 -m0 -O ^64bit "/dev/main/lvroot"のようなコマンドでそれぞれをフォーマットします
  • それらをすべてマウントし、ファイルの束をコピーします
  • アタッチされたEBSボリュームの/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管理パーティションを用意する必要がありますか?

4
Josh Padnick

この問題はLVMとは無関係であることが判明しました。 この変更によりブロックデバイスが起動できなくなるのはなぜですか? で明らかにされているように、本当の問題は、//bootを2つの別々のパーティションに分割することにより、MBR構成がなくなったことです正しい。これを修正するためにGRUB構成ファイルを更新できなかったため、最終的には//bootを同じパーティションに保持し、他のパーティションを別々に追加する必要がありました。理想的ですが、機能します。

2
Josh Padnick

LVM論理ボリュームから起動するための鍵は、(もちろん)カーネルでLVMをサポートし、LVMサポートを含むinitrdで起動することです。 initrdの作成は簡単ではないため、LinuxディストリビューションがLVMから起動するように設定されているかどうかを調べることをお勧めします。また、EC2がinitrdを使用してカーネルを起動していることを確認してください。

1
Emmanuel Rosa