Un paseo por las nubes : Tips and Tricks

“Path too long” when using local storage in an Azure Cloud Service

David Rodríguez — Tue, 18 Jun 2013 16:29:42 GMT

It is insane that in 2013 we still try to workaround the 260 character limit in a file path, more when the conversations are centered on services, scaling and other meta-cloud philosophies.

But this problem is still here and working with VMs hosted in the cloud is no different, on-premise problems will appear in the same way when online. I would recommend the “Long Paths in .NET” series from Kim Hamilton where this matter is deeply discussed. The post is from more than 6 years ago…and this is not solved yet.

So let’s talk about the problem I had. When using local storage on an Azure web or worker role, the root location for this storage while running on Azure starts with a path that can “eat” almost the half of the MAX_PATH -note that I’m not referring to the problem when playing on DevFabric in your local environment, whose solution is commented on this MSDN blog post. This will be something like:

C:\Resources\Directory\<RoleDeploymentId>.<RoleName>.<LocalStorageName>

As example:

C:\Resources\Directory\5bfa990c7fe730f3a1c7c7b40d249462.MyWebRole.MyLocalStorage

The problem is that the RoleDeploymentId is 32 char length, and if you want to keep some sanity on your role names and storage names you will use something that has some meaning. In my case, the path was “eating” 108 chars, almost the half of the max path. While creating some recursive folders inside that temp path the “Path too long” error will appear sooner than later.

Techniques from the past to solve problems from the past

After playing a little bit with Subst.exe, didn’t convince me because I was trying to keep distance from mounting and managing drives between different user sessions. But then César Abreu give an interesting idea: why not use old style DOS format for the paths?

Interesting approach, so after some reading on the Fsutil.exe documentation on TechNet, I did some tests on a running instance:

1) Enable the short name behavior for volume C:

2) Add a short name to the local storage folder

3) Verify

I finally created a simple two line startup task to be executed with elevated privileges and that would give me an additional 83 characters.

REM Enable short names on volume C:
fsutil.exe 8dot3name set c: 0

REM Add a short name to the local storage folder
fsutil.exe file setshortname "C:\Resources\Directory\%RoleDeploymentID%.MyWebRole.MyLocalStorage" S

The first line enables the short name behavior for volume C:. I noticed that this is enabled for other volumes on an Azure role, but is not enabled by default on C: drive. The second line simply sets the folder short name as “S”. With this I can use then the path “C:\Resources\Directory\S” instead of the long one, and worked like a charm. Note that you can’t do the same for “Resources” and “Directory” folder names, since they are in use during the role startup, and would give you an error while trying to do the operation.

Hope this helps!

Configurando Web Platform Installer y WebDeploy en un Azure WebRole

David Rodríguez — Tue, 02 Oct 2012 18:13:00 GMT

Después de pasarme más de tres días intentando resolver una incidencia al configurar WebDeploy en un Azure WebRole –concretamente añadiendo dicha característica al DNN Azure Accelerator-, no me queda más remedio que documentar y compartir la solución para aliviar el sufrimiento a quien le pueda suceder algo parecido.

¿Para qué WebDeploy?

Web Deploy simplifica el despliegue de aplicaciones y sitios web en servidores IIS. Se puede usar para sincronizar servidores IIS o migrar a nuevas versiones del mismo –por ejemplo, migrar de un entorno on-premise a la nube o viceversa.

Permite realizar operaciones de empaquetado y despliegue de aplicaciones web de una manera sencilla, integrándose perfectamente con herramientas como Visual Studio o WebMatrix para ayudar a los desarrolladores en esta tarea. Se pueden empaquetar tanto contenido de las aplicaciones, configuración, bases de datos y cualquier otro artefacto como entradas en el registro, objetos COM, ensamblados en la GAC etc. pudiéndose parametrizar los valores de configuración según entorno. Una vez empaquetados estos paquetes se pueden utilizar usando una aplicación de comandos de Web Deploy o IIS Manager sin requerir privilegios administrativos.

Con la salida de Web Deploy 3.0, tenemos una serie de interesantes características:

Migración de servidores web desde IIS6 a IIS 7 o IIS 8
Sincronización eficiente de tu granja de servidores
Integración con Visual Studio y WebMatrix
Integración con Web Platform Installer para instalar aplicaciones web de la comunidad
Empaquetado de aplicaciones web, incluyendo las bases de datos asociadas, ACLs, COM, GAC, etc.
Despliegue de aplicaciones web sin requerir permisos administrativos, pudiendo parametrizar la configuración en cada entorno, así como integración con el IIS Web Management Service (WMSVC) para despliegue remoto por usuarios no administradores
Sincronización y migración de servidores web, sincronizando sólo los datos que han sido modificados
Copia de seguridad automática de los sitios web antes de realizar ningún cambio
Acceso a través de IIS Manager, Visual Studio, WebMatrix, línea de comandos, PowerShell Cmdlets y APIs.

¿Por qué en el DNN Azure Accelerator?

Como os podéis imaginar, añadir esta característica al DNN Azure Accelerator va a permitir realizar una serie de tareas administrativas no disponibles hasta ahora. Se me vienen a la mente unas cuantas, aunque por nombrar algunas:

Posibilidad de migrar la instancia de DNN de un IIS a otro. Esto incluye migrar desde on-premise a Azure –ya sea Azure WebSites o PaaS-, de Azure WebSites a Azure PaaS ó viceversa, etc.
Acceder y modificar el contenido del site a través de WebMatrix, ¡sin tener que acceder por RDP a las instancias en Azure ni tener que montar el VHD drive con Azure Connect!
Instalar actualizaciones de DotNetNuke, simplemente desplegando el paquete de upgrade a través de WebDeploy y ejecutando el asistente de actualización
Crear y restaurar copias de seguridad de nuestro sitio

Como véis, son unas buenas razones para añadir esta característica, que estará disponible en la próxima release del asistente de DNN Azure Accelerator –el código ya está disponible en CodePlex por si no quieres esperar al empaquetado.

¿Tres días para añadir esta característica?

No sólo tres días sino además unos 50 despliegues para poner en funcionamiento la misma, debido a había Luna llena en Aries y dos errores muy interesantes.

Pero antes que nada, echemos un vistazo a cómo está implementado. Para añadir esta característica sin disparar una línea de código –sin contar los cambios de interfaz en el asistente de instalación-, el enfoque fue el siguiente:

Añadir un EndPoint en los web roles para permitir el tráfico a través del puerto 8172
Incorporar la aplicación de comandos de Web Platform Installer WebPICMD.exe en una startup task del webrole, para automatizar la instalación de WebDeploy. Esto permite, además de no incrementar el tamaño del paquete de servicio del Accelerator, instalar del mismo modo cualquier otro paquete disponible y que requiera nuestro despliegue, como MVC3, Silverlight, node.js, etc.
Habilitar el servicio de administración remota de IIS en una startup task del webrole

Problema nº1: Web Platform Installer no consigue instalar el paquete de WebDeploy

Tras intentar instalar el paquete de WebDeploy con una instrucción como la siguiente, el webrole se quedaba ciclado por un error en la ejecución de la tarea:

   1: ~dp0WebPICMD.exe /Install /Products:WDeploy /AcceptEULA

Después de añadir los correspondientes logs siguiendo las buenas prácticas, el problema se trataba de que al intentar descomprimir los paquetes de instalación una vez que se han descargado, da un error. Este error es debido a que las tareas elevadas se ejecutan como “NT AUTHORITY\SYSTEM”, cuya carpeta de perfil de usuario se encuentra bajo el directorio “system32”. Esto es especial, ya que en máquinas de 64bits (como todas las VMs de Windows Azure), los procesos de 64bits ven esta carpeta, pero los procesos de 32bits ven la carpeta “SysWOW64). Los paquetes de WebDeploy se descargan en la carpeta “system32” al ser WebPICMD.exe de 64bits, pero algunas dependencias usan un ejecutable auto-extraible de 32bits, dando origen al error descrito.

Para solucionar este error, la única referencia en la web es la de nuestro Ángel de la Guarda Steve Marx en el post “Windows Azure Startup Tasks Tips and Tricks”, donde se da más detalle del mismo.

De este modo, la solución al problema 1 es cambiar en la registry la ubicación de esta carpeta antes de ejecutar la instalación y dejarla como estaba después de la misma. Quedaría de la siguiente forma:

md "%~dp0appdata" 

