Planeta Sysadmin

de sysadmins para sysadmins

February 13, 2019

Sobre bits

Primeros pasos con PowerShell para Google Cloud Platform

Cuando alguien me pregunta si realmente merece la pena aprender a manejarse con PowerShell siempre uso como uno de los argumentos a favor el gran apoyo de los fabricantes sobre éste. Compañías como VMware, Veeam, Amazon o Google (además de la propia Microsoft) han creado módulos oficiales con los que administrar sus productos. En la entrada de hoy vamos a ver cómo empezar a utilizar PowerShell para Google Cloud Platform, la plataforma de cloud público de Google.

Primeros pasos con PowerShell para Google Cloud Platform

Un vistazo al módulo de PowerShell para Google Cloud

Las Cloud Tools for PowerShell, que es el nombre que da Google a su módulo, nos van a permitir interactuar con la sintaxis habitual de PowerShell y usar todas sus bondades directamente contra los servicios y recursos de nuestra cuenta de Google Cloud Platform.

Si bien no todos los productos de Google Cloud Platform están cubiertos en su módulo de PowerShell a fecha de hoy, podemos ver que existen cmdlets para una buena cantidad de ellos:

A fecha de hoy ésto supone una nada despreciable cifra de 144 cmdlets disponibles una vez hayamos instalado su módulo, que es lo que vamos a hacer a continuación.

Cómo instalar el módulo de PowerShell para Google Cloud

Para obtener éste módulo de PowerShell tenemos dos opciones:

  • Instalar el módulo mediante Install-Module y luego instalar el SDK de Google.
  • Instalar directamente el SDK de Google que también nos instalará el módulo de PowerShell.

Para esta entrada vamos a ir con la segunda opción, por lo que podemos dirigirnos a la página de descarga del SDK de Google para Windows y descargaremos y ejecutaremos el instalador.

La instalación básicamente es un siguiente > siguiente > siguiente, pero debemos fijarnos en que en la pantalla para elegir componentes tengamos marcado Cloud Tools for PowerShell:

PowerShell para Google Cloud

Y en la pantalla final también nos aseguraremos de dejar marcado Run ‘cloud init’ to configure the Cloud SDK para configurar nuestra conexión a Google Cloud Platform una vez finalice el asistente.

Iniciar gcloud init tras instalacion

Tras pulsar en Finish se iniciará gcloud init, el cuál nos preguntará si queremos logear en nuestra cuenta. Evidentemente introduciremos Y para logear:

Tras ésto se abrirá una nueva pestaña en nuestro navegador por defecto en la que deberemos logear con nuestra cuenta de Google y permitir el acceso que se nos solicita.

Una vez hecho deberemos volver de nuevo a nuestra pantalla de gcloud init en la que deberemos indicar:

  • Proyecto a utilizar.
  • Zona por defecto.

Y tras finalizar la configuración deberíamos recibir un mensaje indicando que la instalación de Google Cloud SDK se ha completado con éxito:

Your Google Cloud SDK is configured and ready to use!

Trasteando con el módulo de PowerShell para Google Cloud Platform

Ahora que ya lo tenemos todo listo podemos empezar a cacharrear con nuestros nuevos cmdlets. Si queremos ver una lista completa de los cmdlets disponibles podemos ejecutar:

Get-Command -Module GoogleCloud

Si queremos ver el detalle de la funcionalidad de algún cmdlet podemos acudir a la referencia del módulo o bien ejecutar Get-Help sobre alguno de ellos.

A partir de aquí toca trastear el módulo. Algo que podríamos querer hacer sería programar un backup de algún archivo o carpeta hacia nuestro Google Cloud Storage. El procedimiento para ello sería sencillísimo.

Primero creamos el bucket donde guardaremos nuestro backup con New-GcsBucket:

 
New-GcsBucket -Name "sobrebits" -StorageClass COLDLINE 

Name        TimeCreated         Updated 
----        -----------         ------- 
sobrebits   10/02/2019 21:34:30 10/02/2019 21:34:30 

Con -Name le damos nombre al bucket y con -StorageClass seleccionamos el tipo de almacenamiento del bucket.

Y posteriormente creamos un nuevo objeto en nuestro bucket con New-GcsObject utilizando el que queremos copiar:

 
New-GcsObject -Bucket sobrebits -File C:\Scripts\Archivo_para_backup.txt -ObjectName "Archivo_par a_backup$((Get-Date).Day)" 

Name                      Size ContentType TimeCreated         Updated 
----                      ---- ----------- -----------         ------- 
Archivo_para_backup10     0    text/plain  10/02/2019 21:44:12 10/02/2019 21:44:12 

Con -Bucket indicamos el bucket creado en el paso anterior, con -File el archivo que utilizaremos para nuestro nuevo objeto y con -ObjectName el nombre que le daremos al objeto en destino añadiendo el día del mes con Get-Date.

Con esto lo último que nos faltaría sería programar una tarea de PowerShell que ejecutara esta última línea cada día y ya tendríamos nuestro backup externalizado a GCP con PowerShell en 2 minutos.

Conclusión

Y hasta aquí esta entrada introductoria sobre PowerShell para Google Cloud Platform. En próximas entradas nos centraremos en algunos de los productos de GCP para ver qué somos capaces de hacer con PowerShell y qué posibilidades de automatización tenemos con éste módulo.

¡Os espero en la próxima!

La entrada Primeros pasos con PowerShell para Google Cloud Platform aparece primero en Sobrebits.

by Marc Meseguer at February 13, 2019 01:30 PM

February 10, 2019

RooTeando

Entrevista En Diferido 3: Pedro, alias Mosquetero Web.

Hoy empezamos la tercera entrevista en @EntrevistaEnDiferido a Pedro, alias Mosquetero Web, podcaster  youtuber,usuario de Linux y Chromebook, profesor y mucho mas.

 

Entrevista En Diferido. Buenas Pedro,la primera pregunta sería una pequeña presentación por parte del entrevistado para que los lectores puedan conocerte un poco. 

¿Te podrías presentar en unas líneas?

 

Pedro.  Hola, soy Pedro Mosqueteroweb quiero dar las gracias a Jose por contar conmigo y desearle mucho éxito ...

February 10, 2019 09:55 PM

February 08, 2019

RooTeando

Tomando Un Café 51: Probando Linux, cambiando mentalidad

Nuevo audio con una reflexión sobre como probar Linux pero desde un punto de vista mas filosófico, el  cambio de mentalidad que requiere y el proceso de adptación que requiere para entender Linux para poder utilizarlo correctamente.

Música: Chad Crouch- Western Tanager- Bird Watching: Piano Preludes.
 

Canales de Telegram @UnDiaUnaAplicacion @UnPythonAldia @AprendePython
Podcast @RadioDev  @ARMparaTODOS @RadioDev

Grupos de Telegram
Alternativas a la Raspberry
https://t.me/AlternativasRaspberry

Twitter 
Podcast
https://twitter.com ...

February 08, 2019 11:48 PM

February 06, 2019

Sobre bits

Migrar VMs de datastore masivamente con PowerCLI

Recientemente por un renovación de storage en una infraestructura VMware tuvimos que migrar de forma masiva un gran número de máquinas virtuales desde una LUN del storage antiguo a varias del nuevo. Dado que era una gran cantidad de VMs todas ellas productivas queríamos hacer el cambio con el menor impacto posible, por lo que me decidí a crear este pequeño script con el que migrar vms de datastore masivamente con PowerCLI de forma secuencial.

Migrar VMs de datastore masivamente con PowerCLI

Requisitos del script

Como apuntaba en la introducción ante todo requeríamos que el rendimiento de las máquinas virtuales del entorno se viera afectado lo mínimo posible y, evidentemente, que no tuvieramos problemas de espacio en ninguna LUN ni nada por el estilo. Es por ello que el script dispone de esta “funcionalidad”:

  • Migración de VMs de forma secuencial: Para evitar posibles problemas en la red o en el rendimiento de las cabinas de origen y destino el script migra VMs una a una. La migración de la siguiente máquina virtual no empieza hasta que la anterior finaliza.
  • Balanceo de máquinas virtuales entre las LUNs destino: Dado que teníamos más de una LUN de destino en la que poner las máquinas virtuales el script migra siempre la VM hacia el datastore más vacío (también funciona con una sola LUN destino).
  • Revisión del espacio libre en las LUNs destino: Evidentemente lo que nunca puede pasar es que el datastore destino se quede sin espacio. Es por ello que antes de iniciar una migración se comprueba que existe espacio en la LUN (contando con una reserva del 10% de espacio libre) y de no haberlo se para el script con un error.

Script para migrar VMs de datastore masivamente con PowerCLI

Ahora que ya está claro lo que obligatoriamente debía hacer el script vamos a ver el código:

############### CONFIGURACION ###############
# Obtenemos la lista de VMs
$Vms = Get-Content C:\Scripts\VMs.txt

# Definimos los datastores de destino
$DestinationDatastores = 'New_Datastore1','New_Datastore2'
#############################################

# Recorremos las VMs
ForEach ($Vm in $Vms) {
    # Determinamos el datastore menos ocupado
    $DestinationDatastore = Get-Datastore -Name $DestinationDatastores | Sort-Object -Property FreeSpaceGB -Descending | Select-Object -First 1

    # Calculamos el 10% del datastore como reserva
    $WarningSpace = $DestinationDatastore.CapacityGB * 0.10

    # Comprobamos que exista espacio en el datastore de destino
    if ((Get-VM $Vm).UsedSpaceGB -gt ($DestinationDatastore.FreeSpaceGB - $WarningSpace)) {
        Write-Error -Message "Espacio disponible insuficiente para mover $Vm a $($DestinationDatastore.Name)" -ErrorAction Stop
    }

    # Movemos la VM
    Get-VM $Vm | Move-VM -Datastore $DestinationDatastore -RunAsync

    # Esperamos a que haya finalizado el movimiento
    Do {
        Start-Sleep -Seconds 30
    }
    While ($(Get-VM -Name $Vm | Get-Datastore | Select-Object -ExpandProperty Name) -notcontains $DestinationDatastore.Name)
}

Como veis tampoco es un script muy extenso, vamos a ver el detalle de lo que hace:

  • 3: Obtenemos el listado de VMs a migrar de un archivo .txt con un nombre de VM por línea. (Podemos extraerlas con Get-VM)
  • 6: Declaramos los datastores en los que alojaremos las máquinas virtuales migradas.
  • 10-30: Recorremos las VMs del archivo una a una.
    • 12: Seleccionamos el datastore menos ocupado.
    • 15: Calculamos el 10% del tamaño total del datastore.
    • 18-19: Comprobamos que exista espacio en el datastore y de no haberlo lanzamos error y finalizamos el script.
    • 23: Migramos la VM de datastore.
    • 26-29: Esperamos hasta que la máquina virtual se haya migrado al datastore de destino.

Conclusión

Y hasta aquí la entrada de hoy, si como yo os enfrentáis en el futuro a una migración de cabina dadle una oportunidad al script o adaptadlo a vuestro gusto, os puede ahorrar mucho tiempo mirando como la barrita de progreso va avanzando :-).

¡Hasta la próxima!

La entrada Migrar VMs de datastore masivamente con PowerCLI aparece primero en Sobrebits.

by Marc Meseguer at February 06, 2019 12:34 PM

RooTeando

Tomando Un Café 50: Opiniones

Nuevo audio con una reflexión sobre las opiniones sin conocimiento, cuando alguién opina sobre un tema sin haberse informado o utilizado previamente. Todo esto me ha surgido después de escuchar el último audios de podcast PodcastInside.
 

Podcast Inside https://tupodcast.com/podcastinside/
Blog https://www.systeminside.net/

 

Canales de Telegram @UnDiaUnaAplicacion @UnPythonAldia @AprendePython
Podcast @RadioDev  @ARMparaTODOS @RadioDev

Grupos de Telegram
Alternativas a la Raspberry
https://t.me/AlternativasRaspberry

Twitter 
Podcast
https ...

February 06, 2019 11:00 AM

January 30, 2019

Sobre bits

PSRemoting (Parte 3): Cómo utilizar PowerShell Remoting

Ahora que tenemos claro qué es PowerShell Remoting y cómo habilitarlo es hora de pasar a la acción. En la entrada de hoy veremos las distintas formas de utilizar PowerShell Remoting para poder sacar el máximo partido a esta tecnología.

Aquí tenéis el índice de la serie:

Cómo utilizar PowerShell Remoting

PowerShell Remoting de forma interactiva con Enter-PSSession

Como decía en la introducción de la entrada, existen distintas formas de utilizar PowerShell Remoting. La primera que veremos será la sesión interactiva, cuya funcionalidad gira entorno al cmdlet Enter-PSSession.

¿Qué es el modo interactivo de PowerShell Remoting?

Podemos pensar en el modo interactivo de PowerShell Remoting como en el Telnet o SSH de PowerShell. Cuando iniciamos una sesión interactiva de PSRemoting contra una máquina remota obtenemos una sesión de PowerShell que a todos los efectos es como si la ejecutáramos en dicha máquina. Los comandos ejecutados durante una sesión interactiva se ejecutarán en la máquina remota y serán mostrados en nuestra consola de PowerShell.

Cuando utilizamos Enter-PSSession debemos tener ciertas cosas en consideración:

  • Como hemos indicado anteriormente, los comandos se ejecutan en la máquina remota.
  • Por lo indicado en el punto anterior los módulos de PowerShell que queramos utilizar deberán existir en la máquina destino, así como variables de entorno, archivos y cualquier cosa que invoquemos desde la sesión remota.
  • Sólo se puede ejecutar una sesión remota a la vez en una misma consola de PowerShell.
  • Cuando iniciamos la conexión no se utiliza ningún perfil de PowerShell.
  • No se puede hacer una nueva sesión remota desde una ya existente.
Cómo utilizar PowerShell Remoting de forma interactiva

Utilizar PowerShell Remoting de forma interactiva es muy sencillo. Si PSRemoting está habilitado lo único que deberemos hacer es ejecutar:

# En un entorno de dominio no requeriremos introducir credenciales si estamos logeados con un usuario con permisos de administrador en la máquina destino:
Enter-PSSession -ComputerName DC01
# De no ser así podemos aportar las credenciales:
$Creds = Get-Credential
Enter-PSSession -ComputerName DC01 -Credential $Creds

Una vez estemos logeados en la máquina remota deberíamos ver algo parecido a esto:

Sesión PSRemoting con Enter-PSSession

Como podemos ver el principio de nuestro prompt ha cambiado y ahora podemos ver el nombre de la máquina seguido de dos puntos ([DC01]:), lo que nos ayudará a distinguir la máquina en la que vamos a ejecutar nuestros comandos.

Si queremos comprobar que realmente estamos en la máquina remota podemos ejecutar hostname:

Hostname en Enter-PSSession

A partir de aquí somos libres de ejecutar las acciones que requiramos y cuando queramos salir únicamente deberemos ejecutar exit para volver a nuestra sesión local.

Ejecutar comandos remotos con PowerShell Remoting

Otra forma de ejecutar PowerShell Remoting es mediante la ejecución remota de comandos, que como veremos a continuación desbloquea algunas opciones interesantes para nuestras automatizaciones.

¿En qué consiste la ejecución remota de comandos con PowerShell Remoting?

La ejecución remota de comandos con PowerShell Remoting consiste en mandar uno o más comando para ser ejecutados en la máquina remota. La diferencia fundamental con la sesión interactiva es que después de la ejecución de nuestros comandos se nos devuelve el control del prompt en nuestra máquina local.

Los puntos a tener en cuenta en este modo son los mismos que en la sesión interactiva. Este tipo de ejecución, en contra de lo que ocurre en la sesión interactiva, nos va a permitir ejecutar comandos remotos a múltiples máquinas a la vez de forma paralela.

Ejecutar comandos remotos de PowerShell Remoting contra una sola máquina (1:1)

Para ejecutar comandos de forma remota utilizando PowerShell Remoting utilizaremos Invoke-Command.

Hay distintas formas de pasar los comandos a nuestra máquina remota. Para empezar podemos utiliza el parámetro -ScriptBlock, con el que enviaremos los comandos directamente desde Invoke-Command:

Invoke-Command con ScriptBlock

Aquí podemos ver un par de cosas interesantes:

  • El contenido de -ScriptBlock debe ir entre {} y tenemos total libertad para escribir las órdenes que deseemos.
  • La salida del ScriptBlock es la misma que si lo ejecutáramos en local con la diferencia de que se añade una propiedad PSComputerName que indica la máquina en la que se ha ejecutado el ScriptBlock.

En el caso de que queramos enviar órdenes complejas es posible que escribir todo dentro del ScriptBlock resulte poco usable. Es por ello que podemos valernos de -FilePath, un parámetro que nos permitirá pasarle un archivo .ps1 con el script a ejecutar de forma remota.

Invoke-Command con FilePath

Como podemos ver la salida es la misma, pero no hemos tenido que escribir los comandos dentro de Invoke-Command.

Ejecutar comandos remotos de PowerShell Remoting contra múltiples máquinas (1:N)

Donde Invoke-Command alcanza todo su potencial es en la ejecución contra múltiples máquinas a la vez. Invoke-Command nos permite reducir tareas que implicarían horas a unos pocos segundos gracias a su ejecución masiva.

Si queremos ejecutar una tarea contra múltiples máquinas a la vez únicamente deberemos facilitar un parámetro -ComputerName con los nombres de todas las máquinas contra las que ejecutar nuestros comandos:

Invoke-Command multiples destinos

En este caso coge más sentido la propiedad PSComputerName, que nos permitirá diferenciar a qué máquina corresponde cada línea. Aquí podemos ver que DC01 tiene más shares que SRV01 puesto que se trata de un DC.

Algo interesante de Invoke-Command es que por defecto nos permite la ejecución en paralelo en todas las máquinas que facilitemos. Esto se resume en tiempos mucho más cortos a la hora de ejecutar tareas de forma masiva. Veamos un ejemplo en el que ejecutamos Get-Process en nuestras dos máquinas:

Invoke-Command multiples destinos tiempos

Como podemos ver por los tiempos de respuesta, cuando ejecutamos Get-Process sobre las máquinas individuales tardamos unos 7-10 segundos en obtener la respuesta. Al lanzarlo sobre ambas máquinas a la vez el comando se ejecuta en el mismo tiempo. Evidentemente esta ganancia de tiempo será cada vez mayor conforme aumentemos el número de máquinas a procesar.

Estos tiempos pueden variar según la carga de los servidores y de la latencia de la red, pero nos ayudan a darnos cuenta de la ejecución paralelizada de Invoke-Command.

Conclusión

Hasta aquí esta nueva entrega sobre PowerShell Remoting. Os recomiendo que introduzcáis ésta tecnología en vuestras automatizaciones ya que os harán la vida mucho más facil y os ahorrará una cantidad de tiempo brutal.

¡Nos vemos en la próxima!


La entrada PSRemoting (Parte 3): Cómo utilizar PowerShell Remoting aparece primero en Sobrebits.

by Marc Meseguer at January 30, 2019 01:04 PM

January 28, 2019

RooTeando

Entrevista en Diferido 02: Joseda

Comenzamos la segunda entrevista del canal de Telegram @EntrevistaEnDiferido, donde se realiza una entrevista a lo largo de una semana.

El entrevistado es mi ccompañero del podcast @RadioDev  , Joseda, desarrollador web. 

Entrevista En Diferido.  Buenas Joseda,  ,la primera pregunta sería una presentación por parte del entrevistado para que los lectores puedan conocerte un poco. 

¿Te podrías presentar en unas líneas?

Joseda. Hola Jose, antes que nada, encantado de estar ...

January 28, 2019 06:41 AM

Tomando Un Café 49: Charla con Lorenzo (alias atareao)

 

Audio nuevo con invitado, una charla muy amena con Lorenzo, del blog y podcast atareao, donde hablamos de muchos ; comunidades, documentación y fragmentación en Linux, programación, git, Django, Flask, podcast y mas temas.  

