Bolly

En este episodio de Compilando Podcast, nos adentramos en el fascinante mundo de la computación cuántica y exploramos cómo el open source está desempeñando un papel clave en su desarrollo.

Descubre qué son los qubits, por qué esta tecnología requiere condiciones extremas —como temperaturas cercanas al cero absoluto y un aislamiento total del ruido y las vibraciones—, y cómo los proyectos de código abierto están haciendo posible experimentar, simular y avanzar en este campo desde cualquier parte del mundo.

Hablamos de referentes como Qiskit (IBM) o Cirq (Google), pero también de nuevas iniciativas que marcan tendencia, como OQTOPUS, QUAlibrate o QuantumToolbox.jl, que demuestran que el futuro cuántico será colaborativo, abierto y compartido.

🔹 Ciencia, software libre y futuro tecnológico, en un episodio que conecta la física más avanzada con la filosofía del código abierto.
🔹 Como siempre, con el sello de Compilando Podcast: divulgación libre, clara y apasionada.

🎧 Escúchalo, suscríbete y comparte —porque el conocimiento, cuando se comparte, se multiplica.

Un proyecto comunitario pretende exportar funcionalidades de YaST que faltan en la nueva herramienta Cockpit, ya que SUSE y openSUSE 16.0 han «jubilado» a la gran herramienta de configuración de sistema YaST

El pasado 1 de octubre de 2025 se publicó openSUSE Leap 16.0. Una nueva versión de esta distribución de GNU/Linux que trajo varios cambios significativos e importantes. Entre ellos, el nuevo instalador Agama y la nueva herramienta web de configuración del sistema que utiliza Cockpit como sustituto del veterano YaST.

Cockpit se introdujo en Leap 16.0 como parte de un cambio más amplio hacia una infraestructura moderna y amigable con la automatización.

Todos los cambios son disruptivos y a veces traumáticos. Y eso de no tener a YaST a la hora de realizar gestiones en nuestro openSUSE Leap puede ser una razón que tire hacia atrás a los usuarios.

Y más cuando la nueva herramienta todavía adolece de algunas funcionalidades básicas que en YaST era algo común y sencillo, pero que todavía no se han exportado a la nueva herramienta Cockpit. Se evaluó cuales eran los módulos de YaST más populares y usados o más necesarios y se fue trabajando en ellos, para priorizar esfuerzos y recursos.

Pero hay muchas lagunas que todavía no se han llenado. Y eso es lo que pretende solucionar un proyecto presentado en la Hack Week 25. Ese proyecto tiene como objetivo abordar los comentarios de la comunidad al incorporar funciones de configuración populares de YaST a Cockpit y System Roles, lo que es un paso para cerrar la brecha dejada por la obsolescencia de YaST en openSUSE Leap 16.0.

Esperemos que ponto vayan llenándose los huecos dejados por la retirada de YaST y se vaya también puliendo los ya existentes. Si te interesa participar con un grupo de desarrolladores y aprender y aportar te podrás unir a este proyecto de Hack Week.

Hack Week es una iniciativa llevada a cabo por SUSE, en la que en una fase inicial los desarrolladores y trabajadores de SUSE aportan sus ideas de diferentes proyectos. Quien quiera se puede unir a los proyectos que le parezcan más interesantes, y durante una semana los desarrolladores aparcan su trabajo habitual para dedicarse al proyecto que han presentado o al que se han unido. Pasada esa semana se puede seguir trabajando en el proyecto personal hasta finalizarlo.

Esta iniciativa de SUSE se viene llevando a cabo desde 2007 y de ella han salido proyectos muy importantes hasta después tener entidad propia y convertirse en proyectos comunitarios muy importantes.

Por poner un ejemplo, de pasadas ediciones de esta Hack Week han salido proyectos como: openQA, Weblate, Aeon, o NextCloud.

A ver si con esta iniciativa se puede dar un empujón a Cockpit para que cada vez sea más completo e incluya más funcionalidades de YaST.

