jueves, 4 de junio de 2015

Alternativa a Active Directory bajo Linux

¿Qué haces cuando tienes un parque de equipos Linux y quieres gestionarlos como lo harías con Active Directory?

De cara al mecanismo de login, es relativamente sencillo. Casi desde siempre se ha podido utilizar un LDAP para tener una gestión centralizada de usuarios. Pero Active Directory ofrece más cosas.

Esas otras cosas que tiene Active Directory se llaman "políticas". Y permiten establecer el fondo de pantalla de un usuario, instalar software en un equipo o configurar una impresora.

Pues bien, ahora podemos tener eso mismo en Linux. Existe un proyecto de la Junta de Andalucía llamado GECOS que hace exactamente esto.

¿Cómo lo hace? Pues lo hace utilizando Opscode Chef (https://www.chef.io/chef/).

A "grosso modo" GECOS se puede dividir en 3 partes:
  • El Centro de Control GECOS: que ofrece una interfaz web para gestionar los usuarios, equipos y políticas de forma cómoda. Este Centro de Control lo que hace es meter valores en Chef por detrás.
  • Un servidor de Chef: que controla la configuración de los equipos en la sombra.
  • Una utilidad de configuración para distribuciones basadas en Ubuntu: que sirve para configurar el cliente de Chef de forma que tire contra el servidor de Chef, y para configurar el login de usuarios de forma que tire contra LDAP o Active Directory.
Este último punto, las utilidades de configuración, ya se encuentran integradas y preparadas en la distribución de Linux Guadalinex GECOS (basada en Linux Mint).

De forma que con GECOS se puede:
  • Cambiar el fondo de escritorio de un usuario
  • Instalar software en un equipo
  • Configurar una impresora en un equipo
  • Mostrar un mensaje de alerta al usuario
  • Etc

Por el lado malo, a fecha de hoy la versión de GECOS existente aún tiene muchos pequeños fallitos y detalles que pulir.

Además, recordemos que Active Directory tiene un esquema más o menos fijo, con lo que el script para importar usuarios de Active Directory dentro de GECOS  funciona más o menos bien.

Pero LDAP tiene un esquema que cada uno configura según su gusto, con lo que cada LDAP es de su padre y de su madre. Así que necesitarás conocimientos de programación para modificar el script base y realizar muchas importaciones de prueba hasta conseguir importar correctamente tu LDAP dentro de GECOS.

Salu2 a to2

lunes, 16 de marzo de 2015

Enviando datos en crudo a una impresora

Hola chavales, en el curro me he topado con un problema con unas viejas impresoras matriciales.
Resulta que el programa que envía los datos a imprimir, los manda "en crudo" ("raw" para los colegas).

Explico, nosotros tenemos un driver que suplanta una impresora Postscript y crea un PDF. Pues bien, la impresión "en crudo" lo que hace básicamente el saltarse el driver a la torera y enviar los datos directamente al puerto.

Para hacer las pruebas pertinentes, utilizamos un programita de Micro$oft:
 https://support.microsoft.com/es-es/kb/138594?wa=wsignin1.0

Gracias a las pruebas con este programita detectamos que el driver no se ejecutaba, y que los datos iban del tirón al puerto en cuestión.

Así que ya sabéis que si una impresora matricial no funciona, quizá la culpa no sea del driver.

Salu2 a to2

jueves, 5 de marzo de 2015

Trabajo con impresoras desde la línea de comandos en Windows

Hola a todos, hoy se ma ha planteado la necesidad de ver cómo se puede cambiar el nombre de una impresora desde la línea de comandos de Windows.

Pues bien, resulta que Microsoft incorpora una serie de Scripts VBS para trabajar con las impresoras.

https://technet.microsoft.com/es-es/library/cc771846%28v=ws.10%29.aspx

Lo primero es localizar estos scripts en el ordenador. En el servidor donde estaba trabajando se encontraban en la ruta C:\Windows\System32\Printing_Admin_Scripts\es-ES\

A partir de ahí puedes utilizar estos scripts para hacer cosas como listar las impresoras del sistema:

   cscript prnmngr.vbs -l 

O cambiar el nombre de una impresora:

  cscript prncnfg.vbs -x -p "Microsoft XPS Document Writer" -z XPS

Salu2 a to2

domingo, 1 de marzo de 2015

Comparando antes y después con Windows

Hola a todos. En un servidor con Windows Server 2012 tenemos una aplicación que cuando un usuario con privilegios de administrador instalaba, dicha aplicación funcionaba correctamente.

Pero si se borraba el perfil local de la máquina (teniendo "roaming profiles" en el Active Directory), tras iniciar sesión en el servidor la aplicación ya no funcionaba.

Dicha aplicación se instala en el perfil del usuario, algo nada recomendable pero por lo que se ve los programadores de esta aplicación lo hicieron así. Así que cuando ese "perfil movil" se movía, había algo de la aplicación que no se estaba moviendo correctamente.

Después de muchos quebraderos de cabeza y muuuuuuuchas horas de trabajo, conseguimos averiguar qué era y solucionar el problema. Para ello usamos el software "Process Monitor".

  https://technet.microsoft.com/es-es/sysinternals/bb896645.aspx

Partiendo de un perfil limpio, instalamos la aplicación y luego lanzamos el process monitor.

Aplicamos todos los filtros necesarios para excluir de la captura de eventos los procesos típicos del sistema (como el "task manager", o el "svchost"), y lanzamos la apliación que lógicamente funcionó correctamente. Luego guardamos la captura como CSV.


Tras esto, cerramos sesión, borramos el perfil local y a tras traerse el perfil móvil hicimos otra captura de eventos con el Process Monitor, pero esta vez sabíamos que la aplicación fallaría.

Una vez que teníamos 2 ficheros CSV (una con los eventos cuando la aplicación funciona y otra cuando no funciona). Los abrimos con Excel y quitamos las columnas de fecha y hora, y del ID de proceso. De esta forma los dos ficheros CSV son similares hasta el punto donde falla la aplicación.

Finalmente, comparando ambos ficheros CSV con Winmerge (que para algo son ficheros de texto), pudimos ver que nos faltaban algunas entradas del registro e incluso una librería DLL.

RESUMIENDO: Si queréis comparar un "antes" y un "después" del comportamiento de una aplicación, el "Process Monitor" es un buen aliado.

Salu2 a to2


martes, 17 de febrero de 2015

PnaclCoordinator: pexe load failed (pp_error=-2).

Hola a todos, hoy me he encontrado el siguiente error al intentar depurar el código PNaCL:

NaCl module load failed: PnaclCoordinator: pexe load failed (pp_error=-2).

Por lo visto, este código lo que indica es que no se ha podido descargar el PEXE. Así que le dí a F12, puse el navegador para ver los elementos que se descargan de la red, y vi que no tenía puesto el "*_unstripped.bc" en el servidor web.

Salu2 a to2

PNaCl ABI verification failed


Hola a todos, ayer estuve todo el día depurando en NaCL y cuando compilé la versión final con PNaCL me encontré el siguiente mensaje de error:

ERROR [NaCl module load failed: PnaclCoordinator: PNaCl Translator Error: PNaCl ABI verification failed]

Tras mucho investigar resulta que tenía definida la variable del entorno NACL_SDK_ROOT apuntando a "pepper_canary" mientras que estaba intentando compilar con "pepper_39".

Así que la causa del problema es que estaba mezclando código de dos NaCL SDK distintos.

Cambié la variable para que apuntara a "pepper_39", recompilé todo y ya funciona.

Salu2  a to2

miércoles, 28 de enero de 2015

Construyendo los naclports

Hola a todos, estoy estudiando el uso de PNaCL para crear un cliente nativo de Chrome para los Chrome books.

Esta es sólo una de las opciones a estudio para ver con cuál de las opciones tendremos en menor tiempo y con menor esfuerzo una versión del cliente de nuestro software para Chromium.

Como parte de las dependencias de nuestro software está OpenSSL, así que viendo por la web encontré que lo mejor es tirar de los "naclports".

Para construir los "naclports" necesitarás:

  • Ubuntu 14 de 64 bits (no uses Debian porque encontrarás problemas con las versiones)
  • Descargar el "nacl_sdk" (debes descargar "pepper_canary") 
  • Descargar los "naclports". 

Como hay partes del "nacl_sdk" compilado para amd64 y partes compiladas para i386, necesitas la versión de 64 bits y obtener las librerías de 32 bits y las herramientas necesarias para la compilación mediante:


sudo apt-get install git curl lib32stdc++6 g++ lib32z1 lib32ncurses5 lib32bz2-1.0


Una vez hecho esto descaga el "nacl_sdk" y los "naclports" siguiendo los pasos indicados en:

Cuando ya has obtenido todo el software podrás construir la librería "openssl" mediante:

  cd naclports/src
  export NACL_SDK_ROOT=/home/usuario/chrome/nacl_sdk/pepper_canary

  export BUILDBOT_BUILDERNAME=true
  NACL_ARCH=pnacl TOOLCHAIN=pnacl make openssl

Si todo va bien deberá construirse la librería sin dar ningún error.

Un saludo