Canales de Telegram @UnDiaUnaAplicacion @UnPythonAldia @AprendePython
Podcast @RadioDev  @ARMparaTODOS @RadioDev

Grupos de Telegram
Alternativas a la Raspberry
https://t.me/AlternativasRaspberry

Twitter 
Podcast
https://twitter.com/Tomando_Un_Cafe
https://twitter.com/RadioDevPodcast

Canales de Telegram
Un Día Una Aplicación ...

January 28, 2019 06:39 AM

January 23, 2019

debianhackers.net

DataDetox: controla tu presencia on-line

De la mano del Tactical Technology Collective y la Fundación Mozilla llega esta fantástica iniciativa que busca concienciar sobre privacidad on-line. Decenas de aplicaciones y sitios web rastrean a diario nuestra actividad, preferencias de navegación y gustos en busca de un trocito del suculento pastel del Big Data.

¿Conoces tu huella digital? ¿Qué saben las redes de ti? ¿Y qué sabes tú de lo que las redes hacen con tus datos?

DataDetox nos invita a indagar en nuestra huella digital, descubrir cual es nuestra identidad on-line y prevenir la fuga masiva de datos a la que estamos expuestos.

8 días, menos de media hora al día ¿te atreves?

Ahí va el programa:

Día 0.- ¿Por qué Detox? Nos vamos preparando.

Día 1.- Descubrir. ¿Quién eres según otras personas?

Día 2.- Todo en un mismo lugar. ¿Cuánto te conoce Google?

Día 3.- Ser sociable. Desintoxicando tus cuentas en redes sociales.

Día 4.- Buscar&navegar. ¿Qué estás compartiendo a través de tu navegador?

Día 5.- Conectando. ¿Con quién habla tu móvil?

Día 6.- Limpieza. Hora de limpiar nuestras aplicaciones.

Día 7.- ¿Quién crees que eres? Porqué crear perfiles no se trata simplemente de mostrarte anuncios.

Día 8.- Creando un nuevo yo. Convierte tu “data detox” en un nuevo estilo de vida.

by Debish at January 23, 2019 05:00 PM

January 17, 2019

Sobre bits

Corregir VMs con Sistema Operativo invitado mal configurado con PowerCLI

Un error común que podemos encontrarnos en infraestructuras vSphere es el de tener máquinas virtuales cuya versión de Sistema Operativo difiere entre la configurada en ESXi/vCenter y la del SO instalado en la máquina virtual en si. Ésto puede ocurrir en el caso de que se actualice el sistema operativo de la máquina virtual o simplemente por una mala configuración inicial. En la entrada de hoy veremos cómo detectar y corregir VMs con el Sistema Operativo invitado mal configurado con PowerCLI para asegurarnos de tener el mínimo de parada de servicio en el proceso.

Corregir VMs con Sistema Operativo invitado mal configurado con PowerCLI

Cómo detectar éstas Máquinas Virtuales

El primer paso para acabar con este problema de configuración será detectar exáctamente qué máquinas virtuales están afectadas. Hacerlo máquina por máquina si disponemos de muchas puede ser un proceso tedioso, pero la buena noticia es que con PowerCLI podemos listarlas todas con un solo one-liner (aunque un poco largo):

Get-VM | Where-Object {$_.ExtensionData.Config.GuestFullName -ne $_.ExtensionData.Guest.GuestFullName -and $_.ExtensionData.Guest.GuestFullName -ne $null} | Select-Object Name,@{N="SO configurado";E={$_.ExtensionData.Config.GuestFullName}},@{N="SO activo";E={$_.ExtensionData.Guest.GuestFullName}}

Vamos a verlo paso por paso:

  • Get-VM: Listamos todas las máquinas virtuales.
  • Where-Object: Filtramos los resultados con las siguientes condiciones:
    • $_.ExtensionData.Config.GuestFullName -ne $_.ExtensionData.Guest.GuestFullName: Objetos cuyo SO invitado difiera entre el activo y el configurado.
    • $_.ExtensionData.Guest.GuestFullName -ne $null: Objetos cuyo SO activo no esté vacío (máquinas virtuales apagadas o sin VMware Tools).
  • Select-Object: Seleccionamos los campos deseados para el objeto devuelto:
    • Name: El nombre de la máquina virtual.
    • @{N=”SO configurado”;E={$_.ExtensionData.Config.GuestFullName}}: El sistema operativo configurado.
    • @{N=”SO activo”;E={$_.ExtensionData.Guest.GuestFullName}}: El sistema operativo activo.
    • Get-VM: Listamos todas las máquinas virtuales.
  • Where-Object: Filtramos los resultados con las siguientes condiciones:
    • $_.ExtensionData.Config.GuestFullName -ne $_.ExtensionData.Guest.GuestFullName: Objetos cuyo SO invitado difiera entre el activo y el configurado.
    • $_.ExtensionData.Guest.GuestFullName -ne $null: Objetos cuyo SO activo no esté vacío (máquinas virtuales apagadas o sin VMware Tools).
  • Select-Object: Seleccionamos los campos deseados para el objeto devuelto:
    • Name: El nombre de la máquina virtual.
    • @{N=”SO configurado”;E={$_.ExtensionData.Config.GuestFullName}}: El sistema operativo configurado.
    • @{N=”SO activo”;E={$_.ExtensionData.Guest.GuestFullName}}: El sistema operativo activo.

Si este one-liner no nos devuelve nada quiere decir que no tenemos máquinas virtuales con este problema. En caso de tener máquinas virtuales afectadas veremos una salida parecida a la siguiente:

VMs mal configuradas

Como podemos ver en la captura tenemos tres máquinas virtuales mal configuradas, una con WS2012, una con WS2008R2 y otra con WS2008 cuando todas ellas en realidad corren Windows Server 2016.

Si la lista es muy grande y queremos mejorar su manejo podemos exportarla a Excel como vimos en entradas anteriores:

Get-VM | Where-Object  {$_.ExtensionData.Config.GuestFullName -ne  $_.ExtensionData.Guest.GuestFullName -and  $_.ExtensionData.Guest.GuestFullName -ne $null} | Select-Object  Name,@{N="SO  configurado";E={$_.ExtensionData.Config.GuestFullName}},@{N="SO  activo";E={$_.ExtensionData.Guest.GuestFullName}} | Export-Excel -Path 'C:\Scripts\SO_mismatch.xlsx' -AutoSize -BoldTopRow -AutoFilter

Con lo que obtendremos nuestro bonito Excel ya filtrado:

VMs mal configuradas Excel

Corregir el Sistema Operativo invitado mal configurado con PowerCLI de forma masiva

Ahora que ya tenemos localizadas las máquinas virtuales que queremos reconfigurar podemos pasar a crear un mini script para arreglar nuestro problema. Lo que queremos que haga nuestro script es lo siguiente:

  • Apagar la máquina virtual a reconfigurar (el cambio debe hacerse en frío).
  • Cambiar el sistema operativo configurado por el correcto.
  • Volver a encender la máquina virtual.

Nada muy complicado, esto es lo que os propongo:

#### Variables ####
# Conexión a vCenter
$vcenterIp = "192.168.168.168"
$vcenterCreds = Import-Clixml -Path "$PSScriptRoot\Credenciales\VMware_rw.xml"

# Obtenemos VMs
$vmNames = 'Test-1','Test-2','Test-3'

#### Cuerpo script ####
# Conectamos al vCenter
Connect-VIServer -Server $vcenterIp -Credential $vcenterCreds -WarningAction SilentlyContinue | Out-Null

# Recorremos las VMs
ForEach ($vmName in $vmNames) {
    # Obtenemos la VM
    $vm = Get-VM -Name $vmName
    # Apagamos la VM
    $vm | Shutdown-VMGuest -Confirm:$false | Out-Null

    # Esperamos hasta que la VM se apaga
    do {
        Start-Sleep -Seconds 5
        $vm = Get-VM $vm.Name
    } until ($vm.PowerState -eq 'PoweredOff')

    # Modificamos el Guest ID de la VM
    $vm | Set-VM -GuestId windows9Server64Guest -Confirm:$false | Out-Null
    Start-Sleep -Seconds 5
    # Iniciamos la VM
    $vm | Start-VM -Confirm:$false | Out-Null
}

# Cerramos conexión
Disconnect-VIServer -Confirm:$false

Si bien el script tiene comentarios bastante explicativos voy a desarrollarlo un poco más:

  • 3-4: Definimos los datos de conexión al vCenter.
  • 7: Definimos los nombres de los servidores a corregir.
  • 11: Conectamos a vCenter.
  • 14-31: Recorremos las VMs a corregir y:
    • 18: Apagamos la VM.
    • 20-24: Esperamos hasta que la VM haya finalizado el apagado.
    • 27: Configuramos el Sistema Operativo invitado correctamente.
    • 30: Encendemos la VM.
  • 34: Desconectamos del vCenter.

En la línea 27 veréis que utilizo ‘windows9Server64Guest‘ para configurar Windows 2016 Server de 64 bits en la máquina virtual. Existe una lista con todos los códigos que podéis utilizar para cada sistema operativo a corregir. Deberéis sustituir éste código por el correspondiente de la versión de sistema operativo que queréis configurar.

Una vez haya finalizado la ejecución de nuestro script si volvemos a ejecutar nuestro one-liner del punto anterior veremos como éstas VMs no aparecen.

Resumen

Es importante mantener la configuración de sistema operativo invitado de forma correcta pues una mala configuración puede provocar problemas de rendimiento, problemas al instalar y actualizar las VMware Tools o imposibilidad de realizar algunos ajustes en las máquinas virtuales.

Debido a que el procedimiento implica parada os recomiendo que programéis una tarea de PowerShell para realizar el proceso fuera de horario de producción para reducir el impacto en vuestros sistemas.

La entrada Corregir VMs con Sistema Operativo invitado mal configurado con PowerCLI aparece primero en Sobrebits.

by Marc Meseguer at January 17, 2019 01:00 PM

January 16, 2019

RooTeando

ARM para TODOS: 07: Lista de placas ARM favoritas.

En este audio hablaré sobre el objetivo de este podcast y del grupo, también comentaré una lista de mis 5 placas, alternativas a la Raspberry, favoritas.

Lista
▪️Banana Pi R2 http://www.banana-pi.org/r2.html

▪️ Banana Pi W2 http://www.banana-pi.org/w2.html

▪️ Libre Computer Renegade  https://libre.computer/products/boards/roc-rk3328-cc/

▪️Rock 64 Pro  https://www.pine64.org/?page_id=61454

▪️Rock Pi 4 http://rockpi.org/

Música:  Pierce M-To Japan-02 So ...

January 16, 2019 12:05 PM

January 13, 2019

RooTeando

Entrevista en Diferido 01: Daniel Primo

Cada entrevista que finalice una entrevista en el canal de Telegram de Entrevista En Diferido, https://t.me/entrevistaendiferido, la convertiré a un post en mi blog. 

Comenzamos con la primera entrevista a Daniel Primo, desarrollador web, podcaster con Web Reactiva y otros proyectos.

EntrevistaEnDiferido Hoy empezamos una entrevista a Daniel Primo desarrollador web freelance, podcaster, youtuber,emprendedor y compañero del podcast RadioDev. Buenas Daniel,la primera pregunta sería una pequeña presentación por parte ...

January 13, 2019 03:36 PM

January 10, 2019

Sobre bits

PSRemoting (Parte 2): Cómo configurar PowerShell Remoting

Ahora que ya sabemos qué es y cómo funciona PowerShell Remoting gracias a la entrada anterior de la serie, estamos listos para empezar con la acción. En la entrada de hoy veremos cómo configurar PowerShell Remoting tanto en origen como en destino para empezar a ponernos en marcha.

Os dejo el índice de la serie:

Cómo configurar PowerShell Remoting

Configuraciones necesarias en la máquina destino

Si bien no es estrictamente necesario conocer el detalle de qué necesita tener configurado una máquina para poder conectarnos a ella mediante PowerShell Remoting, sí que es interesante conocer las distintas partes involucradas. Ésto va a sernos útil en el caso de que queramos hacer troubleshooting de una conexión y, en el caso de que queramos habilitar PowerShell Remoting mediante GPO, se va a volver imprescindible. Las configuraciones necesarias son las siguientes:

  • Configurar el servicio de escucha de WinRM.
  • Habilitar el servicio de WinRM para el autoarranque.
  • Crear una regla en el firewall local de la máquina para aceptar el tráfico entrante de WinRM.

Para nuestra suerte desde Windows Server 2012 estas tres configuraciones vienen habilitadas por defecto, por lo que en dichos sistemas (si no se ha deshabilitado después de la instalación alguno de estos puntos) no haría falta realizar ninguna configuración extra a no ser que intentemos conectar desde una subnet distinta a la de la máquina, puesto que la regla de Firewall por defecto no permite el tráfico desde subredes distintas en redes públicas.

Habilitar PowerShell Remoting en destino mediante Enable-PSRemoting

Sin duda a la hora de configurar PowerShell Remoting la opción más sencilla es utilizar Enable-PSRemoting siempre y cuando queramos habilitarlo en unas pocas máquinas, pues tendremos que ejecutar este cmdlet en cada una de ellas. Enable-PSRemoting se va a encargar de habilitar PowerShell Remoting sin más intervención por nuestra parte. Es importante remarcar también que no se requiere reinicio para aplicar los cambios.

Para usarlo abriremos una consola de PowerShell como administrador y ejecutaremos:

Enable-PSRemoting -Force

Ejecutamos el cmdlet con -Force para que no pida confirmaciones.

Una vez finalice la ejecución ya tendremos lista nuestra máquina.

Si estamos realizando esta operación en una máquina Windows cliente y no estamos en dominio es muy probable que nos encontremos con el siguiente error:

La excepción de firewall de WinRM no funcionará porque uno de los tipos de conexión de red de este equipo está establecido en Público. Cambie el tipo de conexión de red a Dominio o Privado e inténtelo de nuevo.

Para corregirlo deberíamos ejecutar Enable-PSRemoting con el parámetro SkipNetworkProfileCheck, con el que se crearía la regla igualmente pese a estar en una red pública:

Enable-PSRemoting -Force -SkipNetworkCheck

Por último, si quisiéramos acceder a nuestras máquinas (tanto Windows Server como cliente) desde una subnet distinta deberíamos modificar la regla de Firewall creada que por Enable-PSRemoting para que acepte peticiones desde cualquier dirección remota:

Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP" -RemoteAddress Any

Habilitar PowerShell Remoting en destino mediante GPO

Si bien configurar PowerShell Remoting mediante GPO es un poco más laborioso que hacerlo con Enable-PSRemoting, nos va a permitir hacerlo en gran cantidad de máquinas de una sola vez y asegurarnos de que nadie deshabilita PowerShell Remoting.

Para ello crearemos una nueva política de grupo en la que realizaremos las siguientes tres configuraciones.

Configurar el servicio de escucha de WinRM

Configuración del equipo > Directivas > Plantillas administrativas > Administración remota de Windows (WinRM) > Servicio WinRM > Permitir la administración de servidores remotos a través de WinRM

Habilitar WinRM GPO 1


Configurar autoarranque del servicio de WinRM

Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Servicios del sistema > Administración remota de Windows (WS-Management)

Configurar el Firewall de Windows

Configuración del equipo > Configuración de Windows > Configuración de seguridad > Firewall de Windows con seguridad avanzada > Reglas de entrada

Aquí haremos clic derecho y pulsaremos en nueva regla.

Habilitar WinRM GPO 3
Habilitar WinRM GPO 4
Habilitar WinRM GPO 5

Si queremos permitir la conexión por PowerShell Remoting desde una subred distinta deberemos hacer botón derecho en la regla de perfil Público creada y en la pestaña Ámbito permitir cualquier dirección IP remota:

Habilitar WinRM GPO 6

Después de aplicar la GPO a las máquinas correspondientes ya deberíamos ser capaces de conectar mediante PowerShell Remoting.

Comprobar conectividad de PSRemoting

Una vez tenemos PowerShell Remoting en nuestra máquina destino deberemos probar que la conectividad funciona correctamente. Para ello nos valdremos del cmdlet Test-WSMan:

Uso de Test-WSMan

Si tras ejecutarlo nos devuelve una salida parecida a la siguiente sin errores quiere decir que hemos triunfado.

Configurar PowerShell Remoting en origen

Por último, si planeamos utilizar PowerShell Remoting en un entorno fuera de dominio de Active Directory deberemos realizar un pequeño cambio en nuestra máquina cliente (si vas a utilizar PowerShell Remoting en dominio puedes ignorar este paso).

Si intentamos una conexión remota sin hacer cambios en un entorno de dominio encontraremos el siguiente error:

El cliente WinRM no puede procesar la solicitud. Si el esquema de autenticación es distinto de Kerberos o si el equipo cliente no está unido a un dominio, se debe usar el transporte HTTPS o agregar el equipo de destino al valor de configuración TrustedHosts. Use winrm.cmd para configurar TrustedHosts. Tenga en cuenta que es posible que no se autentiquen los equipos de la lista TrustedHosts.

El error es muy autoexplicativo: por motivos de seguridad, si la autenticación no se realiza por Kerberos o si el equipo cliente no está unido a dominio tenemos que elegir una de las siguientes opciones para realizar la conexión:

  • Utilizar WS-Man sobre HTTPS.
  • Añadir el equipo destino a la configuración TrustedHosts.

Por el momento vamos a ver cómo modificar la configuración de TrustedHosts (PowerShell con permisos de administrador):

# Añadir una máquina de destino:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '192.168.253.10'
# Añadir múltiples máquinas destino:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '192.168.253.10,192.168.253.11'
# Añadir un wildcard para permitir todas las máquinas destino (inseguro)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '*'

Después de esto ya deberíamos ser capaces de conectarnos a las máquinas destino que deseemos.

Cómo deshabilitar PowerShell Remoting

Por último, si queremos deshabilitar PowerShell Remoting disponemos de dos opciones:

  • Utilizar el cmdlet Disable-PSRemoting.
  • Crear una GPO que haga lo contrario de la que hemos visto en puntos anteriores.

Resumen

A modo de resumen, debido a que existen distintos escenarios a cubrir y puede parecer un poco lioso, estas son las acciones que hay que realizar según cada escenario posible:

  • Si vas a utilizar PSRemoting en dominio:
    • Servidores destino iguales o superiores a Windows 2012: No es necesario configurar nada.
    • Servidores destino anteriores a Windows 2012: Hay que habilitar PSRemoting con GPO o Enable-PSRemoting.
  • Si vas a utilizar PSRemoting fuera de dominio:
    • Máquinas en la misma subnet: Habilitar PSRemoting con GPO o Enable-PSRemoting y modificar TrustedHosts.
    • Máquinas en distinta subnet: Habilitar PSRemoting con GPO o Enable-PSRemoting, modificar TrustedHosts y modificar regla de Firewall.

Espero que os haya servido la entrada. En la próxima vamos a empezar a trastear con PowerShell Remoting y ver qué podemos hacer.

La entrada PSRemoting (Parte 2): Cómo configurar PowerShell Remoting aparece primero en Sobrebits.

by Marc Meseguer at January 10, 2019 01:16 PM

January 07, 2019

RooTeando

Tomando Un Café 48: Nuevo proyecto en Telegram

En este audio hablo sobre mi nuevo proyecto en Telegram, un canal para realizar entrevistas. Explicaré un poco el funcionamiento del proyecto y porque lo he creado.

 

Canales de Telegram @UnDiaUnaAplicacion @UnPythonAldia @AprendePython
Podcast @RadioDev  @ARMparaTODOS @RadioDev

Grupos de Telegram
Alternativas a la Raspberry
https://t.me/AlternativasRaspberry

Twitter 
Podcast
https://twitter.com/Tomando_Un_Cafe
https://twitter.com/RadioDevPodcast

Canales de Telegram
Un Día Una Aplicación https://twitter.com/UnDiaUnaApp
Un Python Al ...

