Preguntas frecuentes sobre la AMI de Amazon Linux

P: ¿Qué es la AMI de Amazon Linux?

La AMI de Amazon Linux es una imagen de Linux mantenida y compatible que ofrece Amazon Web Services para su uso en Amazon Elastic Compute Cloud (Amazon EC2). Está diseñada para ofrecer un entorno de ejecución estable, seguro y de alto rendimiento para aplicaciones que se ejecuten en Amazon EC2. También incluye paquetes que permiten una fácil integración con AWS, incluidas herramientas de configuración de lanzamiento y muchas bibliotecas y herramientas populares de AWS. Amazon Web Services proporciona actualizaciones continuas de seguridad y mantenimiento para todas las instancias que ejecutan la AMI de Amazon Linux. La AMI de Amazon Linux se proporciona sin cargo adicional a los usuarios de Amazon EC2.

P: ¿Amazon ofrece soporte para la AMI de Amazon Linux?

Sí. Amazon ofrece soporte para la AMI de Amazon Linux mediante suscripciones a AWS Support. Puede encontrar más detalles en la página de AWS Support.

P: ¿Hasta cuándo se ofrecerá soporte para la AMI de Amazon Linux?

La AMI de Amazon Linux (también denominada Amazon Linux 1) finalizó su ciclo de vida el 31 de diciembre de 2023. La AMI de Amazon Linux no recibirá actualizaciones de seguridad ni correcciones de errores a partir del 1 de enero de 2024.

P: ¿Cómo difiere el soporte de mantenimiento del período de soporte estándar?

El soporte de mantenimiento se refiere al periodo una vez finalizado el soporte estándar para la AMI de Amazon Linux. El soporte de mantenimiento se extiende desde el 31 de diciembre de 2020 hasta el 31 de diciembre de 2023. Durante este periodo, AWS ya no agregará soporte para nuevos tipos de instancias de EC2, nuevas características y servicios de AWS y nuevos paquetes. En su lugar, AWS ofrecerá actualizaciones solo para correcciones de seguridad importantes y críticas que aplican a un conjunto reducido de paquetes. Además, algunos paquetes en la AMI y sus repositorios lentamente quedarán obsoletos durante todo el periodo de soporte de mantenimiento según sus prácticas de fin de vida útil subidas.

P: ¿Qué es la lista de paquetes que obtendrán parches de seguridad importantes y críticos durante el periodo de soporte de mantenimiento?

AWS ofrecerá actualizaciones de seguridad importantes y críticas al núcleo de Linux en la AMI, así también como todos los paquetes de espacio de usuario obsoletos.

P:¿Qué paquetes ya no recibirán actualizaciones durante el periodo de “soporte de mantenimiento”?

Durante el periodo de mantenimiento, todos los paquetes, fuera de las bibliotecas de espacio de usuario de bajo nivel, que llegaron al final de la vida en su fuente original, ya no recibirán actualizaciones.

Los siguientes paquetes quedaron obsoletos con el lanzamiento de la versión 2018.03, y no recibirán más actualizaciones como parte del periodo de soporte de mantenimiento:

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

Además, los siguientes paquetes no recibirán más actualizaciones como parte del soporte de mantenimiento y su vida útil ha finalizado:

Todos los paquetes compat
BZR - (paquetes bzr-python26 and 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)

Además, a continuación se enumeran otros paquetes que dejarán de recibir actualizaciones en algún momento durante el periodo de mantenimiento:

Debido a la naturaleza de las dependencias de RPM y cómo uno de esos paquetes de nivel superior puede estar compuesto de muchos RPM, aquí puede consultar una lista de todos los paquetes de RPM en Amazon Linux 1 y sus fechas de fin de vida útil.

P:¿Puedo lanzar las AMI de Amazon Linux después de que el periodo de soporte de mantenimiento finalice?

Sí, si la política cambia se lo comunicaremos con antelación.

P: ¿Es posible usar la AMI de Amazon Linux fuera de EC2?

No. La AMI de Amazon Linux solo se puede usar dentro de Amazon EC2.

P: ¿Puedo ver el código fuente de la AMI de Amazon Linux?

Sí. La herramienta de línea de comandos yumdownloader --source suministrada en la AMI de Amazon Linux permite ver el código fuente dentro de Amazon EC2.

P: ¿Dónde puedo conseguir actualizaciones de la AMI de Amazon Linux?

Se ofrecen actualizaciones a través de un repositorio yum alojado preconfigurado en cada región de Amazon EC2. Las actualizaciones de seguridad se aplican automáticamente durante el arranque inicial de la AMI. Cuando inicie sesión, el mensaje del día (/etc/motd) indicará si hay o no actualizaciones adicionales disponibles.

