¿Por qué tenemos dos claves para acceder al almacenamiento de Azure?

Si has utilizado en producción Windows azure, y en concreto su almacenamiento local para tablas, blobx y colas (Windows Azure Storage), habrás observado que cuando defines una cuenta de almacenamiento dispones de dos claves de seguridad para acceder a las mismas, una primaria y otra secundaria:



¿Por qué hay dos claves, para qué sirven y cómo se relacionan?


La verdad es que es un sistema interesante. Ambas claves son equivalentes y ambas sirven para acceder a la cuenta de almacenamiento, así que podemos utilizar una u otra indistintamente. Generalmente usaremos la primera y la desplegaremos en nuestra aplicación Azure, dentro de sus propiedades de configuración.


Al tener dos claves lo que conseguimos es que no exista ni un segundo de parada de nuestra aplicación si necesitamos cambiarla.


Supongamos que estamos usando la primera clave y alguien nos la roba y tiene acceso también al almacenamiento. ¿Cómo procederíamos para cambiarla y no parar el servicio?


El procedimiento sería el siguiente:



1.- Cambiamos el archivo de configuración de la aplicación Azure para que pasemos a utilizar la segunda de las claves. Este cambio es instantáneo y no es necesario desplegar de nuevo la aplicación. A partir de este momento se está usando la segunda clave y la primera no nos hace falta.


2.- Vamos a la pantalla anterior y pulsamos el botón de regenerar la primera clave. A partir de ese mismo instante la clave anterior queda invalidada y el que nos la haya robado no podrá utilizarla.


3.- Opcionalmente, volvemos a cambiar la configuración para usar la nueva clave primera, aunque no es necesario y podemos quedarnos con la segunda el tiempo que necesitemos, haciendo el procedimiento en sentido inverso si se viese comprometida.


Como vemos este pequeño truco es realmente útil para no interrumpir en ningún momento el funcionamiento de la aplicación Azure, cosa que sí tendríamos que hacer en caso de que sólo existiera una clave.


Espero que lo encuentres útil 🙂

Una reflexión para jefes, responsables, directores… y también para profesionales TIC

Una situación muy común en las empresas cuando les hablas de formación se produce cuando los responsables de RRHH/Equipos/Proyectos te dicen que no forman a su gente porque si lo hacen luego éstos se les marchan a la competencia. Pasa constantemente.


Es cierto que la formación mejora la empleabilidad de la gente. De eso no hay duda. Pero el que se vayan o se queden depende fundamentalmente de que la empresa ponga los medios y -sobre todo- las condiciones para «fidelizar» al empleado, y que por lo tanto éste desee permanecer en ella, porque está motivado, tiene posibilidades de mejorar y sobre todo se sienta realizado en el plano laboral.


Si un trabajador se marcha tras la formación es que ya deseaba irse antes de la formación. Es decir, no existe una relación de causalidad entre formar a una persona y que se quiera marchar de la empresa, como es obvio. Es más, el hecho de que la empresa no les brinde la oportunidad de formarse es una razón más para querer abandonarla, pues no se apuesta por esa persona. Claro que la persona también tiene que ser de una determinada forma, y es este tipo de trabajador al que se debiera apoyar.


En la actual sociedad competitiva y globalizada, donde las barreras de entrada a muchos negocios y actividades se han reducido o, directamente, han desaparecido, las empresas deben saber responder con celeridad a los cambios. Es más, deben en realidad tratar de adelantarse a los cambios y tendencias. En el ámbito tecnológico en el que nos movemos la audiencia de mi blog y yo, la única constante es el cambio.


La verdadera formación continua no sólo se trata del aprendizaje de una determinada disciplina técnica o competencia, sino que implica también «vivir en el mundo», comprender lo que te rodea, estar al tanto de los cambios y tendencias importantes que influyen o influirán a tu trabajo. Sólo de este modo podrán los trabajadores ayudar a su empresa a mejorar, a anticiparse, a ser diferente.