January 07, 2019 10:00 PM

January 03, 2019

Sobre bits

PSRemoting (Parte 1): ¿Qué es PowerShell Remoting?

Si bien ejecutando scripts de PowerShell de forma local en nuestras máquinas y servidores podemos realizar grandes automatizaciones, cuando PowerShell empieza a brillar es cuando ejecutamos acciones directamente en máquinas remotas y de forma masiva. Empezamos esta serie de entradas en la que profundizaremos sobre esta tecnología viendo qué es PowerShell Remoting y cómo funciona.

Os dejo el índice de la serie:

Qué es PowerShell Remoting

¿Qué es PowerShell Remoting?

PowerShell Remoting es una tecnología introducida en Windows PowerShell 2.0 (y refinada en Windows PowerShell 3.0) con la cual podremos ejecutar órdenes de PowerShell en máquinas remotas a través de la red de una forma estandarizada y muy sencilla.

Con PowerShell Remoting conseguimos la capacidad de administrar cientos de máquinas a la vez y ejecutar órdenes en las mismas sin la necesidad de aumentar nuestro tiempo de dedicación.

Es importante no confundir PowerShell Remoting con la capacidad que tienen algunos cmdlets como Get-Process o Get-Service de facilitar un parámetro -ComputerName con el que ejecutar dicho cmdlet de forma remota.

  • PowerShell Remoting trabaja sobre WS-Man, en cambio estos cmdlets utilizan DCOM/RPC. Tal y como vimos en la entrada sobre CIM y WMI, WS-Man es un protocolo más ‘Firewall friendly’ basado en HTTP/HTTPS que DCOM/RPC.
  • PowerShell Remoting proporciona capacidades de ejecución remota a cualquier cmdlet o función que la máquina sea capaz de ejecutar. Con DCOM/RPC cada cmdlet tiene que ser desarrollado con dicha funcionalidad.
  • Con PowerShell Remoting la carga del procesamiento de las tareas se realiza en la máquina remota, con DCOM/RPC ésta se genera en la máquina local.
  • Si realizamos una ejecución masiva a diferentes máquinas con PowerShell Remoting se ejecutan las tareas en paralelo gracias a lo comentado en el punto anterior. De hacerlo con DCOM/RPC se realizan de forma secuencial, con su correspondiente aumento de tiempos de ejecución.

¿Cómo funciona PowerShell Remoting?

Una vez entendido qué es PowerShell Remoting es importante tener claro cómo funciona para poder sacar el máximo partido de él. Para ilustrar mejor su funcionamiento he creado este diagrama donde podemos ver una transacción de PowerShell Remoting:

Cómo funciona PowerShell Remoting

PowerShell Remoting funciona a modo cliente-servidor. Cuando iniciamos una comunicación de PowerShell Remoting desde la máquina cliente ésta manda una petición utilizando WS-Man a la máquina servidor por defecto por el puerto 5985/TCP utilizando HTTP (también se puede ejecutar utilizando HTTPS en cuyo caso utilizaría el puerto 5986/TCP).

Una vez llega dicha petición a la máquina servidor el servicio WinRM (Windows Remote Management) es el encargado de recepcionarla y facilitársela al servicio de background de PowerShell para que la procese y se mantiene a la espera. Cuando el servicio de background de PowerShell finaliza la ejecución devuelve el resultado a WinRM que se encarga de devolver el resultado a la máquina cliente utilizando el mismo canal.

Requisitos de PowerShell Remoting

Como hemos visto anteriormente, PowerShell Remoting fue lanzado para Windows PowerShell 2.0, pero no fue hasta la versión 3.0 que se añadió la funcionalidad completa. Es por ello que desde Microsoft se facilitan dos “juegos” de requisitos:

Para utilizar la funcionalidad de PowerShell Remoting de PowerShell 3.0 o superior tanto cliente como servidor deben disponer de:

  • PowerShell 3.0 o superior.
  • .NET Framework 4.0 o superior.
  • Windows Remote Management 3.0.

Estos requisitos vienen instalados por defecto en todos los sistemas operativos de Microsoft a partir de Windows 8 y Windows Server 2012.

Si en cambio vamos a utilizar la funcionalidad de 2.0 tanto cliente como servidor deben disponer de:

  • PowerShell 2.0.
  • .NET Framework 2.0 o superior.
  • Windows Remote Management 2.0

Si bien podríamos realizar conexiones desde una máquina con PowerShell 2.0 a una con 3.0 dicha comunicación se realizaría perdiendo la funcionalidad que ofrece la versión 3.0.

Por último, a estos requisitos a nivel de máquina deberíamos añadir los siguientes requisitos a nivel de red:

  • Comunicación entre cliente y servidor por el puerto 5985 TCP (para utilizar WS-MAN sobre HTTPS).
  • Comunicación ente cliente y servidor por el puerto 5986 TCP (para utilizar WS-MAN sobre HTTPS).

Conclusión

Y hasta aquí la entrada de hoy, la más teórica de las de esta serie pero sin duda necesaria para entender lo que haremos en las partes más prácticas.

En la próxima entrada veremos qué opciones tenemos para habilitar PowerShell Remoting tanto en origen como en destino y así empezar a trastear con esta tecnología.

¡Nos vemos pronto!

La entrada PSRemoting (Parte 1): ¿Qué es PowerShell Remoting? aparece primero en Sobrebits.

by Marc Meseguer at January 03, 2019 02:12 PM

December 31, 2018

RooTeando

Tomando Un Café 47: Charla con Samuel de Yo Virtualizador

En este audio tengo una charla informal con Samuel, podcast Yo Virtualizador, sobre un distro de Linux que el conoce bien como Red Hat y  mi distro de cabecera que Fedora, que también conoce muy bien. Hablamos sobre diversos temas como el futuro de estas distros, los mitos que tienen, la compra de Red Hat de IBM, paquetería, aderezado con diversas opiniones sobre otros temas. Es un audio largo pero entretenido.

Este audio será el ...

December 31, 2018 02:28 PM

December 27, 2018

blog de Rodolfo Pilas

Rocket Chat super rápido con Vagrant

Rocket Chat es un excelente sistema corporativo de chat completamente software libre (clientes y servidores), con todo el glamour de un sistema de chat moderno (canales, integración, componentes embebitos, chatbots, etc. etc.)

En este Vagrantfile es posible levantarlo de forma tan simple como escribir vagrant up

# -*- mode: ruby -*-
# vi: set ft=ruby :

# https://rocket.chat/docs/installation/updating/#snap-installation
#
# Access Rocket.Chat:  http://localhost:3000

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/xenial64"

  config.vm.network "forwarded_port", guest: 3000, host: 3000

  config.vm.provision "shell", inline: <<-SHELL
    snap install rocketchat-server
  SHELL
end

by pilasguru at December 27, 2018 01:51 AM

December 19, 2018

Sobre bits

Cómo ejecutar PowerShell y PowerCLI desde Docker

Con la aparición de PowerShell Core se abrió un inmenso abanico de posibilidades a la hora de ejecutar PowerShell desde distintos sistemas operativos. Hoy en día es posible ejecutar PowerShell en Linux y en MacOS, cosa que años atrás era impensable con Windows PowerShell. En los últimos tiempos son muchos los módulos que se han adaptado para poder correr en PowerShell Core, entre ellos PowerCLI. En la entrada de hoy vamos a avanzar un paso más y vamos a ver cómo ejecutar PowerShell y PowerCLI desde Docker.

Cómo ejecutar PowerShell y PowerCLI desde Docker

Descargando las imágenes de Docker de PowerShell y PowerCLI

Una de las grandes bazas a favor de Docker es la gran cantidad de imágenes de contenedores que podemos encontrar en su Docker Hub. Tanto Microsoft como VMware en los últimos tiempos han estado acercándose hacia el software libre y eso se nota en este caso, ya que podemos encontrar imágenes oficiales de Microsoft y VMware en Docker Hub para PowerShell y PowerCLI.

Si queremos descargar la imágen de Docker de PowerShell podemos ejecutar:

Descarga de imágen Docker de PowerShellPara descargar la imágen de Docker de PowerCLI ejecutaremos lo siguiente:

Descarga de imagen Docker de PowerCLI

Inspeccionando los contenedores de PowerShell y PowerCLI

Una vez tenemos los contenedores descargados podemos entrar a inspeccionarlos para ver qué tenemos dentro.

Para entrar en el contenedor de forma interactiva podemos ejecutar:

docker run --rm -it mcr.microsoft.com/powershell

Vamos a revisar parte por parte:

  • docker run: Ejecutamos un nuevo contenedor.
  • –rm: Elimina automáticamente el contenedor una vez salgamos de él.
  • -it: Ejecutamos el contenedor de forma interactiva.
  • mcr.microsoft.com/powershell: Indicamos la imagen que utilizaremos para crear nuestro nuevo contenedor.

Una vez dentro podemos ver los detalles del contenedor:

Detalles docker PowerShell

Como se aprecia en la imagen tenemos una versión 6.1.1 de PowerShell Core corriendo en una Ubuntu 18.04.

Si hacemos lo propio con la imágen de PowerCLI:

Detalles docker PowerCLIEn este caso vemos que se trata de una versión 6.0.1 de PowerShell Core corriendo sobre PhotonOS 2.0. Además podemos ver que el contenedor trae 28 módulos de VMware, con lo que desde éste podremos correr comandos contra toda clase de productos de la compañía.

Ejecutando scripts de PowerShell y PowerCLI desde Docker

Hasta aquí todo puede quedar como algo anecdótico, pero en el momento en el que somos capaces de pasarle código para ejecutar a nuestro contenedor podemos empezar a encontrar utilidad a la ejecución de PowerShell y PowerCLI desde Docker.

Para ejecutar un script dentro del contenedor necesitaremos, antes que nada, tener dicho script en alguna ubicación de la máquina que correrá el contenedor. Para nuestro caso será el siguiente script ubicado en C:\Scripts\Hola-Mundo.ps1:

Write-Host "Hola desde Sobrebits.com en PSCore $($PSVersionTable.PSVersion)"

Nada muy complicado, un simple “Hola mundo” que nos mostrará la versión de PowerShell Core de nuestro contenedor.

Ahora ya podemos pasar a ejecutarlo en ambos contenedores:

docker run --rm -it --entrypoint='/usr/bin/pwsh' -v C:/Scripts:/tmp/scripts mcr.microsoft.com/powershell /tmp/scripts/Hola-Mundo.ps1
Hola desde Sobrebits.com en PSCore 6.1.1
docker run --rm -it --entrypoint='/usr/bin/pwsh' -v C:/Scripts:/tmp/scripts vmware/powerclicore /tmp/scripts/Hola-Mundo.ps1
Hola desde Sobrebits.com en PSCore 6.0.1

Repasemos lo que acabamos de hacer:

  • docker run: Ejecutamos un nuevo contenedor.
  • –rm: Elimina automáticamente el contenedor una vez salgamos de él.
  • -it: Ejecutamos el contenedor de forma interactiva.
  • –entrypoint=’/usr/bin/pwsh’: Especificamos el ejecutable a iniciar cuando el contenedor arranca, en nuestro caso el binario de PowerShell Core.
  • -v C:/Scripts:/tmp/scripts: Montamos la carpeta C:\Scripts de nuestra máquina anfitriona en el volumen /tmp/scripts del contenedor.
  • mcr.microsoft.com/powershell: Indicamos la imagen que utilizaremos para crear nuestro nuevo contenedor.
  • /tmp/scripts/Hola-Mundo.ps1: El script que ejecutaremos mediante PowerShell Core en nuestro contenedor.

Como vemos cada contenedor ha devuelto su versión de PowerShell Core. Con esto ya deberíamos ser capaces de lanzar nuestros propios scripts tanto de PowerShell como de PowerCLI desde Docker sin problema.

Conclusión

Ejecutar scripts de PowerShell y PowerCLI desde Docker nos va a permitir hacer nuestras automatizaciones portables a cualquier plataforma capaz de correr Docker y nos puede ayudar a ejecutar scripts de PowerShell de forma programada con un menor consumo de recursos.

¡Os animo a probarlo!

La entrada Cómo ejecutar PowerShell y PowerCLI desde Docker aparece primero en Sobrebits.

by Marc Meseguer at December 19, 2018 04:00 PM

December 12, 2018

Sobre bits

Equivalentes en PowerShell a comandos de Linux

Si provienes del mundo GNU/Linux y tienes cierta experiencia en el manejo de su línea de comandos es posible que al empezar con PowerShell busques instintivamente herramientas parecidas a las que ya conoces para usarlas. La buena notícia es que Microsoft se ha encargado de facilitar lo máximo posible la transición de una shell a la otra, por lo que en la entrada de hoy revisaremos una serie de cmdlets equivalentes en PowerShell a comandos de Linux así como sus alias.

Equivalentes en PowerShell a comandos de Linux

Antes de empezar: diferencias entre sistemas operativos

Si bien en la introducción he apuntado que Microsoft ha facilitado muchísimo la transición para alguien que proviene del mundo GNU/Linux hacia PowerShell hay que tener en cuenta que las diferencias entre GNU/Linux y Windows son muy grandes.

GNU/Linux es un sistema operativo basado en texto. Cualquier configuración se realiza editando archivos de texto y es por ello que bash está repleto de herramientas para manipularlo. Herramientas que además, después de realizar sus modificaciones, devuelven texto.

Windows es un sistema operativo basado en objetos. Dada la base del sistema operativo, PowerShell está lleno de de herramientas orientadas a tratar con objetos. Herramientas que, una vez realizadas sus operaciones, devuelven objetos.

Es por ello que, si bien PowerShell también ofrece herramientas para tratar con texto, hay que tener en cuenta que éstas probablemente no sean la primera opción a escoger, puesto que la salida de nuestro comando probablemente nos estará devolviendo objetos y no texto.

Lista de equivalentes en PowerShell a comandos Linux

Con esta aclaración hecha podemos ponernos con las equivalencias:

Sistema de archivos

Aquí vamos a enumerar los distintos cmdlets relacionados con la gestión del sistema de archivos.

# cd

Para cambiar de directorio en PowerShell tenemos Set-Location:

PS C:\Script> Set-Location C:\Scripts

Alias: cd, chdir, sl

# ls

Para listar el contenido de un directorio en PowerShell podemos utilizar Get-ChildItem:

PS C:\Script> Get-ChildItem C:\Scripts


    Directorio: C:\Scripts


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       09/12/2018     20:58              0 Bienvenido a Sobrebits.txt

Alias: dir, gci, ls

# pwd

Si queremos obtener nuestra ubicación actual disponemos de Get-Location:

PS C:\Scripts> Get-Location

Path
----
C:\Scripts

Alias: gl, pwd

# find

El equivalente a find en PowerShell es, al igual que para listar el contenido de una carpeta, Get-ChildItem pero en esta ocasión con el modificador -Filter (y añadiendo -Recurse si queremos buscar de forma recursiva):

PS C:\Scripts> Get-ChildItem 'C:\Scripts' -Filter '*Bienvenido a sobrebits*' -Recurse


    Directorio: C:\Scripts\Carpeta


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       09/12/2018     21:08              0 Bienvenido a sobrebits.txt

Alias: dir, gci, ls

# touch, mkdir, cp, move y rm

Para crear un nuevo archivo o carpeta (touch y mkdir) disponemos de New-Item, para copiar un archivo o carpeta (cp) disponemos de Copy-Item, para mover un archivo o carpeta (mv) tenemos Move-Item y para eliminar un archivo o carpeta (rm) disponemos de Remove-Item:

PS C:\Scripts> New-Item -ItemType File Sobrebits.txt
PS C:\Scripts> New-Item -ItemType Directory 'Sobrebits folder'
PS C:\Scripts> Copy-Item .\Sobrebits.txt .\Sobrebits2.txt
PS C:\Scripts> Move-Item .\Sobrebits2.txt .\Sobrebits3.txt
PS C:\Scripts> Remove-Item *.txt

Alias New-Item: ni
Alias Copy-Item: copy, cp, cpi
Alias Move-Item: mi, move, mv
Alias Remove-Item: del, erase, rd, ri, rm, rmdir

Manipulación de archivos

# cat

Para mostrar el contenido de un archivo en PowerShell utilizaremos Get-Content:

PS C:\Scripts\Carpeta> Get-Content '.\Bienvenido a sobrebits.txt'
¡Gracias por visitar el blog y compartir!

Alias: cat, gc, type

# tail y head

Tanto para mostrar el final de un archivo (tail) como para mostrar el principio de un archivo (head) en PowerShell utilizaremos Get-Content con los parámetros -Tail y -TotalCount respectivamente:

PS C:\Scripts\Carpeta> Get-Content '.\Bienvenido a sobrebits.txt' -Tail 10
PS C:\Scripts\Carpeta> Get-Content '.\Bienvenido a sobrebits.txt' -TotalCount 10

Alias: cat, gc, type

# grep

Si queremos utilizar el equivalente a grep en PowerShell deberemos utilizar Select-String con el parámetro -Pattern:

PS C:\Scripts\Carpeta> 'Bienvenido','a','Sobrebits'
Bienvenido
a
Sobrebits
PS C:\Scripts\Carpeta> 'Bienvenido','a','Sobrebits' | Select-String -Pattern 'Sobrebits'

Sobrebits

Alias: sls

# diff

Si queremos mostrar las diferencias entre dos archivos tal como lo hace diff usando PowerShell podemos utilizar Compare-Object:

PS C:\Scripts\Carpeta> Compare-Object '.\Bienvenido a sobrebits.txt' '.\Bienvenido a sobrebits2.txt'

Alias: compare, diff

Utilidades

# wget

Para utilizar una funcionalidad parecida a la de wget en PowerShell deberemos utilizar Invoke-WebRequest con el parámetro -OutFile:

PS C:\Scripts> Invoke-WebRequest https://sobrebits.com -OutFile sobrebits.html

Alias: curl, iwr, wget

# curl

Si lo que queremos es utilizar una funcionalidad similar a curl en PowerShell disponemos de Invoke-WebRequest y de Invoke-RestMethod en el caso de que queramos interactuar con una API REST:

PS C:\Scripts> Invoke-WebRequest https://sobrebits.com
PS C:\Scripts> Invoke-RestMethod https://sobrebits.com -Method Get

Alias Invoke-WebRequest: curl, iwr, wget
Alias Invoke-RestMethod: irm

# man

Si queremos consultar la ayuda en PowerShell podemos valernos de Get-Help:

PS C:\Scripts> Get-Help -Name Invoke-WebRequest

Alias: help, man (realmente help y su alias man son aliases de Get-Help añadiendo paginación de los resultados)

# tee

Si queremos guardar la salida de un comando a un archivo y seguir pasándolo por nuestro pipeline podemos utilizar Tee-Object:

PS C:\Scripts> 'Bienvenido a Sobrebits' | Tee-Object -FilePath 'C:\Scripts\Bienvenido a sobrebits.txt'

Alias: tee

# scp

Si bien para SCP no existe una herramienta nativa en PowerShell que la reemplace podemos tirar de WinSCP para PowerShell como vimos en entradas anteriores:

PS C:\Scripts> Receive-WinSCPItem -WinSCPSession $WinScpSession -RemotePath "/tmp/sobrebits.txt" -LocalPath 'C:\Windows\Temp'

Conclusión

Si bien la lista puede seguir y seguir creo que esta es una buena representación de los principales equivalentes en PowerShell a comandos en Linux para cualquier persona recién aterrizada en PowerShell desde el sistema operativo del pingüino. Algo importante a tener en cuenta es que en casi todos los casos existe un alias igual al comando de Linux al que ‘sustituye’, por lo que la transición puede ser muy sencilla.

¡Si echáis de menos algún comando os animo a que lo dejéis en los comentarios!

La entrada Equivalentes en PowerShell a comandos de Linux aparece primero en Sobrebits.

by Marc Meseguer at December 12, 2018 01:00 PM

