Geral

P: O que é o Amazon Linux AMI?

O Amazon Linux AMI é uma imagem compatível e mantida do Linux fornecida pela Amazon Web Services para uso no Amazon Elastic Compute Cloud (Amazon EC2). Ele foi criado para fornecer um ambiente de execução estável, seguro e de alta performance para aplicativos executados no Amazon EC2. Ele também inclui vários pacotes que permitem a fácil integração com a AWS, incluindo ferramentas de configuração de execução e muitas bibliotecas e ferramentas populares da AWS. A Amazon Web Services fornece atualizações contínuas de segurança e manutenção para todas as instâncias que executam o Amazon Linux AMI. O Amazon Linux AMI é fornecido gratuitamente para usuários do Amazon EC2.

P: A Amazon oferece suporte para o Amazon Linux AMI?

Sim. O suporte ao Amazon Linux AMI é disponibilizado por meio de assinaturas do AWS Support. Mais detalhes podem ser encontrados na página do AWS Support.

P: Por quanto tempo o Amazon Linux AMI terá suporte?

A AWS fornecerá atualizações de segurança e correções de bugs para o Amazon Linux AMI até 31 de dezembro de 2020 como parte do prazo de suporte padrão. Encorajamos enfaticamente os nossos clientes a desenvolver novos aplicativos no Amazon Linux 2.

A AWS continuará fornecendo atualizações de segurança críticas e importantes para uma lista reduzida de pacotes no Amazon Linux AMI em um período de “Suporte à manutenção” para clientes que desejam continuar usando a AMI após o prazo de suporte padrão. O período de suporte à manutenção terminará em 30 de junho de 2023.

Para quaisquer dúvidas ou preocupações, entre em contato com o suporte ou envie uma solicitação para o Fórum de discussão do Amazon EC2.

P: Como o suporte à manutenção é diferente do período de suporte padrão?

O suporte à manutenção se refere ao período após o final do suporte padrão do Amazon Linux AMI. O suporte à manutenção se estende de 31 de dezembro de 2020 até 30 junho de 2023. Durante esse período, a AWS não acrescentará mais suporte para novos tipos de instâncias do EC2, novos serviços e recursos da AWS e novos pacotes. Em vez disso, a AWS fornecerá atualizações somente para correções de segurança críticas e importantes que se aplicam a um conjunto reduzido de pacotes. Além disso, alguns pacotes na AMI e respectivos repositórios se tornarão gradualmente defasados durante todo o período de suporte à manutenção de acordo com as práticas de fim de vida útil em etapas anteriores do processo.

P: Qual é a lista de pacotes que obterá correções de segurança críticas e importantes durante o período de suporte à manutenção?

A AWS providenciará atualizações de segurança críticas e importantes para o kernel do Linux na AMI, bem como todos os pacotes de espaço de usuário, exceto os defasados.

P: Quais pacotes não receberão mais atualizações durante o período de “Suporte à manutenção”?

Durante a janela de manutenção, qualquer pacote fora das bibliotecas de espaço de usuário de baixo nível que tiver alcançado o final da vida útil nas fontes em etapas anteriores do processo não receberá mais atualizações. A lista total está descrita abaixo.

Pacotes que (até o momento) não recebem mais atualizações

BZR - (pacotes bzr-python26 e bzr-python27)
Python 2.6 (python26)
Python 3.4 (python34)
Python 3.5 (python35)
PostgreSQL 9.3 (postgresql93)
PHP 5.3
PHP 5.5
Tomcat 7
Tomcat 8
Ruby 1.8
Ruby 1.9
Ruby 2.1
Ruby 2.2
Ruby 2.3
Puppet 2.7.x (puppet)
Puppet 3.7.x (puppet3)

Pacotes que deixarão de receber atualizações em algum momento durante o período de manutenção

Nome do pacote Data do fim da vida útil
OpenJDK 1.7.0 (java-1.7.0-openjdk) 30/06/2020
OpenJDK 1.8.0 (java-1.8.0-openjdk) 30/06/2023
MySQL 5.6 (mysql56) 05/02/2021
MySQL 5.7 (mysql57) 21/10/2023
PHP 7.2 (php72) 30/11/2020
PHP 7.3 (php73) 06/12/2021
PostgreSQL 9.4 (postgresql94) 13/02/2020
PostgreSQL 9.5 (postgresql95) 11/02/2021
PostgreSQL 9.6 (postgresql96) 11/11/2021
Python 3.6 31/12/2021
Ruby 2.4 (ruby24) 31/03/2020

Todos os outros pacotes continuarão a receber correções de segurança críticas e importantes até o período de suporte à manutenção terminar.

P: Posso executar AMIs do Amazon Linux após o período de suporte à manutenção terminar?

Sim, e se essa política mudar em algum momento, comunicaremos antecipadamente.

P: O Amazon Linux AMI tem suporte fora do EC2?

Não. O Amazon Linux AMI está disponível somente para uso dentro do Amazon EC2.

P: É possível visualizar o código-fonte do Amazon Linux AMI?

Sim. A ferramenta de linha de comando yumdownloader --source fornecida no Amazon Linux AMI permite a visualização de código-fonte dentro do Amazon EC2.

P: Onde posso obter atualizações do Amazon Linux AMI?

As atualizações são fornecidas por meio de um repositório yum pré-configurado e hospedado em cada região do Amazon EC2. As atualizações de segurança são automaticamente aplicadas à primeira inicialização da AMI. Ao efetuar login, a Mensagem do Dia (/etc/motd) indica se há alguma atualização adicional disponível ou não.

P: Como posso reportar problemas ou fazer solicitações de recursos ou pacotes?

Usamos o Fórum de discussão do Amazon EC2 para reportar problemas, solicitar novos recursos e solicitar pacotes. Esses fóruns são monitorados pelo Suporte ao desenvolvedor da AWS, assim como pela equipe de engenharia do Amazon Linux AMI.
 

Técnico

P: Como posso ativar o repositório Extra Packages for Enterprise Linux (EPEL)?

Modifique /etc/yum.repos.d/epel.repo. Na seção marcada como [epel], altere enabled=0 para enabled=1.

Para ativar temporariamente o repositório EPEL 6, utilize a opção de linha de comando yum --enablerepo=epel.

Observe que os repositórios do Amazon Linux AMI são configurados com uma prioridade mais alta que repositórios de terceiros. O motivo para isso é que há diversos pacotes que fazem parte do Amazon Linux AMI que também ficam em repositórios de terceiros, e queremos garantir que a versão do Amazon Linux AMI seja instalada no caso padrão.

P: Como posso fixar minha AMI em uma versão específica?

A estrutura de repositórios do Amazon Linux AMI é configurada para fornecer um fluxo contínuo de atualizações que permitem que você troque de uma versão do Amazon Linux AMI para a outra.

As atualizações de pacotes são sempre enviadas para os repositórios e estão disponíveis para qualquer versão do Amazon Linux AMI onde o yum é configurado para apontar para "mais recente". Você pode ver para quais repositórios sua instância está apontando observando a variável "releasever" no /etc/yum.conf – por padrão, o Amazon Linux AMI tem configurada a variável releasever=latest.

Em outras palavras, as AMIs do Amazon Linux são tratadas como snapshots de um momento, com um repositório e uma estrutura de atualização que fornece os pacotes mais recentes que construímos e inserimos no repositório.

O recurso "bloqueio na execução" existe para oferecer aos usuários uma maneira simples de manter suas AMIs em uma versão principal específica, caso eles não tenham interesse em obter atualizações de pacotes sempre que lançarmos novas versões principais do Amazon Linux AMI.

Para habilitar esse recurso em novas instâncias, execute (por exemplo) o Amazon Linux AMI 2015.09 com os seguintes dados de usuário passados para o cloud-init pelo console do EC2 ou por aws ec2 run-instances com a indicação --user-data (isso também pode ser feito com ec2-run-instances -f).
#cloud-config
repo_releasever: 2015.09

Para bloquear instâncias existentes da versão atual (indicada em /etc/system-release), edite /etc/yum.conf. Comente a linha que diz releasever=latest e execute yum clean all para limpar o cache.

OBSERVAÇÃO: se você bloquear a AMI para uma versão dos repositórios que não seja a "mais recente", você não receberá atualizações futuras. A única maneira de receber um fluxo contínuo de atualizações do Amazon Linux AMI é usar a AMI mais recente ou atualizar constantemente sua AMI antiga com os repositórios direcionados para "mais recente".

P: Como posso desativar a instalação automática de atualizações de segurança essenciais e importantes na inicialização?

Na primeira inicialização, o Amazon Linux AMI instala, dos repositórios de pacotes, todas as atualizações de segurança do espaço do usuário que forem classificadas como críticas ou importantes antes que serviços como o SSH sejam iniciados.

Se a AMI não puder acessar os repositórios do yum, esgotará o tempo limite e a AMI tentará novamente várias vezes antes de concluir o procedimento de inicialização. Isso pode acontecer devido a configurações restritivas do firewall ou da VPC que impedem o acesso aos repositórios do pacote do Amazon Linux AMI.

Se você encontrar esse problema, poderá modificar seu ambiente para que o Amazon Linux AMI possa se conectar a seus repositórios de pacote ou poderá desativar a atualização de segurança na inicialização.

Para desativar a atualização de segurança na inicialização usando o console do AWS EC2:

Na página "Opções de instância avançadas" no Assistente de solicitações de instância, existe um campo de texto para enviar os dados do usuário do Amazon Linux AMI. Esses dados podem ser inseridos como texto ou carregados como um arquivo. Em ambos os casos, os dados devem ser:
#cloud-config
repo_upgrade: none

Para desativar a atualização de segurança na inicialização da linha de comando:

Crie um arquivo de texto com os dados de usuário anteriores e passe-os para aws ec2 run-instances com a sinalização --user-data file://<nomedoarquivo> (isso também pode ser feito com ec2-run-instances -f).

Para desativar a atualização de segurança na inicialização durante o reempacotamento do Amazon Linux AMI:

Modifique /etc/cloud/cloud.cfg e altere repo_upgrade: security para repo_upgrade: none.

P: Por que demora tanto para o SSH iniciar quando é executado em uma Virtual Private Cloud (VPC) sem um gateway de internet ou uma instância NAT?

Veja a resposta da pergunta anterior.

P: Por que minhas matrizes de RAID começam em /dev/md127 em vez de /dev/md0?

As versões mais novas do mdadm criam matrizes de RAID com superblocos de versão 1.2, que não se combinam automaticamente com um dispositivo numerado. Faça referência às partições usando um rótulo para o sistema de arquivos. A maioria das ferramentas de criação de sistema de arquivos usa o sinalizador -L para definir o rótulo. Uma vez definido, o rótulo é referenciado pela montagem ou em /etc/fstab com LABEL=[NAME].

Exemplo: criando uma matriz RAID0 com um rótulo.
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

Exemplo: configurando um rótulo de um sistema de arquivos ext[2-4] existente.
e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

P: Por que o grupo wheel foi desativado de /etc/sudoers e como posso ativá-lo novamente?

Os sistemas operacionais Linux têm padrões diferentes em termos de ativação desativação do wheel para o sudo. Acreditamos que o wheel desativado por padrão é uma postura de segurança mais adequada para o Amazon Linux AMI.

Há duas soluções para esse problema, que diferem de acordo com sua capacidade de fazer SSH em suas instâncias, como ec2-user padrão, e do fato de você já ter alterado ou não a capacidade do usuário de usar o sudo.

Opção 1: para usuários que ainda não alteraram nenhum padrão, você ainda deverá poder fazer ssh em suas instâncias como ec2-user e invocar o sudo para obter a raiz, sendo que nesse ponto você poderá modificar o arquivo sudoers para reativar a wheel.
Opção 2: para usuários que alteraram os padrões e não podem usar o sudo pelo ec2-user para a raiz, recomendamos o seguinte:

  • Pare a instância afetada (mas não a encerre).
  • Desvincule o volume do EBS raiz usando o console do EC2 ou as ferramentas de API do EC2.
  • Vincule o volume à outra instância do EC2 para a qual você tem acesso remoto à raiz.
  • Faça login nessa instância.
  • Monte o volume recém-vinculado.
    sudo mount /dev/xvdf /mnt
  • Modifique o arquivo sudoers no volume vinculado e exclua o grupo wheel.
    sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
  • Desmonte o volume.
    sudo umount -d /dev/xvdf
  • Desvincule o volume.
  • Vincule novamente o volume à instância parada (verifique se o dispositivo está igual a antes da desvinculação, normalmente: /dev/sda1).
  • Inicie a instância afetada.

P: Por que eu vejo caracteres estranhos como � ou â quando interajo com o Amazon Linux AMI através de um terminal?

O Amazon Linux AMI usa a codificação de caracteres UTF-8 por padrão. Os terminais cliente que não usam a codificação UTF-8 nem sempre converterão os caracteres UTF-8 corretamente. Para corrigir isso, configure a codificação do terminal cliente como UTF-8:

  • Terminal do GNOME: no menu Terminal, escolha Definir codificação de caracteres e selecione UTF-8.
  • PuTTY: clique com o botão direito na barra de título para exibir o menu. Em seguida, escolha Alterar configurações. Em Janela → Tradução → Conjunto de Caracteres Remotos, escolha UTF-8.

P: Vejo uma opção report_instanceid em /etc/yum.repos.d/amzn*.repo. O que isso faz?

Os repositórios do Amazon Linux AMI são buckets do S3 em cada região. Quando o yum é executado na sua instância, faz download de pacotes desses buckets. As informações sobre essa conexão do S3 são registradas.
Dentro do contexto do Amazon Linux AMI, a configuração report_instanceid=yes permite que os repositórios do Amazon Linux AMI registrem também o ID (por exemplo, i-xxxxxxxx) e a região (por exemplo, us-west-2) da instância que está fazendo o download de um pacote. Isso permite que a equipe do Amazon Linux AMI ofereça um atendimento ao cliente mais focado e específico para instâncias individuais.
report_instanceid=yes é ativado por padrão apenas para os repositórios do Amazon Linux AMI.

P: Por que os arquivos de configuração do yum /etc/yum.repos.d/amzn*.repo são sobrescritos quando o pacote de versão do sistema é atualizado?

Esses arquivos de configuração do repositório são substituídos quando o pacote de versão do sistema é atualizado, a fim de garantir que as instâncias sempre vejam as alterações na configuração do repositório yum do Amazon Linux AMI.
Para versões do Amazon Linux AMI anteriores a 2014.09:
Esses arquivos são gerados por cloud-init de modelos localizados em /etc/cloud/templates/amzn-*.repo.tmpl. As alterações feitas nesses arquivos de modelo persistirão.

Para o Amazon Linux AMI 2014.09 e versões posteriores:

Os arquivos /etc/yum.repos.d/amzn*.repo agora usam variáveis yum para ajudar as instâncias a alcançar os repositórios geograficamente mais próximos, dispensando o uso de modelos cloud-init. Todas as edições feitas nesses arquivos serão preservadas como /etc/yum.repos.d/amzn*.repo.rpmsave quando a versão do sistema for atualizada.

Os usuários que estiverem atualizando para a versão 2014.09 verão as edições feitas nos arquivos /etc/yum.repos.d/amzn*.repo salvas como /etc/yum.repos.d/amzn*.repo.rpmsave.

P: Como posso alterar ou desativar as cores das páginas do man?

As cores de página do man são configuradas no /etc/profile.d/less.sh (bash e zsh) e no /etc/profile.d/less.csh (csh). Para desativá-las, remova todas as linhas com export LESS_ (bash e zsh) e/ou setenv LESS_ (csh).

P: Como faço para desativar a auditoria de chamadas do sistema em instâncias anteriores a 09/2015?

A auditoria de chamadas do sistema foi desativada por padrão em novos lançamentos do Amazon Linux AMI 2015.09. A auditoria de chamadas do sistema adiciona sobrecarga a todas as chamadas do sistema e pode resultar em degradação perceptível do desempenho, especialmente em aplicativos com uso intenso de disco ou rede.

Se você precisar fazer uma auditoria de chamada do sistema, localize a seguinte linha em /etc/audit/audit.rules e remova-a ou faça um comentário nela e reinicie o daemon de auditoria.
-a never,task
Exemplo (como raiz):
# auditctl -l
LIST_RULES: task,never
# sed -i.bak -e '/^-a never,task$/ s/^/#/' /etc/audit/audit.rules
# service auditd restart
# auditctl -l
Sem regras
Se você deseja obter a mesma melhoria de desempenho em instâncias iniciadas a partir de AMIs anteriores a 2015.09, adicione a mesma linha ( -a never,task ) a /etc/audit/audit.rules e reinicie o daemon. Se você estiver fazendo um upgrade e não tiver feito nenhuma alteração nos arquivos de regra de auditoria, poderá simplesmente mover ou copiar o novo arquivo de regras padrão para /etc/audit/audit.rules
Exemplo (como raiz)
# auditctl -l
Sem regras
# 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

P: Há algum exemplo de uso de dados do usuário mimem-multipart com cloud-init?

Você pode encontrar a documentação do mime-multipart para cloud-init aqui.
O formato MIME multipart pode ser complicado, por isso é melhor usar a ferramenta write-mime-multipart para gerar o arquivo multipart. Esta ferramenta está no pacote cloud-utils e pode ser instalada com o comando sudo yum install /usr/bin/write-mime-multipart. A ferramenta usa a primeira linha do arquivo para determinar o tipo de conteúdo, e o cloud-init usa o tipo de conteúdo para determinar como ele deve interpretar o arquivo. Alguns arquivos de exemplo:
#cloud-config
repo_releasever: 2015.09
e
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
Veja a seguir um exemplo de write-mime-multipart, incluindo saída:
[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==--
Mais informações sobre como usar a ferramenta podem ser encontradas em man write-mime-multipart.

P: Como configurar um VPC endpoint para permitir conexões com os repositórios do Amazon Linux AMI?

É possível acessar os repositórios yum em uma VPC sem que seja necessário acessar a Internet. Sua política de VPC endpoints deve permitir tráfego da sua VPC para os buckets do S3 que hospedam os repositórios do Amazon Linux AMI.
Veja abaixo um exemplo de VPC endpoint que executa o seguinte:
{
"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/*"
]
}
]
}

Para obter mais informações, consulte a documentação sobre VPC endpoints.

Conteúdo da página
Geral Técnico