The Debug Machine

VirtualBox y directorios compartidos en Linux

2022-08-07T23:44:00.000+02:00

VirtualBox es probablemente el sistema de virtualización de escritorio más extendido del mundo, debido a su gratuidad, funcionalidad y rendimiento aceptable (aunque lejos de los productos VMWare). Sin embargo, a veces sus problemas de usabilidad provocan algún que otro dolor de cabeza. Uno de los más habituales se da cuando compartes un directorio entre la máquina anfitrión y una máquina virtualizada Linux.

Típica configuración de directorio compartido desde el anfitrión hacia el huésped.

Las opciones de configuración son muy claras al respecto. Según la teoría, ahora en el Linux virtualizado deberíamos tener un directorio montado como /mnt/src y que daría acceso al contenido de la máquina física en d:\home\jam\src.

Sin embargo, al intentar accederr desde el Linux virtual, obtenemos un sonoro error:

¡Oh,.no! A la porra nuestra felicidad.

¡Quiero parao!

No tan deprisa. Lo primero que se te ha pasado por la mente, a ti también, es abrir la consola y calzar un chmod -R 777 o alguna bestialidad equivalente. Sí, bueno... quizás habría funcionado. Pero aquí nos gusta hacer las cosas con un poco más de elegancia.

VirtualBox nos tiene preparado algo muy especial para este propósito: el grupo local vboxsf en la máquina huésped. Si nos fijamos, el directorio compartido queda montado con dicho grupo, algo que podemos ver con un simple ls -l o similar:

¡Estos niños de Innotek pensaron en todo en su momento!

¿Cuál es, entonces, la solución?

Sencillo: añadir nuestro usuario al grupo vboxsf con un simple comando como este (que puede variar según el sabor de Linux o Unix que tengáis):

sudo usermod -G vboxsf -a $USER

Obviamente, si el usuario que queréis añadir no es el mismo con el que estáis logueados (y al que apunta la variable de entorno $USER) tendréis que especificarlo manualmente.

Para finalizar, solo tendréis que cerrar la sesión y volverla a iniciar (o reiniciar el equipo).

¡A disfrutar!

Yahoo! Groups desaparecerá en unos días. ¡Descárgate tus grupos!

2019-10-19T12:34:00.000+02:00

Tal y como suena: un desastre.

Yahoo! Groups ha sido durante más de dos décadas (no olvidemos que comenzó como un servicio llamado Onelist que Yahoo adquirió tras su fusión con eGroups) un punto de encuentro de miles de personas que, mucho antes de que las famosas redes sociales lo inundasen todo, compartían interminables e interesantes charlas que podían indistintamente leerse vía web o usando nuestro email estándar.

Ahora, tras 23 años, un pedazo de historia de Internet (y por tanto del conocimiento universal) va a desaparecer para siempre: Yahoo! (actualmente propiedad de Verizon) ha anunciado que antes de final de año será eliminado todo el contenido acumulado en Yahoo! Groups desde la era de Onelist. Esto incluye todos los mensajes, links, adjuntos y las útiles secciones de archivos que cada grupo albergaba.

El calendario parece que es el siguiente: desde el próximo 28 de octubre (¡eso es dentro de diez días!) ya no se podrá subir nuevo contenido. El 14 de diciembre, todo el contenido será eliminado. Para colmo, Yahoo! parece que no provee ningún mecanismo tan fantástico como el que tienen las cuentas de Google para descargar selectivamente todo lo que nos interese, algo que vino muy bien cuando eliminaron la versión de consumo de Google+.

Pero, tranquilidad. Hay solución.

Bueno, o algo parecido. Por desgracia, Yahoo! no ha publicado nunca una API para el producto Yahoo! Groups, lo que significa que no hay demasiadas herramientas que puedan automatizadamente explotar los datos almacenados en los distintos grupos. Las (escasas) utilidades disponibles se conectan consumiendo la propia UI web lo que, además de mucho más difícil de implementar, es menos eficiente y menos tolerante a cambios en el producto.

A pesar de todo, hemos seleccionado algunas opciones que pueden dar una solución (parcial) al inminente problema (e incomprensible tragedia).

Opción 1: descargar tus datos desde la cuenta Verizon/Yahoo!

Cuando antes dijimos que no se puede hacer una descarga masiva al estilo de las cuentas de Google, no dijimos toda la verdad. Si bien en esencia es cierto que no podemos rescatar toda la valiosa información de los grupos, podemos al menos rescatar el material propio, es decir, aquellos mensajes redactados por nosotros o aquellos archivos que hubiésemos subido.

Para ello basta con ir al panel de control de la cuenta Yahoo! en https://yahoo.mydashboard.oath.com (nos pedirá iniciar sesión) y buscar, abajo del todo, la opción "Solicitar una descarga":

para a continuación marcar el producto que necesitamos:

Tras confirmar la dirección de email en el siguiente paso, se nos enviará un link (puede tardar horas o días según el tamaño) desde el que podremos descargar un archivo comprimido con el material.

Sin embargo, esta funcionalidad se nos antoja insuficiente, especialmente si somos administradores de algún grupo y no queremos que se pierda nada (algunos grupos son realmente valiosas fuentes de información que hoy en día no se encuentra en ningún otro rincón de Internet), ya que el contenido que descargamos directamente de Yahoo! es exclusivamente el que hayamos generado nosotros mismos (que es en muchos casos el menos interesante).

Por este motivo, proponemos una

Opción 2: usar el script "yahoo-groups-backup "

Esta opción permite descargar localmente mucho más material: todos los mensajes (tanto propios como ajenos) así como todos los archivos subidos al grupo. Sigue sin ser una solución perfecta, ya que no parece descargar el apartado de links ni el de fotos, pero al menos permite rescatar el grueso de la información relevante.

Sin embargo, no va a ser un camino de rosas: esta aplicación es de esos programas que encanta desarrollar a los informáticos nerd fanáticos del Python y de Linux con una absoluta carencia de empatía con el usuario final.

El script, que podía haberse desarrollado de una manera mucho más sencilla tecnológicamente plantea de entrada unos requisitos previos de software bastante pomposos, así como una usabilidad anti-usuario (valga la contradicción) que obliga a realizar todas las operaciones en modo consola y no permite fácilmente administrar el material descargado.

Paso 1: instalamos Python

Si tu ordenador es un Mac, casi que puedes saltarte este paso porque lo más probable es que Python venga ya instalado en tu versión de macOS. En caso de ser cualquier otro sistema "tipo-Unix" dependerá de qué distribución se trate pero, es muy probable que también venga preinstalado o que baste con invocar a tu gestor de paquetes favorito (por ejemplo apt-get install python3.7 para distribuciones basadas en Debian, o lo propio con Yum para distribuciones basadas en RedHat).

En caso de Windows, basta con descargarse la versión instalable del siguiente enlace:

https://www.python.org/downloads/

y seguir los pasos de la instalación por defecto. Debemos asegurarnos que la variable de entorno PATH queda correctamente actualizada con la ruta de los binarios.

Paso 2: instalamos MongoDB

Cuando antes dije que esta aplicación era absolutamente user-unfriendly me refería a cosas como esta. Para hacer un cliente web que descargue unos datos, tener que requerir Python y hasta una instancia local de MongoDB me parece desproporcionado y que rompe por completo con la norma de usar siempre la mínima complejidad necesaria al diseñar una solución software. Pero el problema es que la forma de hacer las cosas actual (y de esto la consultoría tiene mucho de culpa, de eso hablaremos otro día) es así de horrible.

Al grano: sí, lo habéis leído bien. Hay que instalar localmente MongoDB (¿para cuándo un icono facepalm en Blogger, señores de Google?). Podéis descargarla de aquí y seguir los pasos de instalación (recomiendo no complicarse la vida y hacer una "full install"):

https://www.mongodb.com/download-center/community

Paso 3: descargamos el driver usado por el script