RooTeando

Tomando Un Café 46:Primer aniversario

Este audio es un episodio especial para celebrar el primer aniversario del podcast, el primer año y espero que sean muchos mas. Contaré un poco la historia y experiencia con mis canales de Telegram,grupos y podcast, también contaré mis futuros proyectos. 

Pedí la colaboración de los oyentes del podcast, para que me enviasen audios o mensajes respondiendo a dos preguntas, pondre esos audios y mensajes, con algunos comentarios mios.

A continuación pondré toda ...

December 12, 2018 10:40 AM

December 04, 2018

Sobre bits

Cómo exportar una máquina virtual con PowerCLI

En más de una ocasión me ha tocado exportar una máquina virtual de un vCenter para luego cargarla en otro y, por algún oscuro misterio, la exportación del cliente web de vSphere no me lo ha permitido. En esas situaciones nos puede ser muy útil saber exportar una máquina virtual con PowerCLI, una tarea la mar de sencilla que además nos aportará algunas funciones extra.Cómo exportar una máquina virtual con PowerCLI

Encontrando el cmdlet correcto

Cuando instalamos PowerCLI en nuestra máquina podemos ver que éste se compone de varios módulos. Los módulos relacionados con vSphere se encuentran en VMware.VimAutomation.Core, por lo que siempre que queramos buscar un módulo de vSphere deberemos buscar en él.

Sabiendo esto vamos a ver qué cmdlets tenemos disponibles que contengan el verbo ‘Export’:

Exportar máquina virtual con PowerCli

Como podemos ver existe el cmdlet Export-VM, que tiene pinta de hacer lo que estamos buscando, pero un detalle importante es que éste es un Alias de Export-VApp como podemos ver en la columna CommandType. Dado que es un alias y que en Hyper-V ya existe un cmdlet llamado Export-VM para esta entrada utilizaremos el cmdlet original: Export-VApp.

Exportar una máquina virtual con PowerCLI mediante Export-VApp

Ahora que ya tenemos localizado el cmdlet que vamos a utilizar podemos ponernos en marcha. Exportar una VM con PowerCLI es tan sencillo como:

# Obtenemos la VM a exportar
$Vm = Get-VM -Name 'Sobrebits VM'

# Apagamos la VM para poderla exportar
$Vm | Stop-VM

# Exportamos la VM
$Vm | Export-VApp -Destination 'C:\Export\'

Vamos a repasar el código:

  • Línea 2: Aquí obtenemos la máquina virtual a exportar con PowerCLI y la guardamos en la variable $Vm con la que trabajaremos en adelante.
  • Línea 5: Apagamos la VM para poder exportarla.
  • Línea 8: Exportamos la máquina virtual y marcamos el Path en el que ubicar los archivos de la misma con la variable -Destination.

Cuando acabe la exportación deberíamos ver algo parecido a esto:

Máquina exportada a OVF con PowerCLI

Este es el uso básico del cmdlet, pero si consultamos su ayuda podemos ver que dispone de alguna funcionalidad extra la mar de interesante:

# Exportamos la VM a OVA y de forma asíncrona
$Vm | Export-VApp -Destination 'C:\Export\' -RunAsync -Format Ova

Vamos a explicar los dos nuevos parámetros:

  • RunAsync:  Este parámetro es común en muchos otros comandos de PowerCLI. Si activamos este flag la tarea que estemos ejecutando (en este caso la exportación de una VM) se ejecuta en segundo plano y nos libera al instante la línea de comandos. Esto nos puede ser útil si queremos ejecutar más de una exportación a la vez puesto que las podemos dejar como tareas y seguir trabajando en nuestra sesión actual de PowerCLI.
  • Format: Por defecto este cmdlet exporta las máquinas virtuales en formato .ovf. Utilizando -Format podemos alterar este comportamiento y exportar una máquina virtual a .ova desde PowerCLI, con lo que conseguiremos tener empaquetada nuestra máquina virtual en un solo archivo.

Una vez finalice la exportación de la VM a OVA podremos ver que en la carpeta existe un único archivo .ova:

Exportar OVA con PowerCLI

Conclusión

Con Export-VApp vamos a ser capaces de ejecutar tareas de exportación de máquinas virtuales desde la línea de comandos, lo que combinado con un poco de scripting básico y la programación de la ejecución de los mismos puede resultar en exportacines de VMs fuera de horario y de forma totalmente desatendida.

Espero que os haya gustado la entrada.

¡Nos leemos en la próxima!

La entrada Cómo exportar una máquina virtual con PowerCLI aparece primero en Sobrebits.

by Marc Meseguer at December 04, 2018 01:27 PM

November 28, 2018

blog de Rodolfo Pilas

Publicar la llave pública SSH

Los principales repositorios (Gitlab y Github) exponen las llaves públicas SSH de sus usuarios de forma que están accesibles para descarga:

https://(gitlab|github).com/<usuario>.keys

Es la URL de donde se obtienen, y aquí las mías:

La ventaja es tener un sitio disponible donde está nuestra clave (y la de nuestros colegas) para usar en automatismos como esta task de Ansible:

- name: Enable pilasguru root access
  authorized_key:
    user: root
    state: present
    key: https://gitlab.com/pilasguru.keys
    validate_certs: False

by pilasguru at November 28, 2018 07:33 PM

Sobre bits

PSSonicWall: Consultas a SonicWall desde PowerShell

Una de las tecnologías con las que acostumbro a trabajar en mi día a día son firewalls SonicWall. Hace un tiempo busqué en la PowerShell Gallery algún módulo para trabajar nativamente con SonicWall desde PowerShell y mi sorpresa fue que no encontré ninguno.

En las últimas semanas he estado trabajando en un módulo con el que realizar consultas a firewalls SonicWall desde PowerShell y hoy os traigo la primera versión de PSSonicWall.

Acerca de PSSonicWall

PSSonicWall es un módulo hecho 100% con PowerShell del que podéis encontrar el código fuente en su repositorio de GitHub. Se sirve de la SonicOS API, la REST API del sistema operativo de SonicWall introducida en la versión 6.5.1.

Con PSSonicWall podremos, en su primera versión, realizar consultas a cualquier firewall SonicWall desde PowerShell gracias a que todos los appliances utilizan el mismo sistema operativo. Podremos sacar la configuración de las interfaces, las zonas, objetos y muchas cosas más.

PSSonicWall en PowerShell Gallery

Cómo habilitar la SonicOS API

Por defecto en todos los firewalls SonicWall la SonicOS API viene desactivada, por lo que antes de nada deberemos habilitarla:

  • Nos logeamos a nuestro firewall con una cuenta de administrador.
  • Entramos en la pestaña Manage.
  • Appliance > Base Settings.
  • Buscamos la sección SonicOS API.
  • Marcamos:
    • Enable SonicOS API.
    • Enable RFC-2617 HTTP Basic Access authentication.

SonicWall desde PowerShell

Si no disponemos de estas opciones lo más probable es que nuestro firewall tenga una versión inferior a 6.5.1, por lo que si queremos utilizar PSSonicWall antes deberemos actualizarlo.

Instalando PSSonicWall

PSSonicWall es el primer módulo que subo a la PowerShell Gallery (más acerca de esto en futuros post), lo que hace que instalarlo en cualquier sistema sea de lo más sencillo:

# Para el usuario actual:
Install-Module -Name PSSonicWall -Scope CurrentUser

# Para todos los usuarios de la máquina:
Install-Module -Name PSSonicWall

Una vez acabado el proceso ya tendremos todo lo necesario para interactuar con nuestro appliance SonicWall desde PowerShell. Como siempre podemos consultar todas las funciones disponibles con Get-Command:

Funciones de PSonicWall

Conectar y desconectar a SonicWall desde PowerShell

El primer paso para interactuar con SonicWall desde PowerShell es autenticarse contra el firewall en cuestión. Para ello nos valdremos de Connect-SWAppliance, al que podremos pasarle un objeto PSCredential o, de no hacerlo, nos solicitará unas credenciales.

Connect-SWAppliance -Server 192.168.168.168

Una vez finalice la ejecución ya podremos empezar a interactuar con nuestro appliance.

Es recomendable que cuando acabemos de ejecutar los comandos pertinentes sobre nuestro SonicWall desconectemos la sesión. Para ello simplemente debemos ejecutar Disconnect-SWAppliance:

Disconnect-SWAppliance

Ejecutando comandos sobre SonicWall desde PowerShell

En esta primera versión de PSSonicWall, como habréis podido comprobar en la captura superior, únicamente se incluyen funciones con el verbo Get, por lo que por el momento únicamente podremos listar información. En futuras releases se irán incorporando nuevas funciones con las que podremos automatizar la creación de NATs y ACLs de SonicWall desde PowerShell.

Las funciones actualmente disponibles son las siguientes:

  • Get-SWAccessRule: Lista las Access Rules.
  • Get-SWAddressGroup: Lista los Address Groups.
  • Get-SWAddressObject: Lista los Address Objects.
  • Get-SWDns: Lista los DNS.
  • Get-SWInterface: Lista las Interfaces.
  • Get-SWNatPolicy: Lista los NAT.
  • Get-SWRoutePolicy: Lista las reglas de Routing.
  • Get-SWSchedule: Lista las programaciones.
  • Get-SWServiceGroup: Lista los service Group.
  • Get-SWZone: Lista las Zonas.

Si, por ejemplo, quisieramos listar un objeto llamado ‘Sobrebits test’ podríamos hacerlo de la siguiente manera:

Listar Address Objects de SonicWall desde PowerShell

Hay que tener en cuenta que todo lo que devuelven estas funciones son objetos, por lo que nos podremos valer de cmdlets típicos de manipulación de objetos para hacer lo que queramos con el resultado:

# Podemos filtrar un resultado con Where-Object
Get-SWAddressObject | Where Name -eq 'Sobrebits Test'

# Podemos seleccionar campos con Select-Object
Get-SWAddressObject | Select Name,Zone

# O incluso podemos exportar el resultado a csv con Export-Csv
Get-SWAddressObject | Export-Csv -Path 'C:\Sobrebits\export.csv'

Obteniendo ayuda en PSSonicWall

Como en todo módulo que se precie, todas las funciones incluidas en PSSonicWall traen su propia ayuda. Podemos utilizar Get-Help para consultar la funcionalidad detallada de cada una de las funciones así como ejemplos de uso:

Ayuda en PSSonicWallConclusión

De momento esto es todo lo que os quería contar sobre PSSonicWall, en futuras entradas veremos casos de uso más concretos del módulo e iré informando sobre nuevas funciones añadidas. ¡Nos vemos en próximas entradas!

La entrada PSSonicWall: Consultas a SonicWall desde PowerShell aparece primero en Sobrebits.

by Marc Meseguer at November 28, 2018 07:00 AM

November 25, 2018

MagMax Blog

Organización

Muchos de los artículos más curiosos comienzan en un hilo en Twitter. Ése es el caso de éste.

En un hilo con @recena, éste dijo:

I am really tired of the trends around job titles etc.... We should talk about
software engineer and responsibilities, that's all.

Y eso es lo que ha inspirado este artículo.

Leer más… (quedan 3 minutos de lectura)

by Miguel Ángel García at November 25, 2018 02:25 PM

November 23, 2018

debianhackers.net

[truco] mariadb se va de paseo (MySQL server has gone away)

O dicho en el idioma de los errores de sistema, ERROR 2006 (HY000) at line 21232: MySQL server has gone away.

$ mysql -h localhost -u user -pUltraSecurePass mydatabase &lt; dump.sql
ERROR 2006 (HY000) at line 21232: MySQL server has gone away
$

El lío

mariadb

mariadb

El error me apareció cuando intentaba importar la base de un wordpress en una instalación de MariaDB 10.1.37-0+deb9u1. Tengo que decir que el fichero SQL no es muy diferente al montón de importaciones que he hecho con MySQL, tiene un tamaño aproximado aunque sí que ha habido ficheros varios megas más grandes en el mismo servidor. Lo inusual del error, el que no fuese un error de sintaxis del fichero me hacía sospechar de la configuración de MariaDB.

La solución

Hay que aumentar una variable del sistema que se encarga del tamaño máximo del buffer donde se almacenan los paquetes, max_allowed_packet. Basta con añadir (o modificar) el valor y ponerlo a algo tremendo para que no falle, en este caso, 2 GB.

sudo sed -i '/max_allowed_packet/d' /etc/mysql/my.cnf
echo "max_allowed_packet = 2G" | sudo tee -a /etc/mysql/my.cnf
sudo /etc/init.d/mysql restart

Tras aplicar el cambio, ya se puede importar sin problema volcados de wordpress o de lo que sea.

$ mysql -h localhost -u user -pUltraSecurePass mydatabase &lt; dump.sql
$

by Diego Martínez Castañeda at November 23, 2018 12:31 PM

November 22, 2018

RooTeando

Diario de Aprendizaje: 02 Programación y niños.

Segundo episodio de este minipodcast que es una sección de mi podcast principal de Tomando Un Café. En esta ocasión hablaré de como enseñar programación a niños, por ese motivo he creado una pequeña lista de recomendaciones que pueden ser útiles a la hora de afrontar una formación de programación a niños:

▪️Los niños no son tontos.
▪️No infantilizar el material.
▪️Centrar la atención de los niños.
▪️Empezar por el final, primero enseñar el resultado ...

November 22, 2018 10:33 AM

Sobre bits

Iniciar RDP o SSH sobre una VM desde PowerCLI

Si como yo os pasáis el día conectados a una infraestructura VMware vSphere haciendo conexiones remotas a diferentes máquinas virtuales sabréis que utilizar la consola integrada de VMware no es la mejor de las opciones. Como sustitución acostumbro a utilizar RDP para las máquinas virtuales Windows y SSH para las GNU/Linux, el gran problema para mi siempre ha sido cómo gestionar toda esa cantidad de conexiones remotas.

Si bien existe software para gestionar dichas conexiones siempre he encontrado que es una solución demasiado manual y que escala muy mal conforme añadimos máquinas a la ecuación. Puesto que me tiro todo el día con una consola de PowerShell abierta y conectado a mi infraestructura me decidí a crear un par de funciones muy sencillitas con las que hacer dicha gestión desde PowerShell de una forma muy fácil y dinámica.

Averiguar la IP enrutable de una VM

La primera problemática para crear una solución de este tipo es obtener la IP correcta sobre la que queremos conectarnos. Es posible que esto no aplique a todo el mundo, pero cuando una VM tiene más de una IP debemos obtener la que esté en el mismo rango que su gateway para asegurarnos de que seremos capaces de enrutar hacia ella en el caso de estar en una VLAN distinta.

Para conseguir la IP correcta de la máquina virtual utilizo esta función:

Function Get-VMIP {
    # Devuelve la IP principal de la VM (Determinado por la primera IP de la misma subred del GW)
    Param(
        [Parameter(
            Position = 0,
            ValueFromPipeline=$true,
            Mandatory=$true
        )]
        [string]$Name
        )
    $ips = (Get-VM $Name).ExtensionData.Guest.Net.IpAddress

    # Si solo existe una IP la devolvemos como principal
    if ($ips.Count -eq 1) {
        Return $ips
    }
    # Si existe más de una IP devolvemos como principal la que está en la misma subred que el GW (solo aplica a las /24)
    elseif ($ips.Count -gt 1) {
        # Obtenemos el gateway para comparar
        $gateway = (Get-VM $Name).ExtensionData.Guest.Ipstack.IpRouteConfig.IpRoute.Gateway.IpAddress
        # Recorremos las IPs
        foreach ($ip in $ips) {
            if ($gateway[0].Split('.')[2] -eq $ip.Split('.')[2]) {
                Return $ip
            }
        }
    }
    # Si no existen IP's devolvemos null
    else {
        Return $null
    }
}

Hay que teneren cuenta que esta solución sólo funciona con redes /24, que es con las que trabajo yo en mi infraestructura, pero se podría adaptar para funcionar con cualquier máscara.

Como siempre vamos a ver qué hace cada parte del código:

  • Líneas 3 a 10: Definimos el parámetro $Name que corresponderá al nombre de la VM de la que obtendremos la IP.
  • $ips = (Get-VM $Name).ExtensionData.Guest.Net.IpAddress: Obtenemos todas las IPs de la máquina virtual.
  • Líneas 14 a 16: Si sólo existe una IP la devolvemos.
  • Líneas 18 a 27: Si existe más de una IP sacamos el gateway y comparamos todas las IPs con éste hasta encontrar la que pertenezca a la misma subred. Una vez encontrada devolvemos la IP.
  • Líneas 29 a 31: Si no existen IPs devolvemos $null.

Con nuestra nueva función cargada ya podríamos ejecutar Get-VMIP para obtener la IP de una máquina virtual:

Iniciar RDP con PowerCLI

Iniciar RDP o SSH sobre una VM

Ahora que ya tenemos creada nuestra función Get-VMIP podemos seguir con la función que realmente utilizaremos: Start-VMRc. Para la conexión SSH Start-VMRC se apoyará en Putty, por lo que deberemos descargarlo y ubicarlo en algún lugar de nuestro path, como C:\Windows\System32.

function Start-VMRc {
    # Inicia una conexión remota RDP o SSH en función del sistema operativo
    param  
    (  
        [Parameter(
            Position = 0,
            ValueFromPipeline=$true,
            Mandatory=$true
        )]
        [ValidateNotNullOrEmpty()]
        [string]$Name
    )
    # Determinamos la IP enrutable de la máquina
    $ip = Get-VMIP -Name $Name
    # Si es una máquina Windows iniciamos RDP
    if ((Get-VM -Name $Name).GuestId -like '*windows*'){
        mstsc /v:$ip
    }
    # Si es una máquina linux iniciamos Putty
    else {
        putty $ip
    }
}

Vamos a desglosar la función:

  • Líneas 3 a 12: Definimos el parámetro $Name que corresponderá al nombre de la VM a la que nos conectaremos remotamente.
  • $ip = Get-VMIP -Name $Name: Invocamos Get-VMIP para obtener la IP de la VM.
  • Líneas 16 a 18: Determinamos si es una máquina Windows y, en caso de serlo, iniciamos un RDP a la IP de la misma.
  • Líneas 20 a 22: De no ser una máquina Windows iniciamos SSH mediante Putty a su IP.

Si tenemos las dos funciones cargadas ya podemos ejecutar Start-VMRC para iniciar RDP contra nuestro servidor con:

Start-VMRC 'Sobrebits VM'

Conclusión

Una vez tengamos creadas las dos funciones podemos añadirlas a nuestro perfil tal y como vimos en la entrada ‘Cómo personalizar nuestro perfil de PowerShell‘.

Yo particularmente utilizo a diario estas dos funciones y os puedo asegurar que si os acostumbráis a ellas os pueden ahorrar una cantidad tremenda de tiempo.

¡Espero que os sea útil!

La entrada Iniciar RDP o SSH sobre una VM desde PowerCLI aparece primero en Sobrebits.

by Marc Meseguer at November 22, 2018 08:00 AM

November 21, 2018

blog de Rodolfo Pilas

Fundamentos y doctrinas de la Guerra Fría

Tuve el gusto de presentar ante dos sextos años de la Escuela Elbio Fernandez un análisis de los fundamentos y las doctrinas de la Guerra Fría, con la idea de complementar el estudio que previamente ellos habían hecho sobre ese período histórico, pero acercando una visión desde la “academia”, gracias a Von Neumann, claro.

Me divertí muchísimo contándoles cómo explota una bomba nuclear y explicando cómo la Teoría de Juegos de John Von Neumann y Oskar Morgenstern podía responder por qué la Guerra Fría fue, precisamente, fría.

Hasta nos hicimos tiempo para representar el dilema del prisionero y el equilibrio de Nash.

Agradezco a las maestras Irene y Annie que me permitieron estar frente a sus alumnos.

by pilasguru at November 21, 2018 08:28 PM

November 20, 2018

blog de Rodolfo Pilas

