SCO Unix sobre qemu: bonus

By cesar | julio 2, 2013

Si instalaste SCO Unix como se describe en la entraga anterior, es posible que las siguientes utilidades te sean de ayuda.

Instalación de putty en GNU/Linux

El primer programa será para instalar en nuestra pc. Los programas gráficos konsole y gnome-terminal tienen el defecto que no se ven bien con la terminal típica de los sistemas SCO que es scoansi. Sin embargo putty es un programa libre de emulación de terminales muy cuidado, con u completo soporte para SCO.

Instalamos los paquetes en nuestro Debian GNU/Linux:

 Bash |   copy code | ?  
apt-get install putty putty-tools

Para configurar la sesión, hay que retocar algunos valores. Supongamos que deseamos acceder a un sistema SCO antiguo, que no tiene SSH y debemos utilizar telnet:

telnet (puerto 23)
host name or ip address: IP_SCO
nombre conexión: srv_produccion
keyboard:
- Backspace -> Ctrl-H
- Function keys: SCO
Window
- Display scroll bar: OFF
- Appearance:
  - Cursor appearance: Block
  - Cursor blinks: ON
- Translation:
  - Remote character set: ISO-8859-1
  - Handling of line drawing characters: Poor’s man line drawing
  - Fonts: Font used for ordinary text: client:FreeMono 16

`rsync` para SCO Unix

Cuando instalas un servidor a nuevo, lo siguiente es copiarle archivos de datos, programas fuentes, y perfiles de usuarios. rsync es una herramienta ideal para esa tarea, ya que puede continuar una copia interrrumpida, sin necesidad de recomenzarla desde el principio.

Vamos a instalar rsync en el SCO Unix.

Lo descargamos en nuestra pc:

 Bash |   copy code | ?  
wget http://www.aljex.com/bkw/sco/rsync.tar.bz2

Lo copiamos al sistema SCO:

 Bash |   copy code | ?  
scp rsync.tar.bz2 root@IP_SCO:/tmp

Descomprimirlo y desempaquetarlo con:

 Bash |   copy code | ?  
bunzip2 /tmp/rsync.tar.bz2
cd /
tar xvf /tmp/rsync.tar

El programa queda instalado en /usr/local/bin/rsync.

Cuando lo queremos usar desde nuestra pc, podemos hacer, por ejemplo:

 Bash |   copy code | ?  
rsync -Pav --rsync-path=/usr/local/bin/rsync root@IP_SCO:/tmp /tmp/

Instalación de RM COBOL 85 sobre SCO Unix 3.2 2

El RM COBOL 85 que me tocó instalar venía en disquetes de 3.5 pulgadas. Si, leiste bien, disquetes. Dos disquetes para el compilador, y dos para el runtime. Menos mal que pude conseguir una disquetera externa conectable mediante USB.

Los disquetes están en formato cpio, que son una especie de archivo multiparte.

La secuencia de instalación, será la siguiente: pasamos los disquetes a imágenes binarias, subimos las imágenes al SCO virtualizado, y las desempaquetamos, luego corremos el programa de instalación.

Vamos a crear la imágenes con dd en GNU/Linux. Si no tienen un GNU/Linux y usas MS Windows, pues, lo lamento por tí, pero igual puedes obtener las imágenes mediante rawread[1].

Para no mezclar las imágenes, utilicé nombres descriptivos en los archivos:

rmcobol85-development-v6.06.01-scounix-v3.2.2-disk-1-of-2.img
rmcobol85-development-v6.06.01-scounix-v3.2.2-disk-2-of-2.img
rmcobol85-runtime-v6.06.01-scounix-v3.2.2-disk-1-of-2.img
rmcobol85-runtime-v6.06.01-scounix-v3.2.2-disk-2-of-2.img

Creamos en el SCO un directorio para contener los archivos desempaquetados a partir de los disquetes:

 Bash |   copy code | ?  
mkdir /usr/local/rmcobol

Copiamos las imágenes de los disquetes a ese directorio, por ejemplo usando SCP o NFS, al directorio /tmp del SCO.

Desempaquetamos los archivos cpio:

 Bash |   copy code | ?  
cd /usr/local/rmcobol
cpio -ivcmB < /tmp/rmcobol85-development-v6.06.01-scounix-v3.2.2-disk-1-of-2.img
cpio -ivcmB < /tmp/rmcobol85-development-v6.06.01-scounix-v3.2.2-disk-2-of-2.img

Si los disquetes se hubieran insertado en la disquetera física de una máquina física, el mandato hubiera sido:

 sh |   copy code | ?  
cpio -ivcmB < /dev/dsk/f0q18dt

Y con un 1 en vez de un 0 si es la segunda disquetera.

Corremos el programa de instalación:

 sh |   copy code | ?  
./rminstall

Este programa copia archivos en /usr/bin/. Los instaladores de antaño eran así de mal comportados. Ahora se esperaría que use /usr/local/.

Esto muestra en pantalla lo siguiente:

 Text |   copy code | ?  

                     Installation of RM/COBOL-85

           You Must be Super User (root) To install This Product
                  (press system cancel key to abort)