P: ¿Cómo puedo informar errores o solicitar características y paquetes?

Utilizamos el foro de debate sobre Amazon EC2 para administrar las notificaciones de errores y las solicitudes de características y paquetes. Estos foros están supervisados por el equipo de soporte al desarrollador de AWS y el equipo de ingeniería de la AMI de Amazon Linux.
 

P: ¿Cómo puedo habilitar el repositorio Extra Packages for Enterprise Linux (EPEL)?

Modifique /etc/yum.repos.d/epel.repo. En la sección marcada con [epel], cambie enabled=0 a enabled=1.

Para habilitar temporalmente el repositorio EPEL 6, utilice la opción de línea de comandos yum --enablerepo=epel.

Tenga en cuenta que los repositorios de la AMI de Amazon Linux se configuran con más prioridad que cualquier otro repositorio de terceros. Esto se debe a que la AMI de Amazon Linux contiene varios paquetes que también se encuentran en repositorios de terceros y queremos asegurarnos de que la versión de la AMI de Amazon Linux esté instalada en el caso predeterminado.

P: ¿Cómo puedo bloquear la AMI en una versión concreta?

La estructura de repositorios de la AMI de Amazon Linux está configurada para ofrecer un flujo continuo de actualizaciones que permiten actualizar de una versión de la AMI de Amazon Linux a la siguiente.

Las actualizaciones de los paquetes se envían siempre a los repositorios y están disponibles para cualquier versión de la AMI de Amazon Linux en que yum se haya configurado para apuntar a “latest”. Para ver a qué repositorios apunta su instancia, consulte la variable “releasever” en /etc/yum.conf. De forma predeterminada, la AMI de Amazon Linux tiene configurado releasever=latest.

En otras palabras, las AMI de Amazon Linux se tratan como instantáneas de un momento dado, con una estructura de repositorios y actualizaciones que proporciona los últimos paquetes que hemos creado e integrado en el repositorio.

La característica “bloquear en el lanzamiento” existe para proporcionar una manera sencilla de mantener las AMI en una versión principal determinada, en caso de que un usuario no quiera recibir actualizaciones del paquete cuando se publiquen nuevas versiones principales de la AMI de Amazon Linux.

Para activar esta característica en instancias nuevas, lance (por ejemplo) una AMI de Amazon Linux 2015.09 con los siguientes datos de usuario pasados a cloud-init, ya sea mediante la consola de EC2 o mediante aws ec2 run-instances con la marca --user-data (también se puede realizar con ec2-run-instances -f).
#cloud-config
repo_releasever: 2015.09

Para bloquear las instancias existentes en su versión actual (indicada en /etc/system-release), edite /etc/yum.conf. Comente la línea en la que se lee releasever=latest y ejecute yum clean all para borrar la caché.

NOTA: Si bloquea su AMI en una versión de los repositorios distinta de “latest”, no recibirá más actualizaciones. El único modo de recibir un flujo continuo de actualizaciones para la AMI de Amazon Linux es utilizar la AMI más reciente, o actualizar de forma constante su antigua AMI con los repositorios apuntados a “latest”.

P: ¿Cómo puedo deshabilitar la instalación automática de actualizaciones de seguridad críticas e importantes durante el lanzamiento inicial?

Durante el primer arranque, la AMI de Amazon Linux instala desde los repositorios de paquetes todas las actualizaciones de seguridad del espacio de usuario que se consideran críticas o importantes y lo hace antes de que se inicien servicios como SSH.

Si la AMI no puede obtener acceso a los repositorios yum, excederá el tiempo de espera y lo reintentará varias veces antes de completar el procedimiento de arranque. Los posibles motivos de este comportamiento son los valores de VPC o los valores de firewall restrictivos que impiden el acceso a los repositorios de paquetes de la AMI de Amazon Linux.

Si detecta este problema, puede modificar su entorno para que la AMI de Amazon Linux pueda conectarse a sus repositorios de paquetes o deshabilitar la actualización de seguridad durante el arranque.

Para deshabilitar la actualización de seguridad durante el arranque desde la consola de AWS EC2, realice lo siguiente:

En la página "Advanced Instance Options" (Opciones de instancias avanzadas) de Request Instances Wizard (Asistente de solicitud de instancias), existe un campo de texto para enviar datos de usuario de la AMI de Amazon Linux. Estos datos se pueden introducir como texto o cargarse como archivo. En cualquier caso, los datos deberían ser estos:
#cloud-config
repo_upgrade: none

Para deshabilitar la actualización de seguridad durante el arranque desde la línea de comandos, realice lo siguiente:

Cree un archivo de texto con los datos de usuario anteriores y trasládelo a aws ec2 run-instances con la marca --user-data file://<filename> (esto también se puede realizar con ec2-run-instances -f).

Para deshabilitar la actualización de seguridad durante el arranque al volver a empaquetar la AMI de Amazon Linux, realice lo siguiente:

Modifique /etc/cloud/cloud.cfg y cambie repo_upgrade: security por repo_upgrade: none.

P: ¿Por qué SSH tarda tanto tiempo en iniciarse cuando se ejecuta en una Virtual Private Cloud (VPC) sin una gateway de Internet o una instancia NAT?

Consulte la respuesta a la pregunta anterior.

P: ¿Por qué mis matrices RAID comienzan en /dev/md127 en lugar de en /dev/md0?

Las versiones más actualizadas de mdadm crean matrices RAID con superbloques de la versión 1.2, que no se ensamblan automáticamente con un dispositivo numerado. Defina una etiqueta para el sistema de archivos a fin de crear referencias de las particiones. La mayoría de las herramientas de creación de sistemas de archivos utiliza la marca -L para definir la etiqueta. Tras haber definido la etiqueta, se hace referencia a ella mediante mount o en /etc/fstab with LABEL=[NAME].

Ejemplo: creación de una matriz RAID0 con una etiqueta.
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
Ejemplo: definición de la etiqueta de un sistema de archivos ext[2-4] existente.
e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

P: ¿Por qué estaba deshabilitado el grupo wheel de /etc/sudoers y cómo puedo volver a habilitarlo?

Los sistemas operativos Linux tienen diferentes opciones predeterminadas para que el grupo wheel esté o no habilitado para sudo. Consideramos que el hecho de que el grupo wheel esté deshabilitado en sudo de forma predeterminada es una estrategia de seguridad más razonable para la AMI de Amazon Linux.

Hay dos soluciones temporales para este problema que difieren en función de si se tiene o no la posibilidad de integrar SSH en las instancias como ec2-user predeterminado o de si se ha alterado o no la capacidad del usuario para utilizar sudo.

Opción n.º 1: si el usuario no cambia ninguna de las opciones predeterminadas, podrá integrar SSH en las instancias como ec2-user y, a partir de ahí, invocar sudo para obtener acceso a la raíz, donde podrá modificar el archivo sudoers para volver a habilitar el grupo wheel.
Opción n.º 2: si el usuario cambia las opciones predeterminadas o no tiene la posibilidad de que sudo llegue a la raíz desde ec2-user, recomendamos seguir los pasos que se indican a continuación:

• Detenga la instancia afectada (sin terminarla).
• Separe el volumen de EBS raíz mediante la consola de EC2 o las herramientas de API de EC2.
• Adjunte el volumen a otra instancia EC2 a cuya raíz tenga acceso remoto.
• Inicie sesión en la instancia.
• Monte el volumen que acaba de adjuntar.
  sudo mount /dev/xvdf /mnt
• Modifique el archivo sudoers del volumen adjuntado y anule el comentario del grupo wheel.
  sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
• Desmonte el volumen.
  sudo umount -d /dev/xvdf
• Separe el volumen.
• Vuelva a adjuntar el volumen a la instancia parada (asegúrese de que el dispositivo sea el mismo que era antes de desacoplarlo, por lo general: /dev/sda1).
• Lance la instancia afectada.

P: ¿Por qué veo caracteres extraños como � o â cuando me comunico con la AMI de Amazon Linux a través de un terminal?

La AMI de Amazon Linux utiliza la codificación de caracteres UTF-8 de forma predeterminada. Los terminales cliente que no utilicen la codificación UTF-8 no siempre traducirán los caracteres UTF-8 correctamente. Para solucionar este problema, establezca la codificación de su terminal cliente en UTF-8:

• Terminal Gnome: en el menú del terminal, elija Set Character Encoding (Definir codificación de caracteres) y seleccione UTF-8.
• PuTTY: haga clic con el botón derecho en la barra del título para que aparezca el menú. A continuación, elija Change Settings (Modificar valores). En Window (Ventana) → Translation (Traducción ) → Remote Character Set (Conjunto de caracteres remotos) elija UTF-8.

P: Aparece la opción report_instanceid en /etc/yum.repos.d/amzn*.repo. ¿Cuál es su función?

Los repositorios de la AMI de Amazon Linux son buckets de S3 de cada región. Cuando el proceso yum de la instancia descarga paquetes de dichos buckets, se registra información sobre esa conexión con S3.
Dentro del contexto de la AMI de Amazon Linux, la configuración report_instanceid=yes permite a los repositorios de la AMI de Amazon Linux registrar también el identificador de instancia (i-xxxxxxxx) y la región (p. ej., us-west-2) de una instancia que descarga un paquete. Esto permite al equipo de la AMI de Amazon Linux ofrecer un servicio de soporte al cliente más específico para instancias concretas.
report_instanceid=yes está habilitado de forma predeterminada solo para los repositorios de la AMI de Amazon Linux.

