Hoy uno rápido...

Muchas veces tenemos que descargarnos archivos de Windows Installer, con extensión .msi, que contienen las aplicaciones que deseamos instalar. Pero si sabemos que las aplicaciones contenidas en su intereior no necesitan instalación, sino que pueden ser utilizadas directamente ¿para qué vamos a instalar usando el .msi?

Es más, a veces Microsoft se empeña en meter en este tipo de archivos de instalación cosas que realmente no necesitan ser instaladas en absoluto. Por ejemplo, archivos de tipo .chm con documentación (me ha ocurrido en diversas ocasiones), o ejecutables escritos en C++ sin ningún tipo de dependencia, o los ejemplos de MSDN Magazine sin ir más lejos.

A mi me resulta muy útil poder extraer de dentro del MSI los archivos sin necesidad de instalarlos y sin que quede registrada en el sistema la instalación. Para ello podemos usar el propio Windows Installer desde la línea de comandos.

Lo que debemos hacer es abrir la línea de comandos como administradores:

y una vez allí escribimos:

msiexec /a "Ruta archivo .msi" /qb targetdir="Ruta a una carpeta donde extraer"

¡Listo! Encontrarás todos los contenidos expandidos y ordenados dentro de la carpeta de destino.

Existen una serie de ajustes en aplicaciones Web que deberíamos cuidar especialmente cuando las despleguemos en un servidor en producción. Se trata de características que, de estar mal establecidas en un servidor abierto a cualquiera a través de Internet, pueden suponer un problema de seguridad o mermar el rendimiento de una aplicación.

En este artículo vamos a estudiar dos de estos ajustes críticos, lo que suelen hacer mal los programadores con ellos y cómo podemos forzar su correcto uso en servidores de producción.

Depuración

Cuando estamos desarrollando una aplicación Web con ASP.NET (tanto Web Forms como MVC) establecemos una serie de configuraciones que nos facilitan la depuración de las mismas: mensajes de error detallados, depuración paso a paso, trazas del código, etc…

Existe un ajuste en la configuración de la aplicación Web (archivo web.config) que controla de manera global el estado de depuración y, por tanto, todas estas características:

<compilation debug=”true”/>

Es más, cuando lanzamos por primera vez una aplicación Web desde Visual Studio pulsando F5, se nos muestra una ventana de confirmación para establecer de manera automática este ajuste y que funcionen todas las características de depuración:

Al aceptar la opción por defecto se establece este ajuste automáticamente por nosotros:

Aunque está muy bien mientras desarrollamos, se trata de algo inaceptable en un servidor en producción, una vez que la aplicación está terminada y puesta a funcionar en su ubicación definitiva.

El principal motivo para desaconsejar el ajuste debug=true en producción es que obtendremos menos rendimiento en la aplicación, ya que el código de depuración generado es menos eficiente.

Es muy habitual que los desarrolladores se olviden de desactivar la depuración en el web.config antes de subir la aplicación al servidor.

Detalles de los errores

Otro ajuste que es frecuente encontrarse mal establecido es el relativo a los mensajes detallados de error. Si colocamos el ajuste:

<customErrors mode="On">

en la configuración, siempre que se produzca un error no controlado se mostrarán los detalles a través de la típica “página amarilla de la muerte” (YSOD), que es como se conoce a las habituales páginas de error de ASP.NET.

JAMÁS debemos dejar que nuestras aplicaciones muestren los detalles de los errores a los usuarios. Aparte de denotar dejadez por parte de los programadores y falta de calidad de las aplicaciones,  a los usuarios tampoco les van a decir nada. Pero es que además mostrar esa información detallada de los errores revela multitud de información sobre cómo están hechas las aplicaciones e incluso, en casos extremos de chapuza, pueden revelar claves, estructuras de directorios, estructuras de bases de datos, etc… Esto proporciona información importante a posibles asaltantes de nuestro servidor, que pueden usarla para atacar nuestra aplicación.

Sin rodeos: mostrar detalles de los errores es una de las peores prácticas de seguridad universalmente reconocidas.

Una vez más, suele ser habitual que los desarrolladores suban aplicaciones a producción con este ajuste establecido.

¿Cómo podemos evitar estas malas prácticas?

Si somos responsables de algún servidor Web en producción sería muy conveniente que pudiésemos forzar de algún modo que los programadores cumplieran las buenas prácticas.

Esto es lo que podemos conseguir usando un ajuste poco conocido: <deployment retail>

Este ajuste sólo se puede indicar en la configuración global del servidor, es decir, en el archivo machine.config ubicado en C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config o similar (vale también para la versión 2.0 o superior de .NET).

Si abrimos este archivo y buscamos la sección “configuration•system.web” podemos establecer dicho atributo a true así:

<configuration>
    <system.web>
        <deployment retail=”true”/>
    </system.web>
</configuration>

Al hacerlo, da exactamente igual que el programador se haya olvidado de quitar el debug=true, las trazas o las páginas de error detalladas, ya que este ajuste prevalece sobre los locales de nuestra aplicación y deshabilita todas estas funciones.

Además, si vemos su definición en el mismo archivo machine.config, vemos que tiene establecido el atributo AllowDefinition=”MachineOnly”:

Esto significa que no podrá ser sobrescrito por configuraciones en niveles inferiores, es decir, que aunque algún programador intentase saltárselo poniendo lo mismo (pero a false) en el web.config, recibiría un error indicándole que no se puede sobrescribir e impediría que la aplicación funcionase.

Por todo ello, este poco conocido pero importante ajuste es algo que todos deberíamos asegurarnos de utilizar en los servidores que tengamos en producción.

¡Espero que te resulte útil!

La verdad es que estoy encantado con mi eeePC siempre teniendo en cuenta las limitaciones de este tipo de chismes pequeños que son los Netbooks, y es que valen para cuando estás de viaje pero no esperes tenerlos como sistema principal. Lo malo de los eeePC de Asus (y en general de Asus) es que aunque es una buena marca el soporte y la documentación dejan bastante que desear. La página de soporte siempre está caída o te dice que tiene demasiadas conexiones y generalmente te cuesta muchísimos intentos el poder acceder a ella y descargarte algo. Y una vez lo consigues las indicaciones son mínimas.

Por ejemplo, la actualización d ela BIOS que quise hacer hoy mismo por un problema que tengo con la batería (y que, por cierto, no me ha solucionado). Vas a la página de descargas de ASUS, encuentras las actualizaciones de las BIOS, te bajas la última y ¿ahora qué?

No hay instrucciones de ningún tipo y en el manual que trae el equipo no aparece nada al respecto (o al menos no lo he visto), así que te encuentras con un archivo ZIP que contiene un .ROM dentro que no sabes qué hacer con él.

Las instrucciones para poder actualizar la BIOS son las siguientes:

1.- Pincha a tu ordenador una llave USB. Formateala como FAT16. ¡Ojo! FAT32 no te servirá.
2.- Descomprime dentro de la llave USB el contenido del ZIP que te has descargado.
3.- Renombra el archivo .rom que se crea y ponle el número exacto del modelo de eeePC que tengas. Por ejemplo, el mío es un 901, así que 901.rom, pero podría ser 900.rom, 1000.rom, etc... Es importante hacerlo así o no te lo encontrará.
4.- Arranca el eeePC con la lave USB pinchada en cualquier puerto. Nada más encenderlo pulsa ALT+F2. Si ves que no te lo pilla reinicia y pulsa esta combinación varias veces.
5.- Ahora se lanzará la utilidad de actualización de la BIOS, la cual encontrará el archivo .rom y efectuará, sin preguntarte, la actualización. Asegúrate de tener pinchado el equipo a la corriente no vaya a ser que se interrumpa el proceso a la mitad y te quedes con él en un estado inutilizable.

La verdad es que podían documentarlo un poco mejor, al menos introduciendo un TXT explicativo junto con el ZIP que te descargas y que tiene la BIOS nueva dentro ¿no?

Espero que a más de uno le pueda servir para no perder el tiempo buscándose la vida con esto.

Saludos!

Si has actualizado tu sistema a Windows 7 desde Windows Vista, es posible que en ciertos escenarios concretos se produzca un problema que fuerce el sistema a estar reiniciándose constantemente. Microsoft no ha dado detalles de en qué condiciones ocurre, aunque serán casos excepcionales.

Lo que pasa es que, tras instalar Windows 7 sobre Vista te sale un mensaje que dice "Esta versión de Windows no ha podido ser instalada. Tu anterior versión de Windows se ha restaurado y puedes continuar usándola". Entonces se reinicia el sistema y lo que pasa realmente es que se reinicia la instalación y sale el mismo mensaje, atrapándote en una espiral infernal.

Al parecer Vista sí está realmente restaurado en el equipo, pero la base de datos de configuración de arranque del sistema (BCD, Boot Configuration Database) está mal actualizada y por eso sigue intentando restaurarlo.

La solución es manual y pasa or hacer lo siguiente:

1.- Introducir el DVD de Windows Vista con el que instalaste el sistema inicial y salir de la instalación de Vista cuando comience.

2.- Ejecutar la línea de comandos como administrador.

3.- Ejecutar esta instrucción:  D:\boot\BootSec.exe /NT60 All   (sustituye D: por la unidad en la que esté el CD de instalación de Vista)

4.- Reiniciar