Press Return To Continue: 
Unzipping compressed files...
Installing compiler into /usr/bin...
Installing runtime into /usr/bin...

Cuando te haga la siguiente pregunta, responde con terminfo, que es la alternativa moderna de gestión de capacidades para terminales.

Which version of the runtime/recover1 do you want to install, (terminfo or termcap)?

Y por último muestra:
Installation complete!

Conclusión

Hemos instalado ciertos programas que facilitan el trabajo con sistemas SCO Unix heredados.

Sinceramente espero que nunca los tengas que usar, y que aproveches tu vida en cosas más modernas y cool.

Nos leemos…

Referencias

[1] http://iutsa.unice.fr/~frati/_TOOLS/zip+iso+boot/rawrite/Rawrite-Rawread.htm

Topics: SCO Unix, sysadmin | No Comments »

Vino viejo en odres nuevos: SCO Unix sobre qemu

By cesar | julio 2, 2013

SCO Unix

Comentaba en una entrada anterior que mis comienzos sonre sistemas U*ix estuvieron relacionados con los sistemas operativos de la empresa Santa Cruz Operations (SCO) [1]. En particular SCO Xenix y SCO Unix, luego SCO OpenServer y por último SCO Unixware.

En 2002, SCO fue adquirida por una firma de abogados de Utah [2], con el objetivo de usar sus derechos de copia del núcleo Unix para parasitar el éxito de los núcleos Linux y cobrar regalías sobre los sistemas GNU/Linux. En particular, iniciaron un juicio contra IBM por mil millones de dólares y comenzaron a mandar cartas amenazadoras a las empresas más grandes que usaban sistemas GNU/Linux con la propuesta de comprar un sistema de «protección» anti demandas legales. Usted ya conoce como es esto. Cuando uno tiene poder de causar daño y pide que usted pague a cambio de la protección de esos posibles daños. No faltó quien se atemorizara y pagara. Los demás esperábamos sin temblar: o la comunidad organizaba una defensa o IBM iba a oscurecer el cielo con abogados cayendo sobre Utah. Al final fue ambas cosas.

En 2007 SCO Group pidió la protección del Capítulo 11, básicamente declarándose en quiebra. Los detalles se pueden seguir cronológicamente en [2] y en Groklaw[3].

De multiusuario a desparramado

Durante la década de 1990, muchas empresas han tenido a SCO Unix como el sistema operativo multiusuario corporativo de elección. La robusteza del sistema, apoyado en servidores basados en procesadores Intel de gama media y alta, con equipos de calidad empresarial de Hewlett Packard, IBM, Compaq, Everex, y otros, da como resultado que hoy en día muchas aplicaciones corporativas todavía están operativas. O sea, están operativas como cuando se las instaló hace más de 15 años. Mismo hardware, mismo sistema operativo. Tal vez con el tiempo se han abandonado las terminales alfanuméricas por terminales de clientes delgados o pcs con un programa de telnet. Pero los servidores siguen rotando sus discos, y los programas RM COBOL 85 o SCO FoxBase siguen interactuando con el personal de carga de datos.

Era plena época de fama del MS DOS y los centros de cómputo sentían la presión y el embate de las microcomputadoras (como se llamaba a las pc en aquella época). Un contador o abogado, podía entonces aprender a usar una planilla de cálculos y hacer sus propios reportes, gráficos, y análisis de datos, sin necesidad de rogar a los desarrolladores de la «caja de cristal» donde se alojaba el mainframe.

Bastaba una pc con MS DOS, un LOTUS 123 y un programa de terminal serie con captura de datos. El contador se conectaba al sistema Unix con el emulador de terminal, activaba la captura de datos en la pc y ejecutaba los listados en pantalla del Unix, los cuales quedaban disponibles en la pc para convertirlos a la planilla LOTUS. Fue la milicia feudal atacando el castillo del rey. Cada señor feudal tenía una pc, empezó a cercar sus datos, y de esa manera tuvo su coto de caza privado con la información de la empresa, y esa información le otorgó poder. Al menos poder de impedir, sino de hacer. Los sistemas se dividieron y hubo que esperar hasta la ola del data mining para volver a tener una visión global de la organización. Y hasta donde sé, tampoco se logró en todas las organizaciones.

Los sistemas eran multiusuario, luego de esto se transformaron en sistemas desparramados. No uso la expresión «sistemas distribuídos» porque ésta conlleva la idea de un plan, y un propósito unificador. El desparramo de sistemas que provocó la pc fue debido a la lentitud y/o inoperancia de los antiguos centros de cómputo para dar respuesta en los tiempos que las gerencias requerían para su toma de decisiones. Se entronó al dato por sobre el sistema que obtiene el dato.

Sin embargo, las funciones de operación siguieron en el centro de cómputos. La carga de datos, validación, informes periódicos, consultas preprogramadas, todas ellas siguieron en los servidores centrales.

Los bytes no envejecen, los proveedores sí