Enviar correo SMTP por telnet

Nada nuevo, esto está por todo internet explicado en muchas formas, tamaños y colores. Pero sucede que lo utilizo mucho y lo que siempre hago es entrar a mi blog y hacer una búsqueda por el término “telnet” y ahi me doy cuenta que tengo todas las formas de telnet para correo, menos la común y corriente. Eso motiva este artículo.

Como enviar un correo electrónico al puerto 25 por telnet:

# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 mail.mydomain.com ESMTP

HELO yourdomain.com
250 mail.mydomain.com

MAIL FROM: you@server.com
250 2.1.0 Ok

RCPT TO: rpilas@mydomain.com
250 2.1.5 Ok

DATA
354 End data with <CR><LF>.<CR><LF>
From: "Some One" <you@server.com>
To: "Rodolfo Pilas" <rpilas@mydomain.com>
Subject: Testing
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="boundary-type-1234567892-alt"
--boundary-type-1234567890
--boundary-type-1234567892-alt
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Testing the text to see if it works!

--boundary-type-1234567892-alt
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<html>Does this actually work?</html>

--boundary-type-1234567892-alt--
--boundary-type-1234567890
Content-Transfer-Encoding: base64
Content-Type: text/plain;name="Here2.txt"
Content-Disposition: attachment;filename="Here2.txt"

KiAxMyBGRVRDSCAoQk9EWVtURVhUXSB7NjU5fQ0KLS1fZjZiM2I1ZWUtMjA3YS00ZDdiLTg0NTgtNDY5YmVlNDkxOGRhXw0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJpc28tODg1OS0xIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KDQoNCkp1c3Qgc2VlaW5nIHdoYXQgdGhpcyBhY3R1
YWxseSBjb250YWlucyEgCQkgCSAgIAkJICA9DQoNCi0tX2Y2YjNiNWVlLTIwN2EtNGQ3Yi04NDU4LTQ2OWJlZTQ5MThkYV8NCkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PSJpc28tODg1OS0xIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KDQo8aHRtbD4NCjxoZWFkPg0KPHN0eWxlPjwhLS0N
Ci5obW1lc3NhZ2UgUA0Kew0KbWFyZ2luOjBweD0zQg0KcGFkZGluZzowcHgNCn0NCmJvZHkuaG1tZXNzYWdlDQp7DQpmb250LXNpemU6IDEwcHQ9M0INCmZvbnQtZmFtaWx5OlRhaG9tYQ0KfQ0KLS0+PC9zdHlsZT48L2hlYWQ+DQo8Ym9keSBjbGFzcz0zRCdobW1lc3NhZ2UnPjxkaXYgZGlyPTNEJ2x0cic+DQpKdXN0IHNlZWluZyB3aGF0IHRo
aXMgYWN0dWFsbHkgY29udGFpbnMhIAkJIAkgICAJCSAgPC9kaXY+PC9ib2R5Pg0KPC9odG1sPj0NCg0KLS1fZjZiM2I1ZWUtMjA3YS00ZDdiLTg0NTgtNDY5YmVlNDkxOGRhXy0tDQopDQpmbHlubmNvbXB1dGVyIE9LIEZFVENIIGNvbXBsZXRlZA


--boundary-type-1234567890--


.
QUIT
250 2.0.0 Ok: queued as 1EDE71400DE

221 2.0.0 Bye
Connection closed by foreign host.

(esto lo he extraido de internet)

by pilasguru at November 20, 2018 03:34 PM

November 19, 2018

blogofsysadmins.com

Mostrar información del certificado SSL desde consola (CLI)

Este pequeño post que os escribo hoy os va a servir a todos aquellos sysadmins, que quieran monitorizar en (nagios por ejemplo) o simplemente ver las fechas de expiración u otros datos de los certificados SSL desde consola. Para ver la fecha de expiración, usamos nmap: Articulos relacionados:Magazine Hacker Highschool [PDF] (0)Actualizar y recrear en …

by GhOsTi at November 19, 2018 12:24 PM

November 15, 2018

Sobre bits

PowerCLI one-liners: Habilitar masivamente ESXi Shell y SSH con PowerCLI

Si bien VMware te avisa con un bonito warning al activarlos, la ESXi Shell y la administración vía SSH son herramientas valiosísimas para hacer troubleshooting en nuestros servidores ESXi. En la entrada de hoy vamos a ver cómo habilitar de forma masiva ESXi Shell y SSH con PowerCLI en nuestros host ESXi para evitar tener que hacerlo a mano uno por uno.

¿Cómo habilitar ESXi Shell y SSH con PowerCLI?

Como siempre, antes de realizar cualquier acción en PowerShell/PowerCLI debemos buscar los cmdlets que nos pueden ayudar a realizar las acciones que necesitamos. Como en este caso lo que necesitamos es manejar los servicios de VMware podríamos hacer la siguiente búsqueda con Get-Command:

Cmdlets Servicios PowerCLI

Si utilizamos Get-VMHostService podemos ver qué servicios tienen nuestros ESXi y su estado:

Servicios ESXi Shell y SSH con PowerCLI

Como podemos ver marcados en rojo ya tenemos los dos servicios que buscamos: TSM (ESXi Shell) y TSM-SSH (SSH). Otras cosas interesantes que podemos observar en la captura son que los servicios no están habilitados (Policy = off) y que no están activos (Running = False). Si juntamos estas piezas con los cmdlets de la captura anterior ya tenemos el one-liner hecho:

Get-VMHost | Get-VMHostService | Where Key -like 'TSM*' | Set-VMHostService -Policy on -Confirm:$false | Start-VMHostService -Confirm:$false

Vamos a desglosar la línea:

  • Get-VMHost: Listamos todos los host.
  • Get-VMHostService | Where Key -like ‘TSM*’: Obtenemos los servicios y filtramos por los que en el campo Key contienen TSM (ESXi Shell y SSH).
  • Set-VMHostService -Policy on -Confirm:$false: Habilitamos el servicio ponendo el parámetro Policy a on.
  • Start-VMHostService -Confirm:$false: Arrancamos el servicio.

La salida del comando debería mostrarnos como ambos servicios han sido arrancados y habilitados:

Servicios ESXi arrancados

Bola extra: Quitar el warning ‘SSH está habilitado en este host’

Una vez ejecutado el one-liner, si nos conectamos a la consola de administración de un ESXi o de nuestro vCenter deberíamos ver este par de mensajes:

  • La shell de ESXi está habilitado en este host.
  • SSH está habilitado en este host.

SSH está habilitado en este host

Como decía al principio de la entrada, VMware nos muestra estos avisos porque son considerados una falla de seguridad. Si queréis asumir el riesgo y quitar estos mensajes, si bien como siempre podéis hacerlo desde la propia consola gráfica, podemos hacerlo con otro one-liner:

Get-VMHost | Set-VmHostAdvancedConfiguration -Name UserVars.SuppressShellWarning -Value 1

Conclusión

Y hasta aquí el one-liner de hoy. Podéis consultar los anteriores PowerCLI one-liners y los PowerShell one-liners desde sus respectivos tags.

¡Espero que os sirvan!

La entrada PowerCLI one-liners: Habilitar masivamente ESXi Shell y SSH con PowerCLI aparece primero en Sobrebits.

by Marc Meseguer at November 15, 2018 02:30 PM

RooTeando

Tomando Un Café 45: MineTime y Rwtxt.

En este audio hablaré de mi experiencia con dos aplicaciones , la primera es MineTime una aplicación de calendario simple y vistosa, la segunda aplicación es Rwtxt un CMS muy minimalista e interesante.

Música: Chad Crouch-Bird Watching: Piano Preludes-Western Tanager. http://freemusicarchive.org/

 


Si quieres apoyarme  de forma económica para mis podcast y canales, puedes realizarlo de diferentes formas:
PayPal   https://paypal.me/JoseAJimenez
Programa afiliado de Amazon  https://amzn.to/2Myjet8, si ...

November 15, 2018 10:21 AM

November 13, 2018

DaboBlog

Hablando de Software Libre y Seguridad en Oviedo

El pasado 20 de octubre tuve la oportunidad de dar una charla para el HackLab Pica Pica en unas jornadas sobre Software Libre organizadas por ellos (fueron también ellos quienes han hecho posible que venga Richard Stallman en dos ocasiones a Asturias).

Allí hablé de unas cuantas cuestiones sobre Seguridad. Desde planteamientos técnicos a otros más conceptuales. Os dejo un enlace al PDF de mi presentación con varios links dentro de él para que os podáis hacer una mejor idea de los temas que abarqué en el evento.

Un evento muy especial ya que mi hija de 6 meses estaba entre el público ;). La verdad es que con la gente de Pica Pica da gusto hacer cualquier tema. Son personas muy (muy) comprometidas con el Software Libre y a las que hay que apoyar sí o sí. Muchas gracias a ellos y a varios amigos que se pasaron por allí.

La entrada Hablando de Software Libre y Seguridad en Oviedo se publicó primero en DaboBlog.

by David Hernández (Dabo). at November 13, 2018 05:59 PM

Sobre bits

Ejecutar script de PowerShell como servicio de Windows

Lo más habitual cuando ejecutamos un script de PowerShell es que o bien lo ejecutemos a mano o bien lo hagamos automáticamente de forma periódica ejecutando PowerShell como tarea programada. En la entrada de hoy veremos un tercer escenario, ‘instalaremos’ un script de PowerShell como servicio de Windows.

¿Por qué ejecutar un script de PowerShell como servicio?

Si bien PowerShell no está diseñado para este tipo de uso, eso no quiere decir que no podamos hacerlo. Ejecutar un script de PowerShell como servicio de Windows nos va a permitir tenerlo corriendo las 24 horas del día y nos va a asegurar que si por cualquier motivo la máquina que lo ejecuta sufre un reinicio éste vuelva a ejecutarse.

Conociendo NSSM

NSSM (the Non-Sucking Service Manager) es una pequeña aplicación que nos va a permitir ejecutar cualquier binario como servicio de forma muy sencilla. Para nosotros el binario será el ejecutable de PowerShell que llamará al script que vamos a ejecutar.

Podemos descargar NSSM desde su página web. Como es una aplicación portable lo que descargaremos será un zip con la versión de 32bits y la de 64. Para hacer el proceso más sencillo podemos descomprimir el ejecutable directamente en C:\Windows\System32 para asegurarnos de que lo tenemos en nuestro PATH.

Diseñando el script de PowerShell

Tenemos que tener en cuenta que no cualquier script de PowerShell es apto para ser ejecutado como servicio. Necesitamos que la ejecución de nuestro script nunca finalice, porque de hacerlo simplemente nuestro servicio se pararía. Para no finalizar nunca la ejecución del script podemos valernos de un simple While:

# Creamos un bucle infinito para que la ejecución del script se mantenga
while ($true) {
    # Aquí dentro ejecutamos nuestro código
}

Otra cosa que deberemos tener en cuenta es cada cuanto queremos que se ejecute el bucle. Si el contenido de nuestro script realizara tareas demandantes de recursos y volviera a ejecutarse justo después de finalizar nos podríamos encontrar con que consumiera gran cantidad de recursos de nuestra máquina de forma continuada. Es por ello que es buena idea añadir un tiempo de espera después de cada ejecución que vendrá determinado por la acción que vaya a realizar el script:

# Creamos un bucle infinito para que la ejecución del script se mantenga
while ($true) {
    # Aquí dentro ejecutamos nuestro código

    # Paramos la ejecución durante 60 segundos
    Start-Sleep -Seconds 60
}

Para esta entrada vamos a hacer un script que se asegure de que el servicio spooler siempre esté ejecutándose, algo que a priori no parece muy útil pero que puede ser útil con algún otro servicio con tendencia a caerse.

# Creamos un bucle infinito para que la ejecución del script se mantenga
while ($true) {
    # Obtenemos el servicio Spooler
    $Servicio = Get-Service -Name spooler
    # Si tiene estado stopped lo volvemos a iniciar
    if ($Servicio.Status -eq 'stopped') {
        $Servicio | Start-Service
    }
    # Paramos la ejecución durante 60 segundos
    Start-Sleep -Seconds 2
}

‘Instalando’ el script de PowerShell como servicio de Windows

Ahora que ya tenemos instalado NSSM y tenemos a punto nuestro script de PowerShell podemos pasar a ‘instalarlo’ como servicio. Para ello abrimos una consola de PowerShell como administrador (también podríamos hacer esto desde cmd) y vamos a definir las variables que necesitaremos pasarle a NSSM:

# Nombre que daremos a nuestro servicio
$NombreServicio = 'Sobrebits'
# Ruta del ejecutable de PowerShell
$RutaPowershell = 'C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe'
# Argumentos a pasar al ejecutable de PowerShell:
# ExecutionPolicy para asegurarnos de que no se bloquea la ejecución del script
# File donde indicamos la ruta de nuestro script
$Argumentos= '-ExecutionPolicy Unrestricted -File C:\Scripts\Servicio_PowerShell.ps1'

Y por último ejecutaremos nuestro NSSM con las variables que acabamos de crear:

nssm install $NombreServicio $RutaPowershell $Argumentos

Si todo ha ido bien ya deberíamos ver ‘instalado’ nuestro script de PowerShell como servicio así que solo haría falta arrancarlo y ver si funciona:

Servicio Sobrebits

Si queremos eliminar el servicio siempre podemos hacerlo mediante:

nssm remove $NombreServicio confirm

Conclusión

Ejecutar un script de PowerShell como servicio de Windows abre un abanico aún más grandes de automatización a nuestros sistemas, así que espero que le podáis sacar partido a NSSM.

La entrada Ejecutar script de PowerShell como servicio de Windows aparece primero en Sobrebits.

by Marc Meseguer at November 13, 2018 08:00 AM

November 07, 2018

Sobre bits

Primeros pasos con Visual Studio Code para PowerShell

Cuando empezamos con cualquier lenguaje de scripting es habitual que editemos nuestros scripts utilizando cualquier editor de texto como Notepad en Windows o Vi en GNU/Linux. Por suerte cuando empiezas con PowerShell enseguida te encuentras con el más que funcional Windows PowerShell ISE, un editor que puede darnos muchas horas de scripting gracias a sus funciones integradas. En la entrada de hoy vamos a empezar con lo que probablemente sea una serie sobre las bondades de Visual Studio Code para PowerShell, un editor que va a llevar nuestras sesiones de programación al siguiente nivel.

Visual Studio Code para PowerShell

¿Qué es Visual Studio Code?

Visual Studio Code es un editor de código desarrollado por Microsoft que se encuentra disponible en Windows, GNU/Linux y MacOS. El programa es gratuito y de código abierto, y lo podemos descargar desde su página web. Visual Studio Code ofrece multitud de características, aquí van unas cuantas:

  • Soporte para extensiones con marketplace propio.
  • Integración con Git.
  • Debugging.
  • Interfaz de línea de comandos integrada.
  • Gestión de proyectos de código.
  • Temas personalizables.

Por defecto  en Visual Studio Code se incluye soporte para JavaScript, TypeScript, CSS o HTML, pero se puede extender dicho soporte mediante plugins, incluyendo el de Visual Studio Code para PowerShell. No vamos a profundizar en todas ellas, pero esta es una pequeña muestra de las características de Visual Studio Code para PowerShell:

  • Resaltado de sintaxis.
  • Snippets‘ de código reutilizables.
  • IntelliSense.
  • Análisis de código basado en PowerShell Script Analyzer.
  • Ayuda online de cmdlets.
  • Debugging con soporte de consola interactiva.
  • Búsqueda de referencias de cmdlets y variables.
  • Y mucho, mucho más.

Cómo empezar con Visual Studio Code para PowerShell

Empezar a desarrollar con VSCode para PowerShell no puede ser más sencillo: necesitamos instalar el software y después instalar el plugin de PowerShell y podemos ponernos en marcha.

Para instalar Visual Studio Code en cualquier plataforma deberemos dirigirnos a su página de descarga y obtener el instalador correspondiente. Una vez ejecutado el instalador no tendremos que hacer más que un next, next, finish para completarlo.

Cuando abrimos por primera vez el editor nos encontraremos con algo parecido a esto:

VSCode para PowerShell bienvenid
Para añadir el soporte de PowerShell para VSCode deberemos pulsar en Herramientas y lenguajes, que nos llevará al buscador de extensiones. Si hacemos un poco de scroll o directamente buscamos ‘PowerShell’ en el buscador encontraremos la extensión que buscamos:

VSCode para PowerShell instalarEvidentemente debemos pulsar sobre el botón Instalar para empezar con su instalación. Cuando ésta complete nos aparecerá el botón Recargar, con el que Visual Studio Code volverá a arrancar con la extensión de PowerShell ya cargada.

Primeros pasos con VSCode para PowerShell

Ahora que ya tenemos todo preparado para desarrollar nuestros scripts de PowerShell toca explorar un poco la interfaz de VSCode.

A mano izquierda veremos cinco iconos donde se concentra gran parte de la funcionalidad del editor:

  • Explorador: Desde aquí podremos realizar toda la gestión de carpetas y archivos y navegar por los mismos.
  • Buscar: Un buscador para encontrar trozos de código en nuestras carpetas y archivos abiertos y con el que podremos incluso reemplazar dichos trozos.
  • Control de código fuente: Desde aquí podremos interactuar con gestores de código fuente como Git directamente desde la interfaz de VSCode.
  • Depurar: Sección desde la que podremos depurar nuestro código.
  • Extensiones: Aquí podremos administrar todo lo relativo a las extensiones de Visual Studio Code. Es desde donde hemos instalado anteriormente la extension de PowerShell.

Si nos dirigimos a Explorador podremos pulsar sobre el botón Abrir carpeta y podremos abrir nuestra primera área de trabajo:

VSCode para PowerShell área de trabajoEs hora de editar un archivo .ps1 y ver cómo se presenta el editor:

Algunas cosas interesantes aquí:

  • En la parte superior podemos ver como se ha abierto el archivo en una pestaña. Podemos abrir las que queramos.
  • Vemos algunas de las funcionalidades del editor, como el resaltado de sintaxis o como se marca la apertura y cierre de las llaves.
  • En la parte inferior podemos ver la consola de PowerShell integrada. Desde aquí podremos ver la salida de nuestros scripts cuando los ejecutemos.
    • Podemos ver como existe un desplegable para elegir qué consola utilizar.
    • Con los botones a la derecha del desplegable anterior podemos abrir nuevas terminales, dividir la actual o eliminarla.

Por último, podemos iniciar la depuración de forma rápida pulsando F5 y ver como se ejecuta el script en la consola que tenemos abierta en la parte inferior:

Ejecución del script

Conclusión

En la entrada de hoy hemos rascado la superficie de Visual Studio Code para PowerShell, pero os recomiendo que instaléis esta joya de editor y empecéis a desarrollar vuestras funciones y scripts desde él, veréis que en cada menú existen pequeñas funcionalidades de lo más útiles. En futuras entradas traeremos vistas más en detalle de su funcionalidad.

¡Feliz automatización!

La entrada Primeros pasos con Visual Studio Code para PowerShell aparece primero en Sobrebits.

by Marc Meseguer at November 07, 2018 08:00 AM

November 04, 2018

CloudAdmins.org

Desplegando PaaS en un “click”

enter

Siguiendo en la línea del posts sobre Infraestructura como Código (IaC) con la herramienta Terraform, os traemos un nuevo tutorial para desplegar la plataforma de PaaS Rancher de forma totalmente automatizada utilizando RKE.

RKE es el acrónimo de Rancher Kubernetes Engine y se trata de un instalador de Kubernetes escrito en Golang. Es fácil de usar y no requiere mucha preparación por parte del usuario para comenzar.

Como en el tutorial anterior utilizaremos el provider de Terraform para OpenNebula, en esta ocasión utilizaremos una versión mejorada del provider desarrollado por el equipo de Blackberry.

