PowerShell

Entegas Anteriores:

• Parte I - El futuro del scripting
• Parte II - Arquitectura

Parte III - PowerShell para IT’s

En las dos anteriores entregas nos hemos dedicado al sustento teórico y al background necesario para saber de que estábamos hablando. Ya falta poco para comenzar, pero antes una información importante para seguir adelante.

Instalar PowerShell

Requerimientos

• Net Framework 2.0
• Windows XP SP2 +, Windows Vista, Windows Server 2003 SP1+, Windows Server 2008

Una vez ya tengas esto debes bajarte la versión de PowerShell de tu preferencia:
Link de descarga

Integración de tecnologías de automatización

Este es el primero de dos puntos clave que PowerShell brinda a los IT’s y es que por primera vez despues de muchos años existe una tecnología de script capaz de integrar todas las tecnologías de script existentes bajo Windows en una sola, pero esto solo es la parte de agrupar tecnologías de script, pero que tal poder acceder por medio de scripts a toda la infraestructura desde un punto central? bueno el dibujo habla por si solo:

PowerShell nos permite interactuar con cada uno de los componentes de nuestra infraestructura de red, ISA Server, Exchange System Center, Active Directory y muchos más, pero por si fuera poco tenemos (sobre todo para desarrolladores pero le impacta a los IT’s) .NET Framework, es decir tenemos las puertas abiertas a hacer lo que queramos, el framework nos lo permite.

Beneficios para crear scripts

Tanto para developers como para IT’s estas características son muy importantes, sere breve:

Bueno ya fue suficiente. Recuerden que esto no es un curso de PowerShell, es un overview donde se mostraran algunas cosas interesantes de manera general.
Let’s begin!!!

Primeros scripts

Antes de empezar les recomiendo que tengan fresca la información de la entrega anterior, iremos al grano así que las explicaciones serán breves.

Nivel de seguridad

PowerShell posee niveles de seguridad en cuanto a la ejecución de script así que nuestro primer script establecera un nivel de seguridad adecuado para los demos. Los posibles valores son:

• Unrestricted : todo script es permitido
• RemoteSigned : todo script local es permitido, pero si son remotos deben estar firmados digitalmente
• AllSigned : todo script debe estar firmado digitalmente

Se debe ejecutar este comando como administrador o en Windows Vista inicializando la aplicaion con elevación de privilegios.

Set-ExecutionPolicy RemoteSigned

1- Nombre de los procesos que tienen ventana con nombre no vacío

get-process | where-object{$_.MainWindowTitle -ne ""}

Aquí podemos observar el pipe ‘|’ que redirecciona la salida de get-process a where-object, dentro de where object ({}) utilizamos $_ para representar a cada uno de los objetos que devuelve el comando anterior (en este caso get-process) lo cual quiere decir que verificamos los objetos donde el atributo MainWindowTitle no sea igual (-ne =not equal) a vacío.

La salida arrojara algo parecido a esto:

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    448      37    70908      85920   287   832,44   5964 Dreamweaver
    302      26    64152      73592   181    36,07   5808 firefox
    642      62   112576     128432   415    28,88   5616 Fireworks
    638      40    65780      66892   239    25,18   5720 iexplore
    796      74    41960      23080   234    40,39   4196 msnmsgr
    783      81    59944      25084   353    31,26   2880 POWERPNT
    283      14    56836      47896   562     0,67   1256 powershell

2- Procesos que comienzan por letras y tienen números, este es aparentemente mas complejo, pero es realmente básico la parte compleja son las expresiones regulares ("^[a-z]+[^0-9]+$") perobasicamente es solo un patrón de busqueda.

get-process | where-object{ $_.Name -match "^[a-z]+[0-9]+$"}

La salida

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
     61       5     1988       4532    52     0,02   2164 MSCamS64
     42       6     3984       6140    79     0,05   4152 rundll32
     93       8     5200       8088    83     0,05   4432 rundll32
     75       5     2184       4984    54     0,09   3964 splwow64

Prueben esta variante, es muy parecida pero hace lo contrario, trae procesos que comiencen por letras y que no tengan números.

get-process | where-object{ $_.Name -match "^[a-z]+[^0-9]+$"}

3- Generar la salida filtrada y direccionarla luego en un archivo html y luego adicionarle un estilo. Vamos a ponerle mas detallitos, tal ves se les complique para algunos IT’s pero para otros…. sera genial, debemos crear un archivo de texto con este contenido:

<style>
   .fila_par
   { background-color:#FFFFCC;}

   .fila_impar {background-color:#CCFFFF;}
</style>

<script type="text/javascript">
<!--
   function AplicarCebra ()
   {
     tables = document.getElementsByTagName("table");
     for ( i = 0; i < tables.length; i++)
     {
       ColoreaFilas(tables[i]);
     }
   }

   function ColoreaFilas(tabla)
   {
     filasTabla = tabla.rows;
     for(j=0; j < filasTabla.length; j++)
     {
       if(j%2==0)
       {
         filasTabla[j].className="fila_par";
       }else
       {
         filasTabla[j].className="fila_impar";
       }
     }
   }
// -->
</script>
<body onload="AplicarCebra();"/>

Guardemos esto en un archivo de texto llamado EstiloYScript.txt, básicamente hemos creado una pequeña hoja de estilos, y algunas funciones útiles de jscript, al final hemos invocado uno de los script desde el body… por el momento no se fijen en lo que hace eso sino lo entienden… ese no es el tema, conformense con saber que es para crear una tabla en una pagina web y hacer que quede coloreada automáticamente.

Ahora desde la consola de PowerShell nos vamos a la carpeta donde guardamos el archivo (si… se hace igual que en una consola DOS, recuerden que PowerShell extiende las funcionalidades de los antiguos bat). Ahora vamos a aprender varias cosas:

Acá vemos como definir una variable ( head, para definirla se le pone $), y también vemos como leer un archivo y asignar sus contenidos a la variable:

$head =get-content "EstiloYScript.txt"

Ahora veamos el siguiente comando, nos permite no solo seleccionar la lista de procesos sino traer únicamente la información que deseamos. Estamos buscando los procesos que comiencen por r. Atención al comando select.

get-process |
where-object{ $_.Name -like "r*"} |
select-object id, processname, handles 

La salida:

  Id ProcessName                                    Handles
  -- -----------                                    -------
2556 rosetta_beta_5.96_windows_intelx86                  52
3740 rosetta_beta_5.96_windows_intelx86                  53
2520 Rtvscan                                            594
4152 rundll32                                            42
4432 rundll32                                            93

Espero que les este gustando, ahora veamos como redireccionar la salida en formato html

get-process |
where-object{ $_.Name -like "r*"} |
select-object id, processname, handles |
convertto-html

La salida html:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
                      "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>HTML TABLE</title>
</head><body>
<table>
<colgroup>
<col>
<col>
<col>
</colgroup>
<tr><th>Id</th><th>ProcessName</th><th>Handles</th></tr>
<tr><td>2556</td><td>
rosetta_beta_5.96_windows_intelx86
</td><td>52</td></tr>
<tr><td>5776</td><td>
rosetta_beta_5.96_windows_intelx86
</td><td>53</td></tr>
<tr><td>2520</td><td>Rtvscan</td><td>594</td></tr>
<tr><td>4152</td><td>rundll32</td><td>42</td></tr>
<tr><td>4432</td><td>rundll32</td><td>93</td></tr>
</table></body></html>

Como direccionarla a un archivo de texto? se puede pasándole por pipe al comando out-file, o bien como en los antiguos bat con el operador > o >>:

get-process |
where-object{ $_.Name -like "r*"} |
select-object id, processname, handles  |
convertto-html > htmlFile.html

Este archivo ya es legible y lo podemos abrir desde el browser, recuerdan el estilo y script que cargamos antes en la variable $head? es momento de usarlo, adicionemosle algo de sabor al html generado:

get-process |
where-object{ $_.Name -like "r*"} |
select-object id, processname, handles  |
convertto-html -head $head > htmlFile.html

Y al abrirlo desde el explorador… revísenlo uds mismos.

4- Matar un proceso recurriendo a Windows Management Instrumentation (WMI), para este ejemplo lo primero que debemos hacer es abrir un bloc de notas. Luego anotar esto en la consola:

$a = get-wmiobject win32_process |
where-object {$_.name -eq "notepad.exe"}
$a.terminate()

5- Consultar el consumo de CPU de un proceso recurriendo a Windows Management Instrumentation (WMI), la salida es formateada con el comando fotmat-table para pesonalizar los labels, y se usa el comando select para determinar que datos serán procesados en la salida.

get-wmiobject Win32_PerfFormattedData_PerfProc_Process |
select-object name, PercentProcessorTime |
where-object { $_.Name -eq "powershell"} |
format-table @{Label="Nombre del Proceso"; Expression={$_.name}},
@{Label="Tiempo de CPU"; Expression={$_.PercentProcessorTime}} -auto

La salida…

Nombre del Proceso Tiempo de CPU
------------------ -------------
powershell                     0

6- Sentencias de control de flujo, ya a estas alturas lo único por explicar es que es que es write-host … escribir en el host , en este caso la consola y throw es para enviar una excepción en un programa.

$a = "white"
if ($a -eq "red")
    {"The color is red."}
elseif ($a -eq "white")
    {"The color is white."}
else
    {"The color is blue."}

Ejecutenlo…creo que es claro. Hagan pruebas cambiando el valor de la variable $a para que vean como cambia el flujo de las instrucciones.

7- Definir funciones, es un ejemplo muy similar al anterior, pero se añaden algunos modificadores a write-host para cambiar los colores de fondo y de fuente.

function ElColor($color)
{
  "El color es: "
  if ($color -eq "amarillo")
  {  write-host "amarillo" -foregroundcolor "yellow” }
  elseif ($color  -eq "azul")
  { write-host "azul"  -foregroundcolor "blue" -backgroundcolor "white”}
  elseif ($color  -eq "rojo")
  { write-host "rojo"  -foregroundcolor "red”}
  else
  { throw "No reconozco ese color”}
}

Con lo anterior hemos creado la función, ahora probemosla

ElColor(”amarillo”);
El color es: amarillo

ElColor(”azul”);
El color es:azul

ElColor(”rojo”);
El color es:rojo
ElColor(”xxx”);
No reconozco ese color
En línea:11 carácter:10
+   { throw  <<<< "No reconozco ese color"}

8- Switches de funciones, ahora rescribamos la función de esta forma:

function ElColor($color, [switch] $comoWarning)
{
  if($comoWarning)
  { write-warning “El color es: “  }
  else
  { “El color es: “  }
  if ($color -eq “amarillo”)
  { write-host “amarillo” -foregroundcolor “yellow” }
  elseif ($color  -eq “azul”)
  { write-host “azul”  -foregroundcolor “blue” -backgroundcolor “white”}
  elseif ($color  -eq “rojo”)
  { write-host “rojo”  -foregroundcolor “red”}
  else
  {throw “No reconozco ese color”}
}

La función ahora recibe un parametro de tipo switch, el cual luego es verificado para determinar si el mensaje se muestra o no a manera de advertencia, la salida y el uso seria igual al ejemplo anterior desde que no se use el switch. Para usar el switch se debe hacer de la siguiente forma:

ElColor(”azul”) -comoWarning
ADVERTENCIA: El color es:
azul

Bien eso es todo, como verán aunque esto es PowerShell para IT’s hubo bastante desarrollo, sin embargo lo que tengo preparadopara los developers es aún mejor, que tal en vez de solamente usar PowerShell… extenderlo? o hacer que su salida no sea una consola sino una aplicación propia? o hacer que los comandos no se digiten en una consola sino desde una pagina web u otra aplicación?… pues de eso tratara la próxima entrega.

• Parte IV - PowerShell para Developers

Hasta la próxima.

Entegas Anteriores:

• Parte I - El futuro del scripting

Parte II - Arquitectura

Modelo Básico

Powershell se compone de 4 elementos fundamentales:

• .Net FrameWork
• Sistema operativo (Windows XP / Vista / Server 2003 / Server 2008)
• CommandLet’s (Cmdlet’s), Data Providers
• PowerShell Host

Desde el punto de vista de desarrollo El .NEt Framework aporta el soporte para CLR 2.0 y junto con el todos los beneficios de el desarrollo sobre esta plataforma.

El sistema operativo es desde luego provee a PowerShell de las API’s necesarias para interactuar con las características del sistema como: archivos, registro, dispositivo, usuarios etc.
LLos Cmdlet’s, como veremos más adelante, son una parte fundamental de PowerShell que esencialmente brindan una interfaz unificada de programación para hacer uso de las características de scripting a través del pipeline processor.

Finalmente encontramos el PowerShell Host, por defecto es una consola de comandos de texto, pero no es una restricción, en los últimos capítulos que traten el tema de PowerShell veremos como podemos hostear tanto la interfaz de entrada de scripts, como la interfaz de resultados en aplicaciones independientes con interfaces gráficas web o de aplicaciones de windows.

Modelo Funcional

El gráfico se debe revisar de abajo hacia arriba, en un primer nivel tenemos al sistema operativo, quien brinda las API’s necesarias para la ejecución e interacción de PowerShell, sobre el sistema operativo tenemos el CLR que en adelante brinda sus servicios a PowerShell, estos servicios son un entorno de ejecución con administración de memoria, aislamiento de dominios de aplicación, etc.

Sin embargo para que el CLR sea realmente útil se requiere una serie de interfaces de adquisición de datos: los PowerShell Providers. Estos Providers se encargan de enviar a los diferentes CmdLets instalados en PowerShell la información solicitada, es decir son fuentes de datos que bien pueden devolver un conjunto de llaves de registro, un listado de archivos, registros de un base de datos, los procesos en ejecución etc etc.

Una vez los datos son accedidos por los Providers esos envían o reciben información de los CmdLet’s, un CmdLet por si solo solo puede realizar un conjunto de tareas limitado, por ejemplo consultar los procesos en ejecución, y otro CmdLet puede por ejemplo ordenar un arreglo según un criterio de ordenamiento. El verdadero poder de los CmdLet esta en la capacidad que tienen para hacer que el resultado de uno de ellos sirva como fuente de datos a otro CmdLet y a su vez el resultado de este CmdLet sirva como entrada a otro más… y así puede funcionar de manera ilimitada, dicha interacción entre CmdLet’s se lleva a acabo gracias a otra parte fundamental de PowerShell : El Pipeline Processor.

El PipeLine Processor tiene una función sencilla, pero crítica para que la magia comience a surtir efecto, el el encargado de hacer que la información fluya entre CmdLet’s, el que recibe los datos de entrada desde el host de comandos y el que envia el resultado final al host de salido. El PipeLine Processor es el hilo conductor que hace que muchos componentes logren ser PowerShell .

En el gráfico podemos observar como en el nivel más superior se encuentran los comandos, cada comando se separa de otro a través de un | (un pipe) este pipe representa el Pipeline Processor por lo cual podemos visualizar como cada un comando envía su información al pipeline y este redirecciona su salida al comando siguiente y así sucesivamete hasta que tras el último comando envía el resultado final al host de salida.

Ahora que ya esta clara la arquitectura, es hora de comenzar con la acción… Próximas entregas:

• Parte III - PowerShell para IT’s
• Parte IV - PowerShell para Developers

Hasta la próxima.

PowerShell

Parte I - El futuro del scripting

Como logro automatizar mis labores administrativas? Quiero ser más eficiente? esa es la pregunta que a diario tienen muchos administradores de red y personal de IT en general, pueden existir muchas opciones:

• Desarrollos personalizados
• Aplicaciones de terceros
• Automatización por medio de scripts

Como es de suponerce este tipo de demandas suelen ser ‘imposibles’ sobre todo dentro del tiempo requerido o con un presupuesto ajustado. Entonces cual es la respuesta a esa pregunta?: PowerShell.

Antes de entrar en materia revisemos unos conceptos importante.

Qué es un script?

Un script es un conjunto de instrucciones utilizadas para automatizar un conjunto de tareas.

Funciona como el guión de una película, donde se describen paso a paso las diferentes acciones que un actor debe efectuar.
En nuestro caso el actor el sistema operativo y el guionista es quien hace el script.

Qué es un shell?

Un shell es una pieza de software que provee una interfaz de uso, desde el punto de vista de la computación se puede definir en varios niveles.

Un componente que provee acceso al kernell (núcleo) del sistema operativo, en el caso de los desarrolladores esa interfaz puede ser Shell32.dll , User32.dll y otras.

Desde el punto de vista de los usuarios el Shell pueden ser el sistema de ventanas de Windows o una consola de símbolo de Sistema.

PowerShell, es un shell que brinda una interfaz robusta para que el usuario IT realice tareas de administración dentro del sistema.

Evolución de los ‘Shell’

Sistemas operativos de la familia UNIX desde su comienzo han tenido un shell de consola de comandos robusto, en contraste Windows siempre se caracterizo por tener falencia en ese sentido debido a que, desde luego, no era algo importante en sus primeras versiones pues la prioridad siempre era brindar una interfaz de usuario(shell) amistosa, meintras que en UNIX esa casi siempre (hasta hace relativamente poco)ha sido una debilidad.

Con el paso del tiempo los sistemas operativos de la familia de windows fueron fortaleciendose y su incursión en la rama empresarial y de IT fue cada vez más notoria lo cual fue volviendo las labores de administración un tema cada vez mas complejo y extenso. Para cubrir esas necesidades Windows cada vez incorporo mas herramientas de línea de comandos , no solo fortaleciendo su clásica interfaz del símbolo del sistema (conocida ‘vulgarmente’ como ventana del DOS) sino además incluyendo nuevos shell para ejecutar script, sin embargo algunos de estos shell realmente eran mas las vulnerabilidades que abrían en el sistema que la utilidad que se les lograba sacar, con el tiempo estos shell se fueron fortaleciendo y surgieron muchos nuevos principalmente orientados a realizar tareas usando wmi (Windows Management Instrumentation) combinado con scripts de tipo VBScript y javascript.

Si bien el ambiente de script cada vez era mas diverso y extendido, hacia falta algo fundamental: Integración, interoperabilidad y flexibilidad.

Así que para cubrir esta nueva necesidad surgió El proyecto Monad el cual más adelante se llamaría: PowerShell 1.0. y hoy día ya estamos ad portas de la versión 2.0.

…

Próximas entregas:

• Parte II - Arquitectura
• Parte III - PowerShell para IT’s
• Parte IV - PowerShell para Developers

Hasta la próxima.