El problema se da cuando el proveedor discontinúa el software que utilizamos. Si un pintor famoso muere, no habrá nuevas obras, y eso hace que sus obras aumenten de precio en el mercado. En el caso de una empresa de software, si deja de producir nuevas versiones de un programa, el programa abandonado ya no vale nada.

A principios de los 1990 me tocó tomar la decisión de elegir un procesador de textos y una planilla de cálculos para usar en las terminales alfanuméricas, conectadas a los servidores multiusuario corporativos con SCO Unix en una empresa importante de mi ciudad natal. Una docena de servidores daría potencia de trabajo a unos 400 usuarios. La planilla de cálculo era una decisión simple: LOTUS 123. El procesador de textos no era tan fácil, pero bueno, «nunca se ha despedido a nadie por comprar equipos IBM» se puede traducir en el mundo de las pc con MS DOS, a «nunca se ha despedido a nadie por comprar software Microsoft», así que SCO Word 5.0 fue la elección. Microsoft fue uno de los colaboradores del desarrollo de SCO Xenix, así que algo de inversión en esto tiene. El MS Word 5.0 para SCO Unix puede grabar en el formato de MS Word 5.0 para MS DOS. Todos podemos formar una feliz familia corporativa.

Cuando salió la versión de SCO con binarios ELF y bibliotecas compartidas, los binarios de SCO Word en formato a.out no corrían en el nuevo sistema operativo. No importa, es una gran empresa como dije, no hay problemas en gastar nuevamente el precio de la docena de licencias y adquirir los binarios para la nueva versión. Oh, oh. Es mediados de los 1990 y a Microsoft no le interesa más el mercado de los procesadores de texto en terminales alfanuméricas, por ello: no hay más opción.

Jaque.

Bueno, sí la hay. Podemos dejar algunos de los servidores con la vieja versión de SCO que corre el SCO Word y actualizar los otros servidores con los sistemas de bases de datos y aplicaciones. Los servidores son equipos con procesadores 386sx y otros con 386. Andan muy bien.

El tiempo pasa, uno de los equipos con 386 se quema. El dinero no es problema, recuerdan que es una gran empresa. Se compra un servidor al estado del arte. Se buscan los disquetes del viejo SCO con binarios a.out y se instalan. Esteeee, no, no se puede instalar. La motherboard del nuevo equipo tiene un chipset y tarjetas SCSI para los cuales no hay drivers en el viejo SCO.

El SCO Word requiere un sistema operativo que no se puede instalar en los equipos que podés comprar.

Jaque.

Luego Microsoft saca el MS Word 6.0 sobre MS Windows 3.1. El MS Word 6.0 no puede leer el formato de 5.0 para MS DOS, que es el que puede escribir el SCO Word.

La tierra informática se fractura y un abismo separa a los usuarios de procesador de texto de MS Word 6.0 para MS Windows 3.1 y los que todavía usan terminales alfanuméricas.

Jaque mate.

Lo único que se puede hacer es eliminar los procesadores de texto sobre SCO. Claro que eso implica perder años de documentos corporativos, porque no se pueden leer con la versión de MS Windows.

Se podría hacer un proyecto de migración de formato usando la versión 5.0 de MS DOS como puente a la versión 2.0 de MS Windows, y de allí a la versión 6.0 para MS Windows. Pero uno se pregunta, ¿porqué una empresa debe pagar semejante proyecto de migración de datos propios? La respuesta es simple: la información era propia, pero una vez que los datos se guardaron en un formato secreto y privativo, quedaron secuestrados en poder del programa que los puede leer. La importancia de los formatos abiertos es tema para otra entrega, pero aquí se puede vislumbrar lo que sucede cuando renunciamos a nuestra libertad de formato, en pos de un programa bonito y popular, pero que es privativo. Cuando menos lo pensamos, perdemos el programa, y perdemos los datos también.

Sistemas SCO en la actualidad

Los casos populares de utilización de SCO Unix eran aquellos en los cuales los sistemas estaban desarrollados por ejemplo con RM COBOL 85[5], Informix[6,7], PROGRESS 4GL[8,9] o SCO FoxBase, con accesos mediante terminales alfanuméricas o telnet sobre TCP/IP, e impresoras de red.

Muchos de estos sistemas construídos en 1990 o poco después todavía están en funcionamiento. Modificación tras modificación, los desarrolladores han quedado pegados a esos entornos como los insectos en la drosera[10]. La aplicación funciona, hay mucho invertido en ella y no vale la pena rescribirla en un lenguaje o entorno de aplicación moderno.

Mientras conseguimos los binarios para el compilador y el runtime de la aplicación, sea que siguen funcionando los viejos o adquirimos licencias para binarios más modernos, la calesita sigue girando y todos contentos.

Hasta que el hardware moderno no nos permite instalar los binarios de nuestro sistema operativo, o no tiene soporte para discos SATA, o … una larga lista de drivers que no están.

Por supuesto que se pueden adquirir licencias con binarios nuevos de la nueva empresa detrás de esos sistemas operativos, llamada XINUOS[11]. Eso sería seguir gastando dinero en un programa que ha pasado de mano en mano muchas veces. La verdad es que no resulta atrayente.

