Cambiando tiempo de expiración de contraseñas para VMware Identity Manager (vIDM) o Workspace One Access (WSA)

Como bien sabemos cuando desplegamos VMware Identity Manager ahora llamado Workspace One Access, desde vRealize Suite Lifecycle Manager, los password son administrados desde el servicio de Locker de este componentes y su periodo de expiración por defecto es de 60 días, el cual si bien es una muy buena practica, puede ser un periodo de rotación de password muy corto para la mayoría de los usuarios y muchos suelen olvidar cambiar los password hasta que tienen una actividad de mantenimiento, troubleshooting o una actualización.

Y es en ese momento es cuando solemos entrar a verificar la plataforma y nos encontramos con una molesta X roja en los dashboards del Identity Manager, indicándonos que nuestros password de root y sshuser han expirado.

En esta ocasión revisaremos un sencillo TIP para cambiar el tiempo de expiración de los password asociados a los usuarios root y ssh de estos appliances.

PROCEDIMIENTO

Iniciar sesión ssh en cada uno de los appliances de la solución VMware Identity Manager (vIDM) o Workspace One Access (WS1 Access).

Ejecutar el comando en cada una de las sesión ssh para verificar el tiempo de expiración actual.

cat /etc/shadow

Nota 1: En la imagen anterior podemos ver que dentro del recuadro azul se ha resaltado el numero de días de expiración para los usuarios root y sshuser.

Cambiar este periodo es muy sencillo y basa con ejecutar los siguientes comandos en cada una de las sesiones ssh asociadas a los appliances de vIDM o WS1 Access presentes en nuestra infraestructura. En este caso al ser un ambiente de laboratorio definiremos el tiempo de expiración a un año (365 días).

passwd -x 365 root
passwd -x 365 sshuser

Una vez ejecutados los comandos anteriores podemos verificar el cambio ejecutando nuevamente el comando cat /etc/shadow, o directamente desde la interfaz gráfica hacer un refresh frente a la politica User Password Expiration y eso es todo. Ya tenemos un nuevo periodo de expiración definido.

Nota 2: Después de unos minutos el dashboard debería volver a un estado óptimo cambiando la molesta X roja de la esquina superior derecha por un check color verde .

Nota 3: Recuerde que es necesario ejecutar el comando tanto para el usuario root como para el usuario sshuser.

Referencias

Todos los créditos para el blogger Rafael Moura quien compartió esta información hace un par de meses atrás.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Anuncio publicitario

Creciendo almacenamiento de vRealize Suite Lifecycle Manager (vRSLCM)

Este post se centrará en un problema común que hemos experimentado con vRSLCM y es que el Request falla al intentar descargar los Binarios desde My VMware o al intentar hacer el Mapping Local de los mismos.

Si analizamos los detalles del request en la sección Home -> Requests del servicio Lifecycle Operations podremos observar que detalle del error básicamente contiene lo siguiente:

com.vmware.vrealize.lcm.common.exception.userinput.myvmware.MyVmwareProductDownloadException: Error occurred while downloading product binaries from MyVMware account : user@lab.local. Please check the logs for more details        at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadRestClient.downloadFile(MyVmwareDownloadRestClient.java:714)        at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadUtil.getDownloadUrlsAndDownloadProductBinaryFiles(MyVmwareDownloadUtil.java:295)        at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadUtil.downloadProductBinaries(MyVmwareDownloadUtil.java:168)        at com.vmware.vrealize.lcm.plugin.core.myvmware.tasks.MyVmwareDownloadTask.execute(MyVmwareDownloadTask.java:203)        at com.vmware.vrealize.lcm.automata.core.TaskThread.run(TaskThread.java:45)        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)        at java.base/java.lang.Thread.run(Unknown Source)Caused by: java.io.IOException: Error occurred when uploading file to a content repo. It could be due to disk space not available.        at com.vmware.vrealize.lcm.drivers.sourcemapping.helper.SourceMappingUtil.mountISOandUpload(SourceMappingUtil.java:1056)        at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadRestClient.downloadFile(MyVmwareDownloadRestClient.java:659)        ... 7 more

Indicándonos una línea muy importante «It could be due to disk space not available» en donde nos esta diciendo que posiblemente no hay espacio disponible para la descarga de los binarios. Para verificar esto haremos lo siguiente:

Iniciamos sesión SSH hacia el Appliance de vLCM con usuario root y la clave configurada durante la instalación.

Ejecutamos el comando df -h

Efectivamente podemos evidenciar que el disco con la ruta /data se encuentra al 72% de utilización y debido a que en este caso de laboratorio el disco es de apenas 20GB, es necesario crecer el disco para poder descargar los BINARIES.

Como lo hacemos entonces para crecer el disco?

No te preocupes… En la interfaz grafica (UI) de vLCM vamos a la sección Home -> Settings -> System Details.

Nota: Desde aquí también obtendremos un resumen del almacenamiento usado.

Para Extender el disco simplemente debemos hacer clic en el botón EXTEND STORAGE y diligenciar los datos solicitados para el vCenter Server que esta administrando el Appliance de vLCM. Para este ejemplo creceremos el disco en apenas 10 GB. (Ver Nota 2 al final sino tienes una credencial configurada para vCenter Server).

Clic en el botón EXTEND para continuar.

Clic en el enlace Click here para verificar los detalles del Request y monitorear su actividad.

Una vez terminado el proceso de expansión podrá ver de nuevo en Home -> Settings -> System Details que ya aparecerá el nuevo espacio. Ahora contamos con un total de 30 GB y un 48% usado.

En este punto podemos intentar de nuevo el proceso para descargar los BINARIOS desde Home -> Settings -> Binary Mapping, y el Request debería funcionar sin problemas.

El request tardará un par de minutos así que se paciente

Una ves completado el Binario estará disponible en Home -> Settings -> Binary Mapping

Nota 1: La configuración de los Binarios lo remataremos en otro blog para no hacerlo tan largo.

Nota 2: En vRSLCM todas la contraseñas son referenciadas desde el Locker. De manera sino cuenta con una credencial creada para vCenter Server, vaya primero al Locker de vLCM y configure una.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Configurar Binarios en vRealize Suite Lifecycle Manager (vRSLCM)

Como ya conocemos vRealize Lifecycle Manager (vRSLCM) es una solución que permite controlar el ciclo de vida de los productos vRealize, haciendo mas fácil las tareas de instalación y actualización. Sin embargo, para que esto sea posible es importante conocer que vRSLCM requiere los conocidos Binarios, que básicamente son los bundles que contienen los archivos de instalación o de actualización de cada solución.

Por suerte, en vRealize Suite Lifecycle Manager existe la posibilidad de agregar los Binarios de cada uno de los productos VMware de diferentes formas:

– Local: Permite asignar los archivos binarios descargados localmente a vRealize Suite Lifecycle Manager.

– NFS: Permite asignar a un producto binario descargado desde un repositorio NFS.

– My VMware Download: Permite asignar un producto binario descargado desde el portal My VMware.

En este post estaremos hablando de los dos métodos mas utilizados, My VMware Download y Local.

Prerrequisitos

Verifique que vLCM tenga suficiente espacio antes de continuar con la descarga de los Binarios. Para esto vaya al servicio de Lifecycle Operations ->Settings -> System Details.

Una vez validado que tenemos suficiente espacio para alojar los Binarios, podemos continuar utilizando alguno de los siguientes métodos. Sino tiene espacio suficiente lo invito a leer el siguiente blog Creciendo almacenamiento de vRealize Lifecycle Manager (vLCM).

OPCIÓN 1. Agregar binarios desde My VMware Download