Enlaces de interés

• https://news.opensuse.org/2025/10/29/hw-project-aims-to-bridge-yast-cockpit-gaps/
• https://hackweek.opensuse.org/25/projects/bring-to-cockpit-plus-system-roles-capabilities-from-yast

El remake L'Abbaye des morts hecha por Nevat es una versión libre hecha con Godot bajo licencia GPL3 basada en el divertido juego freeware que en su día hizó Lomomalito con música de Gryzor.

Si pulsamos la tecla C al inicio del juego podemos disfrutar de los gráficos mejorados.

Curiosamente en la pantalla de inicio pone que es un juego Freeware, supongo que es un despiste porque en la web y en el código pone que es GPL/3.

La respuesta es muy buena y sigue siendo un juego muy divertido y absorbente.

Para descargarlo lo mejor es ir la página de descargas y bajarnos la última versión disponible, podemos elegir entre 4 arquitecturas: PC de 64 y 32 bits o ARM de 64 o 32 bits.

Como son binarios portables, los puedes descargar en cualquier carpeta, darle permisos de ejecución y ejecutarlo.

Mi recomendación es copiarlo luego a /usr/local/bin y así podemos ejecutarlo como un comando más del sistema como otro comando más del sistema, por ejemplo:

abbayedesmorts-godot-1.1.0-linux-arm64

También sería interesante crearle un acceso directo para nuestra mayor comodidad.

Por supuesto, como software libre, tenemos disponible el código fuente para analizarlo y compilar a partir de él.

Uno de los grandes retos en desarrollo y operaciones es la fiabilidad. ¿Cuántas veces hemos oído aquello de “en mi máquina funciona”? Aunque Docker ayudó mucho a estandarizar entornos, todavía existen problemas: imágenes demasiado...

La entrada Entornos reproducibles con Nix + Docker en GNU/Linux se publicó primero en ochobitshacenunbyte.

Quería mostrar esta poderosa herramienta pero no fue posible, falla en kubuntu cuando uso apt, pero si puede que ande con snap.. lo cual solo intento usar lo mínimo posible, para el uso de este software me parece innecesario. Seguro hay parte dos, o con alguna distro Arch, o con kubuntu sin snap, ya que ahí tira de los repos de debian directamente.

La enshitificación de internet y la tecnología actual no tiene límite. Fíjate si estamos mal, que echo de menos los tiempos donde el mayor problema eran los popups y los gifs animados en las webs.

https://f-droid.org/2025/10/28/sideloading.html

La entrada Side Loading se publicó primero en Linux Hispano.

Lynis es una herramienta de software libre con la que podrás auditar la seguridad de tu sistema GNU/Linux y otras derivadas de Unix como FreeBSD, Solaris o MacOS.

Hoy hechando un vistazo a mis feeds, me he encontrado con un artículo en inglés de SUSE, donde nos dan una serie de recomendaciones y guías para securizar nuestro sistema GNU/Linux.

El fortalecimiento de Linux es el proceso de reducir las vulnerabilidades, fortalecer las configuraciones y asegurarse de cumplir con los estándares de seguridad en los sistemas Linux. Con miles de organizaciones que confían en las soluciones empresariales de Linux para cargas de trabajo críticas, el uso de prácticas sólidas de fortalecimiento se ha vuelto esencial para protegerse contra las amenazas cibernéticas y mantener el cumplimiento normativo.

Está escrito por SUSE, pero se pueden extrapolar sus recomendaciones a cualquier sistema GNU/Linux:

• https://www.suse.com/c/linux-hardeningthe-complete-guide-to-securing-your-systems/

En dicho artículo además del conjunto de recomendaciones para fortalecer nuestro sistema GNU/Linux hablan sobre una herramienta que me ha llamado la atención llamada Lynis: Lynis – Herramienta de auditoría y endurecimiento de seguridad, para sistemas basados en UNIX.