P: ¿Por qué se sobrescriben los archivos de configuración del repositorio yum /etc/yum.repos.d/amzn*.repo cuando se actualiza el paquete de lanzamiento del sistema?

Estos archivos de configuración del repositorio se sobrescriben cuando el paquete de lanzamiento del sistema se actualiza para asegurar que las instancias siempre contengan los cambios de la configuración del repositorio yum de la AMI de Amazon Linux.
Para las versiones de la AMI de Amazon Linux anteriores a 09.2014:
Estos archivos se generan mediante cloud-init a partir de plantillas ubicadas en /etc/cloud/templates/amzn-*.repo.tmpl. Los cambios realizados en estos archivos de plantilla se conservarán.

Para las versiones de la AMI de Amazon Linux 09.2014 y posteriores:

Los archivos /etc/yum.repos.d/amzn*.repo utilizan actualmente variables yum para ayudar a que las instancias alcancen los repositorios más cercanos geográficamente, por lo que ya no se usan las plantillas cloud-init. Las modificaciones de estos archivos se guardarán como /etc/yum.repos.d/amzn*.repo.rpmsave cuando se actualice la versión del sistema.

Los usuarios que realicen la actualización a 2014.09 verán todas las modificaciones realizadas en los archivos /etc/yum.repos.d/amzn*.repo guardados como /etc/yum.repos.d/amzn*.repo.rpmsave.

P: ¿Cómo se pueden cambiar o desactivar los colores de las páginas man?

Los colores de las páginas man se configuran en /etc/profile.d/less.sh (bash y zsh) y en /etc/profile.d/less.csh (csh). Para desactivarlos, elimine todas las líneas que empiecen por export LESS_ (bash, zsh) o setenv LESS_ (csh).

P: ¿Cómo se pueden desactivar las auditorías de las llamadas del sistema en las instancias anteriores a 2015.09?

Las auditorías de las llamadas del sistema se han desactivado por defecto en los nuevos lanzamientos de la AMI de Amazon Linux 2015.09. Las auditorías de las llamadas del sistema incrementan la sobrecarga con cada llamada al sistema y pueden perjudicar el rendimiento considerablemente, sobre todo en aplicaciones de uso intensivo de la red o de un disco.

Si necesita activar las auditorías de las llamadas del sistema, encuentre la línea siguiente en /etc/audit/audit.rules y elimínela o coméntela. A continuación, reinicie el daemon de las auditorías.
-a never,task
Ejemplo (como raíz):
# 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
Si quiere obtener las mismas mejoras de rendimiento en instancias iniciadas antes de las AMI 2015.09, agregue la misma línea ( -a never,task) a /etc/audit/audit.rules y reinicie el daemon. Si está realizando una actualización y no ha efectuado ningún cambio en los archivos de las reglas de las auditorías, puede simplemente trasladar o copiar el nuevo archivo de reglas predeterminado a /etc/audit/audit.rules
Ejemplo (como raíz)
# 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

P: ¿Pueden proporcionar un ejemplo del uso de los datos de usuario mime-multipart con cloud-init?

La documentación de mime-multipart para cloud-init se encuentra aquí.
El formato MIME multipart puede ser complicado, así que es mejor utilizar la herramienta write-mime-multipart para generar el archivo multipart. Esta herramienta se encuentra en el paquete cloud-utils y se puede instalar con sudo yum install /usr/bin/write-mime-multipart. Esta herramienta utiliza la primera línea del archivo para determinar el encabezado Content-Type, y cloud-init usa el Content-Type para determinar cómo interpretar el archivo. Algunos archivos de ejemplo:
#cloud-config
repo_releasever: 2015.09
y
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
Aquí tiene un ejemplo de write-mime-multipart, incluido el resultado:
[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==--
Encontrará más información sobre cómo utilizar la herramienta con man write-mime-multipart.

P: ¿Cómo configuro un punto de enlace de la VPC para permitir conexiones a los repositorios de la AMI de Amazon Linux?

Es posible obtener acceso a los repositorios yum dentro de una VPC sin acceso a Internet. Su política de punto de enlace de la VPC debe permitir el tráfico de su VPC a los buckets de S3 que alojan los repositorios de la AMI de Amazon Linux.
A continuación tiene un ejemplo de política de punto de enlace de la VPC que se comporta de este modo:
{
"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 obtener más información, consulte la documentación del punto de enlace de la VPC.