Este driver (usado mediante Selenium tal y como en los tests automatizados típicos de un desarrollo con filosofía devops hace las veces de cliente web "headless" del cual extraer, a través de manipulación del DOM, la información que queremos (recordemos que no hay una API al uso de Yahoo! Groups). En este caso la instalación consiste en copiar el ejecutable a cualquier ruta que esté en la variable de entorno PATH. En el caso de Windows, una manera sencilla es copiarlo a la propia carpeta de instalación de Python ya que probablemente no le vais a dar ningún otro uso.

Lo podéis descargar de aquí:

https://chromedriver.chromium.org

Paso 4: instalamos el script "yahoo-groups-backup"

El script original se ha quedado desfasado y tenía varios bugs que lo hacen inservible para nuestros propósitos. Por eso vamos a utilizar un fork creado a partir del original que soluciona algunos problemas. Lo podemos encontrar en https://github.com/hrenfroe/yahoo-groups-backup y podemos descargarlo con cliente Git o bien descargar el archivo zip y descomprimirlo a algún lugar del disco duro. Importante: el subdirectorio donde descomprimamos el script, para evitar potenciales problemas, debería tener permisos de escritura para todos los usuarios.

Una vez descomprimido, y asumiendo que ya está instalado Python, hay que entrar desde el intérprete de comandos de vuestra elección al subdirectorio del script y ejecutar lo siguiente para su instalación:

pip install -r requirements.txt

Esto provocará que se instalen las dependencias necesarias en Python para que el programa funcione.

También necesitamos editar el archivo settings.yaml.template para configurar las credenciales de acceso de nuestra cuenta de Yahoo! con la que accederemos a los grupos:

password: mipassword

Paso 5: descargamos un grupo

Ya con todo configurado, solo queda empezar a descargar material (recordemos, solo mensajes y archivos, pues el script no soporta otros elementos como la lista de links del grupo).

Para ello tenemos que ejecutar desde dentro del mismo subdirectorio donde esté el script, el siguiente comando:

./yahoo-groups-backup.py scrape_messages --driver chrome nombre_grupo

si estamos en sistemas tipo Unix, o bien lo siguiente en caso de Windows:

yahoo-groups-backup.py scrape_messages --driver chrome nombre_grupo

Breve explicación: el primer comando es obviamente el script. El parámetro scrape_messages es para indicar que queremos descargar todos los mensajes. Se puede sustituir por scrape_files si lo que queremos es descargar los archivos alojados en el grupo. Obviamente el parámetro nombre_grupo es el nombre o identificador que el grupo tiene dentro del producto de Yahoo! Groups.

Consideraciones finales

Parece ser que el script tiene algunos problemas (algunos derivados del driver Chromium para Selenium). Iremos actualizando la entrada con aquellos issues y las soluciones que vayan apareciendo. También podéis compartirlas en los comentarios.

¿Tú también odias las pestañas del nuevo Google Chrome? Lee esto

2018-09-27T10:30:00.001+02:00

Hace ahora 10 años, Google lanzó el que pronto se convertiría en el navegador más usado del mundo, logrando lo que parecía imposible que es desbancar al todo poderoso (y nada estándar) Internet Explorer de Microsoft; un navegador que nació defectuoso y cuyo único mérito fue formar parte del sistema operativo Windows a partir de su versión 95.

Hasta la llegada de Chrome, vimos desfilar variados navegadores que arraigaron más (Netscape, Firefox) o menos (Opera) y que mejoraban las deficiencias de Internet Explorer de uno u otro modo. Chrome sin embargo llegó para mejorar de un plumazo las deficiencias de todos los anteriormente citados y además ofrecer un vertiginoso motor Javascript escrito íntegramente en lenguaje ensamblador y que se convertiría en la piedra angular del nuevo paradigma web.

Una de las cosas que me gustó más en su momento y que lo diferenciaba de otros navegadores era su estética y el diseño de sus pestañas con forma trapezoidal. Por entonces la alternativa era el malogrado Firefox pero cuyo aspecto visual dañaba la retina.

Actualización ¿innecesaria?

Pero si has llegado hasta aquí es porque precisamente te molesta el aspecto que tiene el nuevo Google Chrome tras la última actualización, en la que incomprensiblemente se vuelve al aspecto precámbrico que caracteriza a Firefox:

Por suerte para ti y para mí los desarrolladores de Google han dejado una puerta trasera para configurar el aspecto de los tabs.

Para ello solo hay que abrir dentro de Chrome el siguiente enlace interno:

chrome://flags

que nos dará acceso a la pantalla de configuración interna del navegador donde podemos "trucarlo" con cientos de opciones ocultas. En la barra de búsqueda de arriba buscad el texto "UI Layout" y aparecerá la siguiente configuración:

La opción default es la que viene ahora seleccionada por defecto y que muestra esas pestañas tan espantosas. Si deseamos volver a nuestras queridas pestañas de Chrome, basta con seleccionar Normal y reabrir el navegador, y.... et voilà!

Los otros valores del desplegable permiten acceder a variantes de los estilos enfocadas en dispositivos táctiles, convertibles, etc. ¡Pruébalas!

Algoritmo para búsquedas con comodines (wildcards)

2016-02-24T15:26:00.001+01:00

Recientemente andaba yo enredado en un proyecto personal de poca trascendencia pero que me obligó a hacer una implementación completa de un sistema de archivos FAT a bajo nivel.

La FAT es un sistema de archivos muy simple para los estándares de hoy y la implementación fue muy fácil y rápida.

Sin embargo, en el proyecto además se necesitaba agregar algunas funciones típicas de sistemas operativos de sabor Microsoft, entre ellas la habitual búsqueda por comodines o wildcard. Pues esto, que parece una tontería, me tuvo filosofando para su implementación más tiempo que casi el resto de la implementación.

Se me ocurrieron diferentes acercamientos al problema de interpretar una cadena cualquiera que usase el comodín asterisco (*) para sustituir una subcadena cualquiera y el interrogante (?) para sustituir cualquier carácter coincidente en esa posición. Pensé en aplicar mis oxidados conocimientos de autómatas y lenguajes, o también una simple rutina al estilo amateur a base de recorrer las cadenas con un bucle e ir contando caracteres e intentando cuadrarlo todo usando código spaghetti.

Pero finalmente opté por la implementación más sencilla y elegante, si bien no la más eficiente: convertir los viejos comodines de tipo DOS a expresiones regulares de las que hoy en día se usan para todo. Cualquier lenguaje de programación moderno permite el uso de regex cuyo parseo es transparente para el programador.

Para ello basta con buscar las equivalencias necesarias entre comodines DOS y expresiones regulares o regex:

Función	Wildcard	Regex
Sustituye un carácter en la posición indicada	?	[^\.]
Sustituye una secuencia cualquiera de caracteres	*	.*
Separador de extensión	.	\.
Punto sin extensión final	*.	[^\.]+\.?

Además, si se trata de una regex en un entorno POSIX, es probable que para que la coincidencia de la cadena buscada sea haga desde las posiciones indicadas de cada comodín comenzando por el primer carácter de la cadena (y no en cualquier lugar de la misma), haya que agregar el metacarácter ^ al comienzo de la expresión.

De esta forma, la conversión entre wildcards y regex puede verse ilustrada en los siguientes ejemplos:

Descripción	Wildcards	Regex
Cualquier archivo con cualquier extensión	.	^.\..
Todos los archivos que comiencen por A	A.	^A.\..
Todos los archivos con extensión jpg que comiencen por pic y dos caracteres más	pic??.jpg	^pic..\.jpg
Archivos que comiencen por "abc" y NO tengan extensión	abc*.	abc*[^\.]+\.?

El código

Para transformar los comodines en expresiones regulares hemos visto que basta cualquier tipo de sustitución simple, incluso la que hace un editor de texto con sus macros correspondientes. El lenguaje Perl tiene, como parte de su propia sintaxis, el manejo de expresiones regulares. También existen en Java, Javascript, c#, PHP y casi cualquiera que se precie.

No obstante, en mi ejemplo yo usaré lenguaje C ansi por ser un estándar y porque además era el lenguaje usado en mi proyecto.

#include <string.h>
#include <regex.h>

/*
 *Esta función recorre el patrón basado en comodines y los sustituye por sus equivalencias regex
 */
char * wildcard_to_regex(char * pattern) {

    if (pattern) {
        int len = strlen(pattern);

        char * regstr = malloc(200);

        int r = 0;
        regstr[r++] = '^';

        for (int i = 0; i < len; i++) {

            switch ( * (pattern + i)) {
            case '*': //*  [^\.]+\.?
                if ( * (pattern + i + 1) == '.' && (i == (len - 1))) {
                    regstr[r++] = '[';
                    regstr[r++] = '^';
                    regstr[r++] = '\\';
                    regstr[r++] = '.';
                    regstr[r++] = ']';
                    regstr[r++] = '+';
                    regstr[r++] = '\\';
                    regstr[r++] = '.';
                    regstr[r++] = '?';
                } else {
                    regstr[r++] = '.';
                    regstr[r++] = '*';
                }
                break;
            case '?': //[^\.]
                regstr[r++] = '[';
                regstr[r++] = '^';
                regstr[r++] = '\\';
                regstr[r++] = '.';
                regstr[r++] = ']';
                break;
            case '.': //\.
                regstr[r++] = '\\';
                regstr[r++] = '.';
                break;
            default:
                regstr[r++] = * (pattern + i);
            }
        }
        regstr[r++] = '$';
        regstr[r] = '\0';

        return regstr;

    } else {

        return NULL;
    }

}
/*
 *En esta función se comprueba si el nombre de archivo o cadena coincide con la expresión regex dada
 */
bool pattern_matches(char * filename, char * mask) {

    regex_t regex;
    regcomp( & regex, wildcard_to_regex(mask), REG_ICASE);

    if (!regexec( & regex, filename, 0, NULL, 0)) {
        return true;
    } else {
        return false;
    }
}

Ambas funciones se utilizarían para construir la expresión regular a partir de un patrón de búsqueda por comodines y para comprobar si una cadena dada (por ejemplo, un nombre de archivo) concuerda con dicha expresión regular:

void main (int argc, char *argv[])
{
    if (pattern_matches(argv[1], wilcard_to_regex("test*.*") )
    {
        // el archivo especificado en la línea de comandos
        // concuerda con la máscara "test*.*"

    } else {

        // el archivo no concuerda

    }

}

Ejecución de aplicaciones antiguas en Windows 7 y 10

2015-11-14T12:11:00.004+01:00

En un acto de torpeza premeditada de Microsoft (otro más), las nuevas versiones de Windows, desde la 7 en adelante, no soportan correctamente ciertas aplicaciones antiguas. Algo que ya sabíamos.

Sin embargo, muchas de ellas no han dejado de funcionar debido a las notorias diferencias de arquitectura entre Windows 98/NT/2000/XP, sino simplemente a que ellos lo han decidido así, eliminando bibliotecas esenciales como la MSVBVM50.DLL, la MSVBVM6.DLL, etc. que no son más que los run-times necesarios para aplicaciones escritas en Visual Basic anterior a la era .NET.

Aunque parezca increíble, existen comercialmente muchas aplicaciones escritas en dicho lenguaje y aún más en compañías que hacen desarrollo de software para uso interno.

Para colmo, la descarga en Internet de dichos archivos se ha vuelto cada vez más difícil y arriesgada; Microsoft ha eliminado dicho contenido online (si probáis el enlace de la MSVBVM50 os llevará a una página en blanco) y el resto de opciones son descargas de webs que intentan instalarte algún sypware o algún otro software comercial haciéndote creer que estás descargando lo que buscabas.

Sin embargo...

Hay opciones. Casi siempre las hay.

Os presento una de mis WEBs de cabecera que probablemente uso a diario: THE WAYBACK MACHINE, actualmente integrada en el ambicioso proyecto www.archive.org, que pretende archivar toda la información que existe en el mundo, es un web site que hace snapshots de prácticamente cualquier web que haya existido en el mundo de manera pública.

Esto significa que un enlace que actualmente no existe, o cuya información contenida ya no es la que buscábamos, gracias a esta maravilla puede ser accedida en fechas anteriores que pueden remontarse a más de una década. De esa manera, podemos retroceder en la máquina del tiempo y así rescatar nuestras famosas bibliotecas DLL de las que Microsoft ha decidido (absurda e injustamente) privarnos.

Como ejemplo, intentemos rescatar el instalador de las bibliotecas MSVBVM5. Según la página mostrada arriba, el enlace a dicho instalador debería ser https://support.microsoft.com/kb/180071 que si lo seguimos veremos que ya no está disponible.

Pulsamos en Browse History y nos llevará al calendario de "fotos":

Pues bien, ahora ya podemos pinchar en la fecha exacta a la que queremos retroceder. Sin embargo, hay que tener en cuenta una consideración: dado que la página con el contenido existe, esta aparecerá hasta la fecha de hoy. Sin embargo, el contenido de la misma no es el esperado pues sólo sale el cartel de no disponible.

Eso significa que en gran parte del histórico grabado en la Wayback Machine también faltará el archivo que buscamos. Para evitar este problema, lo mejor es ir siempre a la versión más antigua que haya guardada. En este caso yo he usado el snapshot de 2004 y 4 de diciembre:

Y... et voilà! (También vale la versión de ¡bingo!):

Además, tal y como vemos en la barra superior, podemos navegar entre distintas versiones de la página.

Os recomiendo también el uso de esta genial herramienta cuando alguna compañía os ha cambiado las condiciones de uso online y os quieren intentar perjudicar alegando un contrato que vosotros no habéis aceptado. A mí me pasó una vez con una conocida compañía de teléfonos que me cobró por un compromiso de permanencia que no me correspondía y alegaron unas condiciones que yo supuestamente había aceptado online. Pero esas condiciones no se parecían a las que yo leí. Así que usé esta máquina del tiempo para demostrar que ellos habían cambiado el contenido del contrato que yo acepté.

Estoy seguro de que vosotros encontraréis muchos más usos útiles de esta herramienta.

Por cierto, agrego al blog el enlace de la biblioteca de Microsoft que seguramente andabas buscando si llegaste a esta página.

Página de DESCARGAS del blog

X-Files y Poltergeists. Cuando Windows está maldito

2015-11-11T10:51:00.000+01:00

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.

Los síntomas

Todo comenzó cuando el cliente se quejó de que parte de la aplicación web que corre en ese servidor se quedaba congelada. Pero ocurría sólo con determinadas funcionalidades, no con todo el website. La primera reacción del desarrollador de la aplicación fue descargar de la nube un backup para reinstalar todos los fuentes de la aplicación y ver si eso lo solucionaba.

Y así llegó el segundo susto: no conseguía descargar nada en Google Chrome. El Internet Explorer, directamente no se abría, arrojando un fabuloso error 0xc0000005 (que no es otra cosa que un Acceso denegado de toda la vida); el propio Windows bloqueaba la descarga por "razones de seguridad". Obviamente la reacción lógica fue ir al panel de control y buscar el icono de Internet Settings para comprobar si el nivel de seguridad estaba demasiado alto. Pero... ¡oh, sorpresa! No se abría tampoco dicha aplicación.

En este punto es cuando me llaman y me dicen que el servidor "is dying quickly" y probablemente se deba a una infección de un virus (el argumento del virus es muy socorrido cuando no se tiene ni idea de qué está sucediendo; pero no, casi nunca es un virus).

Con la ceja levantada me puse (previa migración de toda la aplicación a otro servidor en producción) a analizar el asunto. Fue cuando además, descubrí el susto definitivo: no funcionaba la consola de sistema (la aplicación MMC) por lo que no conseguía abrir ni el Visor de Sucesos, ni la lista de Servicios, ni las políticas de Firewall, ni... ¡ni nada! Al abrir la MMC me daba el error Not enough storage is available to complete this operation. Hummm....

Ni siquiera funcionaba el SFC /SCANNOW para restaurar archivos corrompidos; se detenía en el 74% dando también un error.

¿Qué estaba pasando?

La investigación y la solución (desesperada) al problema

Pues teníamos muy poca cosa. Un error, aparentemente, de permisos en Internet Explorer, y un desolador mensaje de Not enough storage is available to complete this operation al intentar abrir la consola MMC.

Dicho mensaje me mandó, obviamente, a comprobar el espacio en disco y memoria RAM, pese a que habían sido recientemente ampliados en la máquina virtual. Tal y como era de esperar, había espacio de sobra.

Todo lo que pude encontrar en Google hacía alusión a falta de espacio en disco, problemas al escribir archivos en %TEMP%, falta de RAM, etc. Sin embargo, ninguno de esos escenarios era parecido a este. Investigando sobre el error y mirando en el SDK de Windows, vemos que dicho error internamente corresponde al errorcode 14, ERROR_OUTOFMEMORY, cuya descripción hace alusión a falta de recursos indirectos, (por ejemplo, falta de handles disponibles para el OS), es decir, que aunque lo parezca, no se refiere a falta de espacio físico de ningún tipo.

El número de handles de cada proceso se puede ver en el Administrador de Tareas, agregando la columna correspondiente. Pero tampoco era ese el caso y todas los procesos se mostraban con normalidad.

¿Qué en-el-infierno estaba pasando?

Fue entonces cuando recordé aquel viejo problema de las DLL mal registradas que, si bien los síntomas globales eran distintos, tenían en común que no podía abrirse la consola MMC (aunque el error mostrado tampoco coincidiera).

Ya hablamos en su momento de ese problema, y de cómo solucionarlo registrando las bibliotecas MSXML3.DLL y MSXML6.DLL.

¿Estaríamos ante ese viejo conocido? Rápidamente hice el consabido regsvr32 MSXML3.DLL y el regsvr32 MSXML6.DLL y....

¡Nada de nada!

Pero el problema tenía que ser muy similar. ¿Y si la DLL mal registrada era simplemente otra? ¿Tendría que probar a registrarlas una a una? Fue cuando se me ocurrió usar algo totalmente old-school: decirle a la consola de texto que hiciese un regsvr32 a TODAS las DLL encontradas en los subdirectorios c:\windows\system32 y c:\windows\syswow64.

Para ello sólo hay que abrir el intérprete de comandos (el famoso CMD.exe al que los usuarios de Windows están tristemente acostumbrados) y escribir la siguiente cosa:

FOR /F %f IN ('dir %windir%\system32\*dll /B') DO regsvr32 %f /s

Así que probé y... ¡SÍ! Esta vez funcionó a la perfección.

El problema de esta solución es que no hemos podido averiguar cuál era la DLL díscola que provocó todo.

Sin embargo, la potencia de este método es que puede ser utilizado para muchos problemas típicos de Windows cuya solución no esté previamente documentada en otros lugares. Por tanto, cuando creáis que en vuestro Windows Server hay un polstergeist, o se trata de un X-File... probad este sistema.

Puede que sea la solución.

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

2014-07-17T13:49:00.001+02:00

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

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)

2013-03-14T18:48:00.000+01:00

<< 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:

chown root:squid /usr/local/etc/smb.conf
chmod 750 /usr/local/etc/smb.conf

Editamos el archivo /usr/local/etc/smb.conf y cambiamos o añadimos las siguientes líneas (cambiad los nombres de servidores, dominio, etc. por el vuestro propio):

workgroup = DEBUGMACHINE
security = domain
load printers = no
password server = DC-01
passdb backend = tdbsam
interfaces = 192.168.3.254/24
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind use default domain = yes

Antes del siguiente paso, tenemos que asegurarnos de que el Appliance es capaz de resolver el nombre de host del controlador de dominio, bien mediante configuración del cliente DNS, o bien mediante el archivo /etc/hosts. Igualmente tenemos que dar al FreeBSD el nombre de host definitivo que queremos que tenga, por ejemplo, private-gw. Para ello editamos el archivo /etc/rc.conf y agregamos la línea hostname="private-gw.debugmachine.com" (no olvidéis como siempre especificar vuestro propio nombre de dominio).

También es necesario que el reloj esté sincronizado con el del controlador de dominio. Para ello tenemos que asegurarnos de que el demonio ntpd está instalado en el FreeBSD, y añadir al /etc/rc.conf las siguientes líneas:

ntpdate_enable="yes"
ntpdate_flags="dc-01.debugmachine.com"

Se recomienda reiniciar el equipo tras los pasos anteriores para asegurarse que todo está bien actualizado y no quedó ningún servicio por levantar.

Y ahora sí, unimos el equipo al dominio con nuestro administrador del dominio y su password:

net join -U administrador%password

Iniciamos el servicio winbindd. Es necesario para poder crear tuberías o pipes entre los servicios de autenticación y las diferentes aplicaciones (en este caso Squid).

/usr/local/sbin/winbindd

Si queremos garantizar el arranque de los servicios en cada reinicio de la máquina, tenemos que activarlos en el /etc/rc.conf al igual que hemos venido haciendo con otros:

winbindd_enable=yes

Cambiamos los permisos del siguiente archivo para asegurarnos que el usuario squid nuevamente puede acceder a él:

chown root:squid /var/db/samba34/winbindd_privileged
chmod 750 /var/db/samba34/winbindd_privileged

Para ver si hasta aquí todo funciona correctamente, podemos probar a autenticar un usuario cualquiera de nuestro dominio. Si todo sale bien deberíamos tener una respuesta similar a esta:

root@private-gw:/# wbinfo -a debugmachine\\administrador%password
plaintext password authentication succeeded
challenge/response password authentication succeeded

Ahora nuestro appliance ya es capaz, mediante Samba/Winbind, de hacer comprobaciones de usuario y password para usuarios de nuestro dominio.

¿Qué es lo siguiente?

Ahora toca configurar nuestro Squid para que se haga cargo de todo esto. Para ello vamos a añadir las siguientes líneas al archivo /usr/local/etc/squid/squid.conf para introducir autenticadores de tipo "basic" y "ntlm". Pondremos 15 procesos "hijo" por defecto de cada tipo de autenticador, suficientes para una compañía de tamaño medio y sin llegar a saturar los recursos de la máquina:

auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 15

auth_param basic program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 15

auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

Squid permite crear ACLs o listas de acceso que sirven para controlar detalladamente los requisitos de uso del proxy. Dichas acls se escriben en el archivo squid.conf y se tienen en cuenta por el orden en que están escritas, teniendo siempre preferencia las más estrictas.

Por defecto, Squid prohíbe el acceso a todos los usuarios salvo los que cumplan algún requisito (por ejemplo, pertenecer a una subred determinada). Para ello utiliza una línea como la siguiente:

http_access deny all

Como podéis imaginar, todos los cambios y configuraciones que propondré a continuación deben estar antes de la línea mencionada o si no serán ignorados al tener prioridad la más restrictiva.

Diseñando una política de acceso

Antes de continuar con la configuración del squid.conf, es necesario tener las ideas claras de cómo será la política a implementar. Yo voy a usar una bastante simple para ilustrarlo a modo de ejemplo, pero por supuesto podría complicarse tanto como requieran nuestras necesidades (la flexibilidad de Squid es infinita).

En nuestra política se tienen que cumplir los siguientes requisitos:

Para poder usar el proxy, es obligatorio estar autenticado (por NTLM o facilitando unas credenciales al iniciar la sesión).
Habrá una serie de páginas web que no necesitarán autenticación previa (por ejemplo, actualizaciones de antivirus, Windows Update, etc.)
Habrá una serie de páginas cuya visita estará totalmente prohibida (para cualquier usuario).
Existirá un grupo en Active Directory llamado "InternetRestringido" cuyos miembros tendrán prohibido el acceso a determinadas webs (por ejemplo, http://www.twitter.com).

Para empezar vamos a crear varios archivos de texto donde se definan las URLs prohibidas, permitidas, etc. Deben definirse mediante expresiones regulares, una en cada línea.

/usr/local/etc/squid/deny.acl - Aquí escribiremos las expresiones regulares que coincidan con aquellas URLs que deseamos que sean restringidas a un determinado grupo de usuarios.
/usr/local/etc/squid/denyall.acl - Aquí irán las expresiones que definan a las URLs que queremos prohibir de manera global, para todo el mundo.
/usr/local/etc/squid/noauth.acl - En este archivo definiremos aquellas URLs para las cuáles Squid no debe exigir autenticación, ideal para procesos automáticos, actualizaciones de software, etc.

Un ejemplo de expresiones regulares que sirvan para identificar el dominio facebook.com (y de paso facebook.es, facebook.it, facebook.*....) así como twitter.com podría ser:

facebook\.
twitter\.com

A continuación os copio y pego el trozo de /usr/local/etc/squid/squid.conf que tendremos que añadir con los pertinentes comentarios que explicando cada directiva de la política. Recordad que debe ir siempre antes del http_access deny all.

#    En primer lugar definimos la "acl" de aquellas URLs que no
#    necesitan autenticarse previamente, y seguidamente la directiva
#    que permita el acceso a dicha acl
acl NoAuthNeeded url_regex "/usr/local/etc/squid/noauth.acl"
http_access allow NoAuthNeeded

#    definimos un tipo de ACL llamada "domainGroup" que nos permita
#    comprobar la pertenencia a grupos de Active Directory
external_acl_type domainGroup %LOGIN /usr/local/libexec/squid/wbinfo_group.pl

#    definimos la acl que comprueba si los
#    usuarios pertenecen al grupo InternetRestringido
acl PartiallyAllowedUsers external domainGroup InternetRestringido

#    definimos la lista de direcciones
#    restringidas para dicho grupo
acl BlockList url_regex "/usr/local/etc/squid/deny.acl"

#    definimos la lista de direcciones
#    restringidas para todo el mundo
acl BlockListAll url_regex "/usr/local/etc/squid/denyall.acl"

#    aplicamos la denegacion a las acls anteriores
http_access deny PartiallyAllowedUsers BlockList
http_access deny BlockListAll

#    si ninguna de las restricciones anteriores ha sido aplicada,
#    entonces comprobamos la exigencia de estar autenticado
acl AuthorizedUsers proxy_auth REQUIRED
http_access allow AuthorizedUsers

IMPORTANTE: cada vez que hagamos cambios al /usr/local/etc/squid/squid.conf es necesario reiniciar el servicio Squid. Para ello sólo tenemos que ejecutar este comando:

/usr/local/etc/rc.d/squid restart

Probando el invento

Llegados a este punto, tenemos que comprobar si todo ha salido bien. Para ello tenemos que configurar nuestro navegador favorito (o en su defecto la configuración global de acceso a Internet del sistema). Como navegador proxy pondremos la IP del lado privado de nuestro Appliance, es decir, la 192.168.3.254 y como puerto el 3128. De momento no necesitamos especificar ningún dato más.

AVISO: Si utilizamos el proxy sin especificarlo en el navegador, sólo usado como gateway (es decir, en modo proxy transparente), no podremos disfrutar de las ventajas de la autenticación NTLM de Windows. La razón es muy sencilla. El proxy transparente actúa haciendo intercepción de paquetes, es decir, en capa 3, mientras que la autenticación es un concepto relacionado con la capa 5 o superior. Si queremos forzar la configuración de proxy del navegador se pueden emplear diferentes estrategias que escapan a esta serie de artículos. No obstante, podremos seguir disfrutando del resto de funcionalidades del proxy (logueo, caché, tipos diversos de directivas, etc.) y hacer políticas de acceso basadas en la IP de cada usuario.

Para comprobar si todo va bien, podemos probar a navegar por distintos sitios, tanto de los permitidos como de los prohibidos, iniciando sesión en Windows con distintos usuarios y ver si todo se comporta como debe.

Además, es fundamental tener controlados los dos archivos de log del Squid, el de registro de accesos (e intentos) y el de información del servicio (necesario para diagnosticar problemas). Respectivamente son:

/var/squid/logs/access.log

/var/squid/logs/cache.log

¿Qué nos queda? Pues aunque el núcleo de nuestro sistema ya está montado, podemos añadirle muchas cosas interesantes: un proxy SOCKS (para aplicaciones que no sean web), herramientas de monitorización y estadísticas, un control básico de consumo de ancho de banda.... como ya veremos podemos estar agregando funciones casi eternamente, por el módico precio de un rato de lectura en The Debug Machine.

Continuará...

<< Artículo anterior

"Se busca Cliente Cisco VPN"

2013-03-10T11:29:00.001+01:00

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.

En realidad se trata de un conjunto de programas que funcionan como las capas de una cebolla. El cliente de Cisco es en realidad un programa de línea de comandos similar al de la versión Linux (vpnclient.exe), que se apoya por un lado en un servicio encargado de levantar la interfaz virtual de red (servicio CVPND) y por otro lado en distintos ejecutables auxiliares para el manejo de certificados, llamada del IPSEC-Tunnel, creación del punto a punto, etc. Y por supuesto, sobre todos estos hay una interfaz gráfica que es la que nosotros vemos normalmente, el programa vpngui.exe.

Opciones de línea de comandos del cliente Cisco VPN. Muy útil para crear automatismos, conexiones transparentes, etc.

El error descrito al comienzo de este artículo suele darse porque el servicio CVPND no está levantado por alguna razón, o porque la interfaz virtual (suele aparecer como Conexión de área local #2 o similar) puede estar deshabilitada.

La solución

Mi recomendación es seguir estos pasos hasta diagnosticar el problema con más exactitud:

Probar a habilitar la conexión, bien con el comando netsh o bien haciendo click-derecho en el icono y en la opción "habilitar".
Probar a arrancar, si estuviese parado, o a levantar el servicio de la interfaz Cisco. La manera más cómoda para mí es ejecutando, como administrador, el siguiente comando: net start CVPND si es en la máquina local, o sc \\equiporemoto start CVPND si se trata de un equipo remoto.
Probar a realizar la conexión mediante línea de comandos. Para ello sólo tenéis que consultar la ayuda del ejecutable vpnclient.exe (que se muestra en la ilustración anterior) y probar a realizar la conexión desde consola. Si este punto funciona, el problema quedaría aislado en la interfaz gráfica y seguramente sería cuestión de reinstalar la aplicación completa.

Si por lo que sea necesitáis reinstalar el cliente, me consta que a veces no sabe uno dónde puso los ficheros de instalación. Por eso os lo dejo en la página de descargas.

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

2013-02-24T19:37:00.000+01:00

<< 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.

La instalación es muy fácil vía sysinstall. Ejecutamos dicha herramienta y seleccionamos los siguientes menús hasta llegar al paquete del Squid:

Configure → Packages → FTP o CD → Net → squid-2.7.9

Para la puesta en marcha, primero haremos unas pequeñas modificaciones de configuración.

Editamos el archivo /usr/local/etc/squid/squid.conf y modificamos la siguiente línea así:

http_port 3128 transparent

Editamos el archivo /etc/rc.conf y agregamos la siguiente línea:

squid_enable=”YES”

Ahora es necesario inicializar el Squid, para crear los subdirectorios de caché, logs, etc. Para ello, con privilegios de root, ejecutamos el siguiente comando:

/usr/local/sbin/squid -z

Y con esto ya podemos arrancar el servicio Squid:

/usr/local/etc/rc.d/squid start

Para probarlo, podemos configurar nuestro navegador de Internet favorito para que conecte a través del proxy (la IP 192.168.3.254, según nuestro ejemplo, y el puerto por defecto, el 3128).

Proxy transparente

Hasta ahora hemos conseguido que nuestro appliance virtual funcione como un eficiente router y como un simple proxy que por defecto nos ahorrará algo de tráfico (por su función de caché) y nos permitirá registrar las visitas de aquellos equipos que lo tengan configurado.

Sin embargo, y aunque hay diversos métodos para forzar a un cliente de la red a que use nuestro proxy, siempre puede quedarnos la posibilidad de que algún usuario avanzado tenga conocimiento y acceso a la configuración de proxy lo que le permitiría borrar esa configuración y salir a Internet directamente por la puerta de enlace, impidiendo así que sus visitas queden registradas.

¿Hay solución a este problema? Por supuesto: se llama "proxy transparente". Es un truco muy habitual en los ISP para ahorrar tráfico de datos y muchas veces nuestras conexiones a la WEB pasan por este tipo de proxies sin darnos cuenta. Consiste en implementar funciones de proxy a la misma puerta de enlace, de tal modo que simplemente por enrutar tráfico hacia dicha puerta de enlace, los paquetes son capturados y redirigidos a un proxy de manera invisible para el usuario. Nuestro Squid, como no podía ser menos, permite el funcionamiento en modo "transparente" (por ello pusimos ese parámetro en el squid.conf).

Para que la puerta de enlace redirija los paquetes de la WEB (por defecto, el puerto 80) hacia el proxy (que hemos puesto en el puerto TCP 3128), utilizaremos el firewall del sistema siguiendo estos pasos:

Creamos el archivo /etc/ipnat.rules con el siguiente contenido:

rdr em0 0/0 port 80 -> 127.0.0.1 port 3128 tcp

Editamos el archivo /etc/rc.conf y le agregamos las siguientes líneas:

ipnat_enable=”YES”
ipnat_rules=”/etc/ipnat.rules”

Con esta configuración, nuestro flamante appliance funciona como proxy transparente y por tanto cualquier equipo que navegue por la WEB usándolo como puerta de enlace ya pasará por el Squid de manera forzada, incluso aunque el navegador esté configurado para navegar en modo directo.

Podemos en cualquier momento comprobar que las visitas a la WEB se van quedando registradas consultando el log de acceso, el cuál se encuentra en la siguiente ubicación:

/var/squid/logs/access.log

En el siguiente capítulo vamos a integrar Squid con Samba para así poder usar autenticación integrada en las estaciones de trabajo de Windows y poder configurar los accesos a Internet (así como restricciones a diferentes páginas web, etc.) en función de la pertenencia a grupos de Active Directory. Y sí, sigue siendo gratis.

Continuará...

<< Artículo anterior

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

2013-02-22T10:07:00.001+01:00

<< 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:

Como vemos, hemos separado físicamente las dos "patas" de nuestro appliance para garantizar que, en caso de fallo de configuración o brecha de seguridad, nuestras estaciones de trabajo jamás podrán alcanzar el segmento de red que daría acceso directo e irrestricto a Internet. Para ello hemos segmentado la red en capa 2 mediante el etiquetado de paquetes 802.1Q, las VLAN.

En nuestro ejemplo, la VLAN por defecto del switch es la 1, y ahí dejaremos la mayoría de dispositivos. La VLAN con ID 2 sería la que contiene la zona desmilitarizada (DMZ) y que conectará a la otra "pata" de nuestro appliance.

Configurando la infraestructura

El primer paso es tener las VLANs a punto en nuestra electrónica de red. Si ya tenemos nuestras VLANes separadas a nuestro gusto, pues sólo tendremos que utilizar las que corresponda a la configuración actual. Si aún todo el switch está gestionado en "plano", este es el momento de configurar una VLAN adicional con el identificador "2" (en nuestro ejemplo la VLAN para la zona "aislada" de la red principal). Cómo configurar las VLANes es algo que escapa al alcance de este artículo y además es distinto para cada fabricante, así que corresponde al lector hacer una pequeña incursión en Google llegado a este punto.

Una vez nuestros switches están configurados, tenemos que crear en nuestro VMware las redes virtuales. Para ello añadimos un switch virtual (vSwitch) y le asociamos la interfaz de red que esté conectada a la VLAN 2 del switch físico. Nos pedirá crear una nueva red virtual (VM Network 2) y como ID de VLAN pondremos 2.

Una vez configurada la red virtual debe quedar algo parecido a esto:

No vamos a entrar en detalles de configuración de redes de VMware ya que hay información detallada por todo Internet.

El siguiente paso es crear la máquina virtual. Creamos una nueva máquina por el procedimiento habitual, y le damos para empezar las siguientes características (se pueden ampliar más adelante):

Tipo de máquina: Typical, Other, FreeBSD 32bit (o 64, dependiendo de nuestra versión de FreeBSD)
RAM 128 MB
HD: 6 GB
CPU: 2 cores
NIC: 2 interfaces de tipo E1000

Aunque las especificaciones parezcan demasiado modestas, en realidad suelen ser suficiente para este tipo de aplicaciones. En cualquier momento se puede ampliar la RAM que es lo que más puede necesitarse.

Una vez creada, y antes de comenzar la instalación del sistema operativo, accedemos a las propiedades de la máquina y asignamos a cada interfaz de red una red virtual diferente (correspondiendo con las VLANs 1 y 2 de nuestro ejemplo), si no lo hicimos ya en el momento de la creación.

Ya estamos listos para el siguiente paso.

Instalación de FreeBSD

Para escribir este tutorial yo me he basado en una imagen ISO que tenía por aquí de FreeBSD 8.2 32bit, aunque no debería haber demasiada diferencia con versiones posteriores.

Comenzad la instalación en la máquina virtual (bien tostando el CD o bien enganchando la imagen ISO con el VMware) y pronto os pedirá los parámetros de organización del disco. El BSD es ligeramente distinto a Linux en cuanto a la nomenclatura usada para el particionado. Para no complicaros mucho la vida, mi recomendación es que hagáis un "slice" principal que ocupe todo el disco físico, y dentro de este slice hagáis las siguientes particiones:

swap 256 MB

/ 4350 MB

/var/log 1536 MB

A continuación tenemos que seleccionar qué paquetes queremos instalar. Seleccionamos "custom installation" y marcamos los siguientes grupos de paquetes:

Base
Kernels
Doc (ENG)
Info
Man
Src/Sys

Después escogemos una password para el superusuario 'root'; no hace falta agregar en principio más usuarios.

Ahora ya podemos iniciar sesión. El primer paso y más importante a realizar en la configuración de FreeBSD es configurar las interfaces de red. Recordaremos que de las dos interfaces, una irá a la VLAN por defecto y la otra irá a la VLAN 2 reservada para la red de salida a Internet. El orden se debería corresponder con el que se haya utilizado en VMware para definir las interfaces, aunque comprobarlo es tan sencillo como habilitar y deshabilitar las interfaces de la VM y hacer un ifconfig para ver con cuáles se corresponden las interfaces em0 y em1.

Una vez se tenga seguridad, se procede a editar el archivo /etc/rc.conf para modificar (o crear) las siguientes líneas:

ifconfig_em0=”inet 192.168.3.254 netmask 255.255.255.0”
ifconfig_em1=”inet 172.16.5.1 netmask 255.255.255.0”
defaultrouter=”172.16.5.254”

No olvidemos que este appliance será el gateway por defecto de nuestras estaciones de trabajo, por lo que si necesitamos añadir algún tipo de ruta estática (por ejemplo, para enrutar el tráfico de una VPN por otro sitio) este es el lugar y momento para hacerlo. Para ello editamos nuevamente el /etc/rc.conf y agregamos las líneas que necesitemos (para ejecutar el comando route):

#nuestra VPN usa la red 192.168.x.x y
#su puerta de enlace es la 172.16.5.253

route add -net 192.168.0.0/16 172.16.5.253

Para finalizar esta primera fase de configuración, dejaremos la puerta abierta a administrar la máquina por SSH, para lo que editaremos el /etc/ssh/sshd_config y añadiremos o modificaremos la siguiente línea:

PermitRootLogin yes

Para asegurarnos de que todos los servicios necesarios están funcionando correctamente y actualizados, lo mejor ahora es reiniciar la máquina. A partir de este momento, si todo ha salido bien, ya podemos entrar con un cliente SSH cualquiera y ya podemos poner como puerta de enlace de nuestros PCs la dirección privada del appliance, es decir, la 192.168.3.254 para tener una navegación básica por Internet.

En el siguiente artículo continuaremos con la configuración básica del proxy Squid.

Continuará...

<< Artículo anterior

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

2013-02-19T23:47:00.000+01:00

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.

Requisitos previos

Para realizar este proyecto os propongo un escenario ideal, aunque se pueden hacer variaciones adecuándolo a nuestras necesidades y, por supuesto, nuestros recursos. En este escenario necesitaríamos:

Un acceso a Internet por Ethernet. Sería válido tanto un router en modo bridge (la IP pública iría a nuestro appliance) o disponer de un acceso detrás de otro router/firewall (en cuyo caso usaríamos una IP del lado privado para la pata WAN de nuestro Appliance). En nuestro ejemplo usaremos esta segunda opción.
Un servidor o PC con dos interfaces de red Ethernet, capaz de correr VMware ESXi (excepto si optamos por hacer un appliance físico).
Un switch gestionable y compatible con el estándar 802.1Q para segmentar la red mediante VLANs.
Una pizca de paciencia ☺

Una vez entendamos el objetivo del proyecto y la configuración, veremos que los puntos anteriores son fácilmente modificables a nuestro antojo.

Funcionalidades y características

Nuestro appliance tendrá al menos las siguientes características y funciones que cito a continuación:

Enrutador
Firewall básico
Proxy web transparente
Proxy web con autenticación de usuarios
Proxy SOCKS5
Integración con usuarios y grupos de Active Directory
Control por usuarios/destino/contenido
Control de ancho de banda y tráfico web por usuario
Caché de contenidos web
Registro exhaustivo de los accesos realizados a Internet
Visualización de estadísticas

Además, dejamos abierta la puerta a futuras funcionalidades como control de tráfico y ancho de banda por protocolo y contenido (traffic shaping con DPI).

Software utilizado

Como cualquier lector se habrá dado cuenta a estas alturas, este proyecto está claramente orientado a un sistema operativo de "tipo Unix". Podemos elegir entre muchos de sus "sabores" (Linux, Solaris, Mac OS X...) pero por una cuestión de gusto personal, he escogido montarlo todo sobre FreeBSD. La razón es que soy más partidario de la rama de Berkeley quizás por tradición y porque se dice que los BSDs son más robustos y seguros que el kernel Linux. Hoy en día no creo que haya razones objetivas para sostener esa creencia, pero aún así daremos una oportunidad a nuestro gran aliado FreeBSD.

La base del propio FreeBSD nos servirá para configurarlo como router. Las funciones de firewall, por supuesto dependerán de IPFW (el firewall integrado con FreeBSD).

El proxy (transparente y autenticado) será el maravilloso SQUID, que se apoyará en Samba para la autenticación y control de usuarios del dominio Active Directory de la compañía. Squid será también el responsable de filtrar o prohibir contenidos, realizar logs completos de la actividad de los usuarios y el control de ancho de banda y tráfico de las conexiones web.

Por último agregaremos un proxy SOCKS5 complementario usando un simple pero efectivo túnel SSH.

Esta configuración es robusta, muy fiable y está ampliamente probada por equipos IT de todo el mundo. En total podemos hacer una estimación de ahorro de varios miles de euros en software respecto de una alternativa basada en Microsoft Windows Server + Microsoft ISA Server, aparte de necesitar un hardware mucho más modesto.

En el próximo artículo definiremos la arquitectura y filosofía de la implementación, así como los primeros pasos (instalación de FreeBSD, paquetes, etc.).

Continuará...

Arranque diferido de servicios en servidores y estaciones Windows

2013-02-18T15:09:00.000+01:00

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.).

Diferentes acercamientos al problema

En realidad es un problema complejo y en cada caso requerirá una estrategia diferente. Sin embargo, hay dos cosas básicas a intentar: crear manualmente dependencias entre servicios y cambiar el orden de arranque de los servicios de tipo driver o controlador. En ocasiones, puede ser un driver el que haya demorado su arranque provocando el fallo de algunos servicios dependientes.

Para crear dependencias de servicios se puede hacer mediante el registro de Windows. Hay otras maneras más elegantes, por ejemplo con un script WSH usando la clase Win32_ServiceSpecification de la WMI/WBEM, pero quedan fuera del alcance de este artículo.

La mayoría de problemas en controladores de dominio se deben a dependencias del servicio Netlogon; trabajemos pues sobre este ejemplo.

Usando la herramienta Regedit o cualquier otra similar, localizamos la clave donde se almacenan los datos de todos los servicios:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

en este caso:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon

Para crear una dependencia, tenemos que editar o crear un valor de tipo REG_MULTI_SZ que se llame DependOnService y agregar en su interior los nombres de los servicios de los cuáles queremos hacerlo depender (uno por cada línea). En nuestro caso, queremos que el servicio Netlogon no intente levantarse hasta tener certeza de que ya está levantado el servicio DNS local (fundamental en controladores de dominio).

Para ello añadimos dicho servicio y aceptamos los cambios:

Para aplicar los cambios debería reiniciarse el servicio, aunque para asegurarse es uno de esos pocos casos en los que es mejor reiniciar el servidor.

IMPORTANTE: en este caso hemos hecho depender a un servicio crítico como es Netlogon del servicio DNS. Si este último no estuviese instalado en el DC o no pudiese iniciar, estaríamos provocando un problema grave de funcionamiento, por lo que es conveniente tener este cabo bien atado.

En ocasiones los servicios, como dijimos, dependen de drivers o controladores. En Windows, un driver no es más que otro tipo de servicio que no se muestra en la ventana services.msc, pero que internamente funciona de manera similar como de hecho se puede comprobar mirando la lista de servicios en el Regedit.

Windows Server no nos permite establecer el orden exacto de arranque de cada driver, pero sí de cada grupo de drivers. La mayoría de drivers están asociados a un grupo determinado, y esos grupos sí pueden ser ordenados a nuestro antojo.

Para ello tenemos la siguiente clave de registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

donde el valor List contiene la lista ordenada de grupos de servicios:

Normalmente, los retrasos en casi todos los servicios de red terminan siendo debidos a que las inteterfaces de red (NIC) tardan en estar operativas. Basta con ordenar los grupos de servicios para que todos los que están relacionados con la red arranquen antes.

Reinicio de servicios en ESXi

2013-02-18T09:59:00.000+01:00

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:

La autenticación Kerberos y la integración con el Active Directory no funcionan, no permitiendo entrar con usuarios de la forma DOMINIO\Usuario.
Problemas al intentar montar un volumen externo (por ejemplo, mediante NFS).
Diferentes problemas lanzan un error como este:

"Error interacting with configuration file /etc/vmware/esx.conf: Unlock of ConfigFileLocker failed : Error interacting with configuration file /etc/vmware/esx.conf: I am being asked to delete a .LOCK file that I'm not sure is mine. This is a bad thing and I am going to fail. Lock should be released by (0)"

Como es de esperar cada problema suele estar relacionado con algún servicio que se ha quedado "atontado". La mayoría de esos servicios no interfieren en la ejecución de las máquinas virtuales por lo que pueden reiniciarse tranquilamente. ¿Que no sabes cuál hay que reiniciar ni cómo? No problemo: los chicos de VMware nos lo han puesto muy fácil.

La solución

Afortunadamente los productos de VMware tienen muchos scripts de administración que facilitan enormemente las tareas más comunes. Sólo hay que entrar en modo consola al hipervisor (por ejemplo, mediante SSH) y ejecutar el siguiente comando:

services.sh restart

No hace falta hacer ninguna parada de las VMs.

Conciliar la descripción de los PC con Active Directory

2013-02-10T20:38:00.000+01:00

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.

Si por otro lado, también queremos tener la descripción detallada en Active Directory... ¿por qué no hacer que la descripción de AD se vuelque automáticamente sobre cada estación? De esta manera tenemos todos los equipos actualizados de manera asíncrona (no los tenemos que encender), sólo tenemos una descripción por lo que no crearemos incongruencias y además tendremos la comodidad de cambiar las descripciones desde la página principal de administración de "Usuarios y equipos de Active Directory".

La automatización

Haremos un script que se ejecutará en cada PC durante su arranque, y el propio equipo preguntará a Active Directory por su descripción para a continuación auto-asignársela.

Para lanzar el script la manera más eficiente es utilizar la opción de scripts de inicio/apagado de las directivas de grupo del dominio. Para ello creamos un nuevo objeto de directiva (GPO) o bien editamos alguno que esté siendo aplicado a la unidad organizativa donde estén nuestros PCs.

Digamos que hemos llamado al script con el nombre pc_description.vbs. Sólo tenemos que agregarlo a la directiva según se ve en esta imagen:

El script se ejecutará cada vez que el equipo arranque. Si lo preferís, puede hacerse que se ejecute al apagarse el equipo.

El script

En verdad es un trozo de código bastante sencillo. Los pasos que haremos en este caso son:

Obtener el nombre del host que está ejecutando el script
Comprobar la conectividad con algún servidor de la red. Esto es necesario para que el script no retrase el arranque del PC en caso de que el equipo esté offline y no tenga conexión al dominio (por ejemplo, un portátil en itinerancia).
En caso afirmativo, obtenemos el "distinguished name" (DN) de nuestro equipo, y con él interrogamos mediante LDAP al AD para leer el campo "Description" de la cuenta del equipo.
Modifica la descripción local del PC con los datos obtenidos en el paso anterior.
Salir del script

Un ejemplo del código necesario para hacer el script es el que publicamos a continuación:

'--------------------------------------
'
'  PC Description 
'  The Debug Machine
'  http://www.debugmachine.com
'
'
'   Copyright 2013 José Ángel Morente

'   Licensed under the Apache License, Version 2.0 (the "License");
'   you may not use this file except in compliance with the License.
'   You may obtain a copy of the License at

'     http://www.apache.org/licenses/LICENSE-2.0

'   Unless required by applicable law or agreed to in writing, software
'   distributed under the License is distributed on an "AS IS" BASIS,
'   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
'   See the License for the specific language governing permissions and
'   limitations under the License.
'
'--------------------------------------

On Error Resume Next

Const ADS_SCOPE_SUBTREE = 2

Dim strComputer, strDescription, strLogonServer
Dim objShell

Set objShell = CreateObject("WScript.Shell")
strComputer = objShell.ExpandEnvironmentStrings("%COMPUTERNAME%")
strLogonServer = "dc-01.debugmachine.com"

'Comprueba si el equipo %logonserver% tiene conectividad

If isAlive(strLogonServer,1,500) Then '1 ping, espera 500ms
 strDescription = getComputerDescription ("LDAP://" & GetDN(strComputer))
 setPCDescription ".",strDescription
Else

 WScript.Quit 0
 
End If

Function getComputerDescription (ldapPath) 
 'Busca en Active Directory mediante LDAP el campo "Description" de la cuenta
 'del equipo
 Dim objComputer, objProperty

 'valor por defecto
 getComputerDescription = Null 

 Set objComputer = GetObject (ldapPath)

 If Not IsNull(objComputer) Then
  objProperty = objComputer.Get("Description")
  If Not IsNull(objProperty) Then
      getComputerDescription = objProperty
      objProperty = Null
  End If
  objComputer = Null
 End If
End Function

Function GetDN(computerName)

 'Obtiene el DN (distinguished name) del equipo          
    Dim objRootDSE, objConnection, objCommand, objRecordSet

    Set objRootDSE = GetObject("LDAP://rootDSE")
    Set objConnection = CreateObject("ADODB.Connection")
    
    objConnection.Open "Provider=ADsDSOObject;"
    Set objCommand = CreateObject("ADODB.Command")
    objCommand.ActiveConnection = objConnection

 queryStr = "'LDAP://" & objRootDSE.get("defaultNamingContext") & "'"

 objCommand.CommandText = "Select Name, distinguishedName from " & queryStr & " where objectClass='computer'"  

 objCommand.Properties("Page Size") = 1000
 objCommand.Properties("Timeout") = 30
 objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
 objCommand.Properties("Cache Results") = False
 
 Set objRecordSet = objCommand.Execute
 objRecordSet.MoveFirst
 
 Do Until objRecordSet.EOF
  If lcase(objRecordSet.Fields("Name").Value) = lcase(computerName) Then
      GetDN = objRecordSet.Fields("distinguishedName")
  End If
     objRecordSet.MoveNext
 Loop
End Function
Sub setPCDescription (computerName,description)
 'Configura la desctripción del equipo con la descripción dada
 Dim objOS
 Set objOS = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & computerName & "\root\cimv2").ExecQuery("Select * FROM Win32_OperatingSystem")
    For Each object In objOS
        object.Description = description
        object.Put_
    Next 
End Sub

Function isAlive(strHost, pingsNo, msWait)
 Dim objFile, objFSO, strDummy, strTempFile
 
 Set objFSO = CreateObject("Scripting.FileSystemObject")
  
 strTempFile = objFSO.GetTempName
 
 'valores por defecto 
 If msWait = "" Then msWait = 750
 If pingsNo = "" Then pingsNo = 2
 
 Const OpenAsDefault  = -2
 Const FailIfNotExist = 0
 Const ReadMode  = 1

 objShell.Run "%comspec% /c ping -n " & pingsNo & " -w " & msWait _
    & " " & strHost & ">" & strTempFile, 0, True

 Set objFile = objFSO.OpenTextFile(strTempFile, ReadMode, _
    FailIfNotExist, OpenAsDefault)

 strDummy = objFile.ReadAll
 objFile.Close

 objFSO.DeleteFile(strTempFile)

 Select Case InStr(strDummy, "TTL=")
  Case 0
   isAlive = False
  Case Else
     isAlive = True
 End Select
End Function

Problemas de DNS con cliente VPN Cisco en Windows

2013-02-10T17:16:00.000+01:00

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).