Para acabar recordaros que el próximo 12 y 13 de Noviembre se celebra una nueva edición de la OpenNebulaConf en esta ocasión el lugar elegido a sido Amsterdam y algunos de los miembros de Cloudadmins estaremos allí y participaremos con la ponencia: Hybrid Clouds: Dancing with “Automated” Virtual Machines

Tutorial

Install Terraform

To install Terraform, find the appropriate package for your system and download it

$ curl -O https://releases.hashicorp.com/terraform/0.11.10/terraform_0.11.10_linux_amd64.zip

After downloading Terraform, unzip the package

$ sudo mkdir /bin/terraform
$ sudo unzip terraform_0.11.10_linux_amd64.zip -d /bin/terraform

After installing Terraform, verify the installation worked by opening a new terminal session and checking that terraform is available.

$ export PATH=$PATH:/bin/terraform
$ terraform --version

Add Terraform providers for Opennebula and RKE

You need to install go first: https://golang.org/doc/install

Install Prerequisites

$ sudo apt install bzr

Use the wget command and the link from Go to download the tarball:

$ wget https://dl.google.com/go/go1.10.linux-amd64.tar.gz

The installation of Go consists of extracting the tarball into the /usr/local

$ sudo tar -C /usr/local -xvzf  go1.10.linux-amd64.tar.gz 

We will call our workspace directory projects, but you can name it anything you would like. The -p flag for the mkdir command will create the appropriate directory tree

$ mkdir -p ~/projects/{bin,pkg,src}

To execute Go like any other command, we need to append its install location to the $PATH variable.

$ export PATH=$PATH:/usr/local/go/bin

Additionally, define the GOPATH and GOBIN Go environment variables:

$ export GOBIN="$HOME/projects/bin"
$ export GOPATH="$HOME/projects/src"

After go is installed and set up, just type:

$ go get github.com/blackberry/terraform-provider-opennebula
$ go install github.com/blackberry/terraform-provider-opennebula 

Post-installation Step

Copy your terraform-provider-opennebula binary in a folder, like /usr/local/bin, and write this in ~/.terraformrc:

$ sudo cp ~/projects/bin/terraform-provider-opennebula /usr/local/bin/terraform-provider-opennebula

For RKE provider, download the binary and copy in the same folder:

$ wget https://github.com/yamamoto-febc/terraform-provider-rke/releases/download/0.5.0/terraform-provider-rke_0.5.0_linux-amd64.zip 
$ sudo unzip terraform-provider-rke_0.5.0_linux-amd64.zip -d /usr/local/bin/terraform-provider-rke
providers {
  opennebula = "/usr/local/bin/terraform-provider-opennebula"
}

providers {
  rke = "/usr/local/bin/terraform-provider-rke"
}

Install Rancher

This repository provide a TF file to install Rancher in a high-availability configuration. The goal is easily install a Rancher on machines running CentOS 7.

Clone this repo:

$ git clone https://github.com/mangelft/terraform-rke-paas.git

Create infrastructure

First we have to initialize terraform simply with:

$ terraform init

This will read your configuration files and install the plugins for your provider.

We let terraform create a plan, which we can review:

$ terraform plan

The plan command lets you see what Terraform will do before actually doing it.

Now we execute:

$ terraform apply

terraform-apply

 

oneKubectl is the CLI tool for interacting with the Kubernetes cluster. Please make sure these tools are installed and available.

To make sure it works, run a simple get nodes command.

$ kubectl get nodes

kubectl

 

 

That’s it you should have a functional Rancher server. Point a browser at the hostname: https://rancher.my.org.

 

rancher-dashboard

 

by Miguel Angel Flores at November 04, 2018 08:43 PM

October 30, 2018

Sobre bits

Ejecutar script de PowerShell después de Sysprep

Recuerdo que uno de mis primeros casos de uso de PowerShell, que además hizo que empezara a profundizar en él, fue personalizar plantillas de sistemas operativos Windows recién desplegados. Si bien los distintos hipervisores ofrecen opciones de este tipo, ejecutar un script de PowerShell después de Sysprep es una solución que funcionará a través de cualquier hipervisor que utilicemos. En la entrada de hoy veremos cómo programar dicha ejecución y que no se destruya después del Sysprep.

¿Qué es Sysprep?

Si has llegado hasta aquí lo más probable es que sepas de sobras lo que es Sysprep, pero nunca está de más aclararlo. Sysprep es una utilidad de los sistemas operativos Windows que podemos encontrar en C:\Windows\System32\Sysprep con la que podemos preparar nuestras plantillas para poder ser desplegadas una y otra vez en un mismo entorno.

Básicamente lo que hace Sysprep es generalizar un sistema operativo quitándole los identificadores únicos al mismo, permitiendo así ser desplegado múltiples veces sin peligro de IDs duplicados.

Script de PowerShell después de Sysprep

¿Por qué ejecutar un script de PowerShell después de Sysprep?

Habitualmente lo que se hace con una plantilla de Windows es actualizar el sistema operativo, realizar las configuraciones oportunas en el sistema e instalar las aplicaciones que necesitemos. El problema es que después de generalizar una instalación con Sysprep las configuraciones del sistema pueden desaparecer, además de que hay otras que es posible que no podamos incluir en la plantilla o que sean variables según el rol del sistema a desplegar.

Ejecutar un script de PowerShell después de Sysprep nos va a permitir que justo después de hacer el primer login podamos personalizar todo lo que se nos ocurra del propio sistema.

¿Cómo ejecutar un script después de Sysprep?

Para programar la ejecución de un programa una sola vez después de iniciar el sistema es habitual utilizar la clave de registro: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce, pero como decía en el apartado anterior, muchas configuraciones se pierden al realizar Sysprep y ésta es una de ellas. Para saltarnos esta limitación podemos tirar del script SetupComplete.cmd.

SetupComplete.cmd es un script que podemos crear en C:\Windows\Setup\Scripts, que se ejecutará justo después del setup del sistema operativo. Si tenemos la suerte de que nuestra personalización puede correr desde un archivo .cmd podemos aplicar las configuraciones en dicho archivo, pero para usar un script de PowerShell deberemos tirar de la entrada de registro anteriormente mencionada. Éste sería el contenido de nuestro archivo SetupComplete.cmd:

REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v "PostDeploy" /d "C:\Windows\System32\WindowsPowerShell\v1.0\powershell -executionpolicy unrestricted -file C:\Scripts\Post-deploy.ps1" /t REG_SZ

Como siempre vamos a desglosar la línea, que ha quedado larguita:

  • REG ADD “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce: Añadimos una entrada de registro nueva en la ruta especificada.
  • /v “PostDeploy”: Especificamos el nombre de la entrada.
  • /d: Especificamos el contenido de la entrada de registro.
    • C:\Windows\System32\WindowsPowerShell\v1.0\powershell: Ejecutamos PowerShell.
    • -executionpolicy unrestricted: Establecemos la Execution Policy de la consola que abriremos a unrestricted para que no nos limite la ejecución de scripts.
    • -file C:\Scripts\Post-deploy.ps1: Establecemos la ruta completa del script de PowerShell que contiene nuestras personalizaciones.
    • /t REG_SZ: Establecemos el tipo de entrada de registro.

¿Qué podemos añadir en nuestro script de PowerShell después de Sysprep?

Básicamente podemos ejecutar cualquier cosa que se nos ocurra en nuestro scripts, pero si andas corto de ideas aquí van unas cuantas:

Y la lista podría seguir hasta el infinito según cada caso de uso.

Espero que el contenido de esta entrada os ayude a arañar unas cuantas horas al reloj gracias a la automatización. 🙂

La entrada Ejecutar script de PowerShell después de Sysprep aparece primero en Sobrebits.

by Marc Meseguer at October 30, 2018 08:00 AM

October 29, 2018

RooTeando

ARM para TODOS 05: Distribuciones para ARM

En este audio hablaré sobre placas con un tamaño pequeño, he realizado una lista con las siguientes placas.

🔹Cubox-i y Cubox pulse: página web
https://www.solid-run.com/product/cubox-i4x4/
https://www.solid-run.com/nxp-family/cubox-pulse/

Disponible en Amazon Cubox-i versión 2 GB RAM
https://amzn.to/2zsHycm

🔹 Vocore2: página web 
https://vocore.io/

Disponible en Amazon
https://amzn.to/2Ocm1gi

🔹Nanopi: Dispone de una familia de producto que destaca por su pequeño tamano. Un ...

October 29, 2018 12:33 AM

Tomando un Café 44: Crossover con Ugeek y Tomando Un Café

Otro audio especial y con invitado, en este caso con Angel de Ugeek, donde hemos hablado de Raspberry, Rock64 y los servicios que utilizamos ene ese dispositivos.

Lista de aplicaciones 
DietPi https://dietpi.com/
Raspbian http://www.raspbian.org/
TinyRSS https://tt-rss.org/
Volumio https://volumio.org/
Syncloud  https://syncloud.org/
Mumble https://www.mumble.info/
KeepassX https://www.keepassx.org/
Passman https://www.passman.cc/
Airsonic https://airsonic.github.io/
Subsonic http://www.subsonic ...

October 29, 2018 12:29 AM

Tomando Un Café 43: Sistemas Operativos y ecosistemas.

En este audio tendré una pequeña reflexión sobre las evolución de los sistemas operativos, también hablaré sobre los ecosistemas, que son, para que sirven y  las migraciones de ecosistemas.

Música: Dark Meat- When The Killer Came. http://freemusicarchive.org/

Si quieres apoyarme  de forma económica para mis podcast y canales, puedes realizarlo de diferentes formas:
PayPal   https://paypal.me/JoseAJimenez
Programa afiliado de Amazon  https://amzn.to/2Myjet8, si compras a través de ...

October 29, 2018 12:15 AM

October 24, 2018

Sobre bits

Descubriendo módulos: Copiar archivos de Linux con PowerShell

Hace unos días me encontré con la necesidad de añadir a uno de mis scripts de automatización la capacidad de copiar archivos de Linux con PowerShell y descubrí un módulo perfecto para ello. Es por ello que en la entrada de hoy retomamos la sección ‘Descubriendo módulos’ (aquí podéis ver la entrada anterior) en la que cacharrearemos con el módulo WinSCP de PowerShell y copiaremos archivos desde una máquina Windows a una GNU/Linux y viceversa.

¿Qué es WinSCP y SCP?

No pretendo descubrir a nadie qué es WinSCP, pero por si hubiera algún rezagado no está de más escribir un par de líneas al respecto. WinSCP es una aplicación libre (licenciada con GPL) para sistemas operativos Microsoft Windows que nos permite interactuar a nivel de archivos con otros sistemas mediante SCP, FTP, SFTP o WebDAV.

SCP (Secure Copy Protocol) es un protocolo que nos permite realizar transferencias entre dos máquinas de forma segura basándose en SSH para tal fin.

SCP sobre Windows con PowerShell

Aprovechando que casi todas las máquinas GNU/Linux incorporan SSH, SCP se convierte en una especie de estándar a la hora de copiar archivos entre máquinas con dicho sistema. El problema viene si queremos copiar archivos de Linux a Windows, puesto que las máquinas Windows no incorporan un cliente SCP por defecto, y aquí es donde WinSCP se ha hecho un hueco.

Si bien WinSCP incorpora opciones de línea de comandos, no existen cmdlets propios de PowerShell. Por suerte en nuestra querida PowerShell Gallery podemos encontrar un módulo de WinSCP para PowerShell listo para descargar:

Install-Module -Scope CurrentUser -Name WinSCP

Como siempre después de instalar un nuevo módulo en nuestra máquina podemos consultar las funciones instaladas por el mismo:

Copiar archivos de Linux con PowerShell

Conectando a una máquina Linux por SCP con PowerShell

Ahora que ya tenemos claro que tenemos instalado el módulo de WinSCP para PowerShell y que tenemos claro qué son SCP y WinSCP podemos ponernos manos a la obra.

Antes de realizar cualquier operación necesitaremos crear una sesión contra la máquina de destino mediante New-WinSCPItem. Para ello necesitaremos un objeto PSCredential que, o bien lo solicitamos con Get-Credential para realizar una sesión interactiva, o bien podemos guardarlo en un archivo XML como vimos en la entrada “Cómo gestionar las credenciales de un script de PowerShell“.

# Pedimos credenciales
$Creds = Get-Credential
# Configuramos los parámetros de la sesión
$WinScpSessionOption = New-WinSCPSessionOption -Credential $Creds -GiveUpSecurityAndAcceptAnySshHostKey -HostName 192.168.168.168 -Protocol Scp
# Establecemos la conexión
$WinScpSession = New-WinSCPSession -SessionOption $WinScpSessionOption

Vamos a explicar qué hemos hecho:

  • $Creds = Get-Credential: Pedimos credenciales de conexión a la máquina destino.
  • $WinScpSessionOption = New-WinSCPSessionOption: Creamos una nueva definición de opciones de WinSCP y la guardamos en la variable $WinScpSessionOption para reutilizarla en futuros comandos.
    • -Credential $Creds: Utilizamos las credenciales obtenidas en la línea anterior.
    • -GiveUpSecurityAndAcceptAnySshHostKey: Aceptamos cualquier clave de SSH.
    • -HostName 192.168.168.168: Establecemos el host de destino.
    • -Protocol Scp: Establecemos el protocolo a utilizar.
  • $WinScpSession = New-WinSCPSession -SessionOption $WinScpSessionOption: Utilizamos la variable creada en la línea anterior para generar una nueva sesión y guardarla en la variable $WinScpSession que utilizaremos durante la ejecución de nuestros comandos.

Copiar archivos de Linux con PowerShell

En este punto ya tenemos nuestra sesión en la variable $WinScpSession, así que ya podemos ponernos a copiar archivos en ambas direcciones.

Empezamos copiando archivos de Linux a Windows con PowerShell mediante Receive-WinSCPItem:

Receive-WinSCPItem -WinSCPSession $WinScpSession -RemotePath "/tmp/sobrebits.txt" -LocalPath 'C:\Windows\Temp'

Una explicación rápida:

  • WinSCPSession: Aquí introducimos la sesión creada en el paso anterior.
  • RemotePath: Ruta completa del archivo a copiar.
  • LocalPath: Ruta donde copiaremos el archivo.

Si en cambio queremos copiar archivos de Windows a Linux con PowerShell deberemos hacerlo con Send-WinSCPItem:

Send-WinSCPItem -WinSCPSession $WinScpSession -LocalPath 'C:\Windows\Temp\sobrebits.txt' -RemotePath "/tmp"

Ningún misterio aquí, mismas opciones que en la línea anterior pero cambia el sentido en el que copiamos el archivo.

Otras opciones interesantes de WinSCP para PowerShell

Si bien solo hemos visto cuatro de las funciones disponibles en este módulo existen un total de 23 funciones en el mismo (a la fecha de escribir este post), que por razones obvias no vamos a cubrir. No obstante os voy a enumerar los que me han parecido más interesantes:

  • Remove-WinSCPSession: Con el que desconectar sesiones existentes.
  • Move-WinSCPItem: Para mover o renombrar un archivo del sistema remoto.
  • Copy-WinSCPItem: Para copiar un archivo del sistema remoto.
  • Test-WinSCPPath: Con el que comprobar si existe un archivo o carpeta remoto.
  • Sync-WinSCPPath: Para sincronizar una carpeta local con otra remota.

Conclusión

Con el módulo de WinSCP para PowerShell podemos ampliar la gama de funcionalidad de nuestros scripts para que no solo interactuen con sistemas de ficheros locales, sino que también lo puedan hacer contra sistemas remotos GNU/Linux o incluso contra datastores de VMware vSphere (si el nodo en cuestión dispone de SSH habilitado).

Además, no olvidéis que más allá de SCP podéis conectaros a sistemas remotos mediante SFTP, FTP y WebDAV utilizando el mismo set de funciones.

¡Espero que os sirva!

La entrada Descubriendo módulos: Copiar archivos de Linux con PowerShell aparece primero en Sobrebits.

by Marc Meseguer at October 24, 2018 07:00 AM

October 23, 2018

DaboBlog

Entrevistado en el blog de Ontinet por María José Montes (ESET)

apachectlMi amiga María José Montes, Responsable de Ciberseguridad de ESET y participante activa en múltiples congresos de Hacking y eventos solidarios, me envío una serie de preguntas para el blog del Laboratorio de Ontinet. Hacía alusión a cuestiones profesionales de mi trabajo en APACHEctl y otras de índole más personal.

Sin más, os dejo con la entrevista. Respondí sin pensar mucho y dejándome llevar (que así las cosas salen con más espontaneidad-;).

Gracias amiga !!!

 

La entrada Entrevistado en el blog de Ontinet por María José Montes (ESET) se publicó primero en DaboBlog.

by David Hernández (Dabo). at October 23, 2018 04:18 PM

October 18, 2018

Sobre bits

PowerCLI one-liners: Listar identificador naa de un datastore

Cuando nos encontramos en la situación de tener que realizar algún tipo de troubleshooting en el storage de una solución VMware vSphere lo más típico es que tanto en la salida de comandos de PowerCLI o esxcli como en los logs del propio sistema se haga referencia a nuestros datastores por su identificador naa.*. En la entrada de hoy veremos un par one-liners con los que obtener el identificador naa de un datastore con PowerCLI.

One-liner 1: Buscando un datastore con su identificador naa

Uno de los casos típicos en los que podemos necesitar este one-liner es cuando un log hace referencia a un cambio de estado en un datastore y nos devuelve su identificador naa. Para encontrarlo rápido:

Get-Datastore | Where-Object {$_.ExtensionData.Info.Vmfs.Extent.DiskName -like “*ID_A_BUSCAR*”}

Vamos a repasar el one-liner:

  • Get-Datastore: Evidentemente, listamos todos los datastores del datacenter.
  • Where-Object {$_.ExtensionData.Info.Vmfs.Extent.DiskName: Filtramos por la propiedad DiskName (bien escondida debajo de ExtensionData) que nos devuelve el identificador naa del datastore.
  • -like “*ID_A_BUSCAR*”}: Buscamos el datastore que tenga como ID parte o toda la cadena que le facilitemos.

Un ejemplo en productivo:

Identificador naa de un datastore

One-liner 2: Obteniendo el identificador naa de todos los datastores

Si necesitamos hacer más de una consulta de la relación ID naa.* con su nombre de datastore, es posible que nos salga a cuenta sacarlos todos y guardarlos en vez de estar haciendo la consulta constantemente. Como ya sabemos cómo sacar el ID naa.* de un datastore con su propiedad de ExtensionData esto va a estar chupado:

Get-Datastore | Select-Object -Property Name,@{Name = 'Naa'; Expression = {$_.ExtensionData.Info.Vmfs.Extent.DiskName}}