Una alternativa: migrar a GNU/Linux

Ya nombramos la empresa Micro Focus que vende un compilador de ACU COBOL para GNU/Linux, el cual puede compilar los fuentes de RM COBOL 85, casi sin modificarlos. Informix provee binarios para GNU/Linux, al igual que PROGRESS. SCO FoxBase puede emularse mediante Linux ABI (Application Binary Interface).

Entonces el proyecto de salir de SCO sobre hardware obsoleto puede ser moverse hacia GNU/Linux sobre hardware moderno.

Otra alternativa: virtualizar SCO

Lo cual nos lleva al tema técnico de esta entrega.

Hasta ahora había fracasado en los intentos que hice de virtualizar versiones antiguas de SCO Unix y SCO OpenServer.

Ya no más. Con SCO OpenServer 5.0.7 y qemu 1.1.2 fue un éxito.

La virtualización te da varias posibilidades:

seguir con el viejo sistema hasta que sea prudente pensar en una rescritura.
utilizar el viejo sistema para poner en producción el nuevo en paralelo
crear una copia virtualizada para que los desarrolladores del nuevo sistema tengan un arenero donde jugar sin romper los datos en producción.

Cómo virtualizar con GUI

En otras entregas hemos virtualizado mediante la línea de mandatos. Para variar hoy utilizaremos una interfaz gráfica.

Instalamos los paquetes necesarios:

 Bash |   copy code | ?  
apt-get install virt-manager kvm

Verificamos si disponemos de soporte para virtualización por hardware:

 Bash |   copy code | ?  
egrep '(vmx|svm)' --color=always /proc/cpuinfo

Es importante que dispongamos de esta característica en la CPU de nuestro sistema de virtualización, porque eso aumenta la velocidad de los sistemas virtualizados.

Una vez instalados los paquetes, podemos verificar que el soporte de virtualización qemu está disponible, mediante:

 Bash |   copy code | ?  
virsh -c qemu:///system list

La conexión tendrá éxito, aunque, es obvio, mostrará una lista vacía de máquinas virtuales.

Ahora, configuramos la placa Ethernet en modo bridge, para eso en nuestro Debian editamos /etc/network/interfaces y dejamos:

 interfaces |   copy code | ?  
## en modo bridge:
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address IP_HOST
        netmask 255.255.255.0
        gateway GW_HOST
        network NETWORK_HOST
        broadcast BROADCAST_HOST
        dns-nameservers NAMESERVER_HOST
        dns-domain DOMAIN.HOST
        dns-search DOMAIN.HOST
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Reiniciamos la red para que los cambios tomen efecto:

 Bash |   copy code | ?  
/etc/init.d/networking restart

La cuenta que vamos a usar para crear las máquinas virtuales, supongamos que es cesarballardini, entonces debemos agregarla al grupo libvirt:
usermod --append --groups libvirt cesarballardini

Sólo nos queda iniciar virt-manager y en la ventana que se abre elegir una nueva máquina virtual, asignarle por ejemplo 20 Gbytes de disco, 128 Mbytes de RAM, conectarle la imagen de instalación de SCO, y una placa de red pcnet. Presta atención de nuevo: la placa de red es pcnet.

El sistema se instala como le es usual, y pide las credenciales de la licencia que has adquirido previamente. Cuando temina lo tienes listo para funcionar.

Conclusiones

Se puede tener corriendo una versión razonablemente moderna de SCO OpenServer en un entorno de virtualización libre como qemu.

Si me pides un consejo, te diría: «no lo hagas». Migra las aplicaciones para que corran nativas sobre GNU/Linux. Más aún, usa lenguajes de programación, y herramientas de trabajo que sean libres.

Como siempre, haz lo que quieras. O lo que puedas.

Nos leemos…

Referencias

[1] https://en.wikipedia.org/wiki/Santa_Cruz_Operation

[2] https://en.wikipedia.org/wiki/SCO_Group

[3] http://www.groklaw.net/staticpages/index.php?page=20061212211835541

[4] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt#Definition

[5] http://www.microfocus.com/products/micro-focus-developer/rm-cobol/ RM COBOL 85 era propiedad de Liant Software Corporation, fundada en 1970 como Ryan McFarland Corp.. En 2008 Micro Focus compra Liant. Micro Focus es la proveedora de ACU COBOL, un compilador nativo recomendado para sistemas GNU/Linux.

[6] http://es.wikipedia.org/wiki/Informix

[7] http://en.wikipedia.org/wiki/Informix_Corporation creada en 1980 y vendida a IBM en 2001

[8] http://en.wikipedia.org/wiki/Progress_Software un poco de historia

[9] http://www.progress.com/ homepage; el PROGRESS 4GL de los 1990, se ha remozado y renombrado a OpenEdge.

[10] http://es.wikipedia.org/wiki/Drosera

[11] http://www.xinuos.com/

Topics: KVM, SCO Unix, sysadmin | No Comments »

Cuando la vida te da limones, hazte limonada — winexe

By cesar | julio 1, 2013

1. Introducción