Para usar un producto binario descargado directamente desde My VMware, verifique que se haya registrado en My VMware, que haya registrado los servicios de My VMware con vRealize Suite Lifecycle Manager y por supuesto, que el Appliance de vLCM tenga salida hacia internet.

Para esto necesitaremos ir al servicio Lifecycle Operations y después a la sección Home -> Settings -> My VMware

Clic en ADD MY VMWARE ACCOUNT  para configurar una cuenta de usuario que cuente con permisos para descargar desde el portal de My VMware.

Nota 1

Para verificar que nuestra cuenta asociada tiene los permisos para realizar la descarga podemos simplemente ir a VMware Downloads, hacer login con el usuario y contraseña e intentar bajar cualquier producto.

Si obtenemos un mensaje como el siguiente y el botón DOWNLOAD NOW no se encuentra disponible, entonces nuestra cuenta NO tiene permisos para descargar y mostrará un error al intentar descargar el Binario.

Por esta razón, recomiendo antes de configurar la cuenta de My VMware en vRSLCM, verificar que podamos descargar medios. Una cuenta con permisos de descarga debe verse de la siguiente forma, con el botón DOWNLOAD NOW habilitado.

Este sencillo procedimiento nos permitirá validar que la cuenta que se va a configurar en vLCM es apta para descargar los BINARIES de vRealize Lifecycle Manager.

Continuando con la configuración de la cuenta My VMware en vLCM debemos hacer clic en VALIDATE.

Y luego clic en ADD.

En este punto podremos iniciar la configuración de los Binarios en Home -> Settings -> Binary Mapping

Clic en ADD BINARIES y seleccionar My VMware

Clic en el botón DISCOVERY. Para listar todo los Binarios de los productos disponibles y compatibles con la versión de vLCM que tenga en el ambiente.

Para este caso seleccionaremos el paquete de Upgrade de vRealize Automation 8.3 y VMware Identity Manager 3.3.4. Y después clic en ADD.

En este punto se lanzará una tarea de Request y comenzará la descarga. Tenga en cuenta que esta tarea puede demorar un par de minutos.

Nota 2

Si la cuenta configurada NO tiene permisos para descargar desde el portal My VMware, en el Request obtendremos el siguiente error.

"Error Code: LCMMYVMWARE60010"
"Failed to get user entitlement accounts from https://my.vmware.com. Please try again after some time"
"Error occurred while downloading product binaries from MyVMware account..."

Generalmente esto ocurre porque la cuenta configurada NO tiene permisos para realizar descargas de medios y por esta razón falla.

OPCIÓN 2. Agregar binarios desde repositorio Local

Para mapear un producto binario utilizando el método Local, deberá descargar el bundle de forma manual desde el portal de My VMware.

Para esto vaya al portal de My VMware Downloads e inicie sesión con una cuenta que tenga permisos para descargar.

Clic en View Download Components frente a VMware vRealize Suite.

Y vaya al enlace GO TO DOWNLOAD de cualquiera de los productos que necesita descargar.

Ejemplos

Para el binarios de VMware Identity Manager 3.3.4 debemos seleccionar el identity-manager-3.3.4.0-17498518-updaterepo-lcm.tar.gz y clic en DOWNLOAD NOW.

Para el binarios de vRealize Automation 8.3 debemos seleccionar el Prelude_VA-8.3.0.15014-17551690-updaterepo.iso y clic en DOWNLOAD NOW.

Para el binarios de vRealize Automation 8.3 debemos seleccionar el Prelude_VA-8.3.0.15014-17551690-updaterepo.iso y clic en DOWNLOAD NOW.

Nota 3

Como puede observar el archivo necesario para actualización contendrá un nombre asociado a Update y contendrá un archivo nombrado como XX-XXXXXXXX-updaterepo.

Una vez descargado los bundle podemos ahora mapearlos a vLCM sin necesidad que vLCM tenga acceso a Internet.

Para este ejemplo estaremos utilizado el Binario asociado a vRealize Log Insight 8.3 debido a que ya descargamos los asociados a vRA y vIDM utilizando el modo My VMware Download descrito arriba.

Ahora utilizando la herramienta WinSCP, debemos subir los Binarios al Appliance de vLCM en la ruta /data.

Después en vLCM debemos ir al servicio Lifecycle Operations y hacer clic en Home -> Settings -> Binary Mapping

Clic en ADD BINARIES y seleccionar la opción Local. Después clic en DISCOVER para visualizar el contenido de la carpeta /data.

Seleccionar el Binario asociado a vRealize Log Insight que subimos por WinSCP anteriormente y clic en ADD.

Clic en el enlace Click here para monitorear el request. Al terminar debería mostrar Completed en la columna Request Status.

Por ultimo, podemos verificar en Home -> Settings -> Binary Mapping que el Binario mapeado aparezca ahora disponible.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Referencias

https://docs.vmware.com/en/VMware-vRealize-Suite-Lifecycle-Manager/8.3/com.vmware.vrsuite.lcm.8.3.doc/GUID-2C93EB0A-055C-4897-A764-77FC73EFE992.html

Actualizar vRealize Suite Lifecycle Manager (vRSLCM) 8.x

La actualización del componente vRealize Suite Lifecycle Manager (vRSLCM) es quizá el paso mas importante durante la actualización de cualquiera de nuestras soluciones de la vRealize Suite, ya que de este dependerán las versiones a las que podremos actualizar de acuerdo con la matriz de interoperatividad dispuesta por VMware.

PRERREQUISITOS

  • Verifique que cumpla con los requisitos del sistema. Consulte Requisitos del sistema.
  • Tome un Snapshot del dispositivo virtual vRealize Suite Lifecycle Manager. Si encuentra algún problema durante la actualización, puede volver a esta instantánea.
  • Verifique que no haya tareas críticas en curso en vRealize Suite Lifecycle Manager. El proceso de actualización detiene e inicia los servicios de vRealize Suite Lifecycle Manager y reinicia el dispositivo virtual vRealize Suite Lifecycle Manager, lo que podría dañar las tareas en curso.
  • Si está actualizando vRealize Suite Lifecycle Manager a través de una URL de repositorio o un CD-ROM, asegúrese de descargar el binario de actualización de vRealize Suite Lifecycle Manager desde el portal My VMware con anticipación. El nombre del archivo debe ser -VMware-vLCM-Appliance-8.XXXX-XXXXXXXX-updaterepo.iso.

PROCEDIMIENTO

Para comprobar las actualización de vLCM tenemos tres opciones de repositorios. En este post estaremos hablando del Check online  y la opción CD-ROM.

ACTUALIZACION ONLINE

En el panel de servicios de vLCM, haga clic en Lifecycle Operations y luego clic en Settings.

Clic en System Upgrade.

Seleccione el tipo de repositorio para las actualizaciones de vRealize Suite Lifecycle Manager (Check Online) y después clic en CHECK FOR UPGRADE. Y si tiene salida a internet, después de unos minutos debería poder visualizar cual es la ultima versión disponible.

Ahora solo debe hacer clic en el botón UPGRADE y hacer click en RUN PRECHECK. Si todo esta bien puede continuar con el proceso.

Este proceso tomará un par de minutos. Si el proceso ve alguna pantallas con el mensajes Waiting for services to start, no se preocupe, es normal.

ACTUALIZACION OFFLINE

En la actualización offline, primero necesitaremos descargar el medio de instalación desde el portal de My VMware.

Nota: Una vez descargado el medio de instalación es importante verificar la integridad del mismo. Para esto lo invito a leer el siguiente post Verificar integridad de medios de instalación VMware (checksum), no tardará mas de 5 minutos.

Lo siguiente que debemos hacer es cargar la ISO a Content Library (si existe) o a un Datastore.