Lynis es una herramienta publicada bajo licencia GPL v3.0, por lo que es software libre y además gratuito, ya que puedes descargarla y utilizarla. Primero veamos cómo se definen en su repositorio de GitHub:

Lynis es una herramienta de auditoría de seguridad para sistemas basados en UNIX como Linux, macOS, BSD y otros. Realiza un análisis de seguridad en profundidad y se ejecuta en el propio sistema. El objetivo principal es probar las defensas de seguridad y proporcionar consejos para un mayor fortalecimiento del sistema. También buscará información general del sistema, paquetes de software vulnerables y posibles problemas de configuración.

Lynis fue utilizado comúnmente por administradores de sistemas y auditores para evaluar las defensas de seguridad de sus sistemas. Además del «equipo azul», hoy en día los probadores de penetración también tienen a Lynis en su caja de herramientas.

La herramienta está orientada a personal técnico como: Administradores de sistemas, Auditores Oficiales de seguridad, Probadores de penetración de sistemas, Profesionales de la seguridad, etc.

Digamos que es una herramienta profesional pero que podemos utilizarla en nuestro sistema GNU/Linux como guía, pero teniendo en cuenta que hay que tener conocimientos profundos del sistema y valorar si realmente nuestro sistema GNU/Linux merece llevar a cabo las sugerencias en cuanto a seguridad que nos ofrece la herramienta Lynis.

En GNU/Linux somos de naturaleza curiosa y nos gusta ver cosas nuevas, así que «¿¿a quien no le va a gustar ejecutar esta herramienta de seguridad???» (punto para ti si reconoces el vídeo parafraseado).

En mi caso la quise probar pero sin instalar nada. Lynis está en los repositorios de openSUSE y de muchas otras distribuciones, así que desde tu gestor de software favorito la puedes buscar e instalar.

En mi caso, como era algo meramente informativo y puntual no quise instalarlo, así que me descargué el archivo comprimido y después lo descomprimí. A día de hoy la versión actual es 3.6.1:

wget https://cisofy.com/files/lynis-3.1.6.tar.gz     
tar -zxvf lynis-3.1.6.tar.gz

Nos descomprime todo en un archivo lynis, entramos en él y ejecutamos la auditoría que queramos.

En mi caso quería algo rápido para ver qué aspecto tiene la herramienta y qué resultados me ofrecía. Así que ejecuté un:

 sudo ./lynis audit system --quick 

Después de introducir la contraseña y de aceptar con ENTER la advertencia que nos hace la herramiente Lynis, comienza el escaneado rápido de nuestro sistema GNU/Linux. Y en él nos va mostrando diferentes mensajes.

Aquí es donde digo que hay que tener un conocimiento profundo del sistema. Nos saldrán varias advertencias, lo que nos puede llevar a tratar de corregirlas sin saber cómo y podremos romper el sistema si actuamos a lo loco.

Más adelante, la propia herramienta Lynis nos ofrece una serie de sugerencias para aumentar la seguridad de distintas partes del sistema. Aquí dejo a tu consideración si realmente merece la pena llevar a cabo las recomendaciones.

También al final del escaneo realizado nos mostrará un par de rutas donde guarda los registros o logs obtenidos, para una revisión más detallada o para enviarlo a un profesional, etc…

Lynis puede ser una buena herramienta si estás estudiando sobre estos temas o si ya trabajas con temas relacionados con la administración se sistemas o seguridad y quieres repasar si tus sistemas tienen puntos débiles que haya que solucionar o mejorar.

Tiene muy buena documentación y al ser software libre, tiene disponibles complementos que pueden expandir sus posibilidades. ¿Te animas a probarlo?

Enlaces de interés

• https://www.suse.com/c/linux-hardeningthe-complete-guide-to-securing-your-systems/
• https://cisofy.com/
• https://cisofy.com/documentation/lynis/get-started/
• https://github.com/CISOfy/Lynis

