Cuando manejas varios servidores Windows lo habitual es conectarse a través de escritorio remoto a éstos para gestionarlos. Con la propia licencia de Windows se incluye gratis la posibilidad de conectarse en remoto con usuarios que pertenezcan al rol de "Administradores" (un máximo de 2 a la vez) para poder gestionar la máquina como si estuviésemos sentados delante de ella. Esto mismo vale para las versiones cliente de Windows (como Windows 7 o Windows 8), así que yo por ejemplo me suelo conectar constantemente a mi equipo de sobremesa de la oficina cuando estoy de viaje o desde casa. Es cuestión de abrir un puerto en el cortafuegos y poco más. Las conexiones son encriptadas, es fácil de securizar y es un protocolo estable, sólido y con relativamente pocos problemas de seguridad.

Cuando te conectas mediante escritorio remoto a una máquina solo tienes dos opciones para dejar la sesión actual: desconectarte (que es lo mismo que cerrar la ventana del escritorio remoto) o cerrar la sesión.

No se ofrecen las opciones habituales de reiniciar y apagar el equipo, ponerlo en modo "sleep" y similares.

El motivo supongo que es que no apagues por error una máquina remota y que pierdas el acceso a la misma. Y es que si no hay nadie para reiniciarla tienes un problema grave.

Sin embargo existen muchas ocasiones en las que forzar un reinicio (o incluso un apagado) puedes estar justificado y ser necesario. ¿Cómo podemos hacer en estos casos?

Por suerte para nosotros, en el sistema operativo se incluye una utilidad para hacer precisamente eso.

…SIGUE LEYENDO…

Los caminos de Windows, a veces, son inescrutables.

En ocasiones, sin saber por qué, en un servidor en producción un proceso empieza a "comerse" todos los recursos del procesador y no tenemos idea de a qué se puede deber (una actualización, un driver, un programa nuestro que se ha desbocado…). Y lo que es peor: si se trata de algún servicio del sistema lo tenemos más difícil pues todos los procesos de ese estilo se llaman igual: svchost.exe.

svchost.exe es un proceso genérico del sistema que sirve para ejecutar DLLs de Windows. Generalmente contienen servicios. Además para evitar que la caída de un servicio afecte a todo el sistema se lanza un svchost.exe por cada grupo de servicios relacionados. Así, por ejemplo, todos los que tienen que ver con servicios de red van en uno, con seguridad en otro, con IIS en otro, etc…

¿Cómo podemos averiguar cuál es el verdadero servicio que nos está causando el problema?

Existen varias maneras…

SIGUE LEYENDO el artículo completo en JASoft.org…

La semana pasada explicaba en un post qué era SNI (Server Name Indication) y cómo podíamos sacarle partido en Internet Information Server 8.0 para albergar varios certificados SSL/TSL en una misma IP, y restringir a dicha IP el acceso solo desde los dominios apropiados.

En teoría en IIS 7.x bajo Windows Server 2008 o 2008 R2, no está disponible esta opción, al menos no para certificados SSL normales.

Sin embargo, si vamos a las propiedades de un "binding" para HTTPS, vemos que dispone de un cuadro de texto para el nombre de dominio, similar al de IIS 8.0, pero que está deshabilitado:

Así que parece que, aunque esté deshabilitado, algún tipo de soporte debe de haber para usar SNI en IIS 7.x ¿no?

Bien, el caso es que IIS 7.0 soporte SNI con certificados SSL de tipo wildcard, es decir, aquellos que son capaces de soportar múltiples subdominios de un mismo dominio con el mismo certificado. Este tipo de certificados se asocian a dominios de tipo *.midominio.com. Es decir, cualquier cosa delante del punto del dominio de segundo nivel (ver post anterior para más información).

De hecho si disponemos de uno de estos dominios wildcard y lo asignamos a un "binding" de un servidor web virtual, veremos que la casilla se habilita y podemos escribir el nombre del subdominio que queramos sin problema.

¿Cómo sacar partido a SNI con cualquier certificado normal?

Existen formas de asignar nombres de dominio con certificados usando herramientas de línea de comandos. Pero en este post me voy a centrar en cómo lograrlo desde la interfaz de usuario.

… SIGUE LEYENDO …

Cuando un navegador se conecta a un servidor web usando el protocolo comúnmente conocido como SSL (Secure Sockets Layer, de manera más formal SSL/TLS: Transport Layer Security), las comunicaciones se cifran entre ambos con el triple objeto de:

• Evitar que se puedan inspeccionar (cifrado)
• Evitar que se puedan modificar (no repudio)
• Autenticar al servidor, y opcionalmente al cliente, aunque no es lo habitual (autenticación).

