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 proporcionar un entorno de ejecución estable, seguro y de alto desempeño 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 ofrece actualizaciones continuas de seguridad y mantenimiento para todas las instancias que ejecuten la AMI de Amazon Linux. La AMI de Amazon Linux se proporciona sin cargo adicional a los usuarios 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 el AMI de Amazon Linux permite ver el código fuente de Amazon EC2.

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

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

P: ¿Con qué frecuencia habrá disponibles actualizaciones para la AMI de Amazon Linux?

La AMI de Amazon Linux se ha creado y se mantiene como publicación continua. Instamos a los usuarios a que la consideren como una sola fuente de paquetes, de los que las propias imágenes de la AMI no son más que snapshots de un momento determinado.

 

Al proporcionar una publicación continua se garantiza que las AMI de Amazon Linux y nuestras instancias de clientes basadas en ellas sean compatibles con las características más recientes de EC2 y AWS en el momento de su lanzamiento. De este modo, la AMI de Amazon Linux también sirve como punto de referencia para otros productores de AMI de Linux (tanto terceros como empresas transformadoras una vez creada la AMI de Amazon Linux), a fin de que también puedan admitir dichas características.

 

Con este modelo, es más probable que los clientes ejecuten las mejoras de seguridad, desempeño y características más recientes, lo que mitiga una amplia variedad de problemas con los que podrían encontrarse.

P: ¿Ofrece Amazon 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: ¿Será compatible la AMI de Amazon Linux fuera de EC2?

No. La AMI de Amazon Linux solo está disponible para su uso dentro de Amazon EC2.

P: ¿Cómo puedo comunicar los 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 [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 para 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 snapshots 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 "lock on launch" 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 de la consola de AWS EC2, realice lo siguiente:

En la página “Advanced Instance Options” del asistente Request Instances Wizard, 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 de 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:// (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é tarda tanto tiempo SSH en iniciarse cuando se ejecuta en una Virtual Private Cloud (VPC) sin un puerto de enlace a Internet o una instancia NAT?

Consulte la respuesta a la pregunta anterior.

P: ¿Por qué las matrices RAID se inician 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 la misma mediante mount o en /etc/fstab con LABEL=[NOMBRE].

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 opción 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 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. En Window → Translation → Remote Character Set, elija UTF-8.

P: Aparece una 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 del AMI de Amazon Linux, la configuración report_instanceid=yes permite a los repositorios del 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 /etc/yum.repos.d/amzn*.repo al actualizar el paquete system-release?

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.

La actualización de los usuarios a 2014.09 reflejará 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 de los manuales?

Los colores de las páginas de los manuales 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 suponen costos con cada llamada al sistema y pueden perjudicar el desempeño 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 bórrela como comentario. 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 desempeño 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 de varias partes. 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 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, incluida la salida:

[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 conexión 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 un VPC sin acceso a Internet. Su política de punto de conexión de la VPC debe permitir el tráfico de su VPC a los buckets S3 que hospedan los repositorios de la AMI de Amazon Linux.

A continuación tiene un ejemplo de política de punto de conexión 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 conexión de la VPC.