reg add "hku\.default\software\microsoft\windows\currentversion\explorer\user shell folders" /v "Local AppData" /t REG_EXPAND_SZ /d "%~dp0appdata" /f 

"%~dp0webpicmd" /Install /Products:WDeploy /AcceptEula >>log.txt 2>>err.txt 

reg add "hku\.default\software\microsoft\windows\currentversion\explorer\user shell folders"/v "Local AppData" /t REG_EXPAND_SZ /d %%USERPROFILE%%\AppData\Local /f

La segunda tarea de instalar el servicio de administración remota era muy sencilla, simplemente habilitar esta característica en la VM y arrancar el servicio, no sin antes tocar algún parámetro en el registro de Windows:

start /w ocsetup IIS-ManagementService  

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server /v EnableRemoteManagement /t REG_DWORD /d 1 /f  

net start wmsvc  

Problema nº2: al intentar conectar a través de WebMatrix desde dentro o fuera de la VM, aparece el error “Unable to establish connection”

Este fue muy “gracioso”, por el número de horas que tuve que dedicarle el fin de semana y por los más de otros 30 despliegues más probando otras alternativas. Digo gracioso por cuál fue la solución.

El síntoma era que una vez que las startup tasks realizaron su trabajo (el puerto 8172 abierto, se instaló correctamente WebDeploy y estaba habilitado el servicio IIS Remote Management), al intentar conectar a través de WebMatrix, me aparecía el warning de advertencia de que no confiaba en el certificado del servidor –cosa totalmente correcta-, pero a continuación me aparecía el mensaje “Unable to establish connection”:

El puerto 8172 abierto, las credenciales correctas, el nombre del sitio correcto –nótese que desde esta release el site en IIS se denomina “DotNetNuke”-, la URL correcta y nombre de servidor correctos. ¿Qué fallaba?

Después de intentar ver algo en el visor de sucesos remoto, comenzar a utilizar artillería –PSTools, Fiddler, etc.- nada concluyente. La única información diferente era la otorgada por la aplicación de consola “msdeploy.exe”, devolviendo el código de error “ERROR_DESTINATION_NOT_REACHABLE” seguido de un precioso “404 Not Found”.

Sin más información ni nada interesante tras dos días de búsqueda por foros técnicos, casi da vergüenza comentar la solución.

La solución al problema 2 es simplemente cambiar el orden de las startup tasks, esto es, instalar primero IIS Management Service y a continuación instalar Web Deploy. Parece que al contrario, Web Deploy no se registra correctamente y hay que reinstalarlo.

La conclusión mereció un tweet:

Conclusión

Espero que sirva de ayuda, tanto la nueva característica de WebDeploy en el DNN Azure Accelerator como las soluciones a los problemas encontrados. En breve estará todo empaquetado en una nueva release con muchas novedades aparte de esta.

Un saludo y happy coding!

[Tip] Un huevo de pascua llamado “dnndev.me”

David Rodríguez — Wed, 28 Dec 2011 12:41:00 GMT

Hoy toca compartir una utilidad muy interesante de esas que se encuentran en la red y que nos facilitan la vida a los desarrolladores que trabajamos con entornos web.

¿Conocías el dominio “dnndev.me”?

El dominio dnndev.me es un dominio registrado en Internet por nuestro amigo Ian Robinson que apunta a la dirección de loopback 127.0.0.1. Y no sólo este dominio, sino que cualquier subdominio *.dnndev.me también lo hace.

Para hacer una prueba, abre una consola de comandos y haz un ping a “<loquetedelagana>.dnndev.me” y comprobarás que siempre responde tu dirección local.

¿Y para qué sirve esto?

Pues para personas que como yo, que trabajamos en desarrollo con más de 30 sitios web en el IIS, cada uno con un binding distinto, con diferentes versiones, etc. editar el fichero de hosts (c:\windows\system32\drivers\etc\hosts) se vuelve una tarea muy tediosa.

De esta manera, puedes configurar en tu IIS un binding en el sitio web, por ejemplo, http://miproyecto.dnndev.me en vez de usar http://localhost/miproyecto o editar el fichero de hosts para introducir http://miproyecto.dev

Gracias a Ian Robinson (ver post original) y a Joe Brinkman por su aportación en esta simple y genial idea.

P.D. no es una inocentada!

Happy coding!