Desde la interface de vCenter Server, debemos mapear la ISO al dispositivo CD/DVD de la maquina virtual de vLCM haciendo Edit Settings a la maquina.

Nota: Si cargó la ISO a un datastore seleccione en CD/DVD drive Datastore ISO file, si la cargó a un Content Library entonces seleccione la opción Content Library ISO File, y seleccione la ISO que contiene la actualización de vLCM.

Volvemos a la interface gráfica de vLCM y en el panel de servicios, haga clic en Lifecycle Operations y luego clic en Settings.

Clic en System Upgrade.

Seleccione el tipo de repositorio para las actualizaciones de vRealize Suite Lifecycle Manager (CD-ROM) y después clic en CHECK FOR UPGRADE. En este caso va a revisar la actualización contra la ISO que hemos mapeado anteriormente y después de unos segundos debería poder visualizar cual es la última versión disponible.

Ahora solo debe hacer clic en el botón UPGRADE.

Este proceso tomara un par de minutos. Si en el proceso ve alguna pantallas con el mensajes Waiting for services to start, no se preocupe, es normal.

Una vez terminada la actualización por cualquiera de los métodos explicado anteriormente, inicie sesión en vRealize Suite Lifecycle Manager UI y compruebe el estado de la actualización haciendo clic en Settings -> System Upgrade.

Cuando se completa la actualización exitosamente, vRealize Suite Lifecycle Manager muestra el mensaje «vRealize Suite Lifecycle Manager successfully Upgrade».

También puede verificar la versión actual haciendo clic sobre el nombre de usuario admin@local -> About, en la esquina superior derecha.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Referencias

https://docs.vmware.com/en/VMware-vRealize-Suite-Lifecycle-Manager/8.3/com.vmware.vrsuite.lcm.8.3.doc/GUID-DD8074D5-E1C9-4900-B324-8D9744C314B4.html

Solucionando error: vRA First boot check on failed on host

En esta oportunidad estaremos revisando la solución al error LCMVRAVACONFIG590060, que podría llegar a ocurrir durante el proceso de actualización de la solución vRealize Automation (vRA) 8.x. Cabe anotar que este error se produjo después de que vRealize Lifecycle Manager (vRSLCM) había marcado el pre check como exitoso. Pero bueno, cosas extrañas pueden ocurrir.

El detalle del error básicamente contienen lo siguiente:

com.vmware.vrealize.lcm.common.exception.EngineException: vRA First boot check on failed on host : vra01.lab.local. Run command 'vracli status first-boot' to find first boot status        at com.vmware.vrealize.lcm.plugin.core.vra80.task.VraVaPreUpgradeTask.execute(VraVaPreUpgradeTask.java:111)        at com.vmware.vrealize.lcm.automata.core.TaskThread.run(TaskThread.java:45)        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)        at java.base/java.lang.Thread.run(Unknown Source)

La solución a este problema es bastante sencilla y únicamente requiere seguir el procedimiento a continuación.

PROCEDIMIENTO

1. Inicie sesión ssh en el nodo que reporta el error en vLCM y ejecute el siguiente comando

vracli status first-boot

Si la salida del comando anterior es Error: Cannot connect to Tiller, continúe con los siguientes pasos.

2. Descargue el archivo 2672731-add-tiller-proxy.tar desde los adjuntos del KB81815.

3. Tome un snapshot al nodo de vRA reportado por vLCM (en este caso el nodo vra01)

4. Inicie sesión en el nodo de vRA que reporta vLCM con la herramienta WINSCP y cargue el archivo descargado "2672731-add-tiller-proxy.tar.gz" en la ruta "/root".

5. Vuelva a la sesión SSH del nodo de vRA (en este caso nodo vra-01) y ejecute el siguiente comando

tar -xvf 2672731-add-tiller-proxy.tar.gz && chmod a+x 2672731-add-tiller-proxy.sh && ./2672731-add-tiller-proxy.sh && rm 2672731-add-tiller-proxy.*

6. Inicie sesión SSH en cada uno de los demás nodos de vRA y ejecute el siguiente comando para verificar que se puede acceder a helm desde todos los nodos de vRA

helm ls

Nodo vRA 01

Nodo vRA 02

Nodo vRA 03

7. Vuelva a la interfaz de vRSLCM, en el request fallido haga clic en RETRY y después en SUBMIT.

8. Al final el proceso de actualización de vRA debería ser exitoso y el resultado del Request debería ser Completed.

Referencia

https://kb.vmware.com/s/article/81815

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Instalar Cloud-Init en Templates usadas por vRealize Automation 8.x

Después de haber leído unos cuantos artículos y haber realizado algunas pruebas de cara a cumplir con los requerimientos del cliente, he decidido crear este post debido a que el tema es un poco confuso. Pero en este blog trataremos de compilar la información de las referencias adjuntas y explicar todo lo que necesita saber acerca de Cloud-Init y su funcionamiento a través de los Cloud Templates (blueprints) de Cloud Assembly.

Como es costumbre comencemos con un poco de teoría…

Cloud-Init es la inicialización automatizada de OpenStack de una nueva instancia, la cual es una tarea que debe dividirse entre la infraestructura de la nube y el sistema operativo invitado. OpenStack ™ proporciona los metadatos necesarios a través de HTTP o ConfigDrive y Cloud-Init se encarga de configurar la instancia en Linux.

Sin embargo, ¿qué pasaría si necesitara hacer lo mismo, pero en un sistema operativo Windows®?

Cloudbase-Init™ es el equivalente de Windows del proyecto Cloud-Init utilizado en la mayoría de las imágenes de OpenStack Linux. Cuando se implementa como un servicio en Windows, Cloudbase-Init se encarga de todas las acciones de inicialización del invitado: expansión del volumen del disco, creación de usuarios, generación de contraseñas, ejecución de scripts personalizados de PowerShell, CMD y Bash, plantillas de Heat, configuración de comunicación remota de PowerShell y mucho más.

Aunque había opciones limitadas para la inicialización de invitados hasta hace poco, ahora puede estar seguro. Cloudbase-Init es el equivalente en Windows de Cloud-Init: un proyecto de código abierto que trae todas las funciones manejadas en Linux, a Windows.

Para hacer uso de Cloud-Init en los Cloud Templates (blueprints) de Cloud Assembly podemos agregar una sección cloudConfig al código del blueprint, en la que podemos agregar comandos de inicialización de máquina que se ejecutan en el momento de la implementación.

cloudConfig: cloudConfig es el código YAML usado en los blueprints de VMware que envía instrucciones a Cloud-Init través de la unidad de CD-ROM en la plantilla de la máquina virtual.

Que pueden hacer los comandos de cloudConfig?

Ejecutar comandos de inicialización para automatizar la aplicación de configuraciones en el momento de la creación de la instancia, por lo que podemos personalizar usuarios, permisos, instalaciones o cualquier otra operación basada en comandos. Ejemplos incluyen:

  • Establecer un nombre de host (hostname).
  • Generación y configuración de claves privadas SSH.
  • Instalar paquetes de software.

Dónde se pueden agregar los comandos de cloudConfig?

Puede agregar una sección cloudConfig al código de Cloud Template (blueprint) como se muestra en el siguiente código. Básicamente como una propiedad del componente máquina virtual.

Pero también puede agregarse en la configuración de Image Mapping. Cuando se configura la infraestructura, específicamente al crear Image Mappings tenemos la opción de agregar comandos cloud-init en el botón EDIT bajo la opción Cloud Configuration.

De esta manera, todos los blueprints que hacen referencia a la imagen de origen (Image Mapping) obtienen la misma inicialización.