¿Qué pasa si no tienes tus DNS? Si tu equipo pertenece a un dominio Active Directory (o alguna otra tecnología dependiente de los DNS internos de la infrastructura de tu grupo) estás vendido por completo. No sólo no podrás resolver nombres de equipos internos (sin hacer la abominable chapuza de añadir nombres al archivo hosts, que me consta que aún hay quien lo hace), sino que tendrás otros problemas relacionados con la falta de resolución interna, por ejemplo algo tan básico como la autenticación o la aplicación de directivas de grupo.

Para colmo, suele producirse un efecto indeseado más: cuando en la LAN del cliente remoto existe un rango de direccionamiento IPv4 utilizado también por la sede remota a la que se pretende llegar por VPN. En este caso, aunque el software de Cisco tiene parámetros para controlar esta circunstancia, la realidad es que siempre termina habiendo problemas.

La solución

En este caso ayuda bastante el hecho de que el propio cliente Cisco te permite lanzar un ejecutable arbitrario una vez producida la autenticación remota. Haremos un script que se encargue de lidiar con los problemas anteriormente citados.

Como primer requisito es que el usuario que lance el cliente VPN Cisco debe tener permisos locales suficientes para gestionar parámetros de las interfaces de red. Aunque he visto más de un sysadmin cazurro agregar al usuario al grupo de Administradores solamente para que disponga de estos privilegios (¡qué barbaridad!), la manera correcta y elegante de hacer esto es agregar al usuario al grupo Operadores de configuración de red. Es un grupo local y por tanto lo encontraremos en la ventana de Administración de equipos.