Obviamente esto implica no sólo que la empresa brinde la oportunidad de hacerlo, sino también trabajadores que tengan interés por ello. Estas personas son algo más que trabajadores, son profesionales.


Lo que expongo se aplica a cualquier trabajo que implique la realización de tareas que no sean mecánicas. En el caso de trabajadores de «cuello blanco» -los que se han dado en llamar «trabajadores del conocimiento»- son la práctica totalidad de los puestos.


En el caso concreto de los técnicos TIC esto último es especialmente cierto. El que se haya metido a programador, administrador de sistemas, etc.. pensando en que no se va a formar hasta el fin de sus días está muy equivocado. Sorprende entrevistar a recien titulados en informática que creen que por haber estudiado esta carrera ya saben todo lo que necesitan. También existe otra categoría de informáticos, muy común, cuya única formación es buscar en Internet la solución concreta al problema concreto que tienen en cada momento, pero sin ir más allá. ¿Cuántos programadores conoces que dicen que al terminar su jornada laboral no quieren tocar un ordenador?.


No son precisamente estos últimos aquellos que las empresas deben cuidar y apostar por su formación.


Pienso que las empresas, más que preocuparse porque si forman a los trabajadores éstos se les van a marchar, deberían preocuparse porque si no los forman, a lo mejor, se les quedan. Y esto sí que será un problema a largo plazo 😉


En fin, esta es mi reflexión personal para una tarde domingo lluviosa, sin nada mejor que hacer, y espero que se me haya entendido 🙂


En Krasis buscamos técnico de marketing y comercial ¿sabes de alguien?

Únete a nosotros


En Krasis estamos buscando personas motivadas para incorporarse a nuestro equipo de Marketing:


Técnico de Marketing Formación – Vigo – Enero 2010



El candidato se responsabilizará de las tareas de Marketing del área de Formación. Entre sus tareas estarán:




  • Identificación de posibles clientes


  • Ejecución y seguimiento de campañas de marketing.


  • Análisis de mercado y seguimiento de la competencia.


  • Coordinación de campañas de publicidad.


  • Relación con clientes.


  • Relación con Microsoft y partners.


  • Gestión del presupuesto de MK asignado.

Buscamos a una persona en el área de Vigo, de carácter resolutivo, con experiencia en marketing on-line, buen nivel de inglés y especial gusto por Internet y los medios digitales. Idealmente el candidato provendría del sector y conocería el ámbito de las certificaciones y formación en tecnología Microsoft, pero no es indispensable.

¡Incorporación inmediata!           Escríbenos un email con el asunto «TM_VGO_011309» a

Server.GetLastError no funciona en IIS 7.0 o superior: cómo solucionarlo y un truco general para IIS 7.5

Si llevas unos cuantos años en esto del desarrollo Web seguro que tienes todavía aplicaciones por ahí escritas en ASP 3.0, también conocido como «ASP Clásico». Este precursor del actual ASP era estupendo y funciona de maravilla aún hoy en día. A pesar de todas las virguerías técnicas existentes en la actualidad (que me encantan) me confieso un enamorado de esa antigua plataforma.

El caso es que aún hoy en día, si tienes que montar una aplicación de ASP 3.0 incluso en un moderno Windows Server 2008 R2 con IIS 7.5, podrás hacerlo sin problemas y funcionará todo de maravilla. O casi…

El otro día tuvimos que montar una de nuestras aplicaciones «legacy» en este entorno precisamente y todo parecía ir de maravilla. El caso es que nosotros instrumentamos todas nuestras aplicaciones, incluso  las antiguas, para llevar un registro automático de todos los eventos de interés que se producen: avisos, advertencias, operaciones importantes sobre los datos… y por supuesto los errores no gestionados y por tanto inesperados. Se trata de una buena práctica que deberías seguir en cualquier aplicación, y más en una para Internet y de la cual algunos ya me habréis oído hablar en ponencias por ahí.