La historia de los RAID (Redundant Array of Independent/Inexpensive Disks) es una evolución fascinante dentro del almacenamiento informático, donde la necesidad de mayor rendimiento, fiabilidad y capacidad dio origen a diversas configuraciones que hoy son estándar en servidores, NAS y PCs avanzados.

Orígenes (década de 1970 – 1980)

En los años 70, los discos duros eran muy costosos y de baja capacidad. Los grandes sistemas (como los mainframes de IBM) usaban arreglos de discos para obtener redundancia y rendimiento, pero eran soluciones propietarias.

En 1987, David Patterson, Garth Gibson y Randy Katz en la Universidad de California, Berkeley, publicaron el documento clave:

“A Case for Redundant Arrays of Inexpensive Disks (RAID)”

Este paper fue el primero en definir formalmente los niveles RAID 0 a RAID 5, y propuso usar discos duros económicos (IDE/SCSI) combinados para obtener rendimiento de mainframe a bajo costo.
El término “inexpensive” (barato) luego se cambió a “independent” por razones comerciales.

Primera generación (finales de los 80s – 90s)

En los años 90, con el auge de los servidores UNIX, NetWare y Windows NT, el RAID se volvió popular. Se implementaba principalmente por hardware, con tarjetas controladoras dedicadas (Adaptec, Compaq Smart Array, etc.).

RAID clásicos definidos:

Nivel Año popularizado Características
RAID 0 ~1988 Striping, sin redundancia; máximo rendimiento, riesgo total.
RAID 1 ~1988 Mirroring, duplicación exacta de datos. Alta fiabilidad, bajo espacio útil.
RAID 2 ~1988 Corrección de errores con código Hamming. Prácticamente en desuso.
RAID 3 ~1989 Paridad dedicada en un disco. Requiere sincronización fina.
RAID 4 ~1990 Similar al 3, pero con bloques completos y un disco de paridad.
RAID 5 ~1992 Paridad distribuida, balance entre rendimiento y redundancia.
RAID 6 ~1996 Doble paridad, tolera fallo de dos discos. Ideal para grandes arreglos.

Segunda generación: software RAID y estandarización (2000s)

Con el aumento del poder de CPU y Linux, surgieron los RAID por software:

mdadm (Linux): herramienta de gestión de RAID por software introducida en 2001.

Windows Dynamic Disks y Storage Spaces (más tarde): equivalentes en el entorno Windows.

Los controladores SATA reemplazaron gradualmente SCSI, y surgieron las primeras controladoras RAID PCI y PCIe con caché y baterías (BBU).

Aparecen también RAID híbridos:

RAID 10 (1+0) y RAID 50 (5+0): combinaciones para obtener velocidad y tolerancia a fallos.

Tercera generación: era del NAS y SSD (2010–presente)

Con el auge del almacenamiento en red (NAS) y los discos de estado sólido (SSD), el RAID se adaptó a nuevas realidades:

Los SSD hicieron evidente que el RAID 5/6 clásico podía degradarse gravemente durante reconstrucciones largas (debido al tiempo de escritura y desgaste de bloques).

Nacen conceptos como:

RAID-Z (ZFS) → combina RAID y sistema de archivos con autocorrección.

Btrfs RAID → RAID por software con verificación de integridad.

Erasure Coding (en Ceph, GlusterFS, etc.) → una evolución matemática del RAID tradicional para almacenamiento distribuido.

RAID NVMe / RAID híbrido SSD + HDD → para acelerar cachés.

Ghostwriter, es un editor de archivos de lenguaje de marcas, también conocido como markdown.

Markdown es un lenguaje para la creación de documentación técnica, los típicos archivos de documentación README.md que acompañan al código en sitios de hospedaje de código, tales como gitlab, github, etc...

Ghostwriter es software libre GPL3, está dentro del proyecto KDE y suele estar incluido en los repositorios de las distros, en el caso de Debian y derivadas se puede instalar con el comando:

sudo apt install ghostwriter 

Este programa permite crear, visualizar y ver estos archivos mostrando una pantalla principal dividida en tres zonas, de izquierda a derecha:

• Información del documento: esta zona, que es la más pequeña, solo se muestra si hemos abierto algún documento y nuestra resolución horizontal es lo suficientemente amplia.
  Muestra unos iconos a la izquierda donde podemos elegir ver:
• Esquema de documento: es un índice interactivo que nos permite ir rápidamente a diferentes zonas del documento, los items los genera a partir de los títulos que vayamos creando en el documento.
• Estadísticas de la sesión actual: muestra información sobre nuestro trabajo en esta sesión de trabajo.
• Estadísticas del documento: Da información como el número de palabras, caracteres, oraciones, párrafos, páginas. 
  También el tiempo, facilidad y nivel de lectura
• Hoja de referencia: muestra la sintaxis del propio lenguaje markdown.
• Código markdown: aquí es donde escribimos el código.
• Resultado visual: muestra el resultado del código que introducimos reflejando los cambios en tiempo real.

También trae muchas funciones extra como generador de formatos, exportación html, corrector ortográfico, zoom, etc..

En conclusión, éste es uno de esos programas que debes tener instalado sí o sí en tu ordenador, en especial si haces documentación en formato markdown.

Que es WinRM y WS-Management

Windows Remote Management (WinRM) es un protocolo diseñado para facilitar la automatización y administración remota de equipos basados en Windows.

Se basa en el protocolo WS-Management, un estándar público para intercambiar datos de administración de forma remota con cualquier dispositivo informático que implemente el protocolo. 

El protocolo WS-Management garantiza la compatibilidad entre dispositivos y sistemas. Resulta útil cuando se combina con la comunicación remota de PowerShell, que permite a los administradores gestionar varios dispositivos mediante scripts y comandos.

Qué hace WinRM

WinRM permite la comunicación entre dispositivos, lo que permite a los administradores interactuar con sistemas remotos, ejecutar comandos de forma remota, recuperar datos y administrar configuraciones de sistemas. Se utiliza ampliamente para tareas como resolución de problemas, implementación de software y monitorización del rendimiento.

Autenticación y cifrado

WinRM admite varios mecanismos de autenticación, entre ellos, autenticación básica, Kerberos y NTLM.
También admite el cifrado para proteger la comunicación entre el cliente y el servidor, lo que garantiza la protección de los datos confidenciales durante el proceso de administración remota.

Administración de equipos Windows

Para administar equipos Windows remotos hay basicamente dos opciones:

• Mediante SSH
• Mediante WS-Management

Mediante SSH

Esta opción es totalmente operativa y permite administrar equipos desde Windows ó desde Linux.

Permite ejecutar tanto comandos CMD, como comandos PowerShell.

• CMD:

ssh -o PreferredAuthentications=password -o StrictHostKeyChecking=no -p 2222 guillermo@localhost 'whoami'

• PowerShell:

ssh -o PreferredAuthentications=password -o StrictHostKeyChecking=no -p 2222 guillermo@winpc 'powershell -Command "Write-Output 'SoloConLinux conectado'"'

Captura de la ejecución:

Para el funcionamiento correcto de la conexion ssh desde un equipo Linux hay que forzar la autenticación, en mi caso lo he realizado con el parámetro: -o PreferredAuthentications=password
En caso contrario nos podemos encontrar con el siguiente error:

Received disconnect from winpc:  Too many authentication failures
Disconnected from winpc

Tambien podemos usar Ansible.

En el caso de usar BashFlow, (producto propio, sin liberar aun) podremos crear nuestro propio playbook y usarlo para realizar la conexion al equipo Windows.
Ejemplo de Playbook en bashflow: winremote_exec.yaml

