Hola, en este nuevo post vamos a realizar la limpieza de los logs de vCS 6x/7x para arreglar los reportes:
vSphere UI Health Alarm", "Log disk exhaustion on vcenter name
Database Health Alarm", "Core and Inventory Disk Exhaustion on vcenter name
Dentro de la administración del appliance (VAMI/5480) se muestra que la partición /storage/log está X% lleno.
Si está en 75% lleno, se despliega una alerta Warning de color amarillo
Si está en 85% lleno, se despliega una alerta Crítica de color rojo
Si está en 95% el servicio vpxd se apagará para prevenir que exista corrupción en el archivo y la BDD.
Por lo general cuando se presenta estas alertas, las causas pueden ser por:
Paquetes de Logs que se generaron y no fueron eliminados luego de extraerlos.
Alta frecuencia de eventos que llenan los logs.
Servicios como Apache Tomcat Java Servlet que fallan en la limpieza de sus archivos.
O muy poco espacio en la partición /storage/log.
En este caso, se observan que los logs guardados son de dos años atrás y además existen paquetes de logs que no fueron eliminados.
Pero existen otros problemas que pueden hacer crecer el espacio en disco y estos son:
Si los problemas de crecimiento en espacio son definidos por Apache Tomcat Java Servlet seguir el KB2151394,
Si en vCS6.0 no existe rotación de log por falta de una configuración seguir el KB2147261,
Si en vCS6.0 no existe zipeado de los archivos de log de SSO seguir el KB2143565,
Si en vCS7.0 el servicio de vmware-pod no puede iniciar e intenta por repetidas veces, llena el log, seguir el KB80803,
Si en vCS6.7 la memoria disponible para el servicio de Analytics es insuficiente, se llenará el log con errores de Out Of Memory, seguir el KB82483,
Si en vCS7.0 si se configura un Proxy para comunicación online con los depots de VMware, se llenará el log de error, seguir el KB85468.
Solución:
Para nuestro caso, seguimos los KB2151389 y KB83070 el cual detallamos a continuación, luego de la validación se muestran los pasos para la eliminación de los archivos LOG que están provocando que se llene la partición /storage/log.
Los paquetes de LOGs, que por lo general se crean para enviar a un caso de soporte técnico de VMware, son almacenados en la partición log.
Como se puede ver, existen dos paquetes de Logs generados del 14 de diciembre 2022 y 27 de junio 2023 que pesan entre los dos aprox. 7 GB los mismos que procedemos a eliminar usando el comando rm.
Además, debemos revisar los logs dentro de las siguientes ubicaciones:
/storage/log/vmware/sso/tomcat/
/storage/log/vmware/eam/web/
/storage/log/vmware/lookupsvc/tomcat/ --> solo para vCS7.0
/var/log/vmware/vmware-sps/
Se deben validar y eliminar los LOGs usando los comandos:
ls -lha catalina*log
rm catalina*log
ls -lha localhost_access*
rm localhost_access*
ls -lha sps-access*log
rm sps-access*log
Y por último, podemos validar si existen archivos grandes que no hayamos tomado en cuenta y pueden estar ocupando mucho espacio, usamos los comandos:
cd /storage/log
du -a |sort -n -r |head -n 20
Y observamos que aún existen archivos que deben ser eliminados, una vez realizado el proceso de eliminación descrito arriba, se valida el espacio de la partición haya bajado y con eso liberamos espacio para seguir trabajando con nuestro vCS.
Finalmente, si existen otras particiones que se quedan sin espacio, recomiendo el KB76563 donde se indican los procesos para realizar el aumento de espacio o la solución de cualquier partición.
Hola, en este nuevo post nos recuperaremos de un evento común que sucede en vCenter Server, el vencimiento de los certificados digitales que tiene y que los servicios cuentan para funcionar.
El error que nos indica este evento es Based on the current configuration, the SSL certificate of the authentication server was not trusted o también 503 service not available...endpoint que se presentan al tratar de ingresar a los servicios web de vCS.
Consideraciones:
Si hay certificados caducados, como STS, Machine SSL o cualquier usuario de la solución, vCenter no podrá iniciar los servicios debido a las dependencias de los servicios.
Si hay Certificados vencidos en BACKUP_STORES, eso activará una alarma de estado de Certificado.
Si hay certificados caducados en trusted root que no están en uso, se activará una alarma de estado del certificado.
Verificación
Debemos verificar la fecha de caducidad de los certificados digitales para lo cual VMware nos brinda los pasos a seguir definidos en el KB82332
Como primer paso, se debe validar el certificado de Single Sign-on Token Signing del servicio STS (VMware Security Token Service) usando un script que VMware crea y pone a disposición dentro del KB79248 y que debe ser ejecutado dentro de vCS mediante una conexión SSH, para este punto, el script fue descargado y fue subido a vCS usando WinSCP. Aceedemos a la consola Shell de vCS con Putty.
Se observa que el certificado del servicio STS va a caducar en dos días.
Como segundo paso, se debe ejecutar el siguiente comando en Shell de vCS:
for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do echo "[*] Store :" $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $store --text | grep -ie "Alias" -ie "Not After";done;
Observamos que los certificados Machine SSL y Solutions User están caducados, por lo tanto, debemos actualizar los mismos.
Solución
Para la renovación de certificados caducados debemos seguir los siguientes pasos:
Primero debemos renovar los certificados caducados de Solutions User: Para lo cual podemos seguir el KB2112277. Se recomienda realizar esta renovación como primer paso para evitar problemas con los servicios de vCS.
Corremos el script dentro del Shell de vCS: /usr/lib/vmware-vmca/bin/certificate-manager
Escogemos de la lista el número 8 para resetear todos los certificados.
Colocamos las credenciales del usuario administrador de vCS y colocamos los datos por defecto que nos indica el script.
Todos los certificados de los servicios se actualizan. Para luego reiniciarse todos los servicios de vCS.
Por último, se debe revisar nuevamente; corriendo el comando previo, que los ceritificados de Solutions User se hayan renovado.
Renovación de certificados STS: debemos correr el script que VMware expone en el KB76719, el mismo que renueva los certifcados STS. El script fue subido usando WinScp a la carpeta tmp.
Se da permisos al script y corremos el script.
El script nos indica la información de los FQDNs y nombres que usa el servicio STS y la fecha de expiración del certificado.
Colomos las credenciales del usuario administrador de SSO.
Finalizado el script nos indica que se detecta un certificado próximo a caducar y el reemplazo del mismo.
Por último, deben ser reiniciados los servicios usando los comandos:
Una vez reiniciados los servicios, validamos nuevamente con el script checksts
Finalmente, debemos tener en cuenta que los certificados de Machine SSL, Solutions User caducan cada dos años luego de la instalación de vCS, se recomienda activar alertas para evitar que los certificados caduquen y dejen de funcionar los servicios.
Hola, en este nuevo post vamos a realizar la actualización de vCenter Server 7.0 Update 3c. Esta nueva versión liberada contine la solución a la vulnerabilidad Apache Log4j Remote Code Execution (RCE) identificada como crítica según el equipo de seguridades de VMware bajo el VMSA (VMware Security Advisory) VMSA-2021-0028.2. Así como la solución a otras brechas de seguridad encontradas y problemas resueltos KB86281.
En esta ocasión vamos a realizar la actualización de nuestro vCSA versión 7, para la versión 6.7 podemos seguir los pasos de mi post aquí.
IMPORTANTE: VMware eliminó las versiones de ESXi 7.0 Update 3, 7.0 Update 3a y 7.0 Update 3b de todos los sitios el 19 de noviembre de 2021 debido a un problema que afecta la actualización. El build 19193900 de ESXi 7.0 Update 3c reemplaza al build 18644231 de ESXi 7.0 Update 3, 18825058 de 7.0 Update 3a y 18905247 de 7.0 Update 3b. Los KBs relacionados a estos problemas están en KB87327.
Como lo mencione, VMware liberó las versiones vCenter Server 6.5 Update 3r, vCenter Server 6.7 Update 3p y vCenter Server 7.0 Update 3c para solventar las siguientes vulnerabilidades reportadas (CVEs) en los paquetes de software open source OSS. Para mayor información aquí:
Script Python pre-check
VMware crea un script basado en python para identificar los hosts ESXi 7.0 (U2c/U2d/U3/U3a) con drivers Intel dobles; para más detalles del problema consulta dual driver conflict. Este problema debe ser remediado antes de realizar la actualización, caso contrario se producirán problemas en el upgrade.
El script llamado vSphere_upgrade_assessment.py se encuentra en el KB87258 el mismo que debe ser descargado y subido al vCenter Server, puede ser en la ubicación /tmp y luego correr con python, así:
python /tmp/vSphere_upgrade_assessment.py
El script crea 4 archivos, uno de ellos es el .log que muestra si se encontraron hosts con problemas a remediar:
En el ejemplo se detalla en el cuadrado de color verde los hosts escaneados que tengan problemas, si el mensaje es "Completed scan of 0 out of 0 hosts" quiere decir que el script no encontró servidores con driver doble y por ende, no se continuará con el chequeo.
El mensaje importante es en "Number of hosts with dual drivers:" si está en 0 el ambiente está listo para realizar el upgrade sin inconvenientes, pero si el mensaje no es igual a 0, se requiere realizar remediación de los hosts. Siguiendo el KB86447.
Los archivos creados son los que están dentro del cuadrado de color rojo y estos son:
vSphere_upgrade_assessment_faulty_hosts_<timestamp>.txt --> contiene los hosts que fueron encontrados con el conflicto del driver Intel i40en
vSphere_upgrade_assessment_skipped_hosts_<timestamp>.txt --> contiene todos los hosts que no fueron tomados en cuenta porque no estaban conectados o no respondieron.
vSphere_upgrade_assessment_errored_hosts_<timestamp>.txt --> contiene cualquier host que no se haya podido comprobar con el scritp, si existen hosts dentro de este archivo, se debe investigar en el dual_driver_check_<timestamp>.log porque no fue posible el escaneo.
Y por último, la configuración avanzada"config.SDDC.VCUpgradeVLCMPrecheck.Skip" en el cuadro azul, se cambia al valor de TRUE. Una vez que la actualización haya sido satisfactoria se recomienda revisar que este parámetro haya vuelto a establecerse en FALSE. Dirigiéndonos a la opción de "Configure" en nuestro vCSA, luego en "Advanced Settings" y en la tabla "Advanced vCenter Server Settings" buscamos la configuración avanzada.
Actualización usando CLI
Primero, no olvidarse siempre tener un respaldo o un snapshot de nuestro vCSA ya que vamos a trabajar con cambios que pueden afectar a la base de datos vpostgres. Dicho esto, procedemos a realizar la descarga del paquete de vCSA desde la página de VMware (VMware-vCenter-Server-Appliance-7.0.3.00300-19234570-patch-FP.iso) o la descarga del paquete directamente desde la consola VAMI del vCSA si este tiene salida al internet.
En nuestro ejemplo, lo descargamos usando la consola VAMI:
Y preparando el paquete para la instalación, procedemos a realizar la validación y posterior instalación del mismo.
Luego de la correcta instalación procedemos a realizar la revisión del paquete instalado.
Finalmente, la nueva versión liberada por VMware solventa varios problemas y vulnerabilidades que deben ser cubiertas para evitar potenciales riesgos de seguridad y/o administración. Recordemos que unas de las mejores prácticas de seguridad es evitar que los servidores tengan salida al internet; por lo tanto, se recomienda restringir el acceso y únicamente mantener las conexiones abiertas para los repositorios de parches de VMware.
Hola, este nuevo post mostraré como realizar la remediación de la vulnerabilidad de Apache Log4j Remote Code Execution (RCE) identificada como crítica según el equipo de seguridades de VMware bajo el VMSA (VMware Security Advisory) VMSA-2021-0028.2. Hablemos un poco de esta vulnerabilidad.
Apache Log4j Remote Code Execution (RCE)
La vulnerabilidad se encuentra indexada en el CVE (Common Vulnerabilities and Exposures) CVE-2021-44228 publicada el 10 de diciembre de 2021 y tiene como puntuación de 10/10 en la escala de severidad.
El fallo consiste en una vulnerabilidad de ejecución remota de código que permite que un atacante ejecute cualquier código en un servidor afectado, valiéndose de una de las librerías de registro más usadas basada en java (Log4j). VMware no queda por fuera de esta vulnerabilidad ya que varios productos trabajan con la librería, los productos afectados se los encuentra en la VMSA-2021-0028.2.
Remediación de vulnerabilidad en vCenter Server 7.x y 6.x
El equipo de VMware tiene una solución alterna o workaround que mitigarán momentáneamente este problema, sin embargo se debe seguir la recomendación del VMSA y actualizar con un nuevo parche cuando esté disponible.
Los pasos para seguir se encuentran documentados en los KBs: 87081 y 87088, en este segmento, vamos a realizar el workaround usando un script automatizado.
Primero debemos descargarnos el script vmsa-2021-0028-kb87081 que está disponible en la página del KB-87088 y luego subimos al vCenter Server a la ubicacion /tmp, podemos usar WinSCP, por si da problemas la conexión el comando a usar para habilitar el Bash Shell:
chsh -s /bin/bash root
Para desactivar se corre el comando:
chsh -s /bin/appliancesh root
Una vez que tenemos el script, y luego de haber realizado un snapshot de preferencia con la VM apagada. Debemos correrlo usando las sentencias:
python /tmp/vmsa-2021-0028-kb87081.py
Esperamos que el script haya finalizado
Segundo debemos descargarnos el script remove_log4j_class que está disponible en la página del KB-87081 y luego subimos al vCenter Server a la misma ubicacion /tmp, para ejecutarlo, con la siguiente sentencia eliminamos las vulnerabilidades:
python /tmp/remove_log4j_class.py
Validamos usando la opción "dry-run" del script en el cual no debe salir información de archivos vulnerables.
python /tmp/remove_log4j_class.py -r
Además, se debe verificar si los cambios afectaron al servicio vMon que inicie con el nuevo parámetro -Dlog4j2.formatMsgNoLookups=true, ejecutando el comando:
ps auxww | grep formatMsgNoLookups
Y por último, analizar el cambio en los servicios Analytics y CM los cuales deben devolver el valor de 0 lineas, usando los comandos respectivamente:
La respuesta debe ser log4j2.formatMsgNoLookups = true bajo la opción System Properties
Finalmente, debemos estar pendientes de las actualizaciones del VMSA para actualizar nuestros vCS, el workaround es una solución temporal, la remediación definitiva vendrá como PARCHE de las versiones de vCS.
Hola, en este nuevo post vamos a realizar la recuperación de nuestra contraseña de root del appliance de vCenter Server, con este método compatible con las versiones 6.5, 6.7 y 7.x. De acuerdo al KB: 2147144
El proceso corresponde a la recuperación de las credenciales de la cuenta ROOT la cual pudo haber fallado, bloqueado por la caducidad del tiempo o porque nos olvidamos que contraseña se colocó.
Primero siempre debemos realizar un snapshot para poder recuperarse en caso que exista un inconveniente con nuestro vCS, el snapshot debe ser creado de preferencia con la VM apagada.
Conectándonos al ESXi donde se encuentra la VM de vCS, procedemos a reiniciar el sistema operativo y al momento antes de iniciar el sistema operativo PhotonOS presionamos la tecla e para ingresar al menú GNU GRUB y procedemos a colocar la siguiente sentencia luego de la línea que comienza con Linux.
rw init=/bin/bash
Para luego presionar F10 o Ctrl+x
Esperamos que se reinicie el vCSA para luego montar nuevamente la raíz en modo lectura y escritura, con el siguiente comando:
mount -o remount,rw /
Una vez realizado este proceso, colocamos la nueva contraseña usando el comando passwd y finalizamos desmontando la partición raíz con el siguiente comando:
umount /
Reiniciamos el vCSA corriendo un reboot -f.
Y validamos que la contraseña haya sido cambiada.
Nota: debemos colocar una contraseña que cumpla con los requerimientos del vCSA de acuerdo a las configuraciones en el VAMI del vCSA (IP:5480).
Ahora, si la contraseña caducó, podemos correr los comandos siguientes para validarlo o para verificar si esta próxima a caducar. Ingresando a SSH:
chage -l root
Si requerimos realizar el cambio de expiración de la contraseña podemos hacerlo usando el siguiente comando:
chage -I -1 -m 0 -M 99999 -E -1 root
Donde:
-I, --inactive INACTIVE
set password inactive after expiration to INACTIVE
-m, --mindays MIN_DAYS
set minimum number of days before password change to MIN_DAYS
-M, --maxdays MAX_DAYS
set maximum number of days before password change to MAX_DAYS
-E, --expiredate EXPIRE_DATE
set account expiration date to EXPIRE_DATE
Y validamos nuevamente para conocer si la contraseña no expirará:
Finalmente, este proceso puede ser evitado si configuramos las alertas y/o notificaciones de caducidad de contraseña y proceder cambiarla cada cierto tiempo como recomendación y de acuerdo a las políticas de seguridad de la empresa.
Hola, en este post vamos a realizar los pasos para actualizar los últimos parches de un vCenter Server Appliance 6.7 usando la consola VAMI (vCenter Server Appliance Management Interface), como ya nos tiene acostumbrados VMware esta mejorando considerablemente las consolas VAMI y la versión 6.7 no es una excepción.
Actualizando vCSA usando la consola VAMI por el puerto 5480
Ingresamos a nuestra consola VAMI usando: https://[IP_VCSA]:5480 colocamos nuestras credenciales de root o del usuario administrador de SSO que se haya definido para acceso a la consola VAMI.
Una vez dentro de la consola, nos dirigimos a la opción de actualizar. Y escogemos Comprobar actualizaciones.
Para que vCenter pueda validar los parches disponibles, debe tener acceso al internet o podemos descargarnos manualmente desde el sitio myvmware el ultimo parche, cargarlo como un ISO en el CDROM del vCSA y en la opción de Comprobar actualizaciones escoger comprobar CD ROOM.
Con estos pasos, verificamos los parches, que son acumulativos y se puede realizar una revisión previa usando la opción Solo realizar copias intermedias o simplemente dar clic en Realizar copias intermedias e instalar.
Una vez realizada ya copia intermedia se procede a instalar la actualización, dando clic en Instalar. Aceptamos el contrato de licenciamiento de usuario final, luego si quieres unirte al CEIP (customer experience improvement program) damos clic en siguiente.
Y en la ventana final damos clic en Finalizar, sin antes marcar en la opción Realicé copias de seguridad de vCenter Server y sus bases de datos asociadas.
Luego de esto, no debes hacer nada más. La instalación finalizará y reiniciará automáticamente vCSA y los servicios.
Actualizando vCSA usando la consola de línea de comandos
Si tienes problemas con la instalación usando la consola VAMI, podemos usar la consola de comandos de vCSA. Lo primero es ingresar con tu cliente favorito de SSH, por ejemplo PuTTY y habilitar SSH.
Importante, sin ingresar al Shell corremos el siguiente comando (para instalación desde la URL de VMware)
software-packages install -–url
Aceptamos la licencia de usuario final escribiendo “yes” y esperamos que se realice la copia intermedia y la instalación, al finalizar nos pedirá que reiniciemos, colocamos un “reboot” esperamos que inicie y listo la instalación del parche se completa.
Para la instalación del parche usando el ISO se coloca el siguiente comando:
software-packages stage -–iso
Segundo, usamos el siguiente comando para realizar la copia intermedia del parche.
software-packages list -–staged
Y para la instalación del parche ejecutamos.
software-packages install -–staged
Finalmente, recomiendo realizar la instalación a nivel de consola VAMI. La interfaz HTML5 es muy amigable y fácil de usar.
Tip, para validar los eventos de error del parchado se puede ver en el log:
/var/log/vmware/applmgmt/software-packages.log
Para la instalación del parche en un ambiente de vCS en alta disponibilidad les dejo los pasos acá.
Este Blog usa cookies propias y de terceros para optimizar la navegación y que puedas ver correctamente su contenido. Si permaneces en el sitio asumiremos que estas de acuerdo .