En ASP clásico la forma de gestionar los errores inesperados pasa necesariamente por personalizar la página de error para el estátus 500 del servidor Web con una página .asp propia. En ésta se obtiene información sobre el error producido usando el método Server.GetLastError que devuelve un objeto ASPError con todos los detalles.

La configuración en IIS 7.0 o IIS 7.5 se hace de la siguiente forma:

1.- En las propiedades del servidor virtual se va a la sección de páginas de error:

2.- Una vez dentro de ésta aparecen la lista de códigos de estátus HTTP estándar, como por ejemplo el 404 para páginas no encontradas (muy recomendable gestionarlo), el 302 (acceso denegado), o el que nos interesa: 50, error interno del servidor. Sustituimos la página por defecto de IIS para el error 500 y colocamos una página .asp propia. Utilizando el mencionado objeto ASPError podemos obtener información sobre errores que se produzcan, anotar información sobre lo que ha pasado con todo lujo de detalles (error, tipo, ubicación, página, usuario, tipo de navegador…) para luego poder hacer un diagnóstico y detectar problemas. También devolveremos una página más bonita y adecuada para los usuarios, lo cual es muy importante también, y además es una buena práctica de seguridad el no mostrar mensajes detallados de error al usuario final.

No funciona en IIS 7.x

La idea es estupenda y funciona muy bien si lo hacemos en IIS 5.0 o 6.0, ¡pero en IIS 7.x no funcionará!. Es decir, sí que se llamará a nuestra página personalizada, y ésta funcionará. El problema es que el método Server.GetLastError devolverá un objeto con todas sus propiedades vacías, por lo que sabremos que se produce un error pero no tendremos ni un sólo detalle del mismo 🙁

Se trata de un bug reconocido por Microsoft desde IIS 7.0, pero que no ha sido corregido en ninguno de los Service Pack ni tampoco en la versión R2 del sistema operativo (nueva versión 7.5 de IIS). Son los riesgos de usar una tecnología antigua para la que Microsoft no tiene la menor intención de seguir invirtiendo ni un segundo.

¿Cómo lo solucionamos?

Como casi siempre hay una vía de escape para solventar el problema. IIS 7.x dispone de un gestor global de códigos de estado HTTP que se usa cuando no hay uno específicamente designado en la configuración. Resulta que en este gestor global de errores el objeto ASPError sí que se rellena correctamente.

Por lo tanto lo que tenemos que hacer es eliminar el estátus HTTP 500 de la lista de errores gestionados por IIS, para que no tenga asignada ni siquiera la página por defecto. Si editamos la configuración general de este módulo de gestión global de errores:

Nos aparece un diálogo en el que podremos ajustar nuestra página de gestión global:

Allí deberemos introducir una ruta relativa a la raíz de nuestra aplicación (por ejemplo «/Logevents/logerr.asp» como en la figura), y usar en el PathType la opción de «Ejecutar una URL».

De este modo se recibirán perfectamente las propiedades del error y podremos trabajar como siempre 🙂

¡Uppps! IIS me da un error de «violación de bloqueo» (Lock Violation)

Vaya. Cuando ya pensábamos que lo teníamos controlado y podríamos tener nuestra aplicación ASP Clásico funcionando a pleno rendimiento, al pulsar «OK» en el diálogo de la figura anterior nos sale este mensaje:

¿Qué demonios es esto? La verdad es que el mensaje no proporciona demasiada información al respecto. He de confesar que cuando nos salio la primera vez pensé que era un bug de la interfaz de gestión de IIS 7.5, que tenía interbloqueos mal hechos ;-P

A base de indagar y probar, ya que no había información en Internet al respecto y la poca que hay no está bien, llegué a la solución del problema.

