Problemas al instarl mysql-devel en una Linux Amazon 1? Yo también los he tenido. Mi EC2 es una Linux Amazon 1 con estas características.
uname -ar
Linux ip-10-0-101-105 4.14.193-113.317.amzn1.x86_64 #1 SMP Thu Sep 3 19:08:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
cat /etc/system-release
Amazon Linux AMI release 2018.03
La distribución Linux Amazon 1 está ya en EOL, no debería estar usándola pero como por otro lado en AWS Beanstalk aún no hay una versión 8.1 de PHP pues así estamos.
The Amazon Linux AMI ended its standard support on December 31, 2020 and has entered a maintenance support phase. A list of supported and unsupported packages along with additional information is now available here.
https://aws.amazon.com/es/blogs/aws/update-on-amazon-linux-ami-end-of-life/
Sea como fuere, el problema es que cambié de AMI a una AMI Amazon Linux 1 pública, que escogí desde el lanzador de instancias de EC2. Al cambiar a la nueva AMI y sustituir la que ElasticBeanstalk usa, tuve el problema de dependencias.
ElasticBeanstalk hace una instalación de paquetería via unos hooks que no podemos modificar y al cambiar a la nueva AMI, el entonrnó pasó a DEGRADED (y yo también)
El problema era el openssl-devel, que era usado por diversos paquetes: mysql-devel, etc
--> Resolución de dependencias finalizada
Error: Paquete: 1:openssl-devel-1.0.2k-16.153.amzn1.x86_64 (amzn-updates)
Necesita: openssl(x86-64) = 1:1.0.2k-16.153.amzn1
Instalado: 1:openssl-1.0.2k-16.155.amzn1.x86_64 (@amzn-updates/latest)
openssl(x86-64) = 1:1.0.2k-16.155.amzn1
Disponible: 1:openssl-1.0.2k-8.106.amzn1.x86_64 (amzn-main)
openssl(x86-64) = 1:1.0.2k-8.106.amzn1
Disponible: 1:openssl-1.0.2k-8.107.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-8.107.amzn1
Disponible: 1:openssl-1.0.2k-12.109.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-12.109.amzn1
Disponible: 1:openssl-1.0.2k-12.110.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-12.110.amzn1
Disponible: 1:openssl-1.0.2k-13.111.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-13.111.amzn1
Disponible: 1:openssl-1.0.2k-16.146.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-16.146.amzn1
Disponible: 1:openssl-1.0.2k-16.148.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-16.148.amzn1
Disponible: 1:openssl-1.0.2k-16.150.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-16.150.amzn1
Disponible: 1:openssl-1.0.2k-16.151.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-16.151.amzn1
Disponible: 1:openssl-1.0.2k-16.152.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-16.152.amzn1
Disponible: 1:openssl-1.0.2k-16.153.amzn1.x86_64 (amzn-updates)
openssl(x86-64) = 1:1.0.2k-16.153.amzn1
Podría intentar utilizar el comando --skip-broken para sortear el problema
Podría intentar ejecutar: rpm- Va --nofiles --nodigest
Lo que tuve que hacer, aunque no es del todo correcto, fue hacer un downgrade del paquete entero y instalar la versión que necesitaba. Con el comando “yum –showduplicates” listamos los paquetes instalados y los que podríamos usar.
Entonces eligimos el que nos conviene y hacemos el downgrade.
# yum --showduplicates list openssl | expand
# yum downgrade openssl-1.0.2k-16.153.amzn1
Lo mismo pasó con mod24_ssl y http24. Exactamente lo mismo.
# yum install mod24_ssl
Complementos cargados:priorities, update-motd, upgrade-helper
Resolviendo dependencias
--> Ejecutando prueba de transacción
---> Paquete mod24_ssl.x86_64 1:2.4.48-1.92.amzn1 debe ser instalado
--> Procesando dependencias: httpd24 = 2.4.48-1.92.amzn1 para el paquete: 1:mod24_ssl-2.4.48-1.92.amzn1.x86_64
--> Resolución de dependencias finalizada
Error: Paquete: 1:mod24_ssl-2.4.48-1.92.amzn1.x86_64 (amzn-updates)
Necesita: httpd24 = 2.4.48-1.92.amzn1
Instalado: httpd24-2.4.51-1.94.amzn1.x86_64 (@amzn-updates/latest)
httpd24 = 2.4.51-1.94.amzn1
Aquí repito los pasos para poder dejar el httpd en la versión que no me da conflictos de paquetería.
# yum --showduplicates list httpd24 | expand
# yum downgrade httpd24-2.4.48-1.92.amzn1 httpd24-tools-2.4.48-1.92.amzn1
Una vez solventado estos dos conflictos, pude desplegar la nueva AMI en el entorno de BETA. Me alegro bastante de haber montado en su día una pipeline básica con entorno BETA que me permita poder probar esto sin romper el blog de producción.
Ahora, probaré si por fin puedo levantar WordPress con PHP 8.0, que es el único disponible por ahora en Beanstalk.
Pero al menos, el objetivo se ha cumplido, que era poder cambiar de AMI, desplegar la nueva EC2, aplicar las .ebextensions y aplicar las actualizaciones de ElasticBeanstalk.