Veamos qué hace el one-liner:

  • Get-Datastore: Evidentemente, volvemos a listar todos los datastores del datacenter.
  • Select-Object -Property Name: Seleccionamos la propiedad Name para formar el objeto de salida de nuestra línea.
  • @{Name = ‘Naa’; Expression = {$_.ExtensionData.Info.Vmfs.Extent.DiskName}: Seleccionamos para nuestro objeto de salida su segunda propiedad mediante una expresión.
    • En la propiedad Name indicamos el nombre de dicha propiedad. En este caso, en un alarde de originalidad, ‘Naa’.
    • En la propiedad Expression hacemos la misma query que en el anterior one-liner para sacar el identificador naa de los datastores mediante el objeto que nos viene del pipe.

Y por último vamos a ver cómo quedaría la salida del one-liner:

PS C:\Get-Datastore | Select-Object -Property Name,@{Name = 'Naa'; Expression = {$_.ExtensionData.Info.Vmfs.Extent.DiskName}}

Name             Naa
----             ---
datastore103     naa.123456789123c9d12366666dd7af1dc6d
datastore104     naa.123456789123123456fd66666b41e924
datastore105     naa.123456789123809ffa44b7766666a91a
datastore106     naa.12345678912397340a666668898e3133
datastore107     naa.123456789123b9c46d85196666632bd5
datastore108     naa.12345678912345bab066666d92b70b8f
datastore109     naa.123456789123c3945fef8666663772e6
datastore110     naa.12345678912304e5666663a38cedbd46

¡Espero que os sirvan estos one-liners de hoy!

La entrada PowerCLI one-liners: Listar identificador naa de un datastore aparece primero en Sobrebits.

by Marc Meseguer at October 18, 2018 07:00 AM

October 16, 2018

Sobre bits

Detectar VMs no respaldadas por Veeam con PowerCLI (Parte 2)

En esta segunda y última parte de la entrada seguiremos justo donde lo dejamos en la anterior y añadiremos un poco más de funcionalidad a nuestro script buscador de máquinas virtuales fuera de backup. Concretamente veremos cómo gestionar excepciones y cómo enviar notificaciones de correo periódicas.

  1. Detectar VMs no respaldadas por Veeam con PowerCLI (Parte 1).
  2. Detectar VMs no respaldadas por Veeam con PowerCLI (Parte 2).

En la entrada anterior nos quedamos con un pequeño script con el que ya conseguíamos sacar las máquinas virtuales sin backup pero poco más:

# Obtenemos todas las máquinas virtuales de la infraestructura que estén encendidas
$Vms = Get-VM | Where-Object PowerState -eq 'PoweredOn'

# Declaramos un array vacío donde almacenar los nombres de las VMs fuera de backup
$VmsSinBackup = @()

# Recorremos la colección de VMs
ForEach ($Vm in $Vms) {
    # Si la VM tiene el Custom Attribute "Sobrebits" sin contenido...
    If (!$Vm.CustomFields.Item("Sobrebits")) {
        # ... añadimos dicha VM a nuestra array de VMs no respaldadas por Veeam
        $VmsSinBackup += $Vm.Name
    }
}
# Mostramos las $VmsSinBackup
$VmsSinBackup

Gestionando las excepciones

Tarde o temprano utilizando este script os encontraréis con la situación en la que se reporta una máquina virtual fuera de backup que realmente debería estarlo, ya sea porque es una máquina de test, una demo o cualquier otra situación. En esta parte vamos a añadir de una forma extremadamente sencilla un archivo de excepciones donde iremos añadiendo el nombre de dichas máquinas virtuales fuera de backup.

Lo primero que haremos será guardar nuestro script en una carpeta, para este ejemplo será C:\Scripts\Get-VmNoBackup.ps1. Un ejemplo de la salida del script sin excepciones sería este:

Máquinas virtuales fuera de backupSabiendo la salida del script podemos proceder a crear el archivo de excepciones, con el que quitaremos las VMs de test de nuestro listado. Nuestro archivo de excepciones simplemente será un archivo .txt ubicado en la misma carpeta del script:  C:\Scripts\Get-VmNoBackup_Excepciones.txt.

PS C:\Scripts> Get-ChildItem
Get-VmNoBackup.ps1
Get-VmNoBackupExcepciones.txt

La idea es que en dicho archivo de excepciones añadamos un nombre de VM por línea, en nuestro caso quedaría así:

Excepciones máquinas virtuales fuera de backupA partir de ahí solo nos queda leer el contenido de dicho archivo utilizando Get-Content y añadir este criterio al if en el que checkeamos si existe el Custom Attribute:

# Leemos el archivo de excepciones
$Excepciones = Get-Content -Path "$PSScriptRoot\Get-VmNoBackup_Excepciones.txt"

# Obtenemos todas las máquinas virtuales de la infraestructura que estén encendidas
$Vms = Get-VM | Where-Object PowerState -eq 'PoweredOn'

# Declaramos un array vacío donde almacenar los nombres de las VMs fuera de backup
$VmsSinBackup = @()

# Recorremos la colección de VMs
ForEach ($Vm in $Vms) {
    # Si la VM tiene el Custom Attribute "Sobrebits" sin contenido...
    If (!$Vm.CustomFields.Item("Sobrebits") -and $Excepciones -notcontains $Vm.Name) {
        # ... añadimos dicha VM a nuestra array de VMs no respaldadas por Veeam
        $VmsSinBackup += $Vm.Name
    }
}
# Mostramos las $VmsSinBackup
$VmsSinBackup

Repasemos las modificaciones:

  • En la línea 2 leemos mediante Get-Content el contenido del archivo de excepciones y lo añadimos a la variable $Excepciones.
  • En la línea 13 añadimos una nueva condición al if en la que el nombre de la VM ($Vm.Name) no debe estar dentro del array de $Excepciones.

Y este es el resultado de ejecutar el script con las últimas modificaciones:

Máquinas virtuales sin backup con excepcionesComo podemos ver ya no aparecen las VMs Sobrebits-Test1 y Sobrebits-Test2.

Otra aproximación para gestionar las excepciones podría ser utilizar tags de vSphere sobre las máquinas virtuales que podrían ser leídos por nuestro script, poner excepciones de carpetas o básicamente cualquier criterio que se os ocurra.

Enviando el resultado del script vía correo electrónico

Para brindar un poco más de funcionalidad al script podemos hacer que éste nos envíe un reporte con las máquinas virtuales fuera de backup por correo electrónico tal como vimos en la entrada “Enviar correo desde PowerShell”.

Para ello necesitaremos de un servidor SMTP desde el que estemos autorizados a enviar correo y hacer unas pequeñas modificaciones a nuestro script.

En primer lugar deberemos configurar los parámetros para la conexión smtp:

# Establecemos configuración SMTP
$from = "[email protected]"
$to = "[email protected]"
$subject = "Máquinas virtuales fuera de backup"
$smtpserver = "mail.sobrebits.com"
$smtpport = 25

Y al final del script, en vez de mostrar el contenido enviamos el correo electrónico (siempre y cuando existan máquinas virtuales fuera de backup):

# Si existen máquinas virtuales fuera de backup...
if ($VmsSinBackup) {
    # ... enviamos correo
    Send-MailMessage -From $from -To $to -Subject $subject -Body $($whitelist -join "`n") -SmtpServer $smtpserver -Port $smtpport
}

Aquí no hay mucho que explicar puesto que no hemos hecho nada que no hicieramos ya en “Enviar correo desde PowerShell”, simplemente aclarar que en el parámetro -Body concatenamos el array y lo juntamos con retornos de carro puesto que esta variable espera un string.

Últimos retoques

Lo último que queda para dar por finalizado nuestro script es programar su ejecución. No voy a explicar al detalle cómo hacerlo puesto que ya se ha tratado en anteriores entradas, aquí os dejo las referencias:

Por último decir que con este método si eliminamos una máquina de backup va a seguir reportándose como máquina dentro de backup puesto que el Custom attribute no se borra al quitar la máquina de Veeam. Es por ello que os recomiendo periódicamente eliminar el contenido del Custom Attribute mediante Set-Annotation sobre todas las máquinas virtuales del entorno.

Poniéndolo todo junto

Después de seguir el proceso de las dos partes de esta entrada debería quedar un script parecido a este:

# Conectamos a vCenter
$vcenter_ip = "192.168.168.168"
$vcenter_creds = Import-Clixml -Path "$PSScriptRoot\VMware_creds.xml"
Connect-VIServer -Server $vcenter_ip -Credential $vcenter_creds -WarningAction SilentlyContinue | Out-Null

# Establecemos configuración SMTP
$from = "[email protected]"
$to = "[email protected]"
$subject = "Máquinas virtuales fuera de backup"
$smtpserver = "mail.sobrebits.com"
$smtpport = 25

# Leemos el archivo de excepciones
$Excepciones = Get-Content -Path "$PSScriptRoot\Get-VmNoBackup_Excepciones.txt"

# Obtenemos todas las máquinas virtuales de la infraestructura que estén encendidas
$Vms = Get-VM | Where-Object PowerState -eq 'PoweredOn'

# Declaramos un array vacío donde almacenar los nombres de las VMs fuera de backup
$VmsSinBackup = @()

# Recorremos la colección de VMs
ForEach ($Vm in $Vms) {
    # Si la VM tiene el Custom Attribute "Sobrebits" sin contenido...
    If (!$Vm.CustomFields.Item("Sobrebits") -and $Excepciones -notcontains $Vm.Name) {
        # ... añadimos dicha VM a nuestra array de VMs no respaldadas por Veeam
        $VmsSinBackup += $Vm.Name
    }
}

# Si existen máquinas virtuales fuera de backup...
if ($VmsSinBackup) {
    # ... enviamos correo
    Send-MailMessage -From $from -To $to -Subject $subject -Body $($whitelist -join "`n") -SmtpServer $smtpserver -Port $smtpport
}

# Desconectamos del vCenter
Disconnect-VIServer -Confirm:$false

¡Espero que esta doble entrada os sirva para ahorraros disgustos de cara a futuro!

La entrada Detectar VMs no respaldadas por Veeam con PowerCLI (Parte 2) aparece primero en Sobrebits.

by Marc Meseguer at October 16, 2018 07:00 AM

October 10, 2018

Sobre bits

Detectar VMs no respaldadas por Veeam con PowerCLI (Parte 1)

Si hay algo que absolutamente siempre debemos tener controlado al dedillo en nuestra infraestructura es el backup, puesto que es ese salvavidas del que siempre vamos a poder tirar en caso de desastre. Una problemática habitual cuando los entornos vSphere empiezan a crecer y cuando muchas manos tocan un mismo entorno es la posibilidad de quedarnos con VMs fuera de backup y, lo más peligroso, sin que nadie se de cuenta de ello. Es por ello que en la entrada de hoy veremos cómo detectar VMs no respaldadas por Veeam Backup de forma automatizada mediante, como no, PowerCLI.

Dejando huella en las VMs respaldadas con Veeam

El primer paso antes de ponernos a picar código de PowerCLI será pasarnos por nuestro (o nuestros) servidor de Veeam para reconfigurar los jobs de backup y hacer que éstos dejen huella en las máquinas virtuales que respalde. La “huella” que dejará en nuestras máquinas virtuales respaldadas será un Custom Attribute de VMware que utilizaremos posteriormente para hacer querys desde PowerCLI.

Editar job de Veeam

Posteriormente nos dirigimos al apartado Storage y pulsamos sobre el botón Advanced.

Veeam editar storage

Una vez aquí debemos desplazarnos a la pestaña Notifications. En la parte inferior encontraremos el campo “Set succesful backup details to this VM attribute”. Deberemos habilitar esta opción y añadir un nombre en el campo de texto correspondiente, que será el nombre del Custom Attribute que se añadirá a la VM.

Custom Attribute Veeam

La forma en que funciona este parámetro es que cuando un backup ha finalizado de forma exitosa sobre una máquina virtual Veeam añade a la misma un nuevo Custom Attribute (si no lo hubiera) y le añade la fecha de dicho backup. Si miramos los Custom Attribute de una VM con backup correcto deberíamos ver algo parecido a esto:

Custom Attribute VM Veeam

Buscando el Custom Attribute con PowerCLI

Vale, ya tenemos funcionando la base sobre la que nuestro script buscará VMs no respaldadas por Veeam, ahora tenemos que construir la query que necesitamos para encontrar dichas VMs.

Para ello vamos a empezar obteniendo todas las VMs que queremos revisar y vamos a ponerlas en una variable para gestionarlas de forma más fácil en el futuro:

$Vms = Get-VM | Where-Object PowerState -eq 'PoweredOn'

En este caso unicamente saco las VMs encendidas, pero podemos hacer la query por un determinado cluster, host o lo que necesitemos.

Ahora que ya tenemos las VMs a escanear en nuestra variable pasaremos a recorrerlas todas en busca de las que no tengan nuestro Custom Attribute lleno. Aquí va el código que os propongo con sus respectivos comentarios:

# Declaramos un array vacío donde almacenar los nombres de las VMs fuera de backup
$VmsSinBackup = @()

# Recorremos la colección de VMs
ForEach ($Vm in $Vms) {
    # Si la VM tiene el Custom Attribute "Sobrebits" sin contenido...
    If (!$Vm.CustomFields.Item("Sobrebits")) {
        # ... añadimos dicha VM a nuestra array de VMs no respaldadas por Veeam
        $VmsSinBackup += $Vm.Name
    }
}

Con esto ya tenemos una variable $VmsSinBackup con todas las VMs no respaldadas en nuestra infraestructura.

Conclusión

Hasta aquí la primera parte de esta entrada. En la segunda parte aplicaremos un poco más de inteligencia a nuestro script añadiendo la posibilidad de añadir excepciones y notificaciones por correo. ¡Muy pronto en Sobrebits!

La entrada Detectar VMs no respaldadas por Veeam con PowerCLI (Parte 1) aparece primero en Sobrebits.

by Marc Meseguer at October 10, 2018 08:00 AM

October 05, 2018

MagMax Blog

Hosting

En el mundo hay distintas soluciones para albergar tus proyectos en internet. Aquí tenéis un pequeño repaso a algunas de las que he probado.

Leer más… (quedan 4 minutos de lectura)

by Miguel Ángel García at October 05, 2018 03:23 AM

October 04, 2018

RooTeando

Diario de Aprendizaje: 01 Libreta de conocimiento y desarrollo

Presentación de un nuevo proyecto en formato minipodcast, 5 minutos de duración, donde hablaré sobre aprendizaje y programación.

Primer episodio de este minipodcast donde hablare sobre estas dos libretas (de papel), que son y para que las utilizo.


Métodos de contacto, los mismo que para el podcast Tomando Un Cafe.

Correo [email protected]

Twitter https://twitter.com/Tomando_Un_Cafe


RSS
Anchor.fm http://anchor.fm/s/18c0860/podcast/rss
Blog(post y audios) https://rooteando ...

October 04, 2018 10:42 PM

ARM para TODOS: 04 Placas pequeñas para ARM

En este audio hablaré sobre placas con un tamaño pequeño, he realizado una lista con las siguientes placas.

🔹Cubox-i y Cubox pulse: página web
https://www.solid-run.com/product/cubox-i4x4/
https://www.solid-run.com/nxp-family/cubox-pulse/

Disponible en Amazon Cubox-i versión 2 GB RAM
https://amzn.to/2zsHycm

🔹 Vocore2: página web 
https://vocore.io/

Disponible en Amazon
https://amzn.to/2Ocm1gi

🔹Nanopi: Dispone de una familia de producto que destaca por su pequeño tamano. Un ...

October 04, 2018 10:25 PM

ARM para TODOS: 03 Almacenamiento en ARM

Nuevo audio donde hablaré de las diferentes opciones de almacenamiento disponible para nuestras pequeñas placas ARM
Lo he dividido en tres categorías

🔹Almacenamiento externo: Tarjetas SD y microSD, eMMC y USB.
🔹 SATA y mSATA: Incluye SATA nativo como mediante conversores USB a SATA.
🔹  PCI-Express:  Memorias M.2, con adaptador puertos SATA.


Música: The Freak Fandango Orchestra - Tales of a dead fish- 01. Requiem for a Fish http://freemusicarchive.org


Si quieres apoyarme  de forma económica ...

October 04, 2018 10:10 PM

October 03, 2018

Sobre bits

Versión de PowerShell según sistema operativo

Uno de los factores determinantes a la hora de diseñar una tarea de automatización con PowerShell es asegurarnos de que los cmdlets que vamos a utilizar estén disponibles en la versión de PowerShell que corre en la máquina que ejecuta el código. En la entrada de hoy me gustaría compartir con vosotros un par de chuletas que he creado para hacer la consulta más sencilla.

Versión de PowerShell por defecto y máxima según sistema operativo

A continuación os pongo una tabla con el resumen de la versión por defecto de PowerShell de cada versión de sistema operativo Windows así como la versión máxima a la que se puede actualizar:

Versión de PowerShell por defecto
*Hay que instalar la característica a través de Server Manager.

Sistemas operativos soportados según versión de PowerShell

Básicamente se trata de la misma tabla anterior pero girada para poder ver rápidamente los sistemas operativos que soportan una determinada versión de Windows PowerShell:

Versión windows segun PowerShell*Hay que instalar la característica a través de Server Manager.

Bola extra: Cómo determinar la versión instalada de PowerShell

Por último, si queremos determinar la versión actual de PowerShell de nuestra máquina deberemos abrir una sesión de terminal y consultar la variable $PSVersionTable.

Versión actual PowerShellEsta variable está disponible en todas las versiones de PowerShell (incluido PowerShell Core) así como en todas las versiones de sistema operativo que pueden correr la shell.

La entrada Versión de PowerShell según sistema operativo aparece primero en Sobrebits.

by Marc Meseguer at October 03, 2018 07:00 AM

September 27, 2018

Sobre bits

PowerShell one-liners: Contraseña nunca expira en usuario local

Después de tres meses desde la última entrada retomamos la sección de PowerShell one-liners. En la entrada de hoy veremos cómo configurar un usuario local para habilitar el flag “La contraseña nunca expira” con PowerShell, y lo haremos siguiendo donde nos quedamos en la entrada anterior, utilizando WMI.

Contraseña nunca expira

¿Por qué modificar un usuario local con WMI y PowerShell?

Si después de leer la introducción de la entrada os ha dado por abrir una terminal de PowerShell con una máquina Windows 10 o 2016 y habéis buscado cmdlets relacionados con usuarios locales habréis visto algo parecido a esto:

Password usuario local no caduque PowerShell

No me he vuelto loco, no voy a complicar las cosas con WMI por gusto, el problema de estos cmdlets es que fueron introducidos en PowerShell 5.1, por lo que una máquina recién instalada sólo dispondrá de ellos a partir de Windows 10/2016. Es por ello que, si nos queremos asegurar la retrocompatibilidad con versiones anteriores de sistema operativo, es mejor que lo hagamos con WMI y aseguremos el tiro.

Impedir que el password de un usuario local caduque con PowerShell

Una vez hecha esta pequeña aclaración vamos directos al one-liner:

Get-CimInstance -ClassName Win32_UserAccount | Where Name -eq Administrador | Set-CimInstance -Argument @{PasswordExpires=0}

Y como siempre vamos a desglosar la línea:

  • Get-WmiObject -Class Win32_UserAccount: Consultamos la clase Win32_UserAccount, que nos muestra los usuarios locales de nuestra máquina.
  • Where Name -eq Administrador: Filtramos por el usuario administrador.
  • Set-CimInstance: Modificamos el objeto que proviene del pipeline.
  • -Argument @{PasswordExpires=0}: Establecemos la propiedad PasswordExpires a 0 (false).

Si quisieramos hacerlo con los cmdlets de WMI en vez de los de CIM para asegurar aún más la compatibilidad hacia atrás nuestro one-liner sería así:

Get-WmiObject -ClassName Win32_UserAccount | Where Name -eq Administrador | Set-WmiInstance -Argument @{PasswordExpires=0}

Y hasta aquí el one-liner de hoy, ¡espero que os ayude en vuestras automatizaciones!

La entrada PowerShell one-liners: Contraseña nunca expira en usuario local aparece primero en Sobrebits.

by Marc Meseguer at September 27, 2018 07:00 AM

September 25, 2018

Sobre bits

Utilizando CIM y WMI con PowerShell

Si bien los cmdlets incorporados en PowerShell nos ofrecen la posibilidad de interactuar con multitud de aspectos de una máquina, hay veces que podemos necesitar consultar o modificar un determinado atributo y nos encontramos con que ningún cmdlet nos lo permite. En la entrada de hoy vamos a ver cómo utilizar CIM y WMI con PowerShell para intentar combatir estas situaciones.

¿Qué son CIM y WMI?

CIM (Common Information Model) es un estándar abierto creado por la organización DMTF orientado a proveer una definición común para el intercambio de información entre sistemas, redes, aplicaciones y servicios.

WMI (Windows Management Instrumentation) es la implementación de Microsoft de CIM, con la que se proveen métodos para consultar y modificar la configuración de una máquina Windows. Si bien el primer sistema operativo de Microsoft que traía WMI instalado fue Windows 2000 la simplificación de su uso vino con PowerShell donde desde la versión 1 se dispuso del primer cmdlet con el que consultar los métodos de una forma muy sencilla.

¿Cmdlets CIM o WMI?

Si bien no vamos a entrar al detalle existen dos juegos de cmdlets relacionados con CIM/WMI:

WMI con PowerShell

Los cmdlets Wmi* fueron los que aparecieron primero pero a partir de Windows PowerShell 3 fueron sustituidos por los CimCmdlets. Si bien estos cmdlets aún son accesibles se espera que tarde o temprano desaparezcan de PowerShell por lo que es mejor usar los “nuevos” CimCmdlets. Algunas de las mejoras incorporadas por los CimCmdlets son las siguientes:

  • Utilizan WinRM (WS-Man) para la comunicación con máquinas remotas, un protocolo mucho más moderno y “Firewall friendly” que DCOM, utilizado por Wmi*.
  • Permite el uso de sesiones mediante New-CimSession con el que poder invocar comandos remotos reutilizando dicha conexión.
  • Mejoran la gestión de la información devuelta.

Un muy buen post sobre las diferencias entre ellos es este.

Cómo listar todas las clases disponibles de WMI con PowerShell

Una vez sabemos lo que es WMI/CIM y hemos visto las diferencias entre los cmdlets CIM* y WMI* podemos pasar de una vez a la acción (sí, en este post me he alargado bastante con los preliminares). Para listar todas las clases de WMI/CIM que tenemos disponibles podemos valernos del cmdlet Get-CimClass:

Clases WMI con PowerShell

Como podemos ver por la salida del segundo comando existen en mi máquina 1202 clases disponibles con las que jugar.

Si vemos el detalle, por ejemplo, de Win32_OperatingSystem podemos ver que esta clase dispone de métodos que podemos invocar y propiedades que podemos consultar y en algunos casos modificar:

Detalle CIM Class con PowerShell

Consultando clases WMI con PowerShell

Siguiendo con el ejemplo de Win32_OperatingSystem vamos a instanciar la clase para ver qué información nos devuelve. Para instanciar una clase nos valdremos de Get-CimInstance:

Detalle CIM Class 2

(La salida del comando saca mucha más información, pero para la entrada con esto nos vale)

Como podemos ver en la captura el comando nos muestra mucha información que con cmdlets corrientes podría ser difícil o imposible de sacar, como la fecha de instalación del sistema operativo, y no solo eso, sino que además lo hace a gran velocidad.

Modificar propiedades WMI con PowerShell

Más allá de consultar las propiedades WMI de una máquina podemos, siempre y cuando dicha propiedad lo permita, modificar su valor utilizando el cmdlet Set-CimInstance.

Antes que nada buscaremos una propiedad que podamos escribir. Para ello volveremos a recurrir a Get-CimClass y veremos el detalle de las propiedades de Win32_UserAccount filtrando por las que no tienen el flag ReadOnly:

Propiedades WMI con PowerShell

Como vemos disponemos de, por ejemplo, la propiedad FullName que utilizaremos para ver cómo realizar modificaciones con Set-CimInstance (deberemos abrir PowerShell como administrador):

Modificando WMI con PowerShell

Conclusión

Aprender a interactuar con WMI/CIM desde PowerShell puede ayudarnos a multiplicar sustancialmente la cantidad de cosas que podemos realizar con nuestros sistemas operativos, por lo que espero que os haya sido de utilidad esta entrada para ampliar aún más vuestras posibilidades con PowerShell.

En futuras entradas intentaremos sacar partido de esta interfaz y ahondaremos más en sus posibilidades.

La entrada Utilizando CIM y WMI con PowerShell aparece primero en Sobrebits.

by Marc Meseguer at September 25, 2018 08:00 AM

September 21, 2018

blog de Rodolfo Pilas

fingerprint de certificados ssh

Con el tiempo uno va coleccionando muchos certificados, algunos dedicados a un determinado proyecto, otros dedicados a algun cliente y, por supuesto los propios. En ese repositorio de certificados que suele ser la carpeta ~/.ssh/ hay que agregar los certificados que por algun motivo distribuimos en algunos servidores… en fin, llegará el día que necesitemos identificar algun certificado privado.

Así que estos son los comandos para obtener el fingerprint (huella dactilar) de certificados privados.

Certificado ssh

$ openssl rsa -in id_rsa -pubout -outform DER | openssl md5 -c
Enter pass phrase for .ssh/id_rsa:
writing RSA key
a2:d7:19:27:fa:89:43:aa:59:fd:ac:eb:71:3f:fb:a8

Como ven, mi certificado privado tiene passphrase y, para leerlo se require que la escriba.

Certificado pem (AWS)

openssl pkcs8 -in .ssh/proyectoX  -inform PEM -outform DER -topk8 -nocrypt | openssl sha1 -c
d3:ff:c0:cf:6f:25:a1:88:b5:c7:9e:9b:ba:b9:57:a4:bb:45:62:68

Los certificados que creamos en AWS se suelen guardar sin passphrase y el fingerprint se muestra inmediatamente.

by pilasguru at September 21, 2018 01:11 PM

September 20, 2018

Sobre bits

Cómo utilizar el historial de PowerShell

Algo que nos pasa a todos cuando utilizamos cualquier tipo de shell es encontrarnos con la necesidad de consultar comandos escritos minutos o días atrás e incluso volver a ejecutarlos. En GNU/Linux disponemos del comando history, y en la entrada de hoy veremos qué opciones tenemos para trabajar con el historial de PowerShell.

Comandos relacionados con el historial de PowerShell

Como siempre, cuando queremos descubrir cmdlets relacionados con una determinada acción debemos acudir al comando Get-Command, con el que consultar dentro de nuestros módulos disponibles. En este caso queremos interactuar con el historial de PowerShell, por lo que la búsqueda es sencilla:

PS C:\ Get-Command -Noun history

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Add-History                                        3.0.0.0    Microsoft.PowerShell.Core
Cmdlet          Clear-History                                      3.0.0.0    Microsoft.PowerShell.Core
Cmdlet          Get-History                                        3.0.0.0    Microsoft.PowerShell.Core
Cmdlet          Invoke-History                                     3.0.0.0    Microsoft.PowerShell.Core

Consultando el historial de PowerShell

Empecemos el repaso por consultar el histórico de comandos ejecutados. Para tal efecto, como podemos deducir de los cmdlets mostrados anteriormente nos valdremos de Get-History:

Consultar historial de PowerShell

Es importante tener en cuenta algunas cosas acerca de Get-History:

  • Con Get-History unicamente podremos ver los comandos ejecutados en la sesión actual de PowerShell. Esto quiere decir que si cerramos la terminal y volvemos a abrirla veremos un historial vacío.
  • Get-History dispone de un máximo de entradas “retenidas” en el historial que, a partir de PowerShell 3.0 es de 4096 entradas. Se puede consultar y cambiar dicha configuración desde la variable $MaximumHistoryCount.
  • Disponemos de un alias con el que ejecutar este cmdlet: h.

Volviendo a ejecutar entradas del historial

Como hemos visto en el punto anterior con Get-History obtenemos dos parámetros: un ID y el comando ejecutado. Con Invoke-History (y su utilísimo alias r) podemos utilizar esta relación ID-comando para ejecutar comandos de nuestro historial. La ejecución es muy simple:

Ejecutar historial de PowerShellDe no facilitar un Id se ejecutará la última entrada de nuestro historial.

Ejecutando entradas del historial aún mejor

Si bien utilizar el método para ejecutar entradas del historial de PowerShell anteriormente mostrado es rápido (sobretodo utilizando los alias h y r) disponemos de una forma aún mejor de buscar y ejecutar entradas anteriores. Si desde nuestra terminal pulsamos la combinación Ctrl+R podremos acceder a la función de búsqueda de nuestro historial:

Búsqueda en historial de PowerShellComo podemos ver en la captura, dado que yo recordaba haber ejecutado un comando que contenía la palabra “test” al escribirla después de la combinación Ctrl+R se ha rellenado mi línea de comandos actual con dicho comando. Algunas cosas interesantes que saber sobre este método:

  • La búsqueda se realiza de forma inversa, es decir, el primer resultado que aparecerá será el que hayamos ejecutado último.
  • Podemos desplazarnos por la búsqueda con Ctrl+R (seguiremos avanzando de forma inversa) y Ctrl+S (retrocederemos en la búsqueda inversa).
  • Una vez nos hayamos desplazado hasta el comando buscado con apretar la tecla Enter ejecutaremos dicho comando.
  • Los resultados que obtendremos del historial son de la propia sesión de PowerShell que estamos ejecutando o de anteriores, al contrario que con Get-History que únicamente obtendremos resultados de la sesión activa.

Exportando, borrando e importando el historial

Otra de las cosas interesantes que podemos hacer con el historial es transportarlo a otra máquina o guardarlo para examinarlo en otro momento. Esto puede ser interesante si hemos realizado un procedimiento y queremos acabar de documentarlo a posteriori o queremos replicarlo en otra máquina.

Para exportar el historial de PowerShell lo que tenemos que hacer es listarlo con Get-History y pasarlo a csv o xml con Export-Csv o Export-CliXml respectivamente.

PS C:\> Get-History | Export-Clixml -Path 'C:\Export\history.xml'

Una vez hecho podemos pasar a borrar el historial de nuestra sesión con Clear-History:

Borrar historial de PowerShellEn este caso borramos el historial entero, pero si indicamos un parámetro -Id podemos borrar de forma selectiva una entrada concreta.

Por último vamos a ver cómo importar el historial previamente exportado. Para ello utilizaremos Import-CliXml para importar el archivo previamente exportado y Add-History para poner su contenido en el historial.

Importar historial de PowerShell

La entrada Cómo utilizar el historial de PowerShell aparece primero en Sobrebits.

by Marc Meseguer at September 20, 2018 08:00 AM

September 19, 2018

blogofsysadmins.com

OVH: Configurar red modo bridge en VM UBUNTU 18

Buenas tardes señores y señoras. Después de un par de tickets intercambiados con el soporte de OVH, he dado con la configuración válida para configurar la red de una máquina virtual. Deciros que no actualmente a fecha de 19 de septiembre 2018 no hay guía en español para configurar Ubuntu 18 en una máquina virtual, …

by GhOsTi at September 19, 2018 06:36 PM

RooTeando

Tomando Un Café 42: Aprendizaje y programación con Alfonso Rovira.

Este es un audio especial, porque lo he grabado con un invitado, Alfonso Rovira, y con una duración bastante mas grande de lo habitual. Tenemos un charla informal donde hablamos de nuestra preferencias a la hora de aprender un lenguaje de programación.  


Si quieres apoyarme  de forma económica para mis podcast y canales, puedes realizarlo de diferentes formas:
PayPal   https://paypal.me/JoseAJimenez
Programa afiliado de Amazon  https://amzn.to/2Myjet8, si ...

September 19, 2018 12:04 AM

September 18, 2018

soyadmin.com

Convertir la salida del comando man a PDF

El comando man nos permite tener un manual de uso o instrucciones de uso de otro comando por ejemplo “man top” nos mostrará un manual de uso y toda la información explicativa del comando top.

Existe una manera de exportar el contenido de man a PDF. Esto podría ser de utilidad para leer el contenido de un comando fuera de la consola, imprimirlo o bien archivarlo en nuestra pc para tenerlo a mano y facilitarnos la lectura cuando no estamos trabajando en la consola.

El proceso es sencillo:

# man -t top | ps2pdf - > top.pdf

Donde:
man: abre el manual
-t: llama a groff un editor de textos que preformatea documentos y transforma el manual a PS (postscript)
ps2pdf: hacemos legible el PS y lo transformamos a pdf
top.pdf: elegimos el nombre que deseamos ponerle al documento en formato PDF

by Mauro at September 18, 2018 01:43 PM

September 17, 2018

soyadmin.com

¿Como limitar cantidad de conexiones FTP por IP?

Hay una manera muy sencilla de controlar la cantidad de conexiones múltiples de FTP usando pure-FTP como servidor.

Editamos el archivo de configuración de nuestro FTP:

# vi /etc/pure-ftpd.conf
## Editamos el valor de MaxClientsPerIP por el valor que queramos colocar.
MaxClientsPerIP 8

Simple y al dedo!

by Mauro at September 17, 2018 06:59 PM

www.rootzilopochtli.com

Resolviendo el #SysArmyMx Challenge Part Deux

¿De qué sirve saber algo, si usted no comparte lo que sabe?
Rubén Blades

Después de 211 visitas al post y 46 descargas de la imagen KVM (Gracias a todos los que participaron!), les comparto la solución, con su debida explicación al #SysArmyMx Challenge:

  • Configuramos nuestra VM con la imagen del disco descargada y la arrancamos; tecleamos F2 o Esc para ver los mensajes de arranque (durante la carga de plymouth). Un par de segundos después, empezaremos a ver los errores en la carga del SO
  • Al terminar, parece mostrarnos el login correctamente, pero al tratar de acceder, nos muestra el mensaje de error que nos proporciona una pista de lo que sucede
  • Al tratar de montar la partición linux, el modo de rescate nos indica que no lo encuentra, por lo que procedemos a montarlo manualmente
  • Al ejecutar chroot sobre la partición de rescate montada, observamos claramente el error

    • Entonces, como podemos observar, el comportamiento al arranque se debía a que la shell (intérprete de comandos) con la que debía levantar el sistema (/bin/bash) no se encontraba disponible. Esto mismo se nos mostraba al inicio de la carga de la VM, cuando, después del intento de login, el sistema nos mandaba el mensaje de error:
--- root: no shell: No such file or directory

Uno de los conceptos principales y básicos como SysAdmin, y que nos ayuda a comprender mejor este comportamiento, es el arranque del sistema. Tradicionalmente, las versiones basadas en System V, realizaban el arranque siguiendo el flujo mostrado hasta que el kernel ejecuta el proceso init, con el que se inicializan todos los procesos del sistema:

Actualmente, los sistemas basados en Systemd, realizan el arranque de manera similar, pero el primer proceso que ejecuta el kernel es systemd, quién se encarga de arrancar todos los procesos y servicios de forma simultánea:

El intéprete de comandos (bash) es el medio que utiliza el kernel para continuar el flujo del arranque, por lo que, como lo mencionamos anteriormente, los mensajes de error relacionados con la carga de unit files de systemd, más el mensaje de error en el login nos daban el indicio de la falla, la cual comprobamos con el proceso de rescate.

  • Para solucionar esta falla, simplemente restauramos el archivo y validamos que podamos ejecutar chroot:
  • Con la partición montada y enjaulada, configuramos la contraseña de root:

  • Al reiniciar, conforme nos mando mensaje de error originalmente, el sistema realizará el re-etiquetado de SELinux:

  • Después de este proceso, el arranque es correcto y podemos hacer login en el sistema:

  • Con el sistema funcionando, podemos realizar la configuración que nos han solicitado:

hostname

# hostnamectl set-hostname host01.sysarmy.mx

kernel

Para actualizar el kernel a la versión solicitada, había que actualizar el SO; éste, es uno de los pasos más recomendados, pero a veces (debido a alguna aplicación hecha en casa o restricciones en las políticas de seguridad para la aplicación de patches) no se aplica. Lo mejor, conforme a las mejores prácticas, es hacerlo al menos dos veces por año en la medida de lo posible. Para esto ejecutamos:

# yum update

network

Para realizar la configuración de la red, conforme un post de hace algunos años, modificamos el archivo de configuración de la nic (/etc/sysconfig/network-scripts/ifcfg-eth0):

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
PREFIX=24
IPADDR=192.168.122.10
DNS1=192.168.122.1
GATEWAY=192.168.122.1

webpage

Esta parte del reto, tiene dos partes en la solución: la más obvia y sencilla (instalar el servidor web [apache]), y, si queremos hacerlo más pro: configurar el firewall del sistema, para que sólo permita conexiones por el puerto de servicio del servidor web:

* apache*

Para instalar el servidor web apache, simplemente se ejecuta:

# yum install httpd

Para posteriormente crear la página de inicio del servicio:

# echo "Hola Mundo" > /var/www/html/index.html

Habilitamos y arrancamos el servicio y validamos que la página de inicio sea visible:

# systemctl enable httpd; systemctl start httpd
# curl http://127.0.0.1
Hola Mundo

firewall*

Para instalar el firewall, se ejecuta:

# yum install firewalld

Después de habilitar y arrancar el servicio, configuramos los servicios y puertos de acceso que deseamos:

# systemctl enable firewalld; systemctl start firewalld
# firewall-cmd --permanent --add-port={22/tcp,80/tcp,443/tcp}
# firewall-cmd --permanent --add-service={http,https,ssh}
# systemctl restart firewalld.service

# firewall-cmd --list-ports
22/tcp 80/tcp 443/tcp

Y validamos nuevamente que la página de inicio sea visible:

# curl http://127.0.0.1 
Hola Mundo

  • Al finalizar la configuración, reiniciamos el sistema y comprobamos que ésta perduren:

 

Además de la complejidad observada, la imagen KVM está configurada con el teclado en “Español Latinoamericano” lo cual, al conectarse por la consola, ocasionaba un pequeño inconveniente al teclear algunos comandos; se podía cambiar el teclado, pero no sentí que fuera un gran obstáculo 😉

Les comparto las evidencias de quienes terminaron el reto y mandaron su captura de pantalla:

Nuevamente, muchas gracias por participar, espero les haya gustado 🙂

P.D.: Que les pareció la lista de Blades en Spotify? 😉

by Alex Callejas at September 17, 2018 05:28 PM

soyadmin.com

Detectando rootkits con Chkrootkit

Según la Wikipedia: “Chkrootkit (Check Rootkit) es un programa informático de consola, común en sistemas operativos Unix y derivados. Permite localizar rootkits conocidos, realizando múltiples pruebas en las que busca entre los binarios modificados por dicho software. Este guion de consola usa herramientas comunes de UNIX/Linux como las órdenes strings y grep para buscar las bases de las firmas de los programas del sistema y comparar un transversal del archivo /proc con la salida de la orden ps (estado de los procesos (process status) para buscar discrepancias. Básicamente hace múltiples comprobaciones para detectar todo tipo de rootkits y ficheros maliciosos.”

Es decir es una herramienta que nos permite escanear nuestra PC/Servidor buscando archivos infectados. Sobre todo los rootkits/malware que tanto daño pueden causar.

NOTA: Seguramente muchos dirán “Pero si linux no tiene estos problemas” “linux no tiene virus” “yo no puedo infectarme” la idea es que en caso de ser portador elimines esta amenaza para que no sigas repartiéndola a otros usuarios ya sea por un pendrive o cualqueira de los métodos de infección. Incluso si posees una página web y tu servidor o sitio está con alguna infección, tus clientes o visitantes pueden también resultar infectados. La idea es evitar la propagación.

¿Como lo instalamos?
1) Instalación en CentOS RHEL y Fedora

# wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
# tar xvzf chkrootkit.tar.gz
# cd chkrootkit*
# make sense

2) Instalación en Debian, Ubuntu, Mint y derivados

# sudo apt-get install chkrootkit

¿Como funciona?
1) Ejecutarlo en CentOS RHEL y Fedora
Desde la carpeta de la herramienta ejecutamos:

# ./chkrootkit
# ./chkrootkit -q (solo muestra en pantalla los archivos infectados)
# ./chkrootkit > reporte.txt (crea un archivo .txt con los resultados del escaneo para así poder revizar luego de finalizado)

2) Ejecutarlo en Debian, Ubuntu, Mint y derivados

# sudo chkrootkit
# sudo chkrootkit -q (solo muestra en pantalla los archivos infectados)
# sudo chkrootkit > reporte.txt (crea un archivo .txt con los resultados del escaneo para así poder revizar luego de finalizado)

Como cada herramienta de detección tiene sus falsos/positivos, se debe estudiar cada archivo detectado para así no cometer un error.

by Mauro at September 17, 2018 02:52 PM