Por defecto, hay ciertas secciones de la configuración global de IIS 7.x que están protegidas para impedir la modifiación en sub-ramas del servidor. Esto está diseñado de esta forma pensando en las empresas de hosting, ya que de esta manera pueden bloquear ciertas secciones peligrosas para que los administradores de los sitios web que venden no puedan cambiar ajustes que puedan comprometer la seguridad global del servidor. ¡Bien hecho Microsoft!. Lo malo es que no está nada claro en ningún sitio (o al menos a mi eso me parece), y a más de uno que gestiona sus propios servidores le puede traer por la calle de la amargura. ¡Mal hecho Microsoft! 😉

En nuestro caso lo que debemos hacer es desbloquear este ajuste en la configuración global del servidor para que nos permita cambiarlo en la configuración secundaria de los sitios Web.

Para ello debes ir, como administrador, a la carpeta «C:WindowsSystem32Inetsrv» o equivalente (está ahí incluso en versiones de 64 bits de Windows). Dentro de ésta encontrarás el archivo applicationHost.config. Sácale una copia por si acaso te cargas algo que no debes, y ábrelo con el bloc de notas, ya que es un simple archivo de texto XML.

Una vez abierto busca el nodo «<httpErrors>». Encontrarás una rama que pondrá algo similar a esto:

<httpErrors defaultPath=»» defaultResponseMode=»ExecuteURL»
lockAttributes=»allowAbsolutePathsWhenDelegated,defaultPath»>

La parte importante aquí es el atributo lockAttributes. Como puedes observar, por defecto, tiene bloqueada la modificación de la ruta por defecto para los errores, que es precisamente lo que pretendemos modificar en nuestro sitio web.

Elimina la palabra «defaultPath» del atributo lockAttributes, graba el archivo y ciérralo. Ahora vuelve a IIS y cambia d enuevo la configuración en el diálgoo que hemos visto. Esta vez, al cerrarlo, no te generará la violación de bloqueo, y todos felices.

Este último consejo te valdrá para IIS en general, y por lo tanto para ASP.NET o incluso PHP, y no se restringe sólo a esta sección de la configuración.

Espero que si llegas hasta aquí a través de un búsqueda, desesperado/a por el problema, todo esto te haya servido. Si me lo quieres agradecer puedes dejar un comentario, y también ya sabes 😉

SQL Server: cómo hacer copias de seguridad directamente en unidades de red

Generalmente, lo que más nos interesa a la hora de realizar copias de seguridad es hacerlas hacia alguna máquina o dispositivo especializado de la red local, distintos a la máquina en la que se ejecuta nuestra aplicación o -en nuestro caso concreto- el servidor de datos. Así podremos recuperarlos desde cualquier otra máquina ante cualquier contingencia que surja. En los Data Center (y en muchas oficinas) suelen existir sistemas NAS (Network Attached Storage, almacenamiento en red) cuyo propósito es precisamente albergar las copias de seguridad.


SQL Server, sin embargo, sólo ofrece soporte nativo para realizar copias de seguridad en unidades de disco o dispositvos de backup hardware locales. Esto siempre me ha parecido una seria limitación, ya que hacer copias de seguridad en local no me resulta útil en absoluto. Y tiene muchas limitaciones más (como no comprimir o cifrar las copias), aunque esto es bueno para las empresas que venden herramientas especializadas en ello, como la excelente SQL Backup de Red Gate Software.


Lo que muchos hemos hecho toda la vida ha sido lo siguiente: haces el backup en una carpeta local y programas, un tiempo prudencial después, la ejecución de un archivo .bat que mueva la copia a una unidad de red usando comandos del sistema operativo. Esto funciona pero añade complejidad ya que hay que coordinar ambas acciones y hay más puntos de fallo. Además hay una cuestión adicional que a mi ya me ha ocurrido en servidores viejos: si el disco local no tiene espacio suficiente no puedes hacer copias de seguridad (no te caben), cuando a lo mejor tienes cientos de GB libres en el NAS que no puedes aprovechar 🙁