Es posible que tenga un Image Mapping y blueprint donde ambos contienen comandos de inicialización. En este caso, en el momento del despliegue, los comandos se fusionan y Cloud Assembly ejecuta los comandos consolidados.

Por otra parte, cuando el mismo comando aparece en ambos lugares (en el blueprint y en el Image Mapping) pero incluye diferentes parámetros, solo se ejecuta el comando definido en el Image Mapping debido a que estos comandos tienen prioridad sobre los comandos del Cloud Template (blueprint).

Haga clic en el enlace para obtener más información sobre Image Mappings en vRealize Automation Cloud.

Ejemplos de comandos de cloudConfig

La siguiente sección de ejemplo cloudConfig se toma del código del blueprint del WordPress casos de uso para el servidor MySQL basado en Linux.

Cómo se forman los comandos de cloudConfig?

Lo primero que debemos tener presentes es que Linux cloud-init y Windows Cloudbase-init no comparten la misma sintaxis. Una sección cloudConfig para un sistema operativo no funcionará en una imagen de máquina de otro sistema operativo.

  • Linux: Los comandos de inicialización siguen el estándar open cloud-init.
  • Windows: Los comandos de inicialización utilizan Cloudbase-init.

Cómo inicializar automáticamente una máquina en un Cloud Template (blueprint) de vRealize Automation Cloud Assembly?

Puede aplicar la inicialización de la máquina en vRealize Automation Cloud Assembly ejecutando comandos directamente o, si se implementa en Cloud Zones basadas en vSphere, puede hacerlo a través de los Customization Specification de vSphere. (Ver mas).

  • Comandos: Una sección cloudConfig en el código de su Cloud Template (blueprint) contiene los comandos que desea ejecutar.
  • Customization Specification (Especificaciones de personalización): Una propiedad en el código del Cloud Template (blueprint) hace referencia a un Customization Specification de vSphere por su nombre (el nombre del custom Spec).

PREPARACION DE TEMPLATES

Ahora que ya conocemos que es Cloud-Init, Cloudbase-Init, cloudConfig y como funcionan; veamos como es el importante proceso de preparación de la plantillas en vSphere tanto para Windows como para Linux. Ver mas (Opcional).

Preparación de Templates Windows

1. Descargue el instalador del agente (version estable) desde el sitio oficial de descarga de Cloudbase.

2. Prepare la maquina con todo lo que necesita a nivel de sistema operativo para tener una plantilla funcional (actualizaciones, configuración de discos, instalación de agente de monitoreo, antivirus, etc).

3. Copie el instalador dentro de la VM que será la plantilla para los despliegues desde vRealize Automation.

4. Ejecute el instalador y haga clic en Next.

5. Acepte los términos de la licencia y luego clic en Next.

6. Tome nota de la ruta de instalación por Default, la va a necesitar mas adelante. Después clic en Next.

7. Cambie el Username default de Admin a Administrator y marque la opción Run Cloudbase-init service as LocalSystem. Luego clic en Next.

Nota 1: Si el usuario de administrador local no es Administrator recomiendo renombrarlo en el sistema operativo. De lo contrario en el campo Username indique el usuario de administrador local que tenga en su ambiente.

8. Clic en Install para inicial la instalación.

9. Cuando termine la instalación NO haga clic en Finish. Por el contrario vaya a la ruta donde instalo el programa dependiendo a su version de sistema operativo. (en este caso C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf). Y verifique que existen los archivos cloudbase-init.conf y cloudbase-init-unattend.conf dentro de la carpeta.

10. Utilice cualquier herramienta para editar como administrador el archivo cloudbase-init-unattend.conf y cambie el valor de metadata_services por el siguiente:

metadata_services=cloudbaseinit.metadata.services.ovfservice.OvfService

11. Guarde los cambios y después cierre el archivo cloudbase-init-unattend.conf.

12. Utilice cualquier herramienta para editar como administrador el archivo cloudbase-init.conf que se encuentra en la misma carpeta. En este caso fijaremos los valores de first_logon_behaviour, metadata_services y plugins. Para esto agregue las siguiente lineas al final del archivo.

first_logon_behaviour=always

metadata_services=cloudbaseinit.metadata.services.ovfservice.OvfService

plugins=cloudbaseinit.plugins.windows.createuser.CreateUserPlugin,cloudbaseinit.plugins.windows.setuserpassword.SetUserPasswordPlugin,cloudbaseinit.plugins.common.sshpublickeys.SetUserSSHPublicKeysPlugin,cloudbaseinit.plugins.common.userdata.UserDataPlugin

Nota 2: Configure el valor first_logo_behavior de acuerdo a sus necesidades. En este caso puntual no requerimos que el password de administrador sea cambiado después del despliegue de las VMs. first_logo_behavior puede tener los valores clear_text_injected_only, no, always. Para mayor información ver aquí o aquí.

13. Guarde los cambios y después cierre el archivo cloudbase-init.conf.

14. Vuelva a la vista del asistente de instalación y haga clic en Finish sin marcar ninguna opción y luego apague la VM.

Nota 3: VMware ha visto casos en los que la ejecución de Sysprep impide que funcionen los despliegues de las imagenes.

Durante el deploy, vRealize Automation Cloud Assembly aplica una especificación de personalización (Customization Specification) generada dinámicamente, que desconecta la interfaz de red. El estado de Sysprep pendiente en la imagen puede hacer que falle el Customization Specification de vSphere y dejar el despliegue desconectado.

Por esta razón, si va a utilizar Customization Specification de vSphere deje las opciones de Sysprep desactivadas al crear la imagen (recomendado). Por el contrario si va realizar el Sysprep desde cloudbase-init entonces marque las dos opciones antes de finalizar la instalación.

15. (Opcional Recomendado) Apague la maquina virtual, haga clic con el botón derecho en editar la configuración, cambie la unidad de CD/DVD 1 a Client Device con el Device Mode en Passthrough CD-ROM. Ver más aquí.

16. Convierta la maquina virtual en Template en el inventario de vCenter Server.

17. En este punto ya podrá configurar el Image Mapping en Cloud Assembly para usar esta plantilla (sino sabe como hacerlo vea How to add image mapping in vRealize Automation to access common operating systems).

Nota 4: La siguiente tabla explica un poco las entradas realizadas durante la instalación

Ejemplo de utilización en Cloud Template (blueprint) con imagen Windows

Para verificar el funcionamiento de los comandos cloudbase-init enviados a través del cloudConfig desde el Cloud Template, recomiendo crear un Cloud Template (bueprint) básico que cree un archivo test.txt en la raíz de disco C:/. Para probar otros comandos puede ver el ejemplo que se encuentra acá o ver muchos mas ejemplos en la pagina oficial de cloud-init aquí.

Realice un despliegue de este blueprint de prueba y debería haberse creado dos archivos test.txt y test1.txt en la raíz del disco C:/. Como puede notar en el blueprint (Cloud Template) el archivo test.txt fue creado desde cloud cloudConfig desde donde se le indicó su contenido, mientras el archivo test1.txt fue creado como producto de la ejecución de comandos "echo" dentro de la maquina virtual.

Nota 5: Si todo va bien hasta aquí, puede comenzar a diseñar sus Cloud Templates (blueprints) mas complejos. Utilice siempre la propiedad customizationSpec: [nombre del Customization Specification file de vSphere] si desea realizar el Sysprep desde vSphere. Por otra parte sino tiene un Custom Spec creado en su ambiente, no se preocupe, cree uno siguiendo las instrucciones de acá.

Actualización 30/11/2021