tasks:
  - name: Ejecutar comando remoto en Windows vía SSH
    module: winremote_exec
    args:
      winuser: guillermo
      winpassword: "{{ clave_guillermo }}"
      port: 2222
      #command: "Get-Process | Where-Object {$_.CPU -gt 1}"
      command: "whoami"

Ejecutamos el playbook:

bashflow -f winremote_exec.yml -h winpc

La salida de la ejecución se vería así:

Mediante WS-Management

Para la administración automatiza de equipos Windows se puede realizar atacando al servicio winrm.exe

Este es el servicio que se ejecuta en los equipos Windows y permite aceptar y responder a las peticiones de administración remota.
Escucha las solicitudes entrantes en puertos específicos (el valor predeterminado es 5985 para HTTP y 5986 para HTTPS).

Para que lo entendamos, podemos decir de forma simplificada que todo se realiza mediante llamadas SOAP.

Para la administración remota, los admistradores de Windows, disponen de PowerShell Remoting que se basa en WinRM y permite ejecutar comandos de PowerShell en sistemas remotos mediante un canal seguro.

Para los equipos Linux, se dispone de pwsh una shell de Powershell, sin embargo esta shell para Linux ya no permite ejecutar comando WS-Management, debido a los cambios de versiones de librerías de OpenSSL y otras medidas de seguridad ampliadas por Microsoft.

Basicamente el problema actual de pwsh en Linux es:

• PowerShell Core (pwsh) en Linux no incluye el cliente WSMan necesario para poder ejecutar:
  Invoke-Command -ConnectionUri.
• WSMan depende de bibliotecas nativas de Windows (winrm.dll) que no existen en Linux.
• Microsoft lo documenta e indica claramente:

“WSMan remoting is not supported on non-Windows platforms.”

Existen alternativas como usar pywinrm pero volvemos al problema de dependencias de Python.

En mi caso quería disponer de alguna "herramienta" que no tuviese dependencias y fuese un único binario al que invocar, tras localizar algunos proyectos relacionados con WS-Management:

• OpenWSMan http://openwsman.github.io/
  Es un desarrollo Open Source de WS-Management, sin embargo tambien termina siendo una implementación en Python.
• wsmancli https://github.com/Openwsman/wsmancli
  Tras varios intentos de compilación, resultó que ademas de usar una implementación incompleta de la API, hay numerosas dependencias de paquetes de terceros y no conseguí hacerlo funcionar correctamente.
• wsman Empaquetado y ajuste de librerias de wsman 2.6
  Existen algunos binarios del cliente de ws-manager wsman pero que tienen dependencias de librerías que ya no están disponibles en las versiones actuales de la paquetería Debian, como para mi el uso de este binario era quizás la opción más sencilla he optado por solventar los problemas de librerias del binario y generar un paquete .deb

Los programas wsman y wseventmgr los podeis instalar en vuestro Debian 13 si teneis configurado el repositorio de SoloConLinux simplemente ejecutando:

sudo apt update
sudo apt -y install wsmancli

Si deseasis decargar el paquete wsmancli.deb para instalarlo a mano mediante: sudo dpkg -i wsmancli.deb
Os dejo el enlace del paquete en el enlace:

Enable-PSRemoting -Force
Set-Item WSMan:\localhost\Service\Auth\Basic -Value $true
Set-Item WSMan:\localhost\Service\AllowUnencrypted -Value $true
Restart-Service WinRM

Ejecución de comandos en Windows desde Linux con wsman

Para la ejecución hay que ejecutarlo con la sintaxis propia de wsman, y ademas hay que encapsular los comandos a ejecutar y dejarlo en formato XML.

Os dejo dos ejemplos de comandos para que veais la sintaxis necesaria:

• comando.xml

<p:Create_INPUT xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process">
  <p:CommandLine>cmd.exe /c echo hola > C:\salida.txt</p:CommandLine>
</p:Create_INPUT>

• abrir_notepad.xml

<p:Create_INPUT xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process">
  <p:CommandLine>notepad.exe</p:CommandLine>
</p:Create_INPUT>

Para lanzar los comandos usaremos wsman:

wsman invoke http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process -a Create -h winpc -P 5985 -u guillermo -p ****** -y basic   -J comando.xml

Y obtendremos el siguiente resultado:

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:x="http://schemas.xmlsoap.org/ws/2004/09/transfer" xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd" xml:lang="en-US">
  <s:Header>
    <a:Action>http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process/CreateResponse</a:Action>
    <a:MessageID>uuid:052BAF01-65FC-45D0-83A1-467B3BA951CE</a:MessageID>
    <a:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:To>
    <a:RelatesTo>uuid:a2f7fea2-414a-114a-8002-06d11fb660a8</a:RelatesTo>
  </s:Header>
  <s:Body>
    <p:Create_OUTPUT xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process" xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common">
      <p:ProcessId>364</p:ProcessId>
      <p:ReturnValue>0</p:ReturnValue>
    </p:Create_OUTPUT>
  </s:Body>
</s:Envelope>

Nos fijamos en ProcessID se ha creado un nuevo proceso en Windows para ejecutar el comando y además obtenemos un ReturnValue con valor 0 que nos indica que ha finalizado correctamente.

Vamos al equipo Windows y vemos que se ha creado el fichero salida.txt correctamente:

Windows para Pruebas

En mi caso dado que no tengo ningun equipo con Windows, he tenido que usar Docker + KVM para poder iniciar un Windows usando https://github.com/dockur/windows
Todas las versiones de windows probadas son versiones Trial oficiales proporcionadas por Microsoft.

Además, para poder simular correctamente un PC con Windows y un Servidor Windows, he tenido que ampliar y ajustar los puertos necesarios para poder usar SSH y WinRM en ese contenedor.

Escucha de Eventos Windows

Además de wsman, si usas los binarios del paquete wsmancli tienes el programa wseventmgr que permite subscribirte via WS-Manager a los eventos de Windows.
Para obtener ayuda sobre todos los parametros necesarios para gestionar los eventos de windows ejecuta:

man wseventmgr

Tambien puedes usar wsman para realizar la subscripción, en este caso te recomiendo usar un XML para facilitar la ejecución.

• subscripcion.xml

<w:Subscribe xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">
  <w:Delivery Mode="Push">
    <w:NotifyTo>
      <a:Address>http://localhost:8080/receiver</a:Address>
    </w:NotifyTo>
  </w:Delivery>
  <w:Filter Dialect="http://schemas.microsoft.com/wbem/wsman/1/WQL">
    SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_Service'
  </w:Filter>
</w:Subscribe>

Y el comando a ejecutar en tu Linux sería:

wsman subscribe -h winpc -P 5985 -u guillermo -p ***** -y basic -J suscripcion.xml

Comandos WinRM con BashFlow

Como ya os he comentado sigo trabajando en BashFlow como herramienta de automatización que funciona unicamente mediante comandos bash.

Como demostración os muestro como se simplifica el uso de WinRM, el playbook es muy sencillo.

• winremote_exec_winrm.yaml

tasks:

  - name: Ejecutar comando remoto en Windows vía WinRM (WS-Manager)
    module: winremote_exec_winrm
    args:
      winuser: guillermo
      winpassword: "{{ clave_guillermo }}"
      command: "cmd.exe /c echo hola > C:\\salida.txt"

Simplemente debemos llamar a bashflow indicando el playbook con los comandos windows deseados, ya sean CMD o PowerShell.

BashFlow recorre el playbook, extrae la password de guillermo del Vault y la usa de forma transparente en la llamada. Además se encapsula el comando y se crea al vuelo en XML necesario para la ejecución facilitando el uso de WinRM desde Linux en procesos de automatización.

bashflow -f winremote_exec_winrm.yml -h winpc

Captura de la ejecución y la salida:

¡ Nos vemos en el próximo artículo !

La entrada us-east-1 se publicó primero en Linux Hispano.