Lo ideal sería hacer la copia directamente en el NAS sin pasar por el disco local. En este post voy a contar cómo podemos conseguir precisamente esto: hacer backups de SQL Server directamente a la red. Además cuento cómo conseguir un backup diario, con un archivo para día de la semana, que se van sobrescribiendo automáticamente, por lo que conseguimos de manera sencilla una retención de 7 días.


Las instrucciones que doy a continuación funcionan con SQL Server 2005 y 2008, y las he sacado a base de prueba y fallo durante bastante tiempo. No he encontrado en Internet instrucciones algunas que contemplen esta operación por completo, sobre todo en lo referente a los pequeños detalles (como la seguridad) que hacen que llegue a funcionar.


1.- Cuenta de ejecución de SQL Server


Lo primero que tenemos que hacer es asegurarnos de que nuestro sistema SQL Server va a tener acceso a la red local. Tanto el motor de bases de datos como el agente de SQL Server se ejecutan suplantando a un determinado usuario del sistema operativo. Mucha gente instala SQL Server para que sus servicios se ejecuten bajo la cuenta de sistema, ya que ésta tiene acceso a cualquier recurso del sistema local, y simplifica la gestión. Esto, aparte de un posible problema de seguridad (en el que no voy a entrar), no es necesario en absoluto. Además hay una cuestión fundamental: la cuenta de sistema no tiene capacidades para acceder a la red. Por lo tanto si nuestro servidor de datos se ejecuta bajo System no podremos realizar copias de seguridad a unidades de red.


La cuenta recomendada para ejecutar SQL Server y conseguir acceso a la red es «Servico de Red» (o, en inglés, «Network Service»). Esta cuenta tiene los permisos suficientes para ejecutar SQL Server sin problema y además nos sirve para nuestro propósito. Lo podemos cambiar desde la configuración de Servicios de SQL Server, en las propiedades de cada servicio:



Si las copias de seguridad las vamos a hacer escribiendo el comando desde el SQL Management Studio, esta cuenta debemos asignarla al motor de SQL Server. Si, como es más común, las copias de seguridad serán automatizadas con el agente de SQL Server, es este servicio el que debe ejecutarse con esta cuenta. En cualquier caso (y sin ser especialista en absoluto en SQL Server), mi recomendación sería que pusiésemos ambos servicios a ejecutarse bajo esta cuenta.


2.- Creación de la cuenta para acceso a la red


Una cosa es la cuenta bajo la que se ejecuta el servidor y otra es la cuenta que usaremos para acceder al recurso de red. Tendrá que ser un usuario que tenga permisos de lectura y escritura en la carpeta compartida en la que queremos escribir el backup. Si no estamos bajo un mismo dominio de Directorio Activo -es decir, utilizamos usuarios diferentes para cada máquina- debemos crear en nuestra máquina local (en la que se ejecuta SQL Server) una cuenta de usuario con el mismo nombre y clave que el que usaremos para acceder a dicho recurso. Por ejemplo, si el NAS tiene un usuario llamado «NASBackup» con clave «backup», deberemos crear también en local este mismo usuario. Cuando accedemos interactivamente desde el explorador de Windows al recurso remoto podemos escribir el usuario y la clave en la ventan que aparece, pero con el Script SQL que usaremos aquí, o disponemos del usuario también en local, o no funcionará. El motivo no lo tengo muy claro, pero es así 🙁


3.-Habilitar el comando xp_cmdshell


Este comando permite ejecutar comandos del sistema operativo desde scripts T-SQL. Vamos a necesitarlo para habilitar el acceso a los recursos remotos. Por defecto viene desactivado y no podremos usarlo, ya que reviste bastante peligro, puesto que otorga acceso a comandos del sistema que pueden ser muy peligrosos (como formatear el disco duro, por ejemplo). En SQL Serevr 2000 venía habilitado por defecto y las aplicaciones con problemas de seguridad debidas a inyeción SQL y ejecutadas bajo cuentas con demasiados privilegios eran una coladera, por eso en la versión 2005 y posteriores se ha deshabilitado por omisión.