He detectado que con la instalación recomendada por VMware y la documentación oficial de cloudbase-init, genera comportamientos erráticos cuando utilizamos customization specification file de vSphere para customizar la VM. Por suerte un Blogger nos ha dado la solución (ver mas aquí), que básicamente consiste en cambiar el inicio del servicio cloudbase-init en la VM template, de Automatic a Automatic (Delayed Start) con el fin que el servicio se inicie después que el servicio de VMtools se haya iniciado. De esta manera, garantizamos que la personalización realizada por el Customization Specification file configurado en vSphere ya haya terminado y haya reiniciado la VM. 

Una manera que me gusta usar para detectar si cloudbase-init y cloudConfig están haciendo bien su trabajo, es colocar en la lista de comandos runcmd, algún comando que nos devuelva la hora en un archivo de texto.

Así, cuando se realicen nuestros despliegues desde vRA podremos verificar al interior de la VM la hora exacta en la cual se ejecutaron los comandos. Es importante hacer una revisión aquí, que los comandos se hayan ejecutado a una hora de inicio después del evento Customization of VM XXXX succededed.

En el ejemplo, hemos creado un Cloud Template (Blueprint) que crea un script test.ps1 que genera un archivo de salida output.txt. Estos archivos se crean al mismo tiempo, sin embargo dentro del script existe un sleep de 10 min y después actualiza el contenido del archivo output.txt. Aquí podemos comprobar que los archivos se crearon a la 08:53 PM, aproximadamente 2 min después de que terminó el evento de vSphere que indica que la customization finalizó satisfactoriamente (08:51:43 PM).

Ahora vemos que los archivos output se actualizaron por ultima vez 10 min después (09:04 PM) lo que indica que el script se ejecuto completamente, de acuerdo a lo programado.

Preparación de Template RedHat/Centos/Ubuntu

Al desplegar maquinas basadas en Linux desde vRealize Automation, que incluyen comandos cloud-init, se recomienda personalizar la imagen para evitar conflictos entre cloud-init y custom specification. Esto debido a que pueden existir diseños que no funcionen correctamente y podrían producir algunos de los siguientes resultados no deseados. (tomado de vSphere static IP address assignment in Cloud Assembly cloud templates):

  • El código de cloud-init no contiene comandos de asignación de red y la propiedad customizeGuestOs es false.
    Ni los Comandos de inicialización (cloud-init) ni el Customization Spec están presentes para configurar los ajustes de red.
  • El código de cloud-init no contiene comandos de asignación de red y la propiedad ovfProperties está establecida.
    Los comandos de inicialización (cloud-init) no están presentes, pero ovfProperties bloquea el Customization Spec.
  • El código de cloud-init contiene comandos de asignación de red y la propiedad customizeGuestOs falta o está configurada como true.
    La aplicación de Customization Spec (vSphere) entra en conflicto con los comandos de inicialización (cloud-init).

Por suerte, alguien ya se tomó el trabajo de crear unos scripts para la preparación de maquinas RedHat, CentOs y Ubuntu que nos ayudan a evitar esos comportamientos inesperados cuando combinamos Custom Spec y cloud-init.

De esta manera la preparación de los templates con cloud-init para este tipo de sistemas operativos se resume en la ejecución del script correspondiente.

1. Descargue los scripts de preparación del siguiente repositorio externo.

Nota 6: Hay dos archivos para cada una de las distribuciones de Linux, los que tienen un myblog al final del nombre del archivo usan un enfoque de cron job que se explica en este blog y el que no lo tiene, usa un servicio runonce personalizado que creamos en lugar de usar un cron job. Ambos funcionan, pero al final estos son dos enfoques diferentes, puede usar el que prefiera. Personalmente recomiendo utilizar el que usa el servicio runonce (sin «myblog» al final del nombre del archivo).

2. Cargue el script a la ruta /tmp del servidor Linux que utilizará como Template para vRealize Automation.

Si utiliza una herramienta como WinSCP. Suba el archivo utilizando la opción de texto plano, para evitar que se cambie el formato del mismo.

3. Verifique el formato del archivo desde una ventana de Terminal dentro del OS. Para esto ejecute uno de los siguientes comando según corresponda con el sistema operativo invitado.

vi /tmp/build-centos-rhel-vra8-template.sh

ó

vi /tmp/build-ubuntu-vra8-template.sh

4. Escriba :set ff? y enter para verificar el formato del archivo cargado.

Si la salida del comando anterior es fileformat=dos entonces deberá ejecutar el siguiente comando para convertirlo a formato UNIX, de lo contrario no podrá ejecutar el script.

5. Escriba ahora :set ff=unix y enter para cambiar el formato del archivo.

6. Guarde los cambio ejecutando :wq

7.  Tómese un tiempo para inspeccionar el script y cambiar el usuario cloudadmin por administrator o root (dependiendo de su configuración).

8.  Comente la ultima línea para evitar que la maquina se apague de manera automática y guarde los cambios. Esta línea la ejecutaremos de forma manual cuando termine la ejecución del script.

9. Cambie los permisos del archivo ejecutando uno de los siguiente comandos (dependiendo de su OS).

chmod +x  /tmp/build-centos-rhel-vra8-template.sh 

ó

chmod +x /tmp/build-ubuntu-vra8-template.sh

10. Importante: Verifique que el servidor tenga salida a internet y alcance los repositorio de actualización.

11. Pruebe el comando yum install -y cloud-init, si funciona correctamente entonces podemos ejecutamos el script con el siguiente comando dependiendo de OS.

 ./tmp/build-centos-rhel-vra8-template.sh 

ó

./tmp/build-ubuntu-vra8-template.sh

Nota 7: Antes de apagar la VM verifique el estado de la VM con el comando cloud-init status, si la salida no es done, elimine el archivo /etc/cloud/cloud-init.disabled como se indica aquí, reinicie la VM y revise de nuevo que la salida del comando cloud-init status sea done.

12. Si la instalación finaliza correctamente, ejecute el apagado de la maquina con el siguiente comando.

shutdown -h now

13. (Opcional Recomendado). Haga clic con el botón derecho en editar la configuración, cambie la unidad de CD/DVD 1 a Client Device con el Device Mode en Passthrough CD-ROM.

14. Convierta la maquina virtual en Template en el inventario de vCenter Server.

15. En este punto ya podrá configurar el Image Mapping en Cloud Assembly para usar esta plantilla (sino sabe como hacerlo vea How to add image mapping in vRealize Automation to access common operating systems).

Ejemplo de utilización en Cloud Template (blueprint) con imagen RedHat/CentOS/Ubuntu

Para verificar el funcionamiento de los comandos cloud-init enviados a través del cloudConfig desde el Cloud Template, recomiendo crear un Cloud Template básico que cree un archivo test.txt en el repositorio /tmp/test.

Realice un despliegue de este blueprint de prueba y debería haberse creado un archivo Test.txt en el repositorio /tmp/test.

Nota 8: En las maquina Linux los comandos enviados desde cloudConfig pueden visualizarse en el archivo

/var/lib/cloud/instance/cloud-config.txt dentro del OS. Esto es útil cuando necesitamos hacer troubleshooting y necesitamos validar si los comandos están entrando a la maquina.

Al abrir el contenido del archivo podemos visualizar todos los comandos que hemos configurado en la sección cloudConfig del Cloud Template (blueprint) de vRealize Automation.

Actualización 03/12/2021

La versión de Ubuntu 20.4 ya tiene instalado el cloud-init por default pero sino simplemente instálelo de la siguiente forma.

Ejecute los siguientes comandos:

apt-get install cloud-init
cat /etc/cloud/ds-identify.cfg, la salida debería ser policy: enabled

systemctl enable cloud-init-local.service
systemctl start cloud-init-local.service