El siguiente paso es abrir el Cisco VPN Client para indicarle la línea de comandos del script que se ejecutará tras la conexión. Digamos que llamaremos al script vpn.vbs y que para no complicarnos mucho la vida, lo copiaremos a la propia ruta del ejecutable de Cisco. El script lo vamos a hacer en VBscript, aunque sería realmente fácil portarlo a JScript. En cualquier caso, lo ejecutaremos con CSCRIPT para poder mostrar mensajes en pantalla sin que nos aparezcan continuos "pop-ups".

Así la cosa, la ruta será la siguiente:

C:\WINDOWS\System32\cscript.exe "C:\Archivos de programa\Cisco Systems\VPN Client\VPN.vbs"

Que tendremos que especificar en la opción del menú correspondiente:

(Nota: es recomendable calcular primero las partes variables de la línea anterior usando variables de entorno para garantizar la compatibilidad: %WINDIR% para el directorio real del sistema, y %PROGRAMFILES% para el subdirectorio de archivos de programa).

Una vez preconfigurado todo, pasamos al meollo del asunto.

El script

Nuestro script hará las siguientes tareas de manera automatizada:

Esperar a que la interfaz virtual esté levantada
Obtener la dirección IP de dicha interfaz
Agregar una ruta dinámica para llegar a la sede remota aún cuando el rango coincida con el local
Borrar los DNS asignados por el extremo remoto del túnel y añadir los de nuestra compañía
Abandonar el script

