Ediciones ENI Editorial | líder en informática
Snap-ins, módulos y PowerShell Gallery
Introducción
Allí donde coinciden PowerShell y la célebre firma de la manzana es en torno al famoso eslogan «hay una aplicación para ello». En efecto, en el ecosistema PowerShell podríamos establecer un paralelismo diciendo que «hay un comando para ello». Esto es todavía más cierto después de que Microsoft haya creado la PowerShell Gallery (de la que hablaremos al final de este capítulo) podríamos compararla con un almacén de aplicaciones. Salvo que, en vez de encontrar aplicaciones, encontramos numerosos comandos adicionales empaquetados en módulos. Como comprenderá, estos comandos adicionales van a permitir extender hasta el infinito las funcionalidades básicas que ofrece PowerShell.
Por otro lado, PowerShell ha suscitado el interés de muchos fabricantes, como, por ejemplo, VMWare, Amazon, Google, Citrix, HP, Hitachi, EMC, F5 Networks, etc. Todos proponen snap-ins o módulos para gestionar sus aplicaciones o equipos. No parece que vaya a detenerse, lo cual está muy bien, ya que cada vez pedimos más.
Los snap-ins
La noción de «snap-in» concierne a Windows PowerShell. Podríamos decir que el snap-in es el ancestro del módulo. Por este motivo, Microsoft los ha retirado completamente de PowerShell Core en beneficio de los módulos.
Con Windows PowerShell 1.0, las nuevas funcionalidades y comandos adicionales se realizaban únicamente mediante snap-ins. Por razones de compatibilidad, Windows PowerShell sigue soportando los snap-ins, pero, a partir de PowerShell 2.0, han cedido su sitio a los módulos, mucho más prácticos y fáciles de usar.
En efecto, para instalar un snap-in, hay que poseer permisos de administrador; los snap-ins se proporcionan como archivos MSI, pues deben registrar sus DLL en el registro. Por el contrario, para instalar un módulo, basta con un simple copiar/pegar y puede hacerse con permisos de usuario sencillo. Por último, como guinda, para desarrollar snap-ins hay que hacerlo necesariamente con un lenguaje .NET compilado (como, por ejemplo, C# o VB.NET), mientras que los módulos pueden desarrollarse en PowerShell, lo cual hace su desarrollo mucho más compatible.
1. Enumerar los snap-ins instalados
Para conocer la lista de snap-ins presentes en su equipo e importados en la sesión actual, teclee el comando Get-PSSnapin. Por defecto, en Windows PowerShell solo existe uno: el snap-in Microsoft.PowerShell.Core.
PS > Get-PSSnapin
Name : Microsoft.PowerShell.Core
PSVersion : 5.1.14393.1944
Description : This Windows PowerShell snap-in contains cmdlets used
to manage components of Windows PowerShell. Get-PSSnapin posee también un conmutador -Registred. Este, cuando se especifica, permite enumerar...
Los módulos
Como hemos dicho antes, los módulos han aparecido con la versión 2.0 de PowerShell. Un módulo es un contenedor (package) que agrupa comandos, pero también scripts, variables, alias y funciones. Comparándolo con un snap-in, la ventaja de un módulo es que es fácilmente transportable (basta con una simple copia del archivo) y por lo tanto también fácil de compartir para que otros usuarios puedan disfrutarlo. También es bastante fácil crearlo uno mismo, aunque esto excede los objetivos de este libro... La idea del equipo de PowerShell de Microsoft es crear una gran comunidad de usuarios y hacer que esta pueda intercambiar o compartir módulos a la imagen de la comunidad CPAN (Comprehensive Perl Archive Network) que conocen bien los usuarios del lenguaje PERL.
Con este objetivo nació en 2015 el sitio web www.powershellgallery.com. La «PowerShell Gallery» pretende ser un repositorio central de módulos PowerShell dirigido por Microsoft para la comunidad internacional de usuarios PowerShell. Este repositorio web es iniciativa de Microsoft. Necesitará como mínimo la versión 5 de PowerShell para poder aprovechar comandos que permiten interactuar con los módulos presentes en este repositorio.
1. Instalar un módulo
Con Windows Server, cada rol instalado da también derecho a un módulo que se instala automáticamente. Sin embargo, puede también recibir el módulo de un tercero. En este caso, basta con copiarlo en alguna de las ubicaciones previstas para alojar los módulos y ¡ya está! Un módulo se presenta bajo la forma de una carpeta que contiene uno o varios archivos. Para que un módulo sea válido, debe contener como mínimo un archivo con la extensión .psd1, así como un archivo con la extensión .psm1. Estos dos archivos tienen el mismo nombre que la carpeta del módulo.
El primer archivo (.psd1) contiene los metadatos del módulo (versión, nombre del autor, funciones y variables exportadas, etc.). El segundo archivo (.psm1) contiene, por su parte, el código de las funciones.
Tenga precaución, pues las ubicaciones...
PowerShell Gallery
1. ¿Qué es?
La PowerShell Gallery es un repositorio de scripts y de módulos (es decir, de numerosos recursos DSC). Está alojado y gestionado por Microsoft y todo el mundo está invitado a contribuir con sus creaciones, y también a consumirlas. Como comprenderá, la idea de la galería PowerShell es favorecer la compartición para evitar tener que reinventar la rueda.
Microsoft es, evidentemente, un contribuyente importante de la PowerShell Gallery, pero no es el único. Los autores somos también contribuyentes, aunque de manera modesta, al enriquecimiento de este repositorio.
En el momento de escribir estas líneas, en la galería existen más de 2750 elementos únicos publicados (scripts y módulos) para un conjunto de más de 15 000 elementos si se contabilizan todas las versiones. Conviene saber que los módulos representan, por su parte, más del 85 % de los elementos presentes en la biblioteca. Estos, a diferencia de los scripts, presentan la ventaja de que están versionados rigurosamente y poseen muchos metadatos. La galería PowerShell es, ante todo, un repositorio de módulos.
2. ¿Quid de la seguridad?
Como se trata de un repositorio público, esta cuestión nos viene inmediatamente a la mente. Es del todo normal. Y mucho mejor plantearse la pregunta, pues de lo contrario podríamos sufrir graves consecuencias.
Conviene saber que, cuando alguien quiere publicar un módulo en la galería, Microsoft utiliza un robot que realiza las siguientes acciones:
1. Instalación del módulo.
2. Escaneo con el antivirus para detectar eventuales malwares.
3. Aplicación del módulo «PowerShell Script Analyzer».
El PowerShell Script Analyzer (presente en la propia galería) es un excelente módulo que permite comprobar la calidad del código de un módulo o de un script PowerShell. Sirve para verificar - a través de un cierto número de reglas predefinidas - que se respetan las buenas prácticas. Como, por ejemplo:
-
Que no se recupera ni almacena ninguna contraseña sin cifrar.
-
Si se deben utilizar credenciales en una función, debe hacerse de una manera segura.
-
No debe almacenarse directamente ningún nombre de máquina.
-
Etc.
Si un módulo se considera como...