systemctl enable cloud-init.service
systemctl start cloud-init.service
systemctl enable cloud-config.service
systemctl start cloud-config.service
systemctl enable cloud-final.service
systemctl start cloud-final.service
cloud-init status
cloud-init clean

Si los comando se ejecutan correctamente, realice el apagado de la maquina con el siguiente comando. shutdown -h now

Por otra parte, si como mencionamos antes el cloud-init ya esta instalado en SO, tener en cuenta que por defecto el cloud-init viene «desconfigurado». De manera que para esta version (Ubuntu 20.04) es importante verificar que tengamos configurada la fuente de datos (Data Source) correcta.

Para configurarlo correctamente de debemos ejecutar el comando:

dpkg-reconfigure cloud-init

Preferiblemente marcar únicamente OVF que será el que utilizaremos para las plantillas de vRA. Sin embargo, en este caso vemos que existe una con el nombre VMware, entonces marcaremos las dos (OVF, VMware).

Nota 9: La fuente de datos OVF (Open Virtualization Format) proporciona una fuente de datos para leer datos desde un ISO de transporte OVF. 

Para verificar que el cambio a tomado efecto podemos ejecutar el comando

cat /etc/cloud/cloud.cfg.d/90_dpkg.cfg

Si por alguna razón todo lo anterior esta bien configurado pero aún no le funcionan los comandos de cloudConfig, no se preocupe en seguida tendrá la solución.

Vamos a hacer un procedimiento sencillo pero que me costó encontrar unas 8 horas. Y que probablemente sino lo hacemos no va a funcionar en esta versión de Ubuntu, debido a que por defecto, el instalador del SO deja deshabilitadas los Data Sources. (Agradecimientos a este foro por existir!)

Ejecute el siguiente comando y verifique si aparece la línea datasource_list [None], si es así. Eureka! Hemos encontrado el problema.

cat /etc/cloud/cloud.cfg.d/99-installer.cfg

Solo basta con editar esa línea y definir la fuente de datos [OVF], para esto podemos utilizar el siguiente comando

vi /etc/cloud/cloud.cfg.d/99-installer.cfg

Para guardar solo presione ESC, y despues :wq!

Después, para verificar que el cambio se ha aplicado podemos ejecutar de nuevo el comando

cat /etc/cloud/cloud.cfg.d/99-installer.cfg

Por último, ejecutaremos los comandos que ya conocemos antes de apagar la VM.

Ahora después de hacer un despliegue del Cloud Template (Blueprint) del ejemplo anterior (Ejemplo de utilización en Cloud Template (blueprint) con imagen RedHat/CentOS/Ubuntu) podremos ver que se ha creado la carpeta test y el archivo Test.txt dentro de la carpeta. Esto quiere decir que ya se están ejecutando los comandos cloudConfig enviados desde el Cloud Template de vRealize Automation.

Preparación de Template SUSE

Llegamos a la ultima plantilla que veremos en este blog, y es tal vez de la que menos información encontramos en la web. Bueno, que realmente funcione sin darnos tantos dolores de cabeza.

El procedimiento de preparación de se resume en los siguientes pasos.

1. Verifique que la maquina virtual que será plantilla para vRealize Automation tenga salida a internet para alcanzar los repositorios de descarga de SUSE.

2. Instalar dependencias recomendadas en el enlace de IBM.

Para instalar los paquetes en SUSE ejecute los siguientes comandos como root.

zypper install xfsprogs
zypper install python3-oauthlib
zypper install python3-Jinja2
zypper install python3-PyYAML
zypper install python3-distro
zypper install python3-jsonpatch
zypper install python3-jsonschema
zypper install python3-PrettyTable
zypper install python3-requests
zypper install python3-configobj

Nota 8: Si por alguna razón falla la instalación de los paquetes python3-jsonpatch y
python3-jsonschema entonces intente instalarlos manualmente con ayuda de la documentación oficial de SUSE.

Ejemplo para SUSE SLE 15.3 (tomado de la documentación oficial python-jsonpatch from devel:languages:python)

En el ejemplo anterior encontramos el repositorio para instalar python-jsonpatch y con el pudimos instalar python3-jsonpatch y python3-jsonschema. No se preocupe si su version de SUSE no es la misma, solo es cuestión de buscar rápidamente en la web el comando correcto para su version.

3. Una vez instalados todos lo paquetes listados anteriormente. Proceda a instalar el cloud-init como lo indica la documentación oficial de SUSE cloud-init from Cloud:Tools. De nuevo puede apoyarse de la web para buscar el comando correcto de acuerdo a su version de SUSE.

Ejemplo para SUSE 15:

4. Una vez terminada la instalación del componente cloud-init en el Template. Ejecute los siguientes comandos:

systemctl enable cloud-init-local.service
systemctl enable cloud-init.service
systemctl enable cloud-config.service
systemctl enable cloud-final.service
systemctl start cloud-init.service
systemctl start cloud-init-local.service
systemctl start cloud-config.service
systemctl start cloud-final.service
cloud-init status
cloud-init clean

5. Si los comando se ejecutan correctamente, realice el apagado de la maquina con el siguiente comando.

shutdown -h now

6. (Opcional Recomendado). Haga clic con el botón derecho en editar la configuración, cambie la unidad de CD/DVD 1 a Client Device con el Device Mode en Passthrough CD-ROM.

7. Convierta la maquina virtual en Template en el inventario de vCenter Server.

8. En este punto ya podrá configurar el Image Mapping en Cloud Assembly para usar esta plantilla (sino sabe como hacerlo vea How to add image mapping in vRealize Automation to access common operating systems).

Ejemplo de utilización en Cloud Template (blueprint) con imagen SUSE

De manera similar a como lo hemos hecho en los casos anteriores, para verificar el funcionamiento de los comandos cloud-init enviados a través del cloudConfig desde el Cloud Template, recomiendo crear un Cloud Template básico que cree un archivo test.txt en el repositorio /tmp/test.

Realice un despliegue de este blueprint de prueba y debería haberse creado un archivo test.txt en el repositorio /tmp/test.

De igual manera a como lo hicimos en el Template RedHat, en SUSE podemos verificar los comando que fueron enviados desde cloudConfig a la nueva instancia de maquina, en el archivo /var/lib/cloud/instance/cloud-config.txt

Nota 10: Puede hacer uso de los logs de cloud-init para hace troubleshooting de ser necesario.

Ejemplo: Visualizacion de Logs.

NOTAS ADICIONALES PARA TODOS LOS TEMPLATES

Nota 11: Para garantizar una interpretación correcta de los comandos, incluya siempre el carácter de barra vertical cloudConfig: | como se muestra.

Nota 12: Si una secuencia de comandos de cloud-init se comporta de manera inesperada, verifique la salida de la consola en /var/log/cloud-init-output.log cuando haga troubleshooting. Para obtener más información sobre cloud-init, puede consultar la documentación oficial de cloud-init .

Nota 13: Cuando despliegue en vSphere, proceda con cuidado si intenta combinar los comandos integrados de cloudConfig con la utilización de Customization Specification de vSphere. No son formalmente compatibles y pueden producir resultados inconsistentes o no deseados cuando se usan juntos. Sin embargo, puede utilizarlos juntos de forma segura siempre y cuando NO utilice comandos de inicialización para la red en cloudConfig ya que esta acción la realiza el Customization Specification de vSphere. Recomiendo leer el siguiente enlace y revisar los ejemplos allí descritos para entender cómo interactúan los comandos y los Custom Specification. Revise los ejemplos para Asignación de direcciones IP estáticas en Cloud Templates de Cloud Assembly .

Nota 14: Es posible examinar los comandos que son enviados a través de cloudConfig desde vRealize Automation. Para esto siga los siguientes pasos.