Un ejemplo del código de dicho script es el siguiente (adaptadlo a los parámetros de vuestro escenario).

'----------------------------------------------------------------------------
'  Configurador de red para clientes CISCO VPN
'  The Debug Machine
'  http://www.debugmachine.com
'
'   Copyright 2013 José Ángel Morente

'   Licensed under the Apache License, Version 2.0 (the "License");
'   you may not use this file except in compliance with the License.
'   You may obtain a copy of the License at

'     http://www.apache.org/licenses/LICENSE-2.0

'   Unless required by applicable law or agreed to in writing, software
'   distributed under the License is distributed on an "AS IS" BASIS,
'   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
'   See the License for the specific language governing permissions and
'   limitations under the License.

'  FUNCIONAMIENTO:
'
'  Las conexiones VPN CISCO, tal y como están configuradas por Telefónica, dan
'  problemas de rutas a la red 192.168.1.0 cuando coincide con la red local, 
'  así como problemas de resolución DNS (imposibilita resolver los objetos de 
'  sistema con los DNS propios).
'
'  Este configurador ha de ejecutarse durante el proceso de conexión (usando la
'  opción "Application Launcher" del cliente VPN CISCO. El programa espera
'  hasta encontrar levantada la interfaz "CVirtA" (nombre interno de la conexión
'  Cisco VPN). Una vez levantada, halla la dirección IP, agrega una ruta para
'  forzar el tráfico de la 192.168.1.0 a través de la interfaz virtual, y 
'  finalmente selecciona los DNS internos de la compañía para que todas las
'  resoluciones se hagan a través de ahí
'
'  El script tiene varios parámetros configurables en forma de constantes.
'
'-----------------------------------------------------------------------------

Option Explicit

'CONFIGURACIÓN DEL SCRIPT
Const NICServiceName = "CVirtA"
Const strComputer = "."  'Equipo local
Const remoteRoute = "192.168.1.0"
Const remoteMask = "255.255.255.0"
Const DNSservers = "192.168.1.11,192.168.1.12,192.168.1.13"


'--------------MAIN

Dim   strIPAddress, NICIndex

WScript.Echo "Esperando a que la interfaz " & NICServiceName & " esté lista..."

'Obtiene dirección IP y la muestra
strIPAddress = GetVPNIPAddress (strComputer, NICServiceName)
WScript.Echo "Dirección IP detectada: " & strIPAddress

'Crea la ruta
WScript.Echo "Agregando ruta de sede remota a la interfaz " & strIPAddress
AddRouteIP4 strComputer, remoteRoute, remoteMask, strIPAddress, NICIndex, 22

'Configura los DNS
WScript.Echo "Configurando los DNS de la interfaz " & strIPAddress
SetDNS NICServiceName, Split (DNSservers,",")

'Salir de la aplicación
WScript.Quit 0

'--------------DECLARACION FUNCIONES