Hace un par de décadas que me dedico a administrar sistemas. Eso indica más sobre mi edad que sobre mi experiencia. Digamos ahora que la mayor parte de ese tiempo he trabajado sobre sistemas Unix. NCR, SCO y por supuesto desde 1995 GNU/Linux y otras variantes libres.

¿Que hacer cuando tu red se ve invadida por computadoras de escritorio con Microsoft Windows? Bueno, puede no ser lo más valiente, pero una alternativa elegante es evadir el tema. Por ejemplo puedes reclutar un alma más dispuesta al sufrimiento en esta tierra y hacerle pagar sus culpas administrando esos sistemas. Puedes emigrar a un terreno más libre; de hecho, ésta es la alternativa más saludable, porque los sistemas libres habitualmente vienen con gente que tiene más onda, y siempre es bueno estar en sintonía en el trabajo con tus compañeros.

Puede ser también que la vida no te deje evadir el curso de colisión y debas enfrentar la administración no sólo de los servidores sino también de los escritorios. En este caso, solamente te deseo que implementes un sistema de atención temprana a los usuarios de los escritorios, para recibir los reclamos, y realizar la atención primaria. ¡Aléjate de ese sistema! ¡Está lleno de gente que no entiende nada de computadoras y seriamente preocupada por su trabajo! Si las computadoras, redes y aplicaciones no funcionan como ellos quieren que así sea, te verán como el estorbo en su camino. Pocas veces se les ocurrre que tu labor es ayudarlos a hacer su trabajo, y no flexionar las leyes de la física y de las comunicaciones electrónicas para que respondan a sus expectativas.

Si hasta aquí has podido con mis consejos, estás en una situación interesante: tienes una red mixta con GNU/Linux y MS Windows, hay un sistema de atención primario o mesa de ayuda que recibe los reclamos, atiende las demandas y calma la furia usuaria. Ahora te queda resolver una cosa simple: asegurar que los sistemas MS Windows tienen ciertas instalaciones estándar dentro de la organización, permisos en ciertos directorios, recursos compartidos, cuentas creadas, impresoras instaladas.

Pero si vienes de una historia U*nix, sabes que para ser productivo necesitas una línea de mandatos. Las interfaces gráficas son muy bonitas y ayudan a hacer fáciles ciertas tareas para los usuarios menos dotados. Mis hijos usan interfaces gráficas desde que tienen 4 años y debo reconocer que lo hacen muy bien. Pero ya no estamos en el jardín de infantes, por eso en lugar de apuntar cosas con el dedo y llorar (point and click) hablamos como personas civilizadas. La CUI (Character User Interface) apela a nuestros rasgos conversacionales.

Supongamos que tenemos resuelto el tema de los mandatos, tampoco queremos escribir una y otra vez los mismos mandatos. Aquí los conocidos scripts pueden darnos una mano. Los sistemas Microsoft, desde la época del MS DOS disponen de archivos batch con extensión .bat, que son francamente horribles, al menos para una estética basada en el shell de U*nix, y ni hablar si lo miramos desde el GNU Bash. La nueva alternativa de PowerShell pinta lindo, me gustaría tenerla disponible, pero debo reconocer mi ignorancia en ese tema. La última vez que escribí scripts para sistemas Microsoft debe haber sido alrededor de 2001, cuando los cipayos locales de empresas transnacionales de software persiguieron a quienes tenían copias ilegales de sus programas. En esa época tuve que adecuar instalaciones para asegurar que cumplían las regulaciones, y allí fue necesario un poco de automatización con scripts.

Además de los scripts, el nuevo chico en la escuela es Puppet[1], de la empresa Puppet Labs[2], que hace relativamente pocos meses tiene soporte para sistemas MS Windows.

2. Gestión remota de sistemas MS Windows

Winexe[3] es un programa de ejecución remota de mandatos sobre sistemas MS Windows. El programa corre en sistemas GNU/Linux.

En el lado MS Windows, es necesario que el sistema tenga la siguiente configuración:

la red local está funcionando correctamente, obvio.
debe activarse la administración remota y los archivos e impresoras compartidos
Una cuenta con privilegios de admnistrador, y con contraseña no vacía, que llamaremos respectivamente ADMIN_USER y ADMIN_PASS, en el resto de esta entrega.
el firewall debe permitir la comunicación con la computadora donde corres winexe

Puedes verificar que esto está correcto, si ves los recursos compartidos ADMIN$ y el IPC$. MS Windows XP Home no sirve para esto, tíralo a la basura, donde pertenece. MS Windows XP debe tener apagado el Simple Sharing.

La magia de winexe es utilizar el mecanismo que usa psexec nativamente en los sistemas MS. Básicamente, usa RPC para levantar un servicio en la máquina MS, y luego se conecta a él. Los puertos usados son 445 para SMB y 135 para DCOM (de paso: siempre es prudente asegurar mediante firewall u otro encantamiento que no hay conexiones desde redes externas dirigidas a estos puertos en la red interna). El servicio que instala winexe es winexesvc.