1. Abra el Deployment en vRealize Automation y después Clic en Topology.

2. En el panel del lado derecho expanda la sección > Cloud Config.

3. Revise los comando que fueron enviados a la instancia de maquina virtual durante el despliegue.

Nota 15: Puede configurar la propiedad remoteAccess en el código del Cloud Template (blueprint) para crear un usuario adicional (diferente al administrator o root) para el acceso después del despliegue de la maquina virtual. Por supuesto deberá utilizar la propiedad de cloudConfig para enviar comandos cloud-init (Linux) o cloudbase-init (Windows) y de esta manera otorgar los permisos necesarios dentro de la maquina virtual. Por defecto tendrá permisos de acceso remoto. (Para mayor información ver aquí).

Nota 14: Los blueprint a partir de la version de vRealize Automation 8.2 han sido renombrados como Cloud Templates.

OPCIONAL

Por ultimo y como paso adicional a la preparación de las plantillas de cualquier sistema operativo. Solo si evidencia algún conflicto entre Custom Spec y cloud-Init, aunque no debería; pero si es el caso siga las recomendaciones descritas en How to make a Cloud Assembly deployment wait for initialization, para hacer que la inicialización de la maquina desplegada por Cloud Assembly espere un tiempo antes de comenzar.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Referencias

  1. Cloudbase-Init
  2. Cloud-Init
  3. Configuration commands in Cloud Assembly templates
  4. vSphere static IP address assignment in Cloud Assembly cloud templates
  5. How to perform Windows guest customization
  6. How to automatically initialize a machine in a vRealize Automation Cloud Assembly template
  7. Creating and Managing Customization Specifications
  8. How to create an initializable Windows image for vSphere
  9. Cloudbase-init Configuration options reference
  10. Windows guest initialization with Cloudbase-Init in vCenter
  11. Logging for cloud-init in redhat OS
  12. Add repository and install manually python-jsonpatch for SUSE SLE 15
  13. Preparing a vSphere VM to Receive a cloud-init Script (KB 76346)
  14. Installing and configuring cloud-init on SLES
  15. cloud-init from Cloud:Tools project
  16. python-jsonpatch from devel:languages:python project
  17. Prepare a SLES or openSUSE Leap virtual machine for Azure
  18. How to add image mapping in vRealize Automation to access common operating systems
  19. How to enable remote access in vRealize Automation Cloud Assembly templates
  20. Supply a username and password to vRealize Automation Cloud Assembly
  21. How to Use Remote Access Authentication in your Cloud Assembly Deployments
  22. Recomendation Passtrough Mode CD/DVD
  23. How to include Cloudbase-Init commands in a cloud template
  24. Delayed deployment in Cloud Assembly
  25. Installing and configuring cloud-init on Ubuntu 20.04
  26. Building a vRealize Automation Cloud Ready Ubuntu Template for vSphere
  27. Cloud-Init Boot Stages

Verificar integridad de medios de instalación VMware (checksum)

Como ya sabemos, una suma de verificación o checksum, es el resultado de ejecutar una función hash criptográfica dentro de un archivo, que tiene como propósito principal detectar cambios en una secuencia de datos para proteger su integridad. La particularidad de esto es que un pequeño cambio en el archivo provoca una salida totalmente distinta.

Dicho esto, checksum nos permite verificar la integridad del medio de instalación y estar seguros que el contenido del mismo no ha sido alterado y es tal y como lo indica su fabricante.

Lo importante a tener en cuenta en este post es que el objetivo no es garantizar una procedencia confiable del medio de instalación, sino verificar la integridad del archivo descargado.

Dejando un lado la teoría vamos a lo que nos interesa…

PROCEDIMIENTO

Utilizando la línea de comando de Windows (CMD) y la herramienta CertUtil incluida en las versiones mas recientes del sistema operativo. Ejecute el siguiente comando.

CertUtil -hashfile "Ubicacion_y_nombre_del_archivo" MD5

Nota 1: Para no tener que escribir el nombre del archivo, podemos simplemente seleccionarlo y arrastrarlo dentro de la consola de CMD de Windows y de esta manera incluirá la ubicación completa del mismo.

El resultado del comando nos devuelve un número de verificación similar al siguiente. Selecciónelo y cópielo para el siguiente paso (el de su Command Prompt).

e05748cea32d60566f0738a5b811cfdc

Para verificar que el archivo no ha sufrido ninguna modificación durante la descarga o posterior a ella, vaya a la página de descargas de VMware, donde descargó el medio de instalación, utilice la función Buscar… (ctrl+f o command+f) y dentro del campo de búsqueda pegue el numero que devolvió la salida del comando anterior.

De esta manera podemos buscar rápidamente si el numero que nos devolvió la herramienta CertUtil corresponde con el numero de verificación (MD5SUM) publicado por el fabricante.

Nota 2: Sino puede ver los detalles del medio de instalación en pagina de descargas. Haga clic en el enlace Read more para visualizar la información publicada por VMware.

Si el numero es encontrado como en la imagen anterior, el medio de instalación es apto para ser usado. Sino es así, vuelva a descargar el medio de instalación porque seguramente esta corrupto.

Nota 3: Puede utilizar la herramienta CertUtil para la suma de verificación de otros algoritmos hash cambiando el parámetro MD5 en el comando por cualquiera de los siguientes. VMware en su página de descargas publica la información para MD5SUM, SHA1SUM y SHA256SUM.

  • MD2
  • MD4
  • MD5
  • SHA1
  • SHA256
  • SHA384
  • SHA512

Por ultimo y como recomendación, realice este procedimiento para evitar algunos dolores de cabeza y perder tiempo tratando de solucionar problemas que probablemente vienen del medio de instalación y no del proceso de instalación o actualización.

Exportar reglas del Firewall Distribuido de NSX-T con vRNI

Muchas veces bien sea desde el lado de implementación o desde la operación, nos encontramos con el problema de no poder exportar las reglas del Firewall Distribuido de NSX-T en las versiones 3.0 y anteriores. Esta característica ha sido recientemente adicionada a la versión 3.1 (ver aquí), de manera que si tenemos una version anterior nos vemos obligados a recurrir a APIs para poder extraer la configuración de estas políticas y reglas.

Por suerte, por lo general cuando hablamos de Micro-Segmentación casi siempre tenemos a la mano la herramienta vRealize Network Insight con lo cual esta tarea se resume a una consulta y a un export.

PROCEDIMIENTO

En la caja de búsqueda de vRNI realice la siguiente consulta: NSX-T Firewall rule

En el filtro NSX Manager, seleccione el NSX Manager de interés. Si solo tiene un NSX Manager conectado a vRNI omita el paso.

Haga clic en More Option y después clic en Export as CSV.

Clic en Clear All para eliminar todas las propiedades y poder ajustar las que son de nuestro interés.

Clic en ADD PROPERTIES y agregue las siguientes propiedades:

Nota: Puede utilizar el buscador para encontrar las propiedades rapidamente.

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction

Activamos el check Save changes to: Create a new template, para crea una plantilla con las nueve (9) propiedades seleccionadas.

Por ultimo, en el campo de texto Create a new template asignamos un nombre a la plantilla (en este caso hemos definido Export DF Rules Template)y hacemos clic en EXPORT.

Seleccionamos el destino y nombre para el archivo .csv y clic en Save.

clip_image005

La próxima vez que desee exportar nuevamente las reglas únicamente tendrá que seleccionar en Property Template la plantilla guardada y automáticamente se cargaran las propiedades asociadas.

Una vez hemos exportado la información simplemente lo importamos en Excel para poder visualizarla como filas y columnas.