Function GetVPNIPAddress (computerName, interfaceServiceName)
'------------------------------------------------------------
'  Queda en espera hasta que se levante la interfaz de Cisco y 
'  devuelve su IP
'
'  Entrada: 
'       computerName            Nombre del equipo ("." para el equipo local)
'       interfaceServiceName    Nombre de servicio de la interfaz
'
'
'  Salida:  
'       dirección IP en formato String
'
'------------------------------------------------------------

        dim strIPAddress
        dim objWMI,colInterfaces,objInterface

        Set objWMI = GetObject("winmgmts:" _
                            & "{impersonationLevel=impersonate}!\\" & computerName & _
                            "\root\cimv2")      'Crea conexión local a la WMI

        
        'obtiene todas las interfaces llamadas deseadas y que estén activas
        'la interface de CISCO aparece como "IPenabled=false" hasta que no tiene una IP asignada
        'por tanto hacemos un bucle hasta que dicha interface sea obtenida en la consulta, lo cuál significa
        'que ya tiene una IP (IPenabled=true)
        Do              
         Set colInterfaces = objWMI.ExecQuery _
             ("Select * From Win32_NetworkAdapterConfiguration where ServiceName=""" & interfaceServiceName & _
                """ and IPEnabled=true")        
        Loop While colInterfaces.count=0
        
        For each objInterface in colInterfaces
                        strIPAddress = Join(objInterface.IPAddress, ",")
                        GetVPNIPAddress = strIPAddress
        Next
End Function

Sub AddRouteIP4 (computerName, route, mask, gateway, InterfaceIndex, metric)
'-------------------------------------------------------------------------
'  Agrega una ruta dinámica en la tabla de rutas IPv4
'  Aunque esta función podría haber sido realizada mediante WMI, para evitar
'  problemas de privilegios de usuario lo haremos ejecutando el comando "route"
'  de Windows a través de una shell.

'  Entrada: computerName


        Dim objShell, strCMD

        Set objShell = CreateObject ("WScript.Shell")   
        strCMD = "route add " & route & " mask " & mask & " " & gateway 
        
        'Parámetros "metric" e "index" pueden ser "null"
        If metric <> Null Then strCMD = strCMD  & " metric " & metric 
        If InterfaceIndex <> Null Then strCMD = strCMD & " if " & InterfaceIndex 
        
        objShell.Exec(strCMD)
        
End Sub

Sub SetDNS (interfaceServiceName, DNSlist)
        Dim objShell, i, strCMD, strNIC
        
        'Obtiene el nombre de la interfaz
        strNIC = GetInterfaceNamebyServiceName (interfaceServiceName)

        Set objShell = CreateObject ("WScript.shell")
        
        'Borra las DNS existentes
        strCMD = "netsh interface ip delete dns name=""" & strNIC & """ all"
        WScript.Echo vbTab & "Borrando DNS actualmente asignados"
        objShell.Run strCMD, 0, True 'ventana oculta y espera a que retorne
        
        'Añade las demás DNS
        For i = 0 To UBound(DNSlist)
                Select Case i+1
                        'Comando DNS primaria
                        Case 1:  strCMD = "netsh interface ip set dns name=""" & strNIC & """" & _
                                                  " source=static addr=" & DNSlist(i) & " register=PRIMARY"
                        'Comando DNS secundarias                                                  
                        Case Else: strCMD = "netsh interface ip add dns name=""" & strNIC & """" & _ 
                                                            " addr=" & DNSlist(i) & " index=" & i+1
                End Select
                WScript.Echo vbTab & "Agregando DNS: " & DNSlist(i)
                objShell.Run strCMD, 0, True
        Next
End Sub

'--------------------------------------------
'  Obtiene el nombre de la interfaz de red
'  a partir del "service name" (CVirtA)
'--------------------------------------------
Function GetInterfaceNamebyServiceName (InterfaceServiceName)
        Dim objWMI, colInterfaces, objInterface
                
        Set objWMI = GetObject("winmgmts:" _
            & "{impersonationLevel=Impersonate}!\\" & strComputer & "\root\cimv2")

        Set colInterfaces = objWMI.ExecQuery _
            ("Select * From Win32_NetworkAdapter Where ServiceName=""" & interfaceServiceName & _
                        """")
        
        If colInterfaces.count Then
                For Each objInterface in colInterfaces
                    GetInterfaceNamebyServiceName = objInterface.NetConnectionId
                Next
        End If

End Function

Espero os haya servido de ayuda.

Saludos

Cambio de "look"

2013-02-10T11:49:00.000+01:00

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

2013-02-04T19:30:00.000+01:00

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.

El programa malicioso configura nuestro sistema para que este navegue a través de un proxy en lugar de hacerlo de manera directa. Pero no usa un proxy real, sino que él mismo hace de proxy en Windows en algún puerto TCP aleatorio poco común, y redirigiendo todas las peticiones a la IP localhost (127.0.0.1) que identifica inequívocamente al sistema infectado.

Podemos tener al parásito durante mucho tiempo hasta que nos demos cuenta. Pero, ¿qué pasa el día que actualizas el antivirus y el bicho es "cazado"? Pues que el falso proxy deja de funcionar, pero el sistema sigue configurado para salir a Internet a través del mismo, lo que causa el aparente síntoma de que no tenemos Internet (aunque en realidad pocos programas se hacen cargo de este ajuste, a excepción de los navegadores web).

Los síntomas básicos de este problema son:

Si haces "ping" a una dirección de Internet bien conocida, ésta responde perfectamente.
Si intentas abrir una WEB con Internet Explorer, aparece un error de conexión, pero no así con Mozilla Firefox.
Otros programas dependientes de Internet tales como Skype funcionan correctamente.

Si es así, es probable que hayamos tenido uno de estos parásitos infectando nuestro sistema y el antivirus lo ha eliminado sin restituir la configuración de proxy.

La solución

Es tan sencillo como reconfigurar manualmente la configuración del proxy de Windows. La forma más fácil (común a Windows 200x, Windows XP y Windows 7) es ir a Panel de Control y seleccionar "Opciones de Internet".

En esta ventana seleccionamos la pestaña "Conexiones" y después "Configuración de LAN"

En la nueva ventana que se nos abrirá, tenemos que localizar las opciones de configuración de Proxy y desmarcar la casilla "Usar servidor proxy para LAN...", así como borrar los campos "Dirección" y "Puerto", que como observaremos, están rellenos con los datos proporcionados por el virus para forzar que todas las conexiones pasen a través de él:

Puede ocurrir que se trate de nuestro PC de trabajo, y el malnacido del sysadmin de la compañía nos tenga bloqueado el acceso a esta ventana para así evitar que toquemos donde no debemos. En ese caso el método a seguir es otro. El sistema de Directivas de Grupo de Windows permite en efecto bloquearnos esta ventana, pero está tan mal diseñado que no establece una seguridad real sobre el objeto final del registro que se modifica para configurar el proxy, por lo que basta con armarnos con el Editor de Registro (alias regedit.exe) y hacer los siguientes cambios:

En la clave HKCU\Software\Microsoft\Windows\Currentversion\Internet Settings\ localizamos el valor "Proxyenable", y lo mofidicamos para que contenga como dato: "0".
En la misma clave anterior, buscamos el valor "ProxyServer" y borramos su contenido (que estará indicando algo similar a lo de antes, 127.0.0.1:58887).

Ni que decir tiene que si en condiciones normales nosotros tenemos configurado un proxy para la salida a Internet, no hay que borrar los valores anteriores, sino sustituirlos por los nuestros.

Errores de VMware vCenter Converter Standalone

2013-01-31T11:45:00.002+01:00

Quizás la mejor solución de virtualización del mundo es VMware, producto amplio, rico y complejo donde lo haya, y piedra angular de lo que hoy llamamos el Cloud Computing.

Aunque su precio es elevado (y vale lo que cuesta), VMware nos ofrece una versión gratuita de su poderoso VMware vSphere cuyas prestaciones mínimas son de por sí apabullantes. En esta versión gratuita no se incluye la poderosa herramienta VMware vCenter que permite gestionar poderosas infrastructuras de servidores virtuales y hosts, pero sí nos dan dos herramientas en versión individual que nos hacen el apaño: el VMware vSphere Client y el VMware vCenter Converter Standalone.

Este último es fundamental para virtualizar máquinas físicas, convertir máquinas virtuales entre formatos, o transferir máquinas virtuales de un host ESXi a otro distinto... cuando funciona. A veces da errores extraños durante el proceso de conversión y te dan muy poca información en el visor para solucionarlo.

El error más frecuente es este:

"Cannot query source HW info"

La solución

Esto es debido a alguna operación anterior que no salió del todo exitosa. VMware utiliza archivos de control de bloqueos con la extensión .lck, normalmente en la misma ubicación de la máquina a convertir

La solución es tan simple como eliminar tranquilamente ese fichero y reintentar de nuevo la conversión.

Identificación de interfaces de red en Linux bajo VMware

2013-01-30T19:00:00.000+01:00

Hoy en día, y aunque pareciese poco concebible hace pocos años, sería raro estar escribiendo sobre administrar un sistema operativo Linux corriendo sobre un servidor físico; la virtualización ha pasado de ser una opción a mirar de reojo y desde la desconfianza a convertirse en prácticamente la única manera eficiente de montar un sistema corporativo.

VMware es un sistema robusto, maravilloso y eficiente. No obstante y pese a su excelente transparencia y múltiples ventajas, a veces surge algún pequeño inconveniente de muy fácil solución pero que nos puede tener entretenidos durante horas. Me ocurrió en cierta ocasión que tuve que clonar una máquina virtual corriendo una distribución Fedora (entiendo que esto os puede ocurrir con otras muchas distribuciones, especialmente todas las de "sabor RedHat" como CentOS, Fedora, Scientific Linux, etc.).

La máquina clonada en este escenario va a presentar con casi toda seguridad problemas para reconocer correctamente las interfaces ethernet (eth1, eth2...) debido a que al clonar la máquina, VMware asigna nuevas direcciones MAC a las interfaces virtuales. Esto es así para garantizar que cada interfaz sigue teniendo un identificador unívoco dentro de cualquier red, física o virtual.

Cabría esperar que en ese caso, el OS simplemente ignoraría las interfaces de origen y detectaría unas nuevas interfaces, bien automáticamente, o bien tras ejecutar un modprobe pcnet32 (por ejemplo etc3, etc4...) pero en la práctica no siempre es tan fácil, pues estas nuevas interfaces quizás no aparezcan con la herramienta system-config-network.

Pasos para la solución rápida

Hay muchas maneras de volver a arreglar esto, pero la manera que me parece más rápida y directa es la siguiente:

Justo tras clonar la máquina, y una vez preparada para su arranque, obtenemos la nueva dirección MAC de las interfaces virtuales de red de VMware. En el caso de ESXi, seleccionamos la máquina a clonar y hacemos right-click y abrimos la opción "Edit settings...". Seleccionamos la interfaz de red y apuntamos la dirección MAC:
Editamos el archivo /etc/udev/rules.d/70-persistent-net.rules y donde aparece la antigua MAC, ponemos la nueva y guardamos:
En el subdirectorio /etc/sysconfig/network-scripts/ buscamos los scripts de configuración de cada interfaz eth. Si la interfaz se llama eth0, el script será ifcfg-eth0. Modificamos también con la nueva MAC y guardamos cambios:
Reiniciamos el servicio de red o bien hacemos un reboot completo de la máquina virtual. Una vez arrancado deberíamos de tener las mismas interfaces ethernet de la máquina original, con los mismos nombres de dispositivo y funcionando perfectamente.

Ahorro de costes con Google Apps (III). Bye, bye, Exchange. Bienvenido, Mr. LDAP

2011-06-26T16:20:00.000+02:00

<<<< Anterior

En los anteriores artículos vimos cómo configurar nuestro dominio para ser usado con Google Apps y aprendimos a hacer unos ajustes básicos. Ahora ya llegado la hora de configurar nuestras propias aplicaciones con el fin de sustituir el servicio Exchange en nuestra compañía.

De las principales ventajas del Exchange, hay algunas que podemos replicar casi de manera inmediata con lo visto hasta ahora. La primera y más característica de este tipo de servidor: la opción de usar una "Libreta Global de direcciones" de la compañía.

Para poder seguir usando esto, realmente nunca habríamos necesitado un Exchange, ya que éste lo único que hace es mostrarnos una vista de las direcciones que tenemos dadas de alta en nuestro dominio Active Directory. Como todo el mundo sabe, el Active Directory no es nada especialmente nuevo ni mucho menos inventado por Microsoft; es en realidad una (otra) implementación del estándar abierto LDAP (Lightweight directory access protocol).

El directorio de equipos, grupos, carpetas y usuarios puede estar basado en cualquier servidor Windows, Netware o Linux que tengan cualquier implementación de LDAP (por ejemplo OpenLDAP).

Mediante el protocolo LDAP podemos acceder y manipular absolutamente todos los datos necesarios para, entre otras cosas, mantener al día nuestra libreta global de direcciones (incluyendo listas de distribución), de una manera casi idéntica a como lo habríamos realizado en un Exchange.

Dado que estos artículos están orientados especialmente a aquellos que desean desprenderse de las garras de Microsoft, enfocaré el desarrollo del tema sobre la base de un directorio Active Directory característico de sistemas operativos Windows Server con el que sin duda estarán familiarizados. No obstante, todo será aplicable de manera muy similar a cualquier otra implementación de LDAP en sistemas basados en Unix o bien en Netware (cuya implementación LDAP es quizás mi favorita).

PRIMEROS PASOS. ORGANIZANDO EL DIRECTORIO

Antes de nada, tenemos que escoger un nombre de dominio para nuestra compañía ficticia. En este caso será debugmachine.local.

Para tener un directorio cuya organización facilite nuestra interacción vía LDAP, deberemos tener en cuenta un detalle diferenciador respecto de cómo se gestionan los usuarios en MS Exchange. Cualquier administrador familiarizado con Exchange conoce la opción avanzada de "No mostrar en las listas de direcciones de Exchange". Dicha opción, muy útil para ocultar un usuario que ha causado baja en la compañía, no la tendremos cuando estemos administrando el directorio directamente por LDAP.

Una forma de solventar esta diferencia es estructurar las unidades organizativas de tal modo que siempre tengamos un contenedor en un nivel anterior a la unidad organizativa que contiene a todos los usuarios activos. Esta última unidad será siempre considerada como la rama "raíz" al hacer búsquedas, por lo que siempre tendremos un contenedor donde colocar los usuarios que queramos hacer desaparecer de las listas.

Para llevar a cabo este paso, crearé dos unidades organizativas muy importantes. Una, llamada Usuarios ocultos será útil para mover ahí los usuarios que no queremos que salgan en la libreta de direcciones (por ejemplo porque abandonaron la compañía), y otra, llamada root que será la raíz de todas las Unidades Organizativas reales de la compañía, es decir, las que contendrán a todos los usuarios, equipos, grupos, etc. que pretendemos que continúen activos.

El siguiente paso consiste en escoger la forma en que queremos acceder contra el servicio LDAP. Existen básicamente dos formas de hacerlo: de manera anónima o mediante autenticación. El acceso anónimo es muy cómodo pero tiene dos inconvenientes: evidentemente la seguridad, y en segundo lugar, que algunos programas de correo tienen comportamientos indeseados cuando se les configura una password vacía.

El modo autenticado es simple: consiste en especificar una credencial con suficientes privilegios para hacer consultas. Todos los usuarios de Active Directory tienen, por defecto, esta posibilidad. El problema es que Outlook y otros programas de correo no permiten integrarse con el usuario logueado y obligan a especificar las credenciales en la configuración. En caso de un hipotético cambio de contraseña en el dominio, habría que luego ir a configurar de nuevo la conexión con la libreta LDAP en el programa de correo.

Yo propongo como solución tirar por el camino de en medio. Para facilitar la configuración de todos los accesos LDAP de la compañía, indistintamente de los cambios de contraseñas, podemos crear un usuario en nuestro dominio cuya función sea exclusivamente esa. Le llamaremos accesoLDAP@debugmachine.local y la password que estimemos oportuno según los requerimientos de seguridad que necesitemos.

ENCONTRANDO LA RUTA LDAP

Una vez preparado y organizado nuestro dominio para accederlo por LDAP, necesitamos un último paso: hallar la ruta LDAP que vamos a usar como raíz de búsqueda. Dicha ruta se especifica en el formato estándar X500 (podéis conocer más detalles sobre cómo se especifica este formato en este artículo).

En nuestro caso, si queremos establecer una libreta de direcciones global para toda la compañía, necesitamos la ruta LDAP de la unidad organizativa root, que sería la siguiente:

OU=root, DC=debugmachine, DC=local

Como vemos, el orden se hace de atrás hacia adelante (excepto los dos valores DC que hacen alusión al dominio desglosado en sus dos miembros).

Pero hilando más fino, podríamos crear no una, sino varias libretas de direcciones distintas, separadas para cada delegación u oficina (en nuestro caso, para cada Unidad Organizativa). Tendríamos entonces:

OU=Delegación Jerez de la Frontera, OU=root, DC=debugmachine, DC=local
OU=Delegación Murcia, OU=root, DC=debugmachine, DC=local
OU=Oficinas centrales, OU=root, DC=debugmachine, DC=local

Como vemos, la lógica del formato X500 es muy simple y aunque en el link anterior está bien descrito, confío en que los ejemplos previos serán más que suficientes para que fácilmente especifiquéis los vuestros.

CONFIGURANDO OUTLOOK

En primer lugar agregaremos la cuenta de usuario. El procedimiento es sencillo: se crea una nueva cuenta usando protocolo IMAP según la propia Google lo describe en este documento.

Una vez realizado, creamos la libreta de direcciones global que actúe contra nuestro controlador de dominio (preferentemente contra alguno que sea un catálogo global). Los ejemplos están realizados con Microsoft Outlook 2003, pero son igual de válidos para cualquier versión posterior.

Vamos al menú Herramientas y después Cuentas de correo electrónico... y agregamos una nueva libreta de direcciones de tipo LDAP:

Y escribimos los siguientes parámetros, para después clickar en "Más configuraciones...":

En esta ventana rellenaremos los campos de ambas pestañas en la manera que sigue (hay que tener en cuenta que el puerto LDAP por defecto es el 389, pero si usamos un servidor catálogo global, entonces se usa el 3268):

Aceptamos todos los cambios, y, muy importante, cerramos y volvemos a abrir Outlook. Una vez tengamos de nuevo abierta la aplicación, sólo tenemos que abrir la Libreta de direcciones (atajo ctrl+shift+B) y veremos lo siguiente:

¡Ahí está! Es nuestra libreta de direcciones de siempre, siendo leída desde el dominio Active Directory, y sin ningún servidor Exchange en el escenario. Como antes expliqué, se puede repetir el proceso tantas veces se necesite para tener diferentes libretas de direcciones segmentadas según el criterio que necesitemos (por ejemplo, por sedes).

OK. ¿Y QUÉ PASA CON EL CORREO?

El correo configurado vía IMAP es similar a un buzón tradicional en Outlook, pero hay algunos matices. Algunas diferencias las evitaremos mediante configuración, mientras que para otras tendremos que introducir leves diferencias en nuestra manera de trabajar.

Todo ello lo veremos en la siguiente entrega.

Saludo y ahorro.

Ahorro de costes con Google Apps (II). Configuración de Gmail

2010-04-11T14:10:00.008+02:00

<<<< Anterior Siguiente >>>>

Continuamos esta serie de entradas dedicadas a "medidas-anticrisis" para empresas, y basadas en los servicios gratuitos de Google.

En el post anterior vimos cómo dar de alta un servicio de Google Apps integrado con un dominio de nuestra propiedad como punto de partida. Dado que, entre otras cosas, nuestro principal objetivo es conseguir retirar los servidores de correo y colaboración Microsoft Exchange, vamos a estudiar ahora algunos ajustes necesarios al servicio de Gmail, y Google Apps orientados a dicha finalidad.

Un servidor Exchange provee diferentes funcionalidades muy típicas en cualquier empresa. Estas ahora han de ser sustituidas o emuladas con distintas alternativas. A continuación expongo el resumen del planteamiento propuesto:

Llegados a este punto es importante una advertencia: las equivalencias de servicios reales y los propuestos no son exactas, e implica cierta adaptación a esta configuración, tanto en tareas administrativas como de los propios usuarios finales. No obstante, y puesto que la ofimática no nació con el Exchange ni con el Outlook, es justo pedir a los usuarios de nuestro dominio un poco de esfuerzo en adaptarse a una serie de ligeros cambios en su manera de trabajar; como recompensa, podrán disfrutar de muchas ventajas nuevas que harán el trabajo más cómodo a la larga, y la empresa podrá ahorrar una fortuna. Y para los que crean que se puede tener un Exchange pirateado de por vida, sé de buena tinta que Microsoft puede llamar a tu puerta cuando menos te lo esperes.

CONFIGURACIONES INICIALES

Vamos primero a configurar pequeños detalles que nos harán nuestra estancia en Google Apps más agradable.

Entramos al panel de control de nuestro dominio a través del siguiente enlace:

http://www.google.com/a/cpanel/debugmachine.com

Si tenéis algún otro dominio registrado y queréis que se comporte como alias del principal, ahora es el momento de agregarlo.

De esta forma, podemos también registrar el dominio ficticio "thedebugmachine.com", como variante del principal.

Así, si por ejemplo ya tenía creado un e-mail llamado joseangel@debugmachine.com, automáticamente dicho buzón también recibirá los mails enviados a joseangel@thedebugmachine.com.

Para ello seleccionad esta opción:

Ahora sólo hay que escribir el nombre del dominio que queremos agregar como "alias" y continuar:

Nos aparecerá una ventana para invitarnos a comprobar que el dominio en efecto es de nuestra propiedad. El procedimiento es exactamente el mismo descrito en el capítulo anterior.

Ahora podemos ir a "Apariencia" y darle un poquito de nuestro "look & feel" subiendo nuestro propio logo. Ha de estar en GIF o PNG y pesar no más de 20KB. En la misma pantalla podemos escoger nuestros colores corporativos.

CREACIÓN Y GESTIÓN DE BUZONES Y GRUPOS

El siguiente paso es replicar todo el contenido del servidor de correo actual en el propio Google Apps. Para ello Google nos ofrece dos métodos en la versión Standard Edition (en la edición Premier existen herramientas de integración mucho más sofisticadas):

Crear individualmente cada buzón (recomendado si el número de altas no es muy grande)
Importar un archivo CSV (valores separados por comas) con todos los buzones.

Dicho CSV se puede crear con cualquier hoja de cálculo, pero lo apropiado ahora para ir viendo el funcionamiento de toda la suite, es hacerlo con el propio Google Docs. Nos vamos a http://docs.debugmachine.com y pulsamos en "Crear nuevo" y "Hoja de cálculo". Nos aparecerá una hoja de cálculo en la que podemos importar un archivo de Excel previamente creado con todos los usuarios (dicho Excel, a su vez, se puede crear exportando la lista de buzones desde el propio Exchange). La estructura, incluyendo la fila con los nombres de los campos ha de ser la que se muestra a continuación:

Una vez tengamos todos los usuarios definidos, lo grabamos como archivo CSV haciendo click en "Archivo" y en "Descargar como > CSV (hoja actual)":

Con el CSV ya descargado en nuestro ordenador, nos vamos, en el panel de control del dominio, al menú "Herramientas avanzadas" y hacemos click en la opción "Actualización masiva de cuentas de usuario":

Ahí ya sólo tenemos que subir el archivo y Google automáticamente dará de alta todos los buzones.

Todos los buzones dados de alta implican en sí mismos una cuenta de acceso Google Apps, por lo que cada uno además de sus 7,4GB de correo, dispondrán de 1024MB para crear o subir documentos online, además de estar automáticamente integrado en la lista global de direcciones y en el Google Talk (chat y llamadas de voz sobre IP).

ACTIVANDO LOS CONTACTOS COMPARTIDOS

Por defecto, el servicio "Google Contacts" no viene activado en las Google Apps para empresas, así que tendremos que activarlo. Para ello iremos a la pantalla principal de gestión, donde salen los iconos de todos los servicios y pincharemos en la siguiente opción:

Configuración del servicio

Añadir más servicios

Ahí buscamos el icono de "Contactos" y lo agregamos. Además, podemos añadir otros servicios experimentales o de terceros, si vamos al "MarketPlace". Aunque esto supone un potencial infinito de Google Apps como herramienta de gestión, no vamos a profundizar por el momento en ello. Espero dedicar más adelante una nueva serie de posts centrándome en el potencial de MarketPlace y en un ranking de las mejores aplicaciones para añadir a nuestras Google Apps.

Una vez agregado el servicio de Contactos, debemos activar la función de compartir la libreta global de direcciones, en el menú "Usuarios y grupos" y "Configuración":

CREACIÓN DE LISTAS DE DISTRIBUCIÓN

Podemos crear cuantas listas de distribución (grupos) deseemos. Para ello vamos al mismo menú de "Usuarios y grupos" y esta vez a "Grupos". Podemos crear uno nuevo y seleccionar todas las direcciones que queremos que formen parte de esa lista de distribución (pueden ser direcciones internas o de cualquier otro dominio de Internet).

Añadiremos una dirección de e-mail para identificar ese grupo y escogeremos los permisos de acceso (para decidir si el grupo es accesible sólo dentro de la organización, o también desde Internet). Es bastante flexible en ese aspecto.

El siguiente paso es escoger los miembros de dicho grupo escribiendo las direcciones en el recuadro correspondiente. También hay una opción para escoger que sea un grupo global (todos los destinatarios).

CONFIGURACIÓN DE UN BUZÓN DE CORREO

Una vez hecha la configuración global del servicio, hay que activar algunas funcionalidades de manera individual en cada buzón. Para ello hay que entrar ya como si fuésemos el propio usuario, ya que muchas de las opciones que nos interesan están ubicadas en el menú de configuración del webmail de la cuenta Gmail. Esto es sin duda una carencia administrativa, pero se debe a que estamos trabajando con el servicio Standard Edition. Si se contrata la Premier Edition, las posibilidades administrativas mejoran sustancialmente.

Cerramos la sesión de administrador, y abrimos la cuenta del buzón que queremos preparar en la URL que en su momento creamos para tal fin: http://mail.debugmachine.com.

Una vez dentro, nos vamos a "Configuración" (arriba a la derecha). Lo primero de todo es activar algunas opciones añadidas que nos vendrán muy bien para hacer un uso más productivo del correo y mejorar la interacción con Outlook o Thunderbird. Para ello Google nos da las "Google Labs".

Una vez dentro activaremos los siguientes plug-ins:

Controles avanzados de IMAP
Imágenes en el chat
Inserción de imágenes
Respuestas prediseñadas

Guardamos los cambios y después nos vamos a la opción "Reenvío y correo POP/IMAP" donde activaremos el protocolo IMAP (¡imprescindible, es el núcleo de todo el jaleo que estamos montando!). Nos aseguramos de que la opción "Borrar los mensajes inmediatamente cuando los marco como eliminados en IMAP" está seleccionada (también necesario si queremos seguir usando Outlook como cliente de mensajería).

Ahora nos vamos a "Etiquetas". Gmail lo que permite es etiquetar los correos con diferentes etiquetas creadas por nosotros. Un mismo correo puede tener varias etiquetas a la vez. Sin embargo, dichas etiquetas, son expuestas por el servicio IMAP como carpetas. Y viceversa, o sea, las carpetas de correo que hayamos creado en nuestro cliente (Outlook, Thunderbird, iPhone o cualquier otro) aparecerán como etiquetas en el webmail. Por tanto, es importante también, para tener un entorno ordenado y agradable, eliminar del IMAP las etiquetas que no queremos ver como carpetas en el programa de correo:

Para finalizar por el momento la configuración del buzón, nos vamos a "Configuración" > "Temas" (aviso: esta opción no saldrá disponible con el navegador Internet Explorer 6 o anterior, pues está pensada para los nuevos estándares). Aquí podemos escoger el aspecto de nuestro webmail para hacer un entorno más agradable y acorde a nuestra organización. Algunos de los "temas" van cambiando dinámicamente según la hora o la zona del planeta en la que vivamos. Yo he escogido el que se muestra en la foto:

Muchas opciones de nuestro Exchange que antes hubiésemos administrado desde la consola de "Usuarios y equipos de Active Directory" encuentran su equivalencia en el "Panel" de Google Apps. Sin embargo, otras muchas hay que ir a buscarlas a la configuración personal de cada buzón; al igual ocurre con algunas opciones del cliente Outlook (por ejemplo, el mensaje de "Fuera de oficina"). A continuación se muestra una relación de algunas tareas administrativas típicas y su actual emplazamiento:

Tarea	Ubicación clásica	Nueva ubicación
Crear nuevo buzón	Usuarios y equipos de AD	Panel de Google Apps
Crear nueva lista o grupo	Usuarios y equipos de AD	Panel de Google Apps
Agregar dirección de e-mail	Usuarios y equipos de AD	Panel de Google Apps
Cambiar contraseña	Usuarios y equipos de AD	Panel de Google Apps o Configuración del buzón Gmail
Reenviar los correos a otra dirección	Usuarios y equipos de AD	Configuración del buzón Gmail
Activar mensaje de "fuera de oficina"	Outlook	Configuración del buzón Gmail
Reglas y alertas	Outlook	Filtros y etiquetas (webmail)
Activar protocolos POP3 o IMAP4 de un buzón	Usuarios y equipos de AD	Configuración del buzón Gmail

Ahora ya estamos preparados para ir a nuestro cliente de correo favorito y atacar al buzón de la cuenta Gmail. En el siguiente artículo veremos cómo configurar el Outlook para ello, intentando que la experiencia sea bastante similar a la de trabajar con el Exchange y para también poder migrar todo el correo de una cuenta a otra.

No obstante, será sólo una parada intermedia antes de ir a nuestro objetivo final como sustituto íntegro de Outlook: Mozilla Thunderbird.

Se puede enunciar, a modo de regla de tres, que "Thunderbird" es a "Microsoft Outlook" como "Firefox" es a "Internet Explorer". Con eso queda dicho todo, creo.

<<<< Anterior Siguiente >>>>

Ahorro de costes con Google Apps (I). Puesta en marcha.

2010-04-08T01:08:00.006+02:00

Como no podía ser de otra manera, en tiempos de crisis hay que sacar dinero hasta de debajo de las piedras. En las empresas actuales, fuertemente basadas en las tecnologías de la información, el problema es aún mayor debido a los costes de licencias de software, al hardware, y al mantenimiento de todo el tinglado.

Sin embargo, hay otra forma de hacer las cosas (otro "paradigma" que dirían los New Age). La cuestión es usar recursos basados en lo que ahora llaman la "nube", y combinarlos con software gratuito libre. Esto nos da unas ventajas muy claras:

Reducción de hardware
Reducción de comunicaciones y publicación de equipos y servicios
Reducción de coste de mantenimiento
Disponibilidad global
Ahorro en licencias
Apoyo de una enorme comunidad de desarrolladores y usuarios.
Los gallifantes que te dan en tu empresa por salvar los presupuestos anuales gracias a tanto ahorro

En definitiva, este es el primero de una serie de artículos donde demostraremos que existen alternativas reales a la tendencia clásica en nuestro país: servidores Windows, suite de producción Microsoft Office, comunicaciones con Microsoft Outlook y servidor de correo Microsoft Exchange.

Este último parecería el producto "irreductible" ya que muy pocas compañías se atreven a prescindir de él. Sin embargo en estas entradas mostraré algunas pistas e indicaciones de cómo es posible retirar los Exchange de la empresa sin que la producción se resienta.

La madre del cordero

Todo esto gira en torno como decía antes a la integración de los servicios de IT en la "nube", palabro que está ahora muy de moda y que viene a hacer alusión al uso de servicios externos, basados en Internet y en tecnologías WEB (especialmente AJAX), de tal forma que toda la información se guarda en la Red, y se trabaja con un simple navegador.

Hay una palabra clave detrás de todo esto: Google.

Alguno ya se estará preguntando:

"Aparte del mejor buscador de la historia, los álbumes de fotos Picasa, el correo GMail, la fantástico motor de cartografía integrada con los demás servicios, los blogs y listas de correo gratuitos, el Reader, los Libros online, el mejor navegador Web de la historia, el GoogleTalk, el repositorio de código abierto y el Orkut, ¿qué ha hecho Google por nosotros?"

Pues la respuesta es sencilla: Google Apps.

Google Apps es una suite de programas accesibles vía web, que permiten, de forma integrada con nuestra cuenta Google, crear, editar, subir, almacenar, compartir, enviar casi cualquier tipo de documento, incluyendo hojas de cálculo, procesador de texto, presentaciones, etc., permitiendo intercambiar datos entre ellos, convertirlos al vuelo a PDF y mil cosas más, crear sitios WEB de manera visual, y alojarlos. Gratis.

¿Pero qué es lo mejor de todo? Lo mejor es que Google nos permite acceder a dicha suite de programas usando nuestro propio dominio de Internet. De esa forma, podemos tener (en la versión gratuita) hasta 50 cuentas de correo electrónico, con 7GB de almacenamiento cada una, accesibles desde IMAP, POP3, WEB y con 1024MB para almacenar documentos creados en Google Apps.

Además, todo funciona de forma muy "2.0" permitiendo empotrar documentos en una web (como se hace por ejemplo con un video de Youtube), enviar el link, escoger el nivel de acceso para cada usuario, etc. Esto muy a grandes rasgos, si nos metemos a fondo, combinando los "gadgets" y las opciones del "Lab" las posibilidades son infinitas.

Este será pues, el núcleo de nuestro proyecto (a desarrollar en los siguientes capítulos) para sustituir una infraestructura de colaboración empresarial típica montada sobre Exchange y Microsoft Office, en otra totalmente gratuita, flexible y eficiente.

¡Hasta el infinito y más allá!

Pues allá vamos. Lo primero que necesitamos es lógicamente, tener un nombre de dominio de nuestra organización para usar con este servicio. Además, necesitamos tener control sobre la tabla de registros DNS de dicho dominio, lo cuál es un servicio básico y habitual de cualquier proveedor de dominios.

Para realizar estos artículos, he registrado en www.godaddy.com un dominio que usaré para este mismo blog: debugmachine.com. Una vez activado y comprobado que tengo acceso a la tabla DNS de dicho dominio, me dispongo a darlo de alta en el servicio "Google Apps Standard Edition". Hay modalidades de pago con infinitas prestaciones orientadas a grandes compañías; de momento iremos a la gratuita, que nos sobra y nos basta.

Nos dirigimos al siguiente enlace:

http://www.google.com/a/cpanel/domain/new

Colocamos nuestro nombre de dominio, y continuamos:

En la siguiente pantalla, rellenamos los datos y continuamos. En el paso 3, tenemos que escoger un nombre de usuario que se usará como administrador de todo el tinglado, pero no recomiendo que lo uséis como usuario en sí mismo (para recibir correo, trabajar, etc.). Yo he escogido admin.

Elegís una password, aceptáis las condiciones y seguimos adelante.

Aquí ya nos aparece el panel de control de Google Apps integrado con nuestro dominio. Podéis mirar por encima que tenemos opciones para cambiar el comportamiento de las distintas aplicaciones: Google Docs, el Chat, Contactos compartidos, integración con teléfonos móviles, etc. Pero antes de poder activar cada uno de estos servicios, es necesario un paso importantísimo, que es demostrarle a Google que dicho dominio es nuestro y que tenemos control DNS sobre el mismo.

Para ello hay que clickar el enlace mostrado aquí:

Google nos ofrece dos maneras de validar nuestro dominio: subiendo a nuestro servidor web un archivo HTML que ellos nos dan, o bien creando un registro CNAME en la tabla DNS del dominio. Puesto que yo no tengo un servidor web vinculado a este dominio, me decanto por el segundo método.

Aquí viene el primer paso peliagudo de esta operación; esto lo necesitamos realizar en la tabla de gestión DNS de nuestro dominio. En mi caso dicha tabla está en GoDaddy, que es a quien he comprado el dominio. Tendré pues que ir allí y dar de alta los datos que me pide Google. Consiste en crear un registro de tipo "CNAME", cuyo nombre y destino son los siguientes:

Dicho CNAME lo doy de alta en mi proveedor de dominios (este paso varía para cada proveedor, pero en esencia debe ser un proceso similar). El panel de control DNS puede también estar bajo el nombre "Nameservers". Una vez localizado, agrego un nuevo registro de tipo "CNAME" (o "alias"):

Y completo los datos con lo indicado por Google:

Una vez aceptado el cambio, pasados unos minutos ya debería aparecer en la lista de alias o CNAMEs:

Ahora hay que dejar reposar el estofado, para que tenga más sabor, y para que estos cambios se propaguen a través de todos los DNS de la Red. El proceso en teoría puede tardar hasta 48 horas, pero en la práctica no suele tardar más de una hora o dos.

Una vez esto ocurra, volvemos a la pantalla de Google para verificar si dicho cambio ya se ha propagado. Si aún no, sólo hay que ser paciente y esperar un poco más. Una vez conseguido, Google dará por bueno el dominio y ya podremos pasar al siguiente paso:

Ahora nuestro dominio ya está legítimamente vinculado a Google Apps y podemos comenzar a activar servicios. Los servicios en principio disponibles para Google Apps Standard Edition son los siguientes:

Mail
Calendario
Documentoss
Chat
Contactos
Sitios web
Móvil

Aparte, nos permite desarrollar nuestras propias aplicaciones e integrarlas aquí, pero eso obviamente escapa al alcance de esta serie de artículos.

Comienza el espectáculo

Lo primero y más evidente que activaremos será el mail. Se trata del mismo servicio de correo GMail, pero bajo nuestro dominio, en este caso @debugmachine.com. Para activar dicho servicio, vamos al panel de control principal y buscamos el link Activar el correo electrónico.

Aquí viene el segundo punto delicado de la operación: de nuevo tenemos que ir al panel de gestión DNS de nuestro dominio para modificar los registros de tipo MX (que son los asociados al correo electrónico).

En este caso, Google ya ha detectado que mi proveedor es uno bien conocido, GoDaddy.com, y me muestra las instrucciones específicas para el mismo, que reproduzco a continuación:

Accede a tu cuenta en http://www.godaddy.com.

Abre la pestaña Domains y selecciona My Domain Names. El sistema te dirigirá a la página Manage Domains.

Haz clic en el nombre de dominio que deseas utilizar con Google Apps.

En el panel Domain Details que queda a la derecha, selecciona el icono + debajo del elemento de lista Total DNS Control. Aparecerá una sublista.

Haz clic en la entrada con el título Total DNS Control And MX Records. Aparecerá el panel Manage MX Records, and DNS Zone File.

Haz clic en Launch Total DNS Control Manager Aparecerá la ventana DNS Manager.

Borra todos los registros MX existentes haciendo clic en Delete.

Haz clic en OK en el cuadro de diálogo de confirmación.

Una vez que hayas suprimido todos los registros existentes, haz clic en Add New MX Record. Aparecerá MX (Mail Exchangers) Record Wizard.

Para cada registro MX, introduce la información de acuerdo con los datos de la tabla siguiente.

Para el menú desplegable Select the Priority Value, introduce el valor de prioridad.

Para Enter a Host Name, deja la configuración predeterminada en @.

Para Enter Goes To Address, escribe el nombre del servidor de Google en la tabla siguiente. Comprueba que hayas incluido el punto al final de cada registro.

Para el menú desplegable Select TTL Value, escribe 1 Week. Aparecerá como 604800 seconds en el sistema de DNS.

PriorityValue HostName Goes To Address (Mail Server) TTL Value

10 @ ASPMX.L.GOOGLE.COM. 1 week

20 @ ALT1.ASPMX.L.GOOGLE.COM. 1 week

30 @ ALT2.ASPMX.L.GOOGLE.COM. 1 week

40 @ ASPMX2.GOOGLEMAIL.COM. 1 week

50 @ ASPMX3.GOOGLEMAIL.COM. 1 week

Haz clic en Continue.

Haz clic en Add para confirmar cada entrada. La página principal de DNS Manager volverá a aparecer cuando hayas terminado.

Una vez añadidos deben aparecer en vuestro panel DNS. Dejamos un ratito para que se propaguen los cambios, y ya podemos apretar el botón de confirmación en el panel de control de Google.

Una vez terminado, nos vamos a la configuración del correo electrónico. Lo primero recomendable es crear una URL intuitiva para acceder a los distintos servicios a través de la WEB. Esto se realiza en la opción "Cambiar url". Una vez ahí, clickamos de nuevo en "Cambiar URL para todos los servicios". En esta página escogemos los subdominios que apuntarán a cada servicio. Yo he dejado los que me sugiere el propio Google. Me gustan.

Ahora de nuevo tenemos que ir al panel de control DNS de nuestro dominio (GoDaddy en mi caso) para dar de alta los correspondientes alias para cada servicio. El proceso es igual que cuando hicimos la verificación de dominio, es decir, añadiendo un registro de tipo CNAME para cada uno de los anteriores, apuntando en este caso a ghs.google.com. Una vez terminado debe quedar similar a esto:

Ahora, dejando propagar los cambios, ya disponemos de nuestro flamante GMail, Calendar, Docs y Sites, accesibles por sus respectivas URLs.

Antes de nada, vamos a dar de alta una cuenta de correo personal. Para ello, aún en el panel de control de nuestro dominio, vamos a "Usuarios y grupos" (en la parte superior). Pulsamos en "Crear un nuevo usuario" y sólo tenemos que completar los datos:

Así de fácil. Ahora sólo falta dirigirnos a la url del correo: http://mail.debugmachine.com y entrar con cualquiera de las dos cuentas creadas:

Y como cabía esperar, aquí tenemos nuestro flamante GMail (y el resto de servicios) con nuestro dominio:

Para poder seguir administrando el dominio y todo su potencial, es necesario volver a entrar al mail, pero esta vez con el usuario "admin" que dimos de alta al principio de todo el proceso. De este modo nos aparecerá un link llamado "administrar este dominio".

Pues por hoy lo dejamos aquí. En la siguientes entregas veremos más cosas interesantes:

Cómo sacar partido al sistema de etiquetas y filtros de Gmail.
Cómo acceder al buzón a través de Outlook, Thunderbird, etc. (usando el protocolo IMAP)
Cómo sincronizar nuestros contactos con los de Gmail
Cómo usar los calendarios de Google y cómo vincularlos a Thunderbird
Cómo usar una libreta de contactos compartida entre miembros, y cómo usar calendarios y buzones compartidos.
Cómo asociar otros nombres de dominio que tengáis para que trabajen como alias del principal con Google Apps.
Cambiar el look & feel de Google Apps para incluir nuestros logotipos y colores corporativos.
Otras muchas cosas...

Mientras tanto os voy dejando digerir esta parte inicial antes de meternos en otras guerras. Espero vuestros comentarios y espero poderos ayudar con cualquier duda que os surja.

Au revoir!

Siguiente >>>>

Alerta phishing en Facebook

2010-03-22T10:06:00.002+01:00

Hola,

me ha sorprendido recibir un mensaje a través de Facebook que provenía de uno de mis contactos, pero cuyo texto estaba escrito en un mal español (mezclado con portugués probablemente).

Se trata de un intento de phishing.

El texto que me ha llegado es:

Mónica Belucci 21 March at 21:31

esta es la tua foto o no?. http://flz914061443265.phototime-15.com/id735rp/
Buena suerte!!!!

Sent via Facebook Mobile

El texto me ha llegado dentro del propio Facebook, lo cuál quiere decir que no proviene de un usuario falso, como suele ocurrir en los e-mails. Según la última línea, podría ser desde un móvil. Eso indica que puede ser un virus de móvil, que los hay, o un troyano desde el equipo infectado de dicho contacto.

Si pincháis en el enlace, os lleva a una página aparentemente idéntica a la de Facebook, pero cuyo dominio es otro externo; ahí os piden vuestro usuario y vuestra password, y por nada del mundo debéis escribirlos o los estaréis entregando al ciberpirata de turno.

En la siguiente captura os muestro la página falsa.

Mucho cuidadín, ¡no caigáis en la trampa!

Besitos.

P.D. Ni que decir tiene que el mensaje no venía de Mónica Belucci, pero entenderéis que no ponga el nombre real de la persona en cuestión.

(Previamente publicado en Misshapen Reality)

Más errores del parser XML de Microsoft (MSXML)

2010-02-23T00:52:00.000+01:00

En mi anterior entrada explicaba un problema bastante común en distintas versiones de Windows (estación y servidor) debido a un fallo en el registro de una DLL relacionada con el motor de parseo XML de Microsoft.

Vimos los problemas más comunes y un sencillo procedimiento para arreglar el problema, consistente en el registro manual de uno o varios archivos DLL.

Pues además, como ya adelantaba, existe una variante de este mismo problema causado por la actualización del MSXML versión 6 de Microsoft en Windows XP con el SP3 o versiones superiores del sistema operativo de Microsoft.

Dicha actualización se produce, por ejemplo, durante la instalación del cliente de Microsoft Dynamics NAV (o lo que antiguamente llamábamos Navision), y más concretamente durante la parte en que se instala el motor de SQL Server 2005 en la misma estación de trabajo.

La razón del fallo es que Microsoft ha protegido ciertos archivos del sistema contra sobreescritura mediante un sistema llamado WFP (Windows File Protection) como medida desesperada para luchar contra el malware y los problemas inherentes a la arquitectura de Windows. El archivo MSXML6R.DLL está incluido dentro de este programa de protección. Y el sistema funciona tan bien, o tan mal, según se mire, que inhibe la sobrescritura de dicho archivo incluso para las propias herramientas de Microsoft.

Por tanto, como ya os imagináis, al llegar al momento de actualizar la MSXML6, el sistema intenta primero desinstalar la actual MSXML6 para reinstalar la nueva versión. La DLL queda "desregistrada", pero la actualización de la misma nunca llega a producirse por el error de escritura. La aplicación se suele dejar terminar de instalar ignorando ese archivo, pero el sistema ya queda "tocado" de muerte con síntomas similares a los descritos en mi anterior artículo.

La vergonzosa respuesta de Microsoft sobre este problema es inconcebible. "Sí, esto es lo que pasa, y si lo quieres bien, y si no, ajo y agua".

La promiscuidad es sana

A pesar del problema, la mayoría de las veces se puede reparar si se vuelve a registrar manualmente de forma similar al artículo anterior, pero con el archivo MSXML6R.DLL, ya que aunque el registro de dicha biblioteca esté defectuoso, el archivo está físicamente en su lugar.

Aún así, una forma de evitar este problema es desactivar el Windows File Protection que provoca tantos quebraderos de cabeza incluso a sus propios autores. Para ello tenemos dos opciones:

Desinstalar temporalmente el SP3; tiene el inconveniente de que es un proceso muy lento y luego hay que volverlo a instalar. Además, no se aconseja si ya se han instalado nuevas actualizaciones o aplicaciones posteriores a la instalación de dicho SP3.
Desinhibir el WFP a partir del siguiente inicio. Implica más reinicios del sistema, pero es más limpio. Para ello hay que cambiar el siguiente valor en el registro (y si no existe, crearlo):

Ruta de la clave: HKLM\Software\Microsoft\Windows NT\Currentversion\Winlogon

Nombre del valor: SFCDisable

Tipo de dato: DWORD

Dato del valor: 0 = Activado (opción por defecto), 1=desactivado (pregunta en el siguiente arranque), 2=desactivado tras reiniciar, 4=activado con avisos desactivados

Lo mejor para nuestro caso particular es ponerlo a 2 y reiniciar el equipo. A partir de ese momento podemos probar la reinstalación. Si ésta vuelve a fallar, entonces lo mejor es ejecutar manualmente la actualización del MSXML versión 6. De esta forma, el instalador del SQL Server 2005 o del Dynamics NAV se saltará este paso al encontrar que la versión instalada es posterior, lo que evitará el problema.

Se puede actualizar manualmente la MSXML6 descargando la actualización de la siguiente ruta:

http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=59914795-60c7-4ebe-828d-f28cb457e6e3

Espero que haya sido de utilidad este truqui, pues por algo tan simple a veces se pueden perder horas o días de trabajo si no se tiene la solución.

Si hay algo que me viene a la mente al pensar en este fallo, es la muerte del loro.

Buenas noches.

PriorityValue	HostName	Goes To Address (Mail Server)	TTL Value
10	@	ASPMX.L.GOOGLE.COM.	1 week
20	@	ALT1.ASPMX.L.GOOGLE.COM.	1 week
30	@	ALT2.ASPMX.L.GOOGLE.COM.	1 week
40	@	ASPMX2.GOOGLEMAIL.COM.	1 week
50	@	ASPMX3.GOOGLEMAIL.COM.	1 week