4 bits blog

No todo en la programación es programar. Además hay que instalar en los servidores de los clientes. Supongo que la mayoría estáis familiarizados con el Terminal Server, un componente de control remoto que viene incluido en Windows y que es lo que en mi caso utilizo masivamente con los servidores de esta plataforma (junto al VNC).

El problema del TS es que utiliza un sistema de sesiones que impide que haya más de 2 sesiones de administrador en el equipo. Si la gente no tiene costumbre de cerrar correctamente su sesión nos podemos encontrar con que no podemos conectar a pesar de que nadie esté trabajando con el servidor remotamente. Pues atención, niños y niñas, que nada es imposible en esta vida. A continuación se lista lo que hay que hacer para desbloquear esas sesiones colgadas (al menos para los que trabajéis con Windows):

1. Abrid un terminal de línea de comandos (Inicio -> ejecutar -> cmd)
2. Ejecutad la siguiente orden (cambiando los valores), pedirá la contraseña del usuario:

   > net use /user:[usuario] \\[ip servidor]\c$

   El 99% de los Windows con los que he trabajado tienen compartido de forma predeterminada todo el disco C a través de C$.

3. Después hay que ejecutar:

   > query session /server:[ip servidor]

   Nunca me ha funcionado así, sino poniendo la ruta completa, esto es, c:\Winnt\system32\dllcache\query ...

4. Mostrará un listado con las sesiones. Habrá que mirar que la que se quiere desconectar no esté activa (esté en Listen, o Disconnected o algo así). Una vez seleccionada la sesión, hay que ejecutar:

   > reset session [ID] /server:[ip servidor]

Voilá. Ya podemos ir a nuestro cliente de Terminal y conectarnos al servidor.

Traducido del original en How-To Geek, donde además os pone capturas de lo que veréis por pantalla, por si a alguno no le ha quedado clara mi espartana explicación.

Para los que programen en C con Visual Studio y sientan añoranza de valgrind, aquí están los pasos sobre cómo detectar fugas de memoria (memory leaks) en Visual Studio:

• Añadir la macro _CRTDBG_MAP_ALLOC del preprocesador, ya sea definiéndola en algún archivo del proyecto o en las opciones de compilación del proyecto.
• Incluir en el siguiente orden stdlib.h y crtdbg.h en los archivos dónde se busquen las fugas de memoria. El archivo crtdgb.h sustituye las funciones malloc y free por unas propias que registran la memoria reservada y liberada.
• Añadir la función _CrtDumpMemoryLeaks () al final del programa en el que se buscan las fugas de memoria. Esta función muestra por la salida de depuración las fugas de memoria detectadas.

Todo esto sólo funcionará cuando el proyecto se compile con la macro _DEBUG definida, es decir, en lo que debería ser para todos la versión de depuración del programa.

La macro _CRTDBG_MAP_ALLOC sirve para que la función _CrtDumpMemoryLeaks () muestre información sobre el archivo y la línea en la que se produjo la fuga de memoria.

Un pequeño ejemplo de cómo quedaría todo:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

int
main (int argc, char *argv[])
{
    /* Código del programa */

    _CrtDumpMemoryLeaks ();

    return 0;
}

Si este programa tuviera alguna fuga de memoria, al compilarlo en modo depuración y ejecutar el depurador de Visual Studio, se obtendría en la salida de éste un listado con las fugas de memoria del programa.

Para más información, leed el artículo Enabling Memory Leak Detection de la MSDN.

Creo que cualquiera que haya tenido que realizar algún tipo de web para un público amplio, ha tenido que lidiar con los problemas que da Internet Explorer (IE) al no cumplir los estándares del W3C.

Pero si encima para rematar la faena te toca insertar un applet, quieres que cumpla con XHTML 1.1 y que se vea en IE, pues acojona un poco al ver que la etiqueta applet dejó de formar parte del estándar hace ya un tiempo.

Sin más dilación, os dejo aquí el código:

<!--[if !IE]>-->
<object id="applet" name="applet" classid="java:es.4bits.applet.Applet"
 type="application/x-java-applet"
 archive="applets/Applet.jar"></object>
<!--<![endif]-->

<!--[if IE]>
<object id="applet" name="applet" code="es.4bits.applet.Applet"
 archive="applets/Applet.jar"></object>
<![endif]-->

Al final, lo único necesario es utilizar los asquerosos hacks de IE, para que no cargue la versión que no entiende de la etiqueta object y cargue la que entiende.

Basado en XHTML Strict Applets.

Hace poco se me ocurrió una forma de aprovechar una memoria USB (o pendrive) antigua (de 256MB) que tenía por ahí. Simplemente, utilizarla para guardar, todo cifrado, un archivo con un listado de contraseñas, documentos personales, claves GPG y/o SSH, …

Así que estuve buscando diferentes opciones, siendo importante que funcionase en Linux y en Windows (por si las moscas). Al final había dos opciones Truecrypt (el archiconocido) y dm-crypt (un gestor de dispositivos cifrados de Linux), me decanté por dm-crypt porque Truecrypt, curiosamente, no está en los repositorios de Debian y porque con dm-crypt no necesitaría de un programa a parte para utilizar mi dispositivo en Linux (aunque sí, en Windows).

Pasos a seguir

Directo al grano, estos son los pasos que realicé:

1. Paquetes necesarios:

   # apt-get install cryptsetup hashalot dmsetup

2. Rellenar la memoria con datos aleatorios (no es necesario, aunque sí recomendable):

   # dd if=/dev/urandom of=/dev/sdX

3. Cargar los siguientes módulos si no lo están ya:

   # modprobe aes
   # modprobe dm_crypt
   # modprobe dm_mod
   # modprobe sha256

4. Crear el contenedor cifrado (pedirá la contraseña para poder luego descifrarlo):

   # cryptsetup -v --key-size 256 luksFormat /dev/sdX NOMBRE-CONTENEDOR

5. Formatear el contenedor (yo utilicé FAT para que funcione en Windows) para ello primero hay que montar el contenedor utilizando cryptsetup:

   # cryptsetup -v luksOpen /dev/sdX NOMBRE-CONTENEDOR
   # mkfs.vfat /dev/mapper/NOMBRE-CONTENEDOR

6. Y ya está, ya se puede montar:

   # mount -t vfat /dev/mapper/NOMBRE-CONTENEDOR /mnt/usb_cifrado

Leer el resto »

Windows System Programming es un libro de introducción a la programación sobre Windows (Win32, aunque hay una breve introducción a Win64), con el lenguaje C.

He de decir que este libro no me ha sorprendido mucho, ya que en cuanto llevas algo de tiempo programando sobre Win32 y visitando la MSDN a menudo, te acabas conociendo las partes más utilizadas. Además, este libro es bastante antiguo (del 2004).

En general, no me convence la forma de explicar los temas por parte del autor, casi todos los capítulos se limita a copiar las diferentes funciones que se utilizan para hacer lo que sea, y a explicar cada uno de sus parámetros. Por lo que el libro se transforma en una especie de resumen de la MSDN.

De todo el contenido del libro me quedaría con los capítulos sobre los servicios de Windows y las estructuras de seguridad (SIDs, ACLs, ACEs) de Windows.

Aún así, puede servir como punto de partida para empezar a programar sobre Windows utilizando Win32, si no fuera por las pegas que he comentado.

Recomendación: Baja.
Nivel: Medio.
Idioma: Inglés.