(Opcional) Una vez la tenemos en este formato, recomiendo crear una tabla dinámica para organizar mejor la información de forma similar a como la vemos en el Firewall Distribuido.

Para esto, active el Diseño de tabla dinámica clásica antes de seleccionar la información de las columnas.

clip_image010

Organice las filas en el siguiente orden y seleccione la opción No mostrar subtotales en el diseño de la tabla dinámica

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction

Por ultimo, utilice la función buscar y remplazar para eliminar la palabra «default.» que antepone cada security group en la información exportada. De esta manera podrá visualizar mejor la información presentada.

Actualizando vRealize Network Insight 5.x (Online Update)

Antes de comenzar a actualizar la solución es recomendable considerar los siguientes puntos:

  • Después de la actualización, vRealize Network Insight tarda entre 12 y 24 horas en procesar los datos que estaban en proceso durante la operación de actualización y reflejarlos en la interfaz de usuario.
  • vRealize Network Insight no admite rollback ni downgrade del producto por lo que se debe realizar una copia de seguridad antes de continuar con la actualización. Para obtener más información sobre el proceso de backup y restauración ver aquí.
  • En un entorno de clúster, debe realizar la operación de actualización solo en el nodo Platform 1.
  • Después de actualizar a vRealize Network Insight 6.x, algunos de los ID de reglas de firewall pueden cambiar a los nuevos ID devueltos por la API de VMware Cloud on AWS 1.9. Si existe alguna regla de firewall de VMware Cloud on AWS 1.8 adjunta a los flujos:
    • Las reglas de firewall de VMware Cloud on AWS 1.9 correctas o respectivas se adjuntarían inmediatamente después de la actualización para todos los flujos activos.
    • Las reglas de firewall se referirían a reglas inexistentes para los flujos cuyo período de inactividad es mayor a 24 horas antes de actualizar la versión 1.8 a 1.9.
  • La solución debería tener acceso a internet para la descarga de los paquetes necesarios de manera automática. Este acceso a internet puede ser directo o a través de un web proxy.
  • La opción Online Update deberá estar habilitada en Settings | Infrastructure and Support | Overview and Update y deberá existir un paquete disponible para instalar.
  • Asegúrese de tener soporte activo para la solución vRealize Network Insight antes de actualizar.
  • Si va a realizar un Upgrade (cambio a una nueva versión) entonces deberá realizar el upgrade también de la licencia en my.vmware.com.

PROCEDIMIENTO

1. Genere un Snapshot para cada una de la maquinas virtuales que conforman la solución (nodos Platform y Proxies) o asegúrese de tener un backup de cada una de ellas en caso de que algo salga mal.

2. Inicie sesión en vRealize Network Insight como administrador y vaya a Settings | Infrastructure and Support | Overview and Update para revisar la existencia de actualizaciones disponibles.

image

3. Verifique el estado de salud de la infraestructura sea Good.

image

4. Haga clic en el enlace View details frente a la nueva versión de paquete que aparece disponible.

image

5. Revise el numero de compilación de la nueva versión y lea atentamente la información de la ventana emergente. (Opcional) haga clic en View release note para conocer mas acerca de la nueva versión.

image

6. Haga clic en CONTINUE para iniciar el proceso de actualización y espere pacientemente a que todos los pasos finalicen con éxito.

image

7. Cuando aparezca el botón DONE en la parte inferior, sabrá que el proceso de actualización ha terminado. Y podrá hacer clic sobre el para cerrar la ventana emergente e ir a la ventana de inicio de sesión.

image

8. Inicie sesión en la solución vRealize Network Insight como administrador y revise las notas What is New de bienvenida, para familiarizarse con las bondades de la nueva versión. Cierre la ventana emergente haciendo clic en la X.

image

9. Una vez cierre la ventana anterior, aparecerá una notificación para ingresar la licencia asociada a la nueva versión.

Nota: Si únicamente se hace un Update dentro de la misma versión no tendrá que hacer este paso.

image

10. Haga clic en PROCEED para ir automáticamente a la sección License and Usage e ingrese la nueva llave que previamente debió haber actualizado desde el portal de my.vmware.com.

image

11. Verifique que el estado de salud para cada uno de los componentes de la infraestructura continúe en Good, en la sección Settings | Infrastructure and Support | Overview and Updates.

image

12. Por ultimo pero no menos importante, verifique que las fuentes de datos continúen recolectando datos.

Identificar el líder en un cluster de NSX-T Manager 3.x

Antes de explicar el sencillo procedimiento para identificar el líder en un clúster, recordemos que un clúster esta formado por un grupo de tres nodos NSX Manager para alta disponibilidad y escalabilidad y que cada NSX Manager appliance tiene incluido los roles de Policy, Manager y Controller.

Podemos construir un clúster de NSX-T Manager de las siguientes dos maneras.

NSX Management Cluster con Dirección IP Virtual

El NSX Management cluster garantiza la alta disponibilidad y es configurado de la siguiente forma:

  • Todos los manager deben estar en la misma subnet.
  • Un nodo Manager es elegido como líder.
  • La IP Virtual del Cluster es unida al manager líder.
  • El trafico NO es balanceado a través de los Managers mientras usa VIP.
  • La IP Virtual del cluster es usada para el trafico destinado a los nodos NSX Manager.
  • El trafico destinado a cualquier Nodo de Transporte usa la IP de management del nodo.
  • Una única dirección IP virtual es usada por los clientes de acceso API y GUI.
image

Cuando se envía una solicitud de usuario a la dirección IP virtual, el manager activo (el líder que tiene la dirección IP virtual adjunta) responde a la solicitud. Si el líder falla los dos managers restantes eligen un nuevo líder y este responderá a las solicitudes enviadas a esa dirección IP virtual.

Las solicitudes de equilibrio de carga y el tráfico no se equilibran entre los administradores mientras se usa VIP.

Si el nodo líder que posee VIP falla, se elige un nuevo líder que envía una solicitud GARP para tomar posesión de la VIP y entonces el nuevo nodo líder recibe todas las nuevas solicitudes de API y UI de los usuarios.

NSX Management Cluster con Load Balancer

Para este caso, un balanceador de carga es el encargado de proveer alta disponibilidad al cluster:

  • Todos los nodos son activos.
  • GUI y API son disponibles en todos los managers.
  • El trafico a la IP Virtual es balanceado a múltiples nodos manager.
  • Los nodos manager pueden estar en diferente subnet.
image

Una vez explicado lo anterior, podría surgir la pregunta -¿Para que querría saber quien es el líder? – pues bien, cuando tenemos un problema con la solución se hace indispensable saber cual de los nodos esta recibiendo las solicitudes de manera que podamos acceder a el a través de la linea de comandos para realizar el debido troubleshooting.

También es útil para la fase de pruebas post implementación (VMware verification workbook) en donde debemos testear la alta disponibilidad y garantizar el correcto funcionamiento del cluster.

PROCEDIMIENTO

1. Inicie sesión SSH hacia la IP Virtual del Cluster con el usuario admin y el password definido en la instalación . Sino tiene habilitado el servicio SSH puede hacer login desde la Consola de la VM en el vCenter.

2. Ejecute el comando get cluster status verbose y observaremos que para cada función del manager tenemos un líder seleccionado.

3. Ahora solo debemos buscar debajo de cada función del manager, el líder asociado para cada uno de los servicios de la misma.

En la siguiente grafica se muestra como líder del servicio api para la función HTTPS, al miembro con UUID terminado en 3d60144055b5 que corresponde al FQDN nsxp02.lab.local.

Nota: Algunas funciones tendrán mas de un servicio, por lo que tendrán un líder asociado para cada uno.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.