Con esto se soluciona el problema y puedes seguir utilizando Vista. Acto seguido yo instalaría Windows 7 desde cero. Merece mucho la pena el nuevo sistema.

Espero que a alguien le pueda ayudar.

ACLARACIÓN: esto no me ha ocurrido a mi ni tampoco sé de nadie a quien le haya ocurrido tampoco. Lo he encontrado de casualidad por ahí y me he hecho eco simplemente.

En el post que escribí hace unos días sobre cómo solucionar el problema de los menús de ASP.NET en IE8, comenté que en un futuro post explicaría cómo forzar desde nuestra aplicación que la gente que acceda a la misma con Internet Explorer 8.0 la vea en modo de compatibilidad con Internet Explorer 7.0. Esto es de especial importancia para nosotros si nuestra aplicación no se visualiza bien según los estándares estrictos de CSS 2.1 pero no tenía problemas con la versión anterior de IE.

Dado que, como comentaba en el anterior post, no podemos confiar en que los usuarios vayan a pulsar el botón de compatibilidad si la página se ve mal (simplemente semarcharán o si tenemos mucha suerte intentarán usar Firefox), lo mejor que podemos hacer es forzar de manera transparente para ellos esa compatibilidad.

Para ello disponemos de varias técnicas:

1.- Usar una etiqueta META especial en nuestra página

Si incluimos la siguiente etiqueta META en la cabecera de nuestra página podremos conseguir que el navegador de forma automática y transparente para el usuario utilice el modo de compatibilidad:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>

Ya está. Con esto conseguiremos que, incluso, el agente de usuario del navegador sea como el de IE7, es decir, a todos los efectos el navegador se hará pasar por IE7.

2.- Etiqueta META en todas las páginas

Lo anterior está genial si son una o dos páginas las que presentan problemas. Sin embargo en un sitio Web grande, con decenas o cientos de páginas la cosa ya no es tan interesante pues habría que ir una a una poniendo la cabecera. Para estos casos podemos obligar a que sea la propia infrastructura de ASP.NET la que fuerce la inclusión de la etiqueta en cada una de las páginas. Para ello necesitamos modificar el nodo <system.webServer> dentro del archivo de configuración web.config de nuestra aplicación, así:

El nodo httpProtocol nos permite añadir cabeceras propias a todas las páginas, así como cabeceras de redirección. En este caso añadimos una cabecera normal con la pareja nombre-valor necesaria para forzar la emulación en IE8. Es equivalente a poner en todas las páginas la cabecera META anterior.

3.- Forzar la cabecera de compatibilidad en el servidor

Si quieres forzar que todas las aplicaciones de tu servidor fuercen el modo de compatibilidad, sin tener que ir por cada web.config haciendo lo anterior, puedes incluir dicha cabecera de forma sencilla tanto en IIS 6 como IIS7.

En IIS6 basta con ir a las propiedades de un sitio Web y una vez ahí a la pestaña encabezados:

En IIS 7 es más fácil aún pues se puede establecer para el servidor completo así:

¡Listo!

Si eres de los que programa aplicaciones Web en ASP.NET para Linux o Mac usando Mono, puedes encontrar una guía de la propia Microsoft sobre cómo configurar las cabeceras de compatibilidad para IE8 en Apache.

Algunos detalles más

1.- ¿Y si quiero que ocurra todo lo contrario? Es decir, quiero que siempre se use el modo de compatibilidad total con estándares (es decir modo IE8) aunque el usuario pulse tenga configurado mi dominio para compatibilidad con IE7. Pues se puede hacer lo mismo que he dicho antes pero con esta otra pareja de nombre-valor en una cabecera:

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

2.- ¿Cómo distingo que el navegador que me visita es en realidad Internet Explorer 8 en compatibilidad con IE7?. Claro, la pregunta tiene lógica ya que si hasta el agente de usuario se modifica para reflejar que es IE7, ¿cómo hago? Lo puedo necesitar para estadísticas o lo que sea...

Cuando IE8 hace una petición a una página en modo compatibilidad esta es la cadena que usa como agente de usuario (la real en mi propio equipo)

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022; OfficeLiveConnector.1.1; .NET CLR 3.5.30729; .NET CLR 3.0.30618;

Lo importante a destacar aquí es lo que está en negrita. El fragmento inicial, hasta MSIE 7.0, es lo que indica que es IE7 quien solicita la página. No se distinguiría de una petición hecha con el IE7 real (de hecho en IE8 sólo cambia ese número y pondría MSIE 8.0). Lo que la distingue realmente del IE7 real es la otra negrita de arriba: Trident/4.0.

Trident es el nombre del motor de renderizado de páginas de Internet Explorer 8.0, siendo 4.0 su versión. Si buscamos la palabra Trident sabremos que el navegador es realmente IE8.

¡Espero que te resulte útil!