En nuestro caso lo necesitaremos, así que tenemos que habilitarlo. Para ello debemos lanzar las siguientes instrucciones T-SQL desde SQL Management Studio:


— Permitir el cambio de opciones avanzadas de SQL Server
EXEC sp_configure ‘show advanced options’, 1
GO
— Reconfigurar para que permita modificarlas.
RECONFIGURE
GO
— Habilitar la característica xp_cmdshell
EXEC sp_configure ‘xp_cmdshell’, 1
GO
— Refrescar para que el cambio surta efecto
RECONFIGURE
GO

Ya está.


4.- Programar la copia de seguridad


Ahora ya tenemos las bases necesarias para que esto funcione, así que lo único que nos resta es crear una nueva tarea del agente SQL que se encargue de realizar la copia de seguridad. En el apartado de «pasos de la tarea» crearemos un nuevo paso con las siguientes instrucciones T-SQL:


SET LANGUAGE us_english
exec xp_cmdshell ‘net use \192.168.1.1backupsSQL clave /user:backup’
DECLARE @Archivo AS nvarchar(100)
SET @Archivo = N‘\192.168.1.1BackupsSQLMiBaseDeDatos_’ + DATENAME(WEEKDAY, GETDATE()) + ‘.bak’
BACKUP DATABASE [MiBaseDeDatos] TO DISK = @Archivo WITH NOFORMAT, INIT,
NAME = N‘MiBaseDeDatos-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10;
exec xp_cmdshell ‘net use \192.168.1.1BackupsSQL /D’

Lo que estamos haciendo es poner el lenguaje actual en inglés. Yo suelo usar siempre el inglés para todo y tengo los sistemas en este idioma porque considero que tiene muchas ventajas pero tú, claro está, puedes usar el idioma que prefieras. El hecho de establecer el idioma es para asegurarnos de que si transportamos el Script a otro servidor diferente los nombres de los archivos de copia de seguridad van a tener nombres consistentes, ya que usaremos el nombre del día de la semana para crear un archivo .bak cada día (lunes, martes, y así sucesivamente).


El comando xp_cmdshell de la segunda línea habilita la conexión a la carpeta de red backupsSQL que está en nuestro NAS, con dirección IP 192.168.1.1. Podríamos haber usado el nombre de red (por ejemplo \NAS o similar), pero con la IP nos aseguramos de que siempre va a funcionar, pues lo otro a veces he detectado que da problemas. En esta línea, por tanto, debes poner la ruta de red que queires usar e indicar la clave y nombre de usuario que usaremos para acceder (ver paso 2).


Las dos siguientes líneas declaran el nombre y la ruta del archivo de backup que vamos a crear. Lo que yo hago aquí es ponerle como sufijo el nombre del día de la semana en inglés, de forma que se me crean copias de seguridad diarias con el nombre «MiBaseDeDatos_Monday.bak», «MiBaseDeDatos_Tuesday.bak», y así sucesivamente. Con esto consigo tener una copia completa cada día de la semana, con una retención de 7 días, que se va sobrescribiendo automáticamente cuando pasa una semana. Para mi esto es más que suficiente, pero si quisieras más retención o más de una copia diaria al día tendrías que buscar una forma alternativa para nombrar los archivos.


La siguiente línea es una instrucción T-SQL normal y corriente para crear una copia de seguridad, sólo que en este caso ya se hará directamente sobre la carpeta de red, y no en local, que es lo que deseábamos.


Finalmente con xp_cmdshell, nos desconectamos del recurso de red. Esto es necesario para que no queden conexiones abiertas y nos impidan volver a reconectar en sucesivas ocasiones.


Espero que te resulte útil y que mis horas de prueba y error te ahorren a ti mucho tiempo. Si me loquieres agradecedr, ya sabes, matricúlate en alguno de nuestros cursos o compra alguno de nuestros libros 😉