Una utilidad espectacular basada también en esta idea, y escrita en Python es psexec.py[4]. La ventaja sobre winexe, es que se puede hacer toda clase de malabares en Python, para consultar y/o modificar los sistemas MS Windows, sin necesidad de usar scripting en shell.

A modo de ayuda memoria, te indico una página muy conocida[5] con un resumen de los mandatos de psexec.

En las siguientes secciones, agrupé las tareas típicas que debe realizar un sysadmin sobre los sistemas MS Windows. Al menos, son las tareas que me toca hacer a mí.

3. ¿Cómo instalo winexe en mi GNU/Linux?

Puedes descargar los fuentes y compilarlos en tu sistema. Si tienes la posibilidad de usar los binarios preempaquetados, por ejemplo, puedes encontrar los paquetes en[6].

Descargas el apropiado, en mi caso es:

 Bash |   copy code | ?  
wget http://repo.openpcf.org/repository/ext/openpcf/debian/dists/squeeze/main/binary-i386/winexe_1.00-0openpcf2~squeeze_i386.deb

Podría haber instalado el repositorio de paquetes, pero en realidad no hace falta porque el paquete mencionado no tiene dependencias resueltas dentro de su repo, así que basta con descargarlo y luego instalarlo:

Instalo el paquete

 Bash |   copy code | ?  
dpkg -i winexe_1.00-0openpcf2~squeeze_i386.deb

¡Y listo! Ya se puede usar.

4. ¿Cómo correr winexe?

Si escribes winexe, te mostrará una breve lista de opciones, y si deseas una lista más explicada puedes correr:

 Bash |   copy code | ?  
winexe -?

Por supuesto, la referencia clara es la que puedes leer en el manual:

 Bash |   copy code | ?  
man winexe

Hago la aclaración de la página de manual, porque muchos administradores jóvenes vienen acostumbrados a no leer los manuales, lo cual da pena.

Vamos a correr nuestro primer mandato remoto con winexe. Supongamos que las siguientes variables de entorno almacenan la información que se describe:

 Bash |   copy code | ?  
export ADMIN_USER=Administrador    # cuenta con privilegios de administración
export ADMIN_PASS=c@ntrasen14    # contraseña de la cuenta anterior
export ESCRITORIO=192.168.123.234  # ip de la pc de escritorio con MS Windows

Y corremos winexe para ver el contenido del directorio raíz en la unidad C: de la pc de marras:

 Bash |   copy code | ?  
winexe -U ${ADMIN_USER}%${ADMIN_PASS} //${ESCRITORIO} 'cmd.exe /c dir C:\'

El último argumento es la cadena de caracteres con el mandato a ejecutar en el sistema Microsoft. Una línea tan larga ruega a gritos que la transformemos en una función de shell:

 Bash |   copy code | ?  
rmcmd() {
  echo rmcmd: $*
  echo -e $* "\nexit" |  winexe -U ${ADMIN_USER}%${ADMIN_PASS} //${ESCRITORIO}  'cmd.exe'
}

El echo -e nos permitirá concatenar strings con saltos de línea para enviar múltiples mandatos en una misma sesión. El único inconveniente es que debemos prestar atención al escape de las contrabarras (\) que en los casos de comillas simples no hace falta y en el caso de comillas dobles deberán duplicarse.

5. ¿Cuál es la lista de software que tiene instalado el escritorio?

Con seguridad debes asegurar que cierto programa está y que tal otro no está. La lista de los programas instalados que se pueden desinstalar es:

 Bash |   copy code | ?  
rmcmd 'REG QUERY HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall'

6. ¿Cuál es la configuración de red del escritorio?

La salida de ipconfig, sin necesidad de ir hasta la consola de la pc:

 Bash |   copy code | ?  
winexe -U ${ADMIN_USER}%${ADMIN_PASS} //${ESCRITORIO} 'ipconfig /all'

o más brevemente:

 Bash |   copy code | ?  
rmcmd 'ipconfig /all'

7. ¿Cuál es la MAC de la pc?

 Bash |   copy code | ?  
rmcmd 'getmac'

8. ¿Cuál es la versión y nombre de host?

 Bash |   copy code | ?  
rmcmd 'cmd  /c ver && hostname ' | recode pc/

Usamos recode para preservar el sentido de los caracteres acentuados.

9. ¿Cómo gestiono la hora en el escritorio?

9.1. ¿Cuál es la hora del escritorio?

 Bash |   copy code | ?  
rmcmd 'net time \\\\localhost'

9.2. Poner en hora contra el servidor de archivos:

Determino un servidor de hora:

 Bash |   copy code | ?  
export SRV_NAME=filesrv01

Asigno la hora del escritorio para que sea la del servidor de hora:

 Bash |   copy code | ?  
rmcmd 'net time \\\\'"${SRV_NAME}"' /set /yes'

Preste atención especial al escapado de las contrabarras y los diferentes usos de comillas dobles y simples.

10. ¿Cómo gestiono las cuentas de usuario?

10.1. Ver cuáles son las cuentas definidas:

 Bash |   copy code | ?  
rmcmd 'net user'

10.2. Dar de alta una cuenta:

 Bash |   copy code | ?  
rmcmd 'net user prueba pwd123456 /add /active:yes /comment:"usr de prueba" /countrycode:000 /expires:never /fullname:"Nombre Apellido" /passwordchg:yes /passwordreq:yes /logonpasswordchg:no'

10.3. Ver información detallada de una cuenta:

 Bash |   copy code | ?  
rmcmd 'net user prueba'

10.4. Dar de baja una cuenta:

 Bash |   copy code | ?  
rmcmd 'net user prueba /delete'

11. Cómo conecto a una unidad de red

Además de las variables para conectarnos al escritorio a administrar, ahora usaremos otras variables para indicar la información de un servidor de archivos en la red local. La idea es que el escritorio se conecte a un recurso compartido en el servidor.

 Bash |   copy code | ?  
export ADMIN_USER=Administrador    # cuenta con privilegios de administración
export ADMIN_PASS=c@ntrasen14      # contraseña de la cuenta anterior
export ESCRITORIO=192.168.123.234  # ip de la pc de escritorio con MS Windows

Los datos para acceder al servidor serán:

 Bash |   copy code | ?  
export SRV_NAME=filesrv01
export SRV_SHARE=Temporal
export SRV_PASS=otr@passw0rd
export SRV_USER=jperez

El SRV_NAME es el nombre NETBIOS del servidor de archivos, SERV_USER/SRV_PASS son las credenciales válidas para conectarnos al recurso compartido SRV_SHARE.

El mandato completo queda, usando la función que habíamos preparado:

 Bash |   copy code | ?  
rmcmd  'net use P: \\\\'${SRV_NAME}'\\'${SRV_SHARE}' /PERSISTENT:No '${SRV_PASS}' /USER:'${SRV_NAME}'\\'${SRV_USER}

y lo podemos verificar con dir a continuación:

 Bash |   copy code | ?  
rmcmd  'net use P: \\\\'${SRV_NAME}'\\'${SRV_SHARE}' /PERSISTENT:No '${SRV_PASS}' /USER:'${SRV_NAME}'\\'${SRV_USER}  "\n" \
    "dir p:"

Si al dir lo hacemos en otra sesión, diferente de la sesión en la cual se conecta la unidad, no se ve la unidad.

Por último, desconectamos la unidad de red con:

 Bash |   copy code | ?  
rmcmd 'net use P: /DELETE /Y'

Note que la conexión puede no existir fuera de la sesión que la creó.

12. Cómo creo un recurso compartido en el escritorio

Vamos a crear un directorio, asignarle permisos y compartirlo a través de la red. Una buena referencia sobre cómo cambiar permisos en archivos se puede encontrar en [7].

Creamos el directorio en el escritorio:

 Bash |   copy code | ?  
rmcmd 'mkdir c:\descarga_paquetes'

Asignamos los permisos necesarios para el acceso local

 Bash |   copy code | ?  
rmcmd 'echo S | cacls c:\descarga_paquetes /G Administrador:F '
rmcmd 'echo S | cacls c:\descarga_paquetes /G Administradores:F '

Permisos para acceso a través de la red; estos permisos son obligatorios y no son los que se usan para limitar el acceso de las cuentas a los archivos, para ese fin se acomodaron los permisos en el paso anterior:

 Bash |   copy code | ?  
rmcmd 'net share DescargaPaquetes=c:\descarga_paquetes /GRANT:Todos,FULL /remark:"directorio recien creado." '

Verificamos que el escritorio es accesible con la cuenta con privilegios administrativos, ya que a esa cuenta le dimos permisos sobre el directorio en la pc:

 Bash |   copy code | ?  
smbclient //${ESCRITORIO}/DescargaPaquetes -U${ADMIN_USER}%${ADMIN_PASS} -c "mkdir BORRAME"
smbclient //${ESCRITORIO}/DescargaPaquetes -U${ADMIN_USER}%${ADMIN_PASS} -c "dir"

Y por último, dejamos de compartir el directorio a través de la red:

 Bash |   copy code | ?  
rmcmd 'net share DescargaPaquetes /delete'

13. Cómo copio un archivo hacia el escritorio

Supongamos que tenemos un archivo en un servidor de red, y queremos transferirlo hacia el escritorio. Vamos a crear un directorio en el escritorio y lo compartiremos a través de la red, como en el apartado anterior. Antes de dejar de compartirlo, haremos la copia, por ejemplo con:

 Bash |   copy code | ?  
smbclient //${ESCRITORIO}/DescargaPaquetes -U${ADMIN_USER}%${ADMIN_PASS} -c "put /ruta/completa/archivo.ext  "

14. Cómo instalo Puppet en MS Windows, remotamente

Lo que haremos es descargar el instalador para sistemas MS Windows, lo copiaremos a la pc escritorio, y luego realizaremos la instalación.

Para copiar un archivo al escritorio usaremos las instrucciones ya comentadas en una sección anterior.

Descargamos el instalador desde la zona de versiones open source[8], como voy a usar un servidor 2.7, uso un cliente apropiado y descargo el:

 Bash |   copy code | ?  
wget https://downloads.puppetlabs.com/windows/puppet-2.7.12.msi

Lo copiamos al directorio de descargas como se explicó antes.

Lo instalamos:

 Bash |   copy code | ?  
rmcmd  'msiexec.exe /i c:\\descarga_paquetes\\puppet-2.7.12.msi /quiet /norestart PUPPET_MASTER_SERVER=puppet.MIDOMINIO.COM'

donde a MIDOMINIO.COM lo deberás reemplazar por el tuyo, o si no tienes sistema de nombres configurado en tu red, puedes poner allí el número de ip de tu puppetmaster.

¿No sabes lo que es un puppetmaster? ¿No lo tienes configurado? No cabe en esta entrega cómo instalar y configurar tu puppetmaster, pero hay muchos recursos en la Web. En particular, la documentación oficial está en [9], las guías de instalación en [10], y cómo escribir las recetas para sistemas MS Windows, en [11].

15. Vamos ahora a hacer algunas tareas típicas con puppet.

Lo configuramos para que no corra al arranque de la computadora. Después de todo, estamos iniciando nuestra red, y queremos mantener el control al principio, para asegurar de no romper nada. Más tarde tendremos diferentes environments, para máquinas con recetas de producción, de testing y de desarrollo. Estos entornos no tienen que ver con las aplicaciones que los usuarios utilizan, y el desarrollo de las mismas. Son los entornos para el desarrollo de las configuraciones, o sea, el desarrollo que hacen los sysadmin, como nosotros.

 Bash |   copy code | ?  
rmcmd 'sc config puppet start= demand'

detenemos el servicio si está corriendo:

 Bash |   copy code | ?  
rmcmd 'sc stop puppet'
rmcmd 'del C:\\ProgramData\\PuppetLabs\\puppet\\var\\run\\agent.pid'

arrancamos el servicio

 Bash |   copy code | ?  
rmcmd 'sc start puppet'

Y el más interesante, forzar al agente a hacer una corrida:

 Bash |   copy code | ?  
rmcmd ' "C:/Program Files/Puppet Labs/Puppet/bin/puppet.bat" agent --test  --verbose --one'

Ahora el agente en el escritorio se contacta con el puppetmaster y trata de reconocerse mediante certificados digitales. No vamos a entrar en detalles, pero baste decir que debemos ir al puppetmaster para firmar el certificado del cliente.

En el puppetmaster, vemos la lista de solicitudes pendientes de firma:

 Bash |   copy code | ?  
puppet cert --list

Firmamos la solicitud pendiente de la pc con el agente en Ms Windows:

 Bash |   copy code | ?  
puppet cert --sign nombre-de-certificado</p>

La siguiente vez que el agente se conecte, pedirá su receta de nodo, así que es mejor que le preparemos una.

16. Una receta básica para un escritorio

¿Qué debemos asegurar que haya en los escritorios? Cosas que vienen a mi mente son:

Un usuario con privilegios de administración y una contraseña dada
Ciertos usuarios no privilegiados para que los empleados puedan usar el escritorio
Ciertas unidades de red, conectadas
Ciertos directorios del escritorio, compartidos por la red con permisos para ciertas cuentas.
Los programas de oficina, como LibreOffice, Putty, etc., y otros administrativos

Empezamos por algo simple, y lo demás queda de tarea para el lector:

 puppet |   copy code | ?  
node 'escritorio.MIDOMINIO.COM'  {

  # demo de un archivo transferido al escritorio:
  file { 'c:/prueba.txt':
    ensure => 'file',
    mode => '0660',
    owner => ‘adminuser’,
    group => 'Administradores',
    content => 'hola mundo desde puppet',
  }

  # demo de un usuario creado en el escritorio:
  user { "adminuser":
    ensure      => present,
    password    => adminpasswordsecret4,
    groups      => "Administradores",
  }

  info('------------->>>>> soy la pc de fulanodetal')
}

Conclusiones

Con el material que hemos cubierto en esta entrega, podemos armar un plan para configurar y administrar en forma remota los escritosios MS Windows.

Las fases del plan pueden ser las siguientes:

Relevar la red en busca de equipos con MS Windows. Se puede escanear la red para tener una vista previa de la situación, pero al final hay que ir puesto por puesto para asegurar el inventario, a causa de equipos apagados o desconectados. Asegurar los requisitos para que funcione winexe, y una cuenta con privilegios administrativos y su correspondiente contraseña.
Instalar winexe en el sistema GNU/Linux de gestión.
Usar winexe para instalar puppet en los escritorios.
Instalar un puppetmaster en GNU/Linux.
Escribir las recetas puppet para los escritorios. Someter las recetas a riguroso control de versiones.
Usar winexe para forzar la ejecución del agente en los escritorios. Cuando se estabilicen las configuraciones, programar la tarea agente para que se ejecute cada media hora.
Adoptar un workflow de trabajo para el desarrollo de las recetas puppet, designando máquinas para el desarrollo y prueba de los cambios en las recetas, antes de pasarlas a producción.