El handsahe de TLS se produce antes de que se intercambien cabeceras algunas entre cliente y servidor. Es decir, que en la comunicación que se inicia todo el tráfico va encriptado, incluso las propias peticiones, lo cual incluye el propio nombre de dominio al que nos conectamos. Esto presenta una dificultad para el servidor ya que hasta que recibe la petición y la descifra no sabe a qué dominio nos queremos conectar, pero si no lo sabe ¿cómo sabe qué certificado debe utilizar?

La respuesta tradicional a este problema ha sido que cada certificado SSL estuviese asignado a una única dirección IP. De este modo, según la dirección IP a la que se estuviese realizando la llamada, el servidor podría saber perfectamente qué certificado le correspondía, usar su clave privada para descifrar la petición inicial e iniciar el proceso de comunicación.

Esta solución, aunque válida, tenía varias pegas importantes, pero sobre todo estas dos:

1. Si hay más de un dominio albergado en la misma IP, cualquier conexión a dicha IP a través e otros dominios no asociados al mismo certificado SSL generarían un aviso de seguridad por parte del navegador. El motivo es que se recibe la petición, se atiende con el certificado asociado a la IP, pero el nombre de dominio solicitado y el del certificado no coinciden.
2. Si queríamos usar más de un certificado SSL en un servidor teníamos que disponer como mínimo de tantas direcciones IPs como certificados, lo cual encarece y complica la gestión del servidor. Además es un impedimento enorme para las empresas de hosting.

Para tratar de solucionar estas pegas se definieron unas extensiones al protocolo SSL/TSL llamadas Server Name Indication o SNI. Lo que hacen es que incluyen el nombre del dominio como parte de la negociación inicial (o handshake) de SSL/TSL. Esto permite al servidor saber cuál es el dominio al que nos queremos conectar y utilizar así el certificado apropiado. Gracias a estas extensiones los problemas mencionados anteriormente se pueden solventar de un plumazo.

Además permite la utilización de certificados SSL de tipo "wildcard", es decir, que sirven para cualquier subdominio de un dominio dado. Podemos comprar un certificado de tipo *.dominio.com y que sirva para cualquier subdominio de éste: subdom.dominio.com, otro.dominio.com, etc… lo cual puede ser muy útil (por cierto, estos certificados wildcard son mucho más caros que los normales).

Es más, en teoría con SNI podríamos tener un certificado SSL asociado a múltiples dominios diferentes a la vez, aunque en la práctica no se utilizan por la dificultad de gestión (por ejemplo, habría que anular el certificado y crear uno nuevo ante cualquier cambio en la lista de dominios).

…SIGUE LEYENDO PARA:

• Saber qué soporte hay para SNI
• Aprender a configurarlo en IIS 8.0

A raíz de un artículo que escribí hace ya un tiempo en el que explicaba cómo crear enlaces de descarga directa para archivos de Google Drive o de OneDrive, un lector me preguntaba si se podría utilizar alguna técnica similar para poder embeber vídeos subidos a OneDrive en una página propia, albergada fuera de los servidores de Microsoft.

Me decía que si ponía una etiqueta iframe apuntando a la URL que yo indicaba cómo generar, que se mostraba la páginad e OneDrive, pero no se veía el vídeo. Claro, lógicamente, porque si haces eso estás simplemente enlazando con la página de OneDrive que visualiza el vídeo, pero no estás visualizando el vídeo en sí.

En OneDrive, al seleccionar un archivo de tipo Office (Excel, Word o PowerPoint), una de las opciones que te proporciona, aparte de compartirlo, es embeberlo. Por ejemplo, en esta imagen tengo seleccionada una hoja de cálculo de Microsoft Excel, y me permite generar el código para embeberla en cualquier página externa:

Por el contrario, no permite embeber vídeos en páginas externas y no ofrece esa opción "Embed" en el caso de un vídeo.

Así que de entrada la respuesta es que no se puede.

Sin embargo, pensé que seguramente no sería tan difícil "hackear" un poco OneDrive para permitir usarlo como repositorio externo de vídeos que podamos usar en otras páginas. Y realmente se puede conseguir, aunque con algunas limitaciones.

Vamos a ver el proceso, y luego las limitaciones que tiene…

… SIGUE LEYENDO EN JASoft.org…

Todo programador que se precie utiliza para desarrollar algún sistema de control de código de fuente (no te engañes: aunque no trabajes en equipo es indispensable usar un sistema de estos). Entre los más conocidos están Apache Subversion/SVN, que es un sistema centralizado, y Mercurial o Git, dentro de la categoría de sistemas distribuidos (DVCS: Distributed Version Control Systems).

Sea cual sea el que uses, para los más conocidos existe una colección de aplicaciones llamadas TortoiseXXX que sirven para integrar de manera fácil este tipo de soluciones dentro del explorador de archivos de Windows. Así, tenemos TortoiseSVN para Subversion, TortoiseHg para Mercurial y TortoiseGit para Git.

Todos tienen un aspecto y funcionalidad muy similar (ya que parten del mismo código base) y lo que hacen básicamente dos cosas:

• Añaden un menú contextual a las carpetas de tu sistema de modo que puedas gestionar repositorios de código de manera sencilla:

  

• Muestran el estado de cada archivo que esté bajo control de código mediante el uso de iconos superpuestos sobre el icono normal de un archivo o carpeta, indicando si está cambiado, ya respaldado, con conflictos, etc…:

  

De este modo, es realmente fácil gestionar cualquiera de estos sistemas de control de código sin necesidad de recurrir a la línea de comandos ni a otras herramientas especiales.

Gracias a ello y a que son gratuitas y Open Source, Tortoise es una de las herramientas más populares para trabajo con sistemas de control de código fuente.

Un problema habitual que suele ocurrir, sobre todo si usas Dropbox, es que los iconos de esta de carpetas y archivos no funcionen.

El motivo es que otras aplicaciones que también superponen sus iconos en otras carpetas del sistema, y a veces por cuestión de orden pueden interaccionar.

Si no se muestran los iconos superpuestos y por lo tanto no sabes en qué estado están tus repositorios, prueba a hacer lo siguiente:

…SIGUE LEYENDO…

Aunque hayamos diseñado nuestra aplicación web con el máximo cuidado y tratando de que esté lo más optimizada posible, si tiene éxito y acaba creciendo mucho en cuanto a necesidades de atender usuarios y peticiones, llegará un momento en el que no de más de si y sea necesario hacerla crecer.

Una aplicación que reciba simplemente unas pocas peticiones por segundo va a funcionar sin problema en cualquier servidor barato, pero si el número de peticiones crece y necesitamos atender a decenas, cientos o miles de peticiones por segundo es el momento de pensar en la escalabilidad y el crecimiento.

La escalabilidad de un sistema informático se define como la capacidad de éste para expandirse según las necesidades que se deriven del uso que se le va a dar. De este modo decimos que una aplicación web es escalable si es capaz atender a un número cada vez mayor de usuarios sin necesidad de cambiar el código de la aplicación.

Fundamentalmente existen dos maneras de escalar:

• Escalado vertical: implica añadir más recursos físicos al sistema actual para que pueda atender más solicitudes. Así, por ejemplo, se le añaden más procesadores o más memoria a un servidor. El escalado vertical presenta un límite claro y llega un punto en el que la aplicación necesita ser rediseñada para poder escalar más. En inglés a este tipo de escalado se le denomina "Scale Up".
• Escalado horizontal: en este caso el escalado se consigue simplemente añadiendo más nodos al conjunto del sistema, por ejemplo, poniendo otra máquina en paralelo a funcionar. Este tipo de escalado es más sencillo y no tiene límite, pero implica que las aplicaciones deben estar adaptadas para poder hacerlo, pues implican coordinación, replicación, etc… Se denomina comúnmente como "Scale Out".

El escalado vertical tiene un límite, mientras que el horizontal no.

Evidentemente el escalado que debiéramos buscar siempre es el horizontal. Al menos tener la posibilidad de hacerlo cuando sea necesario. Si nos limitamos a añadir más memoria y procesador al servidor, cuando llegue el momento (y si tenemos suerte llegará) de que la máquina no soporte más, será necesario que pasemos a escalar de manera horizontal. Y si nuestra aplicación no está preparada lo pasaremos muy mal.

SIGUE LEYENDO para aprender:

• Qué es una Web Farm o Granja de Servidores
• Cómo funciona el mantenimiento de sesión en estas infraestructuras
• Cómo podemos configurar ASP.NET para usar un servidor de estado o una base de datos remota para mantener la sesión
• Otros detalles importantes

Como ya os he contado hace poco, PowerShell es una herramienta avanzada de línea de comandos para Windows que trata de llevar a este sistema la potencia de otros intérpretes de comandos (fundamentalmente el shell bash para UNIX), muy extendidos en otros sistemas operativos.

Si estás trabajando con alguna herramienta de administración desde línea de comandos puede que al cargar PowerShell te muestre el siguiente error:

File Microsoft.PowerShell_profile.ps1 cannot be loaded because running scripts is disabled on this system.

o en español "El archivo Microsoft.PowerShell_profile.ps1 no se ha podido cargar porque la ejecución de scripts está deshabilitada en este sistema":

Pulsa para aumentar

Este error se debe a que, por defecto, los permisos de ejecución de scripts externos están restringidos en PowerShell y solamente nos permite ejecutar comandos interactivos, es decir, directamente en la consola. El archivo que menciona el mensaje de error se crea por parte de algunas aplicaciones (por ejemplo posh–git) para cargar un entorno de ejecución personalizado para el usuario (en el caso de posh-git, por ejemplo, para modificar la salida del prompt de modo que nos indique el estado de un repositorio Git cuando entramos en él).

Dado que los permisos por defecto no permiten la ejecución de archivos de comandos PowerShell (con extensión .ps1), la ejecución falla y obtenemos ese error.

SIGUE LEYENDO para descubrir:

• Qué políticas de ejecución existen
• Cómo cambiarlas
• Cómo librarte de ese error

Para los administradores de sistemas más avanzados, uno de los puntos débiles de Windows frente a otros sistemas operativos ha sido tradicionalmente  la capacidad de administración de éste desde línea de comandos.

Windows siempre ha sido un sistema operativo muy fácil de administrar visualmente. En general todos los productos de Microsoft lo son, y esta ha sido siempre una de las principales causas de su preponderancia como sistema operativo. Sin embargo esta facilidad de uso, basada en consolas gráficas y asistentes, ha sido tradicionalmente un arma de doble filo y fuente de controversias. Por un lado la sencillez con la que se realiza cualquier tarea hace que ciertas personas ganen excesiva confianza. En muchas ocasiones esta sencillez se convierte en un grave problema que lleva a que los sistemas estén mal administrados, debido a que no se ha profundizado bien en los conceptos necesarios para una buena gestión (la sencillez de un asistente no alienta tampoco el meterse en grandes honduras). Por otra parte ha sido también un problema porque esas mismas interfaces gráficas que tanto facilitan el trabajo más común, se convierten en un estorbo a la hora de realizar tareas complejas (formadas por otras tareas individuales más simples) que precisen de cierto grado de automatización.

La consola del sistema tradicional (cmd) nunca ha sido especialmente generosa en características, y desde luego está a años luz de los “shell” de UNIX en los que se inspira. Los clásicos archivos .bat son muy limitados y es un dolor realizar con ellos cualquier interacción avanzada con el usuario.

Hace ya bastantes años Microsoft incorporó a sus sistemas operativos un subsistema de automatización llamado Windows ScriptingHost (WSH) que trataba de acortar distancias con la administración de otros entornos. WSH se basa en la escritura de código en lenguajes de script, y soporta multitud de ellos (JavaScript, VBScript, Perl, Python, TCL, Ruby, PHP… hasta COBOL!). Estos scripts permiten crear tareas mucho más complejas que con un simple .bat, además de brindar acceso a la funcionalidad de cualquier objeto COM automatizable, incluyendo por ejemplo acceso a datos, a la red o a servicios web, y las funcionalidades de diversas aplicaciones con interfaz automatizable (como las de Office entre muchas otras).

Realmente WSH supuso una gran mejora sobre lo existente hasta entonces (la línea de comandos de MS-DOS) pero también presentaba un importante problema y es que, al fin y al cabo, los administradores no tienen porque ser también programadores. Si bien es cierto que VBScript o JScript son lenguajes sencillos cuyos rudimentos se aprenden rápido, para hacer uso de las funcionalidades de administración que necesitamos es necesario asimilar el uso de objetos COM que no son nada sencillos en general. Por ejemplo WMI (Windows Management Instrumentation) o ADSI (para acceso al directorio activo).

Esta es una grave limitación puesto que para sacarle partido a WSH hay que saber programar a un cierto nivel, aparte de ser difícil de depurar y requerir mucha ceremonia (en forma de archivos XML) para combinar entre sí la funcionalidad de diversos archivos WSH.

SIGUE LEYENDO PARA APRENDER: 

• El origen de PoowerShell – Monad
• Cómo usarlo
• Cómo concatenar comandos
• Cómo crear funciones propias
• Cómo exportar resultados a Excel
• Cómo filtrar y ordenar resultados
• Más comandos
• Referencias varias

Este es un truco que, sorprendentemente, muchos programadores que usan Visual Studio a diario desconocen. Se trata de la posibilidad de buscar a toda velocidad cualquier elemento de nuestro código, incluyendo archivos, variables, funciones, clases…

La funcionalidad se denomina "Navigate to", y en las últimas versiones de Visual Studio se ha mejorado mucho, incluyendo VS2013.

La velocidad de búsqueda es enorme, y además realiza vista previa y ofrece opciones avanzadas para localizar cualquier cosa. No es lo mismo, pero se parece mucho a la opción "Goto Anything" de Sublime Text.

…SIGUE LEYENDO…