Q: Amazon Linux AMI とは何ですか?

Amazon Linux AMI は、Amazon Elastic Compute Cloud(Amazon EC2)で使用するアマゾン ウェブ サービスによって提供される、サポートおよび管理された Linux のイメージです。これは Amazon EC2 上で実行するアプリケーションのために、安定した安全で高性能な実行環境を提供できるよう設計されています。また、起動設定ツールおよび多くの AWS 人気ライブラリやツールなど、AWS の統合を容易にするいくつかのパッケージも含まれています。アマゾン ウェブ サービスでは、Amazon Linux AMI を実行するすべてのインスタンスに対し、セキュリティと保守のアップデートを継続的に提供しています。Amazon EC2 のユーザーの方は、追加料金なしで Amazon Linux AMI をご使用いただけます。

Q: Amazon Linux AMI へのソースコードを見ることができますか?

はい。Amazon Linux AMI で提供されるソースコマンドラインツールである yumdownloader により、Amazon EC2 内のソースコードを表示できます。

Q: Amazon Linux AMI はどこで更新できますか?

各 Amazon EC2 リージョンがホストしている、事前設定された yum リポジトリを介して更新することができます。セキュリティ更新は、AMI の最初の起動時に自動的に適用されます。ログイン時に、Message of the Day (当日のメッセージ) (/etc/motd) により追加のアップデートがあるかどうかが示されます。

Q: Amazon Linux AMI のアップデートはどれくらいの頻度で提供されますか?

Amazon Linux AMI はローリングリリースで構築、管理されます。Amazon Linux AMI はちょうど 1 本の川のようなパッケージで、AMI イメージ自体はその時点でのスナップショットにすぎないと考えてください。

 

ローリングリリースによって、Amazon Linux AMI とそれらに基づくお客様のインスタンスが、EC2 と AWS が起動する最新の機能をサポートします。これにより、Amazon Linux AMI は、その他の Linux AMI プロデューサー(サードパーティおよび Amazon Linux AMI のダウンストリーム)の参照点となり、それらも最新の機能をサポートします。

 

このモデルにより、お客様は最新のセキュリティ、パフォーマンスおよび機能の強化を実行でき、遭遇する可能性のある広い範囲の問題を緩和します。

Q: Amazon は Amazon Linux AMI のサポートを提供していますか?

はい。Amazon Linux AMI は、AWS Support のサブスクリプションを介してサポートされています。詳細については、AWS Support ページをご覧ください。

Q: Amazon Linux AMI は EC2 以外でサポートされますか?

いいえ。Amazon Linux AMI は、Amazon EC2 内のみで使用可能です。

Q: バグ報告、機能のリクエスト、およびパッケージのリクエストを報告するにはどうすればよいですか?

Amazon EC2 フォーラムでバグ報告、機能のリクエスト、およびパッケージのリクエストを受け付けております。このフォーラムには、AMI エンジニアリングチームに加えて AWS Developer Support の担当者も参加しています。

Q: Extra Packages for Enterprise Linux(EPEL)リポジトリを有効にするにはどうすればよいですか?

/etc/yum.repos.d/epel.repo を変更します。[epel] セクションで、enabled=0 を enabled=1 に変更します。

一時的に EPEL 6 リポジトリを有効にするには、yum コマンドラインオプション --enablerepo=epel を使用します。

Amazon Linux AMI リポジトリは、サードパーティのリポジトリよりも高い優先度で構成されています。これは、Amazon Linux AMI に含まれるパッケージが、サードパーティリポジトリにも含まれることもあるからです。この構成により、Amazon Linux AMI バージョンがデフォルトでインストールされるようになります。

Q: AMI を特定のバージョンに固定するにはどうすればよいですか?

Amazon Linux AMI リポジトリ構造は、Amazon Linux AMI の 1 つのバージョンから次のバージョンへのローリング更新を可能にする、連続的な更新を提供するように設定されています。

パッケージの更新はいつもリポジトリへ組み込まれ、yum が「最新」に設定されている、どのバージョンの Amazon Linux AMI にも適用されます。お客様のインスタンスがどのリポジトリを指しているかを /etc/yum.conf の releasever 変数で確認します。Amazon Linux AMI ではデフォルトで releasever=latest にセットされています。

つまり、Amazon Linux AMI は各ポイントでのスナップショットとして処理されます。このスナップショットにはリポジトリとアップデートの構造が保存され、これにより、リポジトリに組み込んだ構築済みの最新パッケージが提供されます。

Amazon Linux AMI の新しいメジャーバージョンがリリースされたときにパッケージの更新を受け取ることを希望しない場合、「lock on launch」は特定のメジャーバージョンで AMI を固定する簡単な方法です。

この機能を新しいインスタンスで有効にするには、EC2 コンソールを使用するか、aws ec2 run-instances で -f フラグを指定して、(例えば)2015.09 Amazon Linux AMI を起動し、次のユーザーデータを cloud-init に渡します。

#cloud-config
repo_releasever: 2015.09

既存のインスタンスを現在のバージョン(/etc/system-release で指定)に固定するには、etc/yum.conf を編集します。releasever=latest という行をコメントアウトし、yum clean all を実行してキャッシュをクリアします。

注: AMI を「最新」ではないリポジトリのバージョンに固定すると、それ以上の更新を受け取ることができなくなります。Amazon Linux AMI の更新を継続的に受け取るには、最新の AMI を使用するか、必ず「最新」とされているリポジトリで古い AMI を更新する必要があります。

Q: 初回起動時に非常に重要なセキュリティアップデートの自動インストールを無効にするにはどうすればよいですか?

初回起動時に Amazon Linux AMI では、パッケージリポジトリから、必須または重要と思われるすべてのユーザースペースセキュリティアップデートがインストールされます。このインストールは、SSH などのサービスが開始される前に実行されます。

AMI が yum リポジトリにアクセスできない場合は、それがタイムアウトとなり、起動手順が完了する前に複数回再試行されます。考えられる理由としては、制限されたファイアウォール設定または VPC 設定により Amazon Linux AMI のパッケージリポジトリへのアクセスが妨げられていることが挙げられます。

この問題が発生した場合は、環境を変更して Amazon Linux AMI がそのパッケージリポジトリに接続できるようにするか、または起動時にセキュリティアップデートを無効にすることができます。

起動時に、AWS EC2 コンソールからセキュリティアップデートを無効にする方法:

リクエストインスタンスウィザードの「高度なインスタンスオプション」ページに、Amazon Linux AMI のユーザーデータを送信するテキストフィールドがあります。このデータは、テキストとして入力するか、またはファイルとしてアップロードすることができます。どちらの場合でも、データは以下のようになります。

#cloud-config
repo_upgrade: none

起動時に、コマンドラインからセキュリティアップデートを無効にする方法:

前述のユーザーデータを使用してテキストファイルを作成し、--user-data file:// フラグを含む aws ec2 run-instances に渡します (これは、ec2-run-instances -f でも実行できます)。

Amazon Linux AMI をリバンドリングする際、起動時にセキュリティアップデートを無効にする方法:

/etc/cloud/cloud.cfg を修正し、repo_upgrade: securityrepo_upgrade: none に変更します。

Q: インターネットゲートウェイまたは NAT インスタンスなしに Virtual Private Cloud(VPC)で実行する際、なぜ SSH の起動に長時間かかるのですか?

前の質問の答えをご覧ください。

Q: 私の RAID アレイはなぜ /dev/md0 ではなく /dev/md127 で始まるのですか?

新しいバージョンの mdadm では、バージョン 1.2 スーパーブロックで RAID アレイが作成されるので、番号が付いたデバイスによる自動アセンブルは行われません。ファイルシステムのラベルを設定して、パーティションを参照します。ファイルシステム作成ツールでラベルを設定する場合は、ほとんどのツールで -L フラグを使用します。一度設定されたラベルは、マウントまたは LABEL=[NAME] が指定された /etc/fstab によって参照されます。

例: ラベルで RAID0 アレイを作成する。

mdadm --create --verbose /dev/md0 --level=0 --name=0 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 -L RAID0 /dev/md0
mkdir -p /mnt/RAID0
mount LABEL=RAID0 /mnt/RAID0

例: 既存の ext[2-4] ファイルシステムのラベルを設定する。

e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

Q: wheel グループが /etc/sudoers から無効にされたのはなぜですか? これを再度有効にするにはどうすればよいですか?

Linux オペレーティングシステムでは、wheel が sudo に対して有効かどうかについては、デフォルトの設定がさまざまです。sudo からの wheel がデフォルトで無効になっているのは、Amazon Linux AMI のセキュリティに対する姿勢を考えると理にかなっています。

この問題は、デフォルトの ec2-user としてインスタンスに SSH 接続できるかどうか、また、ユーザーによる sudo の使用機能を変更したかどうかに応じて、2 つの方法で回避できます。

オプション 1: ユーザーがデフォルトの機能を変更していない場合は、引き続き ec2-user としてインスタンスに SSH 接続し、そこから sudo を起動してルートにアクセスし、sudoers ファイルを変更して wheel を再度有効にできます。

オプション 2: ユーザーがデフォルトを変更した場合、または ec2-user からルートに sudo を実行できない場合は、次の手順を実行することをお勧めします。

  • 影響のあるインスタンスを停止します(終了はしません)。
  • EC2 コンソールまたは EC2 API ツールを使用して、ルート EBS ボリュームをデタッチします。
  • リモートルートアクセスできる他の EC2 インスタンスにボリュームをアタッチします。
  • そのインスタンスにログインします。
  • 新しくアタッチされたボリュームをマウントします。
    sudo mount /dev/xvdf /mnt
  • アタッチされたボリュームで sudoers ファイルを変更し、wheel グループのコメントを解除します。
    sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
  • ボリュームのコメントを解除します。
    sudo umount -d /dev/xvdf
  • ボリュームをデタッチします。
  • 停止されたインスタンスにボリュームを再アタッチします(デタッチ前と同じデバイスであることを確認してください。通常は /dev/sda1 です)。
  • 影響のあるインスタンスを開始します。

Q: 端末から Amazon Linux AMI にアクセスすると、� や â などの奇妙な文字が表示されるのはなぜでしょうか?

Amazon Linux AMI は、デフォルトで UTF-8 文字エンコーディングを使用します。UTF-8 エンコーディングを使用していないクライアント端末は、UTF-8 文字を正しく変換できないことがあります。この問題を修正するには、クライアント端末のエンコーディングを UTF-8 に設定します。

  • GNOME 端末: 端末のメニューから [Set Character Encoding] を選択し、[UTF-8] を選択します。
  • PuTTY: タイトルバーを右クリックしてメニューを呼び出します。次に、[Change Settings] を選択します。[Window] → [Translation] → [Remote Character Set] の下で、[UTF-8] を選択します。

Q: オプションの report_instanceid/etc/yum.repos.d/amzn*.repo にあります。これは何をするのですか?

Amazon Linux AMI リポジトリは、各リージョン内の S3 バケットです。このバケットからインスタンスの yum プロセスによってパッケージがダウンロードされるとき、対応する S3 接続に関する情報が記録されます。

Amazon Linux AMI のコンテキスト内で report_instanceid=yes と設定すると、Amazon Linux AMI リポジトリでは、パッケージをダウンロードしているインスタンスのインスタンス ID (i-xxxxxxxx) やリージョン (us-west-2 など) も記録できます。これにより、Amazon Linux AMI チームは個々のインスタンスについて、より詳細で具体的なカスタマーサポートを提供することができます。

report_instanceid=yes は、Amazon Linux AMI リポジトリでのみデフォルトで有効になっています。

Q: システムリリースパッケージがアップグレードされると、/etc/yum.repos.d/amzn*.repo の yum リポジトリ設定ファイルが上書きされるのはなぜですか?

システムリリースパッケージがアップグレードされると、リポジトリ設定ファイルは上書きされます。これにより、Amazon Linux AMI yum リポジトリ構成に対する変更内容が各インスタンスによって確実に参照されるようになります。

2014.09 より前のバージョンの Amazon Linux AMI の場合

これらのファイルは cloud-init によって、/etc/cloud/templates/amzn-*.repo.tmpl にあるテンプレートから生成されます。これらのテンプレートファイルに加えられた変更は永続的です。

2014.09 以降のバージョンの Amazon Linux AMI の場合

/etc/yum.repos.d/amzn*.repo ファイルで yum 変数を使用することで、各インスタンスが地理的に最も近いリポジトリを参照するようになったため、cloud-init テンプレートが不要になりました。これらのファイルに対する編集内容は、システムリリースのアップグレード時に、/etc/yum.repos.d/amzn*.repo.rpmsave として保存されます。

2014.09 バージョンにアップグレードすると、/etc/yum.repos.d/amzn*.repo ファイルに対するすべての変更内容は /etc/yum.repos.d/amzn*.repo.rpmsave ファイルとして保存されます。

Q: man ページの色を変更する、または無効にする方法を教えてください。

man ページの色は、/etc/profile.d/less.sh(bash と zsh)および /etc/profile.d/less.csh(csh)で設定されています。無効にするには、export LESS_ (bash, zsh) や setenv LESS_ (csh) で始まるすべての行を削除します。

Q: 2015.09 インスタンスより前のシステムコール監査をどのように無効にできますか?

2015.09 Amazon Linux AMI を新たに起動すると、システムコール監査はデフォルトで無効になっています。システムコール監査は、特にディスク集約型またはネットワーク集約型アプリケーションでの、顕著なパフォーマンスの低下に関するすべてのシステムコールをオーバーヘッドで追加します。

システムコール監査が必要な場合 /etc/audit/audit.rules の行を探し、削除あるいはコメントアウトし、audit デーモンを再起動します。

-a never,task

例(ルートとして)

# auditctl -l
LIST_RULES: task,never
# sed -i.bak -e '/^-a never,task$/ s/^/#/' /etc/audit/audit.rules
# service auditd restart
# auditctl -l
No rules

2015.09 AMI より前のバージョンで起動したインスタンスで、同じパフォーマンスの向上を得たい場合、/etc/audit/audit.rules へ (-a never,task) の同じラインを追加し、デーモンを再起動します。アップグレードし、監査ルールファイルをまだ何も変更していない場合、/etc/audit/audit.rules へ移動するか、新しいデフォルトルールファイルをコピーします。

例(ルートとして)

# auditctl -l
No rules
# cp -p /etc/audit/rules.d/audit.rules.default /etc/audit/audit.rules
cp: overwrite ‘/etc/audit/audit.rules’? y
# service auditd restart
# auditctl -l
LIST_RULES: task,never

Q: MIME マルチパートユーザーデータを cloud-init で使用している例がありますか?

cloud-init のための MIME マルチパートのドキュメントはこちらです。

MIME マルチパートは難解なフォーマットであることが多く、マルチパートファイルを生成する write-mime-multipart ツールを使うのが最善です。このツールは cloud-utils パッケージ内にあり、sudo yum install /usr/bin/write-mime-multipart を使用してインストールできます。このツールはファイルの最初の行を使用して Content-Type を判断し、cloud-init は Content-Type を使用して、ファイルをどのように解釈できるかを決定します。いくつかのサンプルファイル

#cloud-config
repo_releasever: 2015.09

および

#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt

出力を含む write-mime-multipart の例を次に示します。

[ec2-user@ip-172-31-4-37 ~]$ write-mime-multipart repo_releasever-2015.09.cfg ci-was-here.sh
Content-Type: multipart/mixed; boundary="===============6347220379374809187=="
MIME-Version: 1.0

--===============6347220379374809187==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="repo_releasever-2015.09.cfg"

#cloud-config
repo_releasever: 2015.09

--===============6347220379374809187==
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ci-was-here.sh"

#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt

--===============6347220379374809187==--

ツールの使い方など詳細については、man write-mime-multipart を使用してご確認ください。

Q: VPC エンドポイントを設定して Amazon Linux AMI リポジトリへの接続を許可するにはどうすればよいですか?

インターネットにアクセスしなくても、VPC 内の yum リポジトリにアクセスすることが可能です。お客様の VPC エンドポイントポリシーで、VPC から Amazon Linux AMI リポジトリをホストする S3 バケットへのトラフィックを許可する必要があります。

以下はこれを実現する VPC エンドポイントポリシーの例です。

{
  "Statement": [
    {
      "Sid": "Amazon Linux AMI Repository Access",
      "Principal": "*",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::packages.*.amazonaws.com/*",
        "arn:aws:s3:::repo.*.amazonaws.com/*"
      ]
    }
  ]
}

詳細は、VPC エンドポイントのドキュメントをご覧ください。