Blog de FErArg

• SSL Warnings
• Certificate expired
• Insecure links
• Unknown Certificate Authority

Type on screen

thisisunsafe

Un ejemplo práctico Como exponen en el ejercicio, y que es un problema muy habitual en cualquier empresa, lidiar con la instalación de nuevo software, despliegue de actualizaciones del S.O. o de programas instalados, desinstalar software innecesario, configuraciones dispositivos, etc., son tareas que cualquier SysAdmin realiza a diario, por orden natural de las cosas, solemos automatizar estas tareas y nos esforzamos en que así sea, más aún si son procesos repetitivos, tediosos y plausibles de estandarización dentro de la organización. En este ejemplo los dispositivos corren S.O. Windows y se requiere automatizar el despliegue de actualizaciones del navegador Google Chrome, además de rastrear el estado de los mismos, (si el dispositivo se ha actualizado o no, estado de las configuraciones, etc). La propuesta del Departamento de I.T., es utilizar la plataforma Ansible, que permite automatizar procesos, despliegue de configuraciones, instalación de software y registro de los procesos, estados y cambios. ¿Pasos a seguir? En el Ordenador Cliente Se puede utilizar Ansible con clientes Windows, desde las versiones Windows 7 SP1, 8.1 y 10, además de las versiones para servidor 2008, 2008 R2, 2012, 2012 R2, 2016 y 2019 (7.i). Existen dos formas de conectar con ordenadores clientes Windows, una es utilizando el servicio WinRM(7.i.2) la otra es utilizando SSH(7.i.3), presente desde la versión 2.8 de Ansible, aún en fase de desarrollo. Explicaremos como utilizar Ansible con los servicios de WinRM para utilizarlo como canal de comunicación. Para poder validarnos el cliente Windows desde el servidor Ansible, podemos utilizar un certificado digital y crear o utilizar un usuario con permisos de administrador. Antes de configurar este servicio, hay que actualizar PowerShell a la versión 3.0 y debe estar instalado .NET 4.0 como versión mínima, para ello seguimos los siguientes pasos: Actualización de PowerShell 3.0, ejecutar el siguiente script PS:

$url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Upgrade-PowerShell.ps1"
$file = "$env:temp\Upgrade-PowerShell.ps1"
$username = "Administrador"
$password = "Cl@v3"

(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force

# Version can be 3.0, 4.0 or 5.1
&$file -Version 5.1 -Username $username -Password $password -Verbose

Una vez completado el proceso, se debe eliminar el “Auto Logon” y devolver a la configuración predeterminada las políticas de ejecución:

# This isn't needed but is a good security practice to complete
Set-ExecutionPolicy -ExecutionPolicy Restricted -Force

$reg_winlogon_path = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $reg_winlogon_path -Name AutoAdminLogon -Value 0
Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultUserName -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultPassword -ErrorAction SilentlyContinue

PowerShell v3.0 tiene un “error”, que limita la memoria disponible para los servicios WinRM, para solventar este inconveniente, ejecutamos el siguiente script:

$url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Install-WMF3Hotfix.ps1"
$file = "$env:temp\Install-WMF3Hotfix.ps1"

(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
powershell.exe -ExecutionPolicy ByPass -File $file -Verbose

Para configurar los servicios de WinRM, ejecutar el script de configuración “Configure a Windows host for remote management with Ansible” (7.i.6), con este script se configuran las opciones básicas del servicio para poder utilizar Ansible:

$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:temp\ConfigureRemotingForAnsible.ps1"

(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)

powershell.exe -ExecutionPolicy ByPass -File $file

El script PS de “Configure a Windows host for remote management with Ansible”(7.i.6), utilizado anteriormente configura el servicio en modo escucha, utilizando HTTPS, y crea el certificado autofirmado. Finalizadas estas configuraciones, en caso de no utilizar la validación de conexión utilizando un certificado digital, HTTP, se debe configurar un usuario con permisos de administrador o utilizar el usuario administrador, al que le asignamos una clave segura. Este usuario se declarará en el inventario de Ansible y lo utilizaremos para validarnos desde el servidor Ansible en el ordenador cliente(7.i.5). Si necesita personalizar la configuración de este servicio, puede encontrar información detallada en el manual de Ansible, apartado “WinRM Service Options”(7.i.4). Con el cliente configurado, ya podemos continuar con la configuración del servidor. En el Servidor Proceso inicial, instalar el servidor Ansible en un ordenador, que actuará como el servidor central para este sistema, como se especifica en los manuales del software el servidor necesariamente debe ser Linux(6). Instalado el server Ansible, creamos el primer “inventario” de ordenadores a controlar remotamente, el inventario es un archivo de texto donde “agrupar” los ordenadores a gestionar. Ejemplo de inventario: (YAML)

all:
contabilidad:
mariajose:
ansible_port: 5555
ansible_host: 192.1.2.50
antonio:
ansible_port: 5554
ansible_host: 192.1.2.51
[win:vars]
ansible_user=Administrador
ansible_password=Cl@v3
ansible_connection=winrm
ansible_winrm_server_cert_validation=ignore

Guardamos este inventario en el directorio “inventory” de ansible con nombre “contabilidad.yml”. Con el inventario configurado, se puede probar Ansible, ejecutando una tarea que no necesita aún configuración en el ordenador cliente, enviar un ping para comprobar que equipos están activos:

Comando:
ansible -i contabilidad.yml -m win_ping

Obteniendo como respuesta:
192.1.2.50 | SUCCES =>{
“changed”: false,
“ping”: “pong”
}
192.1.2.51 | SUCCES =>{
“changed”: false,
“ping”: “pong”
}

Configuración del PlayBook Para automatizar la instalación de actualizaciones de Google Chrome, se debe configurar un “Playbook”. Los Playbooks son el lenguaje de configuración, despliegue y orquestación de Ansible, donde se describen los procesos que se deben aplicar en los dispositivos remotos. Para poder gestionar ordenadores con S.O. Windows e instalar software, es necesario instalar el módulo de “win_package” o el módulo «win_chocolatey” en el servidor Ansible, en el ejemplo utilizaremos el primer módulo. Ejemplo de Playbook para la Instalación o actualización de Google Chrome en ordenadores con S.O. Windows:

- name: Descargar Google Chrome Bundle
win_get_url:
url:https://dl.google.com/tag/s/appguid%3D%7B8A69D345-D564-463C-AFF1-A69D9E530F96%7D%26iid%3D%7B6D39DF7E-589D-764C-E9BE-93376AB1B6E1%7D%26lang%3Den%26browser%3D3%26usagestats%3D0%26appname%3DGoogle%2520Chrome%26needsadmin%3Dtrue%26ap%3Dx64-stable-statsdef_0%26brand%3DGCEB/dl/chrome/install/GoogleChromeEnterpriseBundle64.zip
dest: C:\\Temp\\GoogleChromeEnterpriseBundle64.zip

- name: Extract the bundle
win_unzip:
src: c:\\Temp\\GoogleChromeEnterpriseBundle64.zip
dest: C:\\Temp\\Chrome

- name: Install Chrome
win_package:
path: C:\\Temp\\Chrome\\Installers\\GoogleChromeStandaloneEnterprise64.msi
wait: yes
state: present
when: ACTION == "Install"

- name: Uninstall Chrome
win_package:
path: C:\\Temp\\Chrome\\Installers\\GoogleChromeStandaloneEnterprise64.msi
wait: yes
state: absent
when: ACTION == "Uninstall"

- name: Clean up the bundle.zip
win_file:
path: C:\\Temp\\GoogleChromeEnterpriseBundle64.zip
state: absent

- name: Clean up the bundle
win_file:
path: C:\\Temp\\Chrome
state: absent

Guardamos el nuevo playbook con el nombre “win_google_chrome.yaml”. Los ordenadores en los que hay que instalar o actualizar el navegador de Google, son los ordenadores del departamento de Contabilidad, que detallamos en el inventario anteriormente, para ello ejecutamos siguiente comando:

ansible-playbook win_google_chrome.yaml -i contabilidad.yml -e ACTION=Install

En pantalla podremos observar el estado de los procesos y comprobar el resultado de la instalación correcta o errores. Estos procesos puede configurarse para ser ejecutados cada cierto tiempo, comprobar la versión del software se encuentra instalada y no proceder a la actualización, etc. Registro de procesos Para llevar un registro centralizado del estado de estas acciones de instalación y actualización por medio de Ansible, existen varios métodos, el más simple es utilizar los logs de Ansible, habilitando el registro de sucesos en archivo de configuración de Ansible(7.k), otra posibilidad es utilizar los denominados “callback plugins”(7.l), como explica la web de los mismo: “Estos plugins añaden nuevos comportamientos a Ansible, estos controlan la mayor parte de la salida que se ven cuando se ejecutan los programas, pero también se pueden utilizar para añadir salida adicional, integrarse con otras herramientas y ordenar los eventos.” Junto con estos plugins de consola, contamos con el proyecto “ARA”(4), que de forma sencilla y visual nos permitirá comprobar el estado de los playbooks ejecutados. Visualizando los Estados de los Playbooks con ARA El “Ansible Run Analysis”(4) proporciona la visualización detallada en un navegador del estado de la ejecución de los playbook, incluyendo(4.c): • Descripción de tareas, estado y salida • Descripción y duración de la ejecución • Ordenadores involucrados • Archivos ejecutados • Parámetros utilizados • etc. La instalación de ARA es bastante simple, el manual de instalación de la aplicación, en la web del proyecto, explica paso a paso como instalar(4.e) y configurar(4.f) este servicio complementario de Ansible.     Enlaces

1. Comparativas Ansible vs Otros sistemas de Automatización
   1. https://www.intigua.com/blog/puppet-vs.-chef-vs.-ansible-vs.-saltstack
   2. https://www.edureka.co/blog/chef-vs-puppet-vs-ansible-vs-saltstack/
2. Continuous Delivery
   1. https://docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.html
3. Ansible Galaxy
   1. https://galaxy.ansible.com/
4. Ansible Run Analysis
   1. https://github.com/ansible-community/ara
   2. Demo: https://web.demo.recordsansible.org/playbooks
   3. https://sebiwi.github.io/blog/ara/
   4. https://dzone.com/articles/ansible-run-analysis
   5. https://ara.readthedocs.io/en/latest/installation.html
   6. https://ara.readthedocs.io/en/latest/ansible-configuration.html#configuring-ansible-to-use-ara
   7. https://ara.readthedocs.io/en/latest/ansible-role-ara-web.html#ansible-role-ara-web
   8. https://ara.readthedocs.io/en/latest/ansible-role-ara-api.html#ansible-role-ara-api
5. Ansible Tower
   1. https://www.ansible.com/products/tower
   2. https://www.upguard.com/articles/ansible-vs.-ansible-tower
   3. https://www.ansible.com/products/tower/editions
6. Control Node requeriments
   1. https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#control-node-requirements
7. Documentación utilizada para este ejercicio
   1. https://docs.ansible.com/ansible/latest/modules/net_ping_module.html
   2. https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html
   3. https://docs.ansible.com/ansible/latest/user_guide/playbooks.html
   4. https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html
   5. https://docs.ansible.com/ansible/latest/modules/win_package_module.html
   6. https://github.com/r3ap3rpy/ansibler/blob/master/test_win_chrome_deploy.yaml
   7. https://docs.ansible.com/ansible/latest/user_guide/windows_usage.html
   8. https://www.ansible.com/integrations/infrastructure/windows
   9. https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html
      1. https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html#upgrading-powershell-and-net-framework
      2. https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html#winrm-setup
      3. https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html#windows-ssh-setup
      4. https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html#winrm-service-options
      5. https://www.ansible.com/blog/connecting-to-a-windows-host
      6. https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
   10. https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH
       1. https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html#win32-openssh-authentication
   11. https://github.com/ansible/ansible/blob/devel/examples/ansible.cfg
   12. https://docs.ansible.com/ansible/latest/plugins/callback.html
8. Comunidad Ansible – https://www.ansible.com/community

Bibliografía Consultada

1. Ansible Best Practises : The essential
2. Ansible Up & Runing
3. Ansible for DevOps

Estamos desarrollando un proyecto que utilizará mini y micro ordenadores, y para prototipar la instalación utilizamos RaspberryPi 3 modelo B+, que lleva un microprocesador Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC @ 1.4GHz. Como sistema de base de datos nos decantamos por CouchDB, por lo siguiente:

• Reducido tamaño en disco
• Utiliza pocos recursos
• Utiliza JSON
• Utiliza RestAPI
• Tiene función de Notificaciones (eventing)
• y un largo etc …

El inconveniente es que no hay paquete para microprocesadores ARM en los repositorios de Debian, y nos recomiendan la instalación desde el código fuente. El HowTo de la web de CouchDB, aunque completo y detallado, tiene algunos fallos con la instalación en Raspbian. Encontramos varios manuales de instalación, pero eran incompleto, o no eran compatibles con la instalación en el Raspbian. Como instalar CouchDB desde el código fuente en Raspbian de 64bits en RapsberryPi 3 modelo B+

• Actualizar el sistema operativo

  apt-get update && apt-get -y dist-upgrade

• Instalar los paquetes necesarios para poder compilar CouchDB

  apt-get --no-install-recommends -y install build-essential pkg-config erlang erlang-nox erlang-dev erlang-reltool libicu-dev libmozjs185-dev libcurl4-openssl-dev libicu-dev libmozjs185-1.0 libmozjs185-dev curl

• Descargar CouchDB, descomprimir y compilar

  wget http://apache.rediris.es/couchdb/source/2.3.0/apache-couchdb-2.3.0.tar.gz
  tar xvzf apache-couchdb-2.3.0.tar.gz
  cd apache-couchdb-2.3.0
  ./configure
  make
  make release

• CouchDB utilizará el usuario «couchdb» para ejecutar el servicio, por ello creamos el usuario

  adduser --systcode --shell /bin/bash --group --gecos "CouchDB Administrator" couchdb

• Copiar el contenido del directorio «rel» de CouchDB, que se ha compilado en uno de los pasos anteriores, y cambiar los permisos del home del usuario «couchdb»

  cp -r rel/couchdb/* /home/couchdb/
  chown -R couchdb:couchdb /home/couchdb
  find /home/couchdb -type d -exec chmod 0770 {} \;
  chmod 0644 /home/couchdb/etc/*

• Para probar la instalación, ejecutar manualmente el servicio

  sudo -i -u couchdb /home/couchdb/bin/couchdb

• Ejecutar los siguientes comandos para finalizar la configuración del servicios

  curl -X PUT http://127.0.0.1:5984/_users
  curl -X PUT http://127.0.0.1:5984/_replicator
  curl -X PUT http://127.0.0.1:5984/_global_changes

• Para probar el correcto funcionamiento de CouchDB, ejecutamos

  curl http://127.0.0.1:5984

• Nos debe dar como respuesta algo parecido a lo siguiente

  {"couchdb":"Welcome","version":"2.3.0","git_sha":"07ea0c7","uuid":"a4c3673efdde48d8d301fff79cfd92ff","features":["pluggable-storage-engines","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

Si necesitamos que CouchDB se inicie al encender el ordenador, debemos seguir estos pasos extras

• Crear el archivo «couchdb.service» para iniciar el servicio por SystemD

  nano /etc/systemd/system/couchdb.service

• Agregar el siguiente contenido

  [Unit]
  Description=Couchdb service
  After=network.target
  
  [Service]
  Type=simple
  User=couchdb
  ExecStart=/home/couchdb/bin/couchdb -o /dev/stdout -e /dev/stderr
  Restart=always

• Ahora podremos utilizar los siguientes comandos

  systemctl start couchdb.service - Para iniciar el servicio

  systemctl stop couchdb.service - Para detener el servicio

  systemctl restart couchdb.service - Para re-iniciar el servicio

  systemctl status couchdb.service - Para comprobar el estado del servicio

Si es necesario acceder desde un ordenador remoto al servidor CouchDB

• Modificar el archivo «default.ini»

  nano /home/couchdb/etc/default.ini

• Modificar la línea

  bind_address = 127.0.0.1

• reemplazar por la siguiente línea, para permitir el acceso desde cualquier otro dispositivo de la red

  bind_address = 0.0.0.0

• Reiniciar el servicio

  systemctl restart couchdb.service

• desde un ordenador remoto ejecutar

  curl http://IP_Servido_CouchDB:5984

• Nos debe dar como respuesta algo parecido a lo siguiente

  {"couchdb":"Welcome","version":"2.3.0","git_sha":"07ea0c7","uuid":"a4c3673efdde48d8d301fff79cfd92ff","features":["pluggable-storage-engines","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

Ayudas que utilizamos

• https://docs.couchdb.org/en/master/install/unix.html#installation-from-source
• http://docs.couchdb.org/en/stable/install/unix.html#debian-based-systems
• http://guide.couchdb.org/draft/source.html
• http://guide.couchdb.org/draft/tour.html
• https://stackoverflow.com/questions/49037016/access-couchdb-from-another-pc
• https://github.com/apache/couchdb/issues/1103
• https://serverfault.com/questions/700862/do-systemd-unit-files-have-to-be-reloaded-when-modified/700956
• https://www.jamescoyle.net/how-to/2527-add-systemd-startup-script-for-couchdb
• https://askubuntu.com/questions/676007/how-do-i-make-my-systemd-service-run-via-specific-user-and-start-on-boot
• https://stackoverflow.com/questions/21785027/couchdb-ip-address-and-port

   

Uno de nuestros clientes tiene instaladas varias máquinas virtuales en un Debian 9.0, la versión de VirtualBox instalada desde los repositorios era la 5.1 (5.1.38-122592).

Al intentar actualizar a la nueva versión de VirtualBox, (5.2.18 r124318), nos encontramos con el siguiente error:

"Running VMs found VirtualBox is currently running. Please close it and try again. Please note that it can take up to ten seconds for VirtualBox (in particular the VBoxSVC daemon) to finish running."

Este error nos informa que VirtualBox está funcionando o que una máquina virtual está corriendo en el ordenador.

Para comprobar que alguna está ejecutando, podemos listar las máquinas virtuales ejecutadas:

$ VBoxManage list runningvms

Si no existe ninguna VM funcionando, debemos ejecutar el siguiente comando para comprobar que el servicio «VBoxSVC» no esté funcionando:

$ pidof VBoxSVC

Si este comando da como respuesta el número de proceso, (PID), del servicio debemos detenerlo, utilizando este número y ejecutando el comando kill «matamos» el proceso:

$ kill -9 númeroProceso

Una vez el proceso haya muerto, volvemos a intentar la actualización de VirtualBox a su versión 5.2 o posterior.

Mas Información:

1. How to list all VirtualBox available virtual machines from command line

2. Removing Virtualbox-5.1 in a stuck state