一般問題
問:什麼是 Amazon Linux AMI?
Amazon Linux AMI 是由 Amazon Web Services 所提供,可在 Amazon Elastic Compute Cloud (Amazon EC2) 上使用,且受 Linux 支援和維護的映像。它旨在為 Amazon EC2 上執行的應用程式提供穩定、安全和高效能的執行環境。其中也包含一些可輕鬆與 AWS 整合的套件,包括啟動組態工具和許多常見的 AWS 程式庫和工具。Amazon Web Services 為執行 Amazon Linux AMI 的所有執行個體提供持續的安全性和維護更新。Amazon EC2 使用者無須支付其他費用即可使用 Amazon Linux AMI。
問:Amazon 是否提供 Amazon Linux AMI 的支援?
是。Amazon Linux AMI 是透過訂閱 AWS Support 來提供支援。您可以在 AWS Support 頁面找到更多詳細資訊。
問:Amazon Linux AMI 支援期間多長?
Amazon Linux AMI (也稱為 Amazon Linux 1) 於 2023 年 12 月 31 日生命週期結束。自 2024 年 1 月 1 日起,Amazon Linux AMI 不會收到任何安全更新或錯誤修正。
問:維護支援期間與標準支援期間有何不同?
維護支援是指對 Amazon Linux AMI 的標準支援終止之後的期間。維護支援從 2020 年 12 月 31 日至 2023 年 12 月 31 日。在此期間,AWS 將不再新增對新 EC2 執行個體類型、新 AWS 服務和功能以及新套件的支援。取而代之的是,AWS 將僅針對適用於減少套件集的關鍵和重要的安全修復提供更新。此外,在 AMI 及其儲存庫中的某些套件將根據其上游生命週期結束實務,在整個維護支援期間內逐步取代。
問:在維護支援期間獲得關鍵和重要安全修補程式的套件清單有哪些?
AWS 將為 AMI 中的 Linux 核心,以及除已取代的使用者空間套件之外的所有套件提供關鍵和重要的安全更新。
問:在「維護支援」期間哪些套件將不再接收更新?
在維護時段期間,低級別使用者空間庫之外的任何套件在其上游來源已達到生命週期結束的套件將不再接收更新。
以下套件於 2018 年 3 月發佈的原始版已被取代,並在維護支援期間不會收到進一步更新:
MySQL 5.1
PHP 5.3
PHP 5.4
PHP 5.5
PHP 7.0
PostgreSQL 8
Python 2.6
Ruby 1.8
Ruby 1.9
Ruby 2.1
Ruby 2.2
此外,以下套件將不再作為維護支援的一部分作任何進一步更新,且生命週期結束:
所有相容套件
BZR - (bzr-python26 和 bzr-python27 套件)
Ganglia
Mercurial
MySQL 5.5
Python 3.4 (python34)
Python 3.5 (python35)
PostgreSQL 9.3 (postgresql93)
PHP 7.1
PHP 7.2
Tomcat 7
Tomcat 8
Ruby 2.3
Ruby 2.4
PostgreSQL 9.4
Puppet 2.7.x (puppet)
Puppet 3.7.x (puppet3)
Subversion 1.9
Transmission
OpenJDK 1.7.0 (java-1.7.0-openjdk)
此外,某些其他套件在維護期間某個時候將停止接收更新
套件名稱 |
生命週期結束日期 |
---|---|
MySQL 5.6 (mysql56) |
2021 年 2 月 5 日 |
PostgreSQL 9.5 (postgresql95) |
2021 年 2 月 11 日 |
PostgreSQL 9.6 (postgresql96) |
2021 年 11 月 11 日 |
PHP 7.3 (php73) |
2021 年 12 月 6 日 |
Python 3.6 |
2021 年 12 月 31 日 |
MySQL 5.7 (mysql57) |
2023 年 10 月 21 日 |
OpenJDK 1.8.0 (java-1.8.0-openjdk) |
2023 年 6 月 30 日 |
由於 RPM 相依項的性質以及這些頂級套件中其中一個可包含多個 RPM 的方式,可在此處查看 Amazon Linux 1 中所有 RPM 套件及其生命週期結束日期的完整清單。
問:維護支援期間結束後,我是否可以啟動 Amazon Linux AMI?
是,若該政策發生變化,我們會提前通報。
問:在 EC2 以外是否支援 Amazon Linux AMI?
否。Amazon Linux AMI 只能在 Amazon EC2 內部使用。
問:是否可檢視 Amazon Linux AMI 的原始程式碼?
是。Amazon Linux AMI 中提供的 yumdownloader --source 命令列工具能夠檢視 Amazon EC2 內部的原始程式碼。
問:可以從哪裡取得 Amazon Linux AMI 的更新?
系統透過每個 Amazon EC2 區域中託管之預先設定的 yum 儲存庫來提供更新。AMI 初始啟動時,便會自動套用安全性更新。登入時,當日訊息 (/etc/motd) 會指出是否有任何可用的其他更新。
問:如何回報錯誤,或是請求功能和套件?
我們使用 Amazon EC2 開發論壇進行錯誤回報、功能請求和套件請求。AWS 開發人員支援和 Amazon Linux AMI 工程團隊會監控這些論壇。
技術
問:如何啟用 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 的版本。
問:如何將 AMI 鎖定為特定版本?
Amazon Linux AMI 儲存庫結構設定為交付持續的更新流程,讓您從一個 Amazon Linux AMI 版本累積更新到下一個版本。
套件更新一律推送至儲存庫,並供 yum 設為指向 "latest" 之任何版本的 Amazon Linux AMI 使用。您可以檢查 /etc/yum.conf 中的 "releasever" 變數,查看您的執行個體指向哪個儲存庫 – Amazon Linux AMI 預設會設為 releasever=latest。
換言之,您可以將 Amazon Linux AMI 視為某個時間的快照,具有的儲存庫和更新結構可提供已建置並推送至儲存庫的最新套件。
"lock on launch" 功能是為了提供一種簡單的方式將 AMI 保持在特定的主要版本,若您不想在我們發行新的 Amazon Linux AMI 主要版本時就取得套件更新,則可採用此方式。
若要在新的執行個體啟用此功能,請啟動 2015.09 Amazon Linux AMI (舉例來說),然後透過 EC2 主控台,或透過 aws ec2 run-instances 並搭配 --user-data 旗標 (也可以使用 ec2-run-instances -f),將下列使用者資料傳送至 cloud-init。
#cloud-config
repo_releasever: 2015.09
若要將現有的執行個體鎖定在目前的版本 (/etc/system-release 中所指示的版本),請編輯 /etc/yum.conf。將 releasever=latest 這行設為註解,並執行 yum clean all 以清除快取。
注意︰若您把 AMI 鎖定為並非 "latest" 的儲存庫版本,將不會收到任何進一步的更新。接收 Amazon Linux AMI 持續更新流程的唯一方式,就是使用最新的 AMI,或是將儲存庫指向 "latest" 以不斷更新您的舊 AMI。
問:如何停用初始啟動時的關鍵和重要安全性更新自動安裝?
第一次啟動時,Amazon Linux AMI 會從套件儲存庫安裝關鍵或重要等級的任何使用者空間安全性更新,且會在啟動服務 (例如 SSH) 之前進行。
如果 AMI 無法存取 yum 儲存庫,它將會逾時並在啟動程序完成之前多次重新嘗試。發生這個情形的原因可能是防火牆設定或 VPC 設定的限制,使其無法存取 Amazon Linux AMI 套件儲存庫。
如果發生此問題,您可以修改環境以讓 Amazon Linux AMI 能夠連接至套件儲存庫,或者停用啟動時的安全性更新。
要停用啟動時的安全性更新,請從 AWS EC2 主控台:
在 Request Instances Wizard 的 "Advanced Instance Options" 頁面上,有一個用來傳送 Amazon Linux AMI 使用者資料的文字欄位。此資料可透過輸入文字或上傳文字檔案來提供。無論哪種方式,資料都應該如下:
#cloud-config
repo_upgrade: none
要從命令列停用啟動時的安全性更新:
建立一個文字檔案,內容為前述使用者資料,然後將這個檔案傳送至 aws ec2 run-instances 並搭配 --user-data file://<filename> 旗標 (也可以使用 ec2-run-instances -f)。
要在重新綁定 Amazon Linux AMI 時停用啟動時的安全性更新:
修改 /etc/cloud/cloud.cfg,並將 repo_upgrade: security 變更為 repo_upgrade: none。
問:為什麼在沒有網際網路閘道或 NAT 執行個體的情況下,在 Virtual Private Cloud (VPC) 中執行 SSH 時需要很長的時間來啟動?
請參閱上一個問題的解答。
問:為什麼我的 RAID 陣列是在 /dev/md127 啟動而不是 /dev/md0?
較新版本的 mdadm 會使用 1.2 版的 superblock 來建立 RAID 陣列,不會自動結合裝置編號,而是設定檔案系統的標籤來參考分割區。大多數檔案系統建立工具使用 -L 旗標來設定標籤。設定之後,就會在掛載時參考標籤,或在 /etc/fstab 中以 LABEL=[NAME] 來參考標籤。
範例:建立帶有標籤的 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
問:為什麼 wheel 群組在 /etc/sudoers 中停用了,要如何重新啟用?
各種 Linux 作業系統對於是否為 sudo 啟用 wheel,各有不同的預設值。我們認為預設從 sudo 停用 wheel,就 Amazon Linux AMI 的安全性而言較為合理。
此問題的解決方法有兩種,使用的方法取決於您是否能夠以預設的 ec2-user 使用 SSH 連接到執行個體,以及是否更改過此使用者使用 sudo 的能力。
選項 #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)。
- 啟動受影響的執行個體。
問:為什麼透過終端機與 Amazon Linux AMI 交談時會看到 � 或 â 之類的奇怪字元?
Amazon Linux AMI 預設使用 UTF-8 字元編碼。未使用 UTF-8 編碼的用戶端終端機不一定能正確轉譯 UTF-8 字元。要修正此問題,請將您的用戶端終端機編碼設為 UTF-8:
- GNOME 終端機:從 Terminal 功能表選擇 Set Character Encoding,然後選取 UTF-8。
- PuTTY:在標題列按一下滑鼠右鍵,以開啟功能表。然後選擇 Change Settings。在 Window → Translation → Remote Character Set 底下選擇 UTF-8。
問:我在 /etc/yum.repos.d/amzn*.repo 中看到 report_instanceid 選項。這有何功能?
Amazon Linux AMI 儲存庫是每個區域中的 S3 儲存貯體。當執行個體上的 yum 程序從這些儲存貯體下載套件時,便會記錄該 S3 連線的相關資訊。
在 Amazon Linux AMI 環境中,report_instanceid=yes 設定允許 Amazon Linux AMI 儲存庫同時記錄下載套件之執行個體的執行個體 ID (i-xxxxxxxx) 和區域 (例如 us-west-2)。這可讓 Amazon Linux AMI 團隊針對個別執行個體提供更集中且具體的客戶支援。
只有 Amazon Linux AMI 儲存庫預設啟用 report_instanceid=yes。
問:為什麼系統版本套件升級時會覆寫 /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。
問:如何變更或關閉 man 頁面的顏色?
man 頁面的顏色可以在 /etc/profile.d/less.sh (bash 和 zsh) 和 /etc/profile.d/less.csh (csh) 進行設定。若要關閉顏色,請將以 export LESS_ 開頭 (bash、zsh) 和/或以 setenv LESS_ 開頭 (csh) 的所有行移除。
問:如何停用 2015.09 版之前執行個體的系統呼叫稽核?
新推出的 2015.09 Amazon Linux AMI 預設已經停用系統呼叫稽核。系統呼叫稽核會在每次系統呼叫時增加負載,可能導致明顯的效能降級,特別是對磁碟或網路需求較大的應用程式。
如果您需要系統呼叫稽核,請在 /etc/audit/audit.rules 中找到下面這行,並將這行移除或設為註解,然後重新啟動稽核協助程式。
-a never,task
範例 (以 root 身分):
# 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 啟動的執行個體上得到相同的效能改進,請將同一行 (-a never,task) 新增至 /etc/audit/audit.rules,然後重新啟動協助程式。如果正在升級,且尚未對稽核規則檔進行任何變更,只要將新的預設規則檔移動或複製到 /etc/audit/audit.rules 即可
範例 (以 root 身分)
# 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
問:是否可以提供在 cloud-init 使用 mime-multipart userdata 的範例?
適用於 cloud-init 的 mime-multipart 文件位於這裡。
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,找到有關如何使用此工具的詳細資訊。
問:如何設定 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 端點文件。