X-Files y Poltergeists. Cuando Windows está maldito

Hace poco me encontraba con uno de esos problemas de resolución aparentemente imposible en una máquina Windows Server 2008 de 64 bits.

En ocasiones, la información y soporte que Microsoft dan al respecto son tremendamente pobres y a veces incluso dicha información es confusa o inexacta.

Tal fue el asunto que me tuvo ocupado con la susodicha máquina hasta casi el borde de la desesperación. Sin pistas, sin ningún otro caso descrito similar en ningún foro, la cosa pintaba mal. Sería el típico caso en que la mayoría de administradores de sistemas habrían optado por reinstalar todo el sistema operativo. Pero en mi caso, eso no era una opción.

De hecho, nunca me ha parecido una opción. Reiniciar o reinstalar vendría a suponer, en la analogía de un médico, amputar una pierna porque no se esforzó lo suficiente en encontrar la causa que le provoca el dolor al paciente.

Así que vamos allá. La solución fue usar la fuerza bruta en un modo en el que se pueden solucionar otras muchas complicaciones en Windows. 

Problema firmando el GDB (The GNU Project Debugger) en Mac OS X

Buenas tardes,

andábame yo inmerso en un fantástico proyecto cross-platform desarrollado en Lazarus (el famoso clon del mítico Delphi, que ya por fin funciona y es usable) cuando se me ocurrió probar el tema de las múltiples plataformas instalando el IDE en el Mac.

La instalación de Lazarus  es sencilla en principio (como cualquier otra aplicación de Mac). El problema es que hace falta tener instaladas las "command-line tools" y parece ser que en Xcode 5.0 no es tan trivial como parece.

Pues bien, el principal problema es que hay que instalar el debugger de GNU (es decir, la herramienta gdb) y hay que firmarla con un certificado.

Siguiendo las guías oficiales me encontré con algunos escollos que no estaban bien aclarados, y que una vez resueltos, comparto con todo el mundo por si os ocurre también. Las guías en cuestión son:

http://wiki.lazarus.freepascal.org/Installing_Lazarus_on_MacOS_X#Xcode_5.0.2B_compatibility_.28Mac_OS_X_10.8_and_10.9.29

y

http://wiki.lazarus.freepascal.org/GDB_on_OS_X_Mavericks

Podéis seguir sin problema paso a paso ambos manuales. Pero al llegar a la parte de cómo crear un certificado y cómo firmar el ejecutable del debugger, hay que tener en cuenta dos detalles que no se dicen:

Para poder crear el certificado con el asistente siguiendo los mismos pasos, antes tenéis que desbloquear la opción de crear certificados de tipo system. Si no, simplemente no os saldrán las opciones correctas en el asistente (sólo unas parecidas) y estaréis perdidos al intentar seguir los pasos del manual. Para ello tenéis que desbloquear la herramienta de acceso a las claves y certificados:

Una vez realizado ese paso ya podéis usar el asistente para la creación del certificado exactamente en los mismos términos que explica la guía.

Si todo ha salido bien, el siguiente paso es firmar el ejecutable gdb siguiendo los pasos de la guía. Esos pasos son correctos y hay que seguirlos. Sin embargo, no se nos avisa de que para que Lazarus reconozca al ejecutable del debugger como un programa firmado, hay que, o bien reiniciar el sistema (innecesario y exagerado) o bien escribir el siguiente comando en la terminal (como root):

killall taskgated

Tras esto, volved a abrir Lazarus y ya debería dejaros compilar y debuguear sin problemas.

Creación de un Virtual Appliance para control de Internet con VMware (parte 4)

<< Artículo anterior

Continuamos esta serie de artículos sobre el "appliance virtual" basado en Squid. Ahora ha llegado el turno de la integración con redes y dominios basados en Windows y en Active Directory. El primer paso a seguir es instalar SAMBA en nuestro FreeBSD.

Como en otras ocasiones ejecutamos sysinstall y buscamos la instalación del paquete adecuado:

Configure → Packages → net → samba34-3.4.9_1

(Obviamente el número de versión del paquete dependerá del resto de versiones de cada instalación).

Necesitamos el siguiente cambio de permisos al archivo de configuración smb.conf para garantizar que el usuario squid (usado para correr el servicio) es capaz de abrir la configuración de Samba:

"Se busca Cliente Cisco VPN"

He detectado que en ocasiones algunos usuarios del cliente Cisco VPN se quejan de que éste "desaparece" en su versión de Windows.

El síntoma principal es que si abres el icono del cliente (el de forma de candado) o alguno de los atajos a los perfiles (archivos PRF), no se abre la ventana de conexión ni se inicia el proceso, en los respectivos casos.

Normalmente esto se debe a que por alguna razón hay un servicio parado. Pero antes veamos cómo está compuesto el cliente VPN de Cisco.

Creación de un Virtual Appliance para control de Internet con VMware (parte 3)

<< Artículo anterior

Una vez que tenemos nuestro sistema operativo base, el FreeBSD, montado y actuando como router y firewall básico es el momento de seguir con el siguiente paso: la instalación del proxy-caché, el afamado SQUID. Estamos ante uno de esos productos que, además de ser open-source y gratuitos, son la mejor opción del mercado para realizar sus funciones, por lo que una vez más se demuestra que los productos gratuitos no tienen por qué ser necesariamente inferiores a sus competidores comerciales.

Aunque en el momento de escribir este tutorial, la versión estable en producción es la 3.3, me he basado en la versión 2.7.9, no por nada en especial, simplemente porque es el paquete que venía en la ISO de FreeBSD que teníamos por aquí a mano y que hemos usado de base para el proyecto.

Creación de un Virtual Appliance para control de Internet con VMware (parte 2)

<< Artículo anterior

En el anterior artículo habíamos sentado las bases sobre el appliance que queremos construir: las funcionalidades, la intrastructura y el software y herramientas necesarias.

El siguiente paso es describir el planteamiento de manera más concreta y comenzar con la instalación básica del sistema operativo base y de los paquetes mínimos necesarios.

La red

Desde el punto de vista de la red local, este esquema representa la filosofía del proyecto:

Creación de un Virtual Appliance para control de Internet con VMware (parte 1)

Esta es la primera entrega de varios artículos que voy a publicar en los próximos días mostrando un caso práctico de creación de un appliance virtual para controlar el acceso a Internet de una compañía usando exclusivamente software gratuito.

La guía que vamos a desarrollar podría perfectamente valer para crear un appliance tradicional basado en un equipo headless cualquiera; además no es necesario un equipo de extremada potencia por lo que es la excusa perfecta para reutilizar cualquier PC al que íbamos a dar matarile. Sin embargo, he escogido el formato de máquina virtual porque así de paso nos aprovechamos de las distintas ventajas de usar una plataforma como VMware para usos que no siempre son tan conocidos o habituales.

Arranque diferido de servicios en servidores y estaciones Windows

En muchas ocasiones, algunos errores muy comunes en los sistemas operativos de Microsoft se deben a que algunos servicios arrancan de manera asíncrona, pero sin embargo tienen dependencias entre ellos para poder funcionar. Hay veces que dichas dependencias están ya preconfiguradas por defecto (el típico servicio que no puedes pararlo sin parar antes otros cuatro dependientes de él); pero otras veces las dependencias no están incluídas en la configuración de los servicios, y cuando el servicio dependiente se adelanta a su dependencia, empiezan a producirse todo tipo de problemas.

Varios de estos típicos errores suelen darse en los servidores que son controlador de dominio, especialmente cuando el servicio DNS local se retrasa más de la cuenta. Dado que el DNS es parte del corazón de la infraestructura Active Directory, si dicho servicio no está levantado a tiempo afectará a otros servicios y funciones (sobre todo cuando es necesario interrogar al DC acerca de detalles de la infaestructura, resolver nombres internos, etc.).

Reinicio de servicios en ESXi

Aunque la familia de productos VMware es en general extremedamente eficiente y estable, en ocasiones el hipervisor no está exento de comportamientos imprevistos.

En al menos una o dos ocasiones he experimentado problemas que requerían reiniciar la máquina física conteniendo al hipervisor, y cuando se trata de un sistema en el cuál no hay cabina externa de almacenamiento de las máquinas virtuales, ni vMotion, ni otras facilidades para conseguir alta disponibilidad, pues es un problema porque hay que hacer una parada de todos los servidores virtualizados dependientes de ese host.

Problemas de este tipo suelen ser los que tienen síntomas como:

Conciliar la descripción de los PC con Active Directory

Si eres uno de esos administradores de sistemas que, como yo, intentas que todos los campos en Active Directory estén lo mejor cumplimentados posible (especialmente si usas algún software de inventario basado en Active Directory), te habrás topado alguna vez con este pequeño inconveniente del que os voy a hablar.

Se trata de la discrepancia entre el campo "Descripción" de la cuenta de equipo en Active Directory y el campo local "Descripción" del propio equipo en sí. Cuando hacemos un "net view" o simplemente examinamos la red desde una estación de trabajo cualquiera, junto al nombre de cada host aparece la descripción del propio equipo.

Cambiar dicha descripción (local o remotamente) en cada PC es un trabajo de chinos. Hay que ir uno a uno, o bien hacer un script o archivo de lotes de comandos. Pero esto tendría el inconveniente de que tienen que estar todos encendidos, y además no se actualizarían automáticamente.

Problemas de DNS con cliente VPN Cisco en Windows

Si trabajáis con redes virtuales y sistemas Cisco, es probable que alguna vez os encontréis con este problema.

Resulta que cuando un usuario de Windows utiliza el Cisco VPN Client para conectar a la VPN de su empresa, este levanta una interfaz virtual para enrutar el tráfico privado por el IPsec Tunnel creado por el cliente Cisco. Hasta aquí todo correcto y previsible.

El problema viene cuando dicha interfaz virtual toma los DNS que el peer remoto le asigna, y no te dan opción a poner tú los tuyos, ya que estos son "machacados" cada vez que conectas con la VPN. Es fácil configurar cuando se tiene acceso a todos los parámetros de ambos extremos, y en especial cuando tienes la gestión del router/firewall que está actuando como terminador de túneles (típicamente un ASA, un PIX o algún otro chisme cisquero con esas capacidades). Pero en la vida real no suele ser el caso si utilizas un servicio gestionado por compañías como Movistar (cuya flexibilidad en la gestión de la VPN deja mucho que desear).

Cambio de "look"

Buenos días,

en lo sucesivo voy a intentar cuidar un poco más este blog que tenía un poco olvidado y a empezar a alimentarlo con más contenidos y mejores.

Mientras tanto y como anticipo he hecho un ligero cambio de look & feel (título, colores, etc.) para renovarlo un poquitín.

Además, he cambiado la dirección principal, que antes pasa a ser http://www.debugmachine.com en vez de la habitual de Blogger (http://debugmachine.blogspot.com).

Nos vemos pronto.

Problemas de acceso a la WEB en Windows. Los malwares proxy

Existe un tipo de malwares, virus, etc. pululando por los sistemas Windows que provocan que los navegadores Internet Explorer, Google Chrome y Safari dejen de funcionar (aunque no así en Mozilla Firefox, salvo que este esté configurado para usar la configuración de proxy del sistema).

Este tipo de bichos están diseñados para obtener toda la información posible acerca de nuestros hábitos de navegación con diferentes propósitos: spyware, robo de contraseñas no seguras, etc. El ataque que provocan es de tipo man-in-the-middle, aprovechando la configuración de proxy de usuario de Windows la cuál es fácilmente manipulable mediante una simple escritura en el registro.