miércoles, 25 de julio de 2018

Qué es una 'rolling release' de Linux



¿Qué es una distribución de Linux 'rolling release'? ¿Qué diferencia hay entre una versión 'normal' de Linux y una rolling release? ¿Qué rolling releases de Linux existen en el mercado?



Si estás interesado en Linux, alguna vez habrás leído la palabra rolling release (en español liberación contínua). O puede que no. Sea como sea, las rolling release son distribuciones de Linux que gozan de actualizaciones contínuas y no tienen ningún número de versión asociado a su nombre.

¿Cómo es eso posible?

Los repositorios de las distribuciones rolling release de Linux se actualizan constantemente, ofreciendo siempre las versiones más nuevas de todo el software que contienen. Las distribuciones clásicas, en contraposición, ofrecen ciclos cerrados para cada paquete.

Para verlo con un ejemplo, basta con fijarse en el kernel de un sistema Linux.:

- Un sistema Linux tradicional trae una versión específica del kernel empaquetada, por ejemplo la 4.4, para la cual el creador de la distribución ofrece parches cada vez que estos aparecen. Cuando actualizamos el kernel, pasamos a tener la versión 4.4.1, 4.4.2, etc.

- En una rolling release, en cambio, cuando aplicamos actualizaciones al sistema operativo, el sistema no se queda en una versión estanca del kernel sino que instala cada vez la última versión publicada de este, siempre que esté disponible en sus repositorios. De este modo, podemos pasar de un kernel 4.4 a un kernel 4.8, si este ya está disponible.

Una rolling release no tiene número de versión general; así pues, ArchLinux es ArchLinux y OpenSUSE Tumbleweed es siempre OpenSUSE Tumbleweed, sin versión 1.0 ni similar. No existen números de versión porque todas las partes del sistema que compondrían una versión del sistema operativo son actualizadas a la última versión cada vez que actualizamos el sistema. Por este motivo, dos PCs con, por ejemplo, OpenSUSE Tumbleweed instalado, pueden tener versiones muy diferentes del mismo software.

Debido a la naturaleza de las actualizaciones contínuas, muchas de las combinaciones de componentes (ej. última versión de Apache corriendo bajo el último kernel publicado) no han sido probadas extensamente, lo cual hace que las rolling releases puedan llegar ser menos estables que los sistemas tradicionales y dar más problemas en general. Es por ello que las rolling releases suelen ser usadas más bien por usuarios avanzados/expertos de Linux, capaces de resolver incidencias rápidamente.


Lista de distribuciones rolling release de Linux



A continuación una lista con algunas de las distribuciones 'rolling release' de Linux en activo:

Antergos
AntiX
Arch Linux
Gentoo
Manjaro Linux
NuTyX Linux
OpenSUSE Tumbleweed


Experiencia personal



Personalmente, he usado bastante tiempo OpenSUSE Tumbleweed en mi portátil y me ha dado menos problemas actualizándolo constantemente, que las actualizaciones de versión de distribución de Ubuntu. Por ejemplo, al pasar de Ubuntu 14 a Ubuntu 16 tuve problemas serios y tuve que formatear el portátil y al pasar de Ubuntu 16 a 18 también me encontré algunas dificultades, mientras que actualizando OpenSUSE semanalmente durante cerca de un año aun no me he encontrado ningún problema. También tengo que decir que en mi día a día, en mi ordenador personal, uso muy pocas aplicaciones, así que no soy el mejor ejemplo.

Para terminar, creo que una rolling release es una mejor opción - o una opción más cómoda - para equipos de sobremesa/portátiles, ya que al no tener que instalar nunca una nueva versión del sistema operativo no tendremos que cruzar los dedos para que funcione la tarjeta WiFi o la gráfica en esa nueva versión. Las distribuciones con versión, por otro lado, al haber sido testeadas a conciencia, ofrecen robustez y son perfectas para su uso en servidores, donde lo que más se valora es la estabilidad. Se mantienen versiones que se sabe trabajan bien en conjunto y cuando se ejecuta el proceso de actualización solo se aplican parches sobre las versiones instaladas.
0

miércoles, 18 de julio de 2018

Preparar nueva instalación Windows con 'sysprep'



Qué es el 'sysprep'? Cuándo realizar un sysprep? Dónde se encuentra sysprep.exe? Veamos cómo ejecutar sysprep en una imagen de Windows para generalizarla.



sysprep es una utilidad específica de Windows (incluida tanto en Windows Server como en Windows de escritorio) que nos permite preparar una instalación de Windows para que esta pueda usarse como plantilla para futuras máquinas virtuales (o físicas).

Las características principales de sysprep son:

  • Elimina información específica de la máquina donde se ha desplegado Windows originalmente, incluido el identificador de seguridad de la máquina (SID). Este proceso es conocido como "generalizar una instalación de Windows".

  • Desinstala controladores (drivers) específicos de la máquina original donde se desplegó la instalación de Windows si estos no son necesarios en el nuevo hardware.

  • Prepara el PC para la entrega a un cliente, configurando el PC para arrancar en OOBE (Out of the Box Experience). Eso significa que al iniciar el equipo, el usuario final de la máquina podrá especificar su zona horaria, país y nueva contraseña de administrador local.

Se debe (o se debería) ejecutar sysprep como último paso al crear una plantilla de Windows para futuros servidores o PCs. Para ejecutar sysprep, nos dirigimos a:

C:\Windows\system32\sysprep\



Ejecutamos sysprep.exe y veremos esta pantalla:



Seleccionamos OOBE, marcamos 'Generalize', seleccionamos 'Shutdown' y pulsamos OK. Esto iniciará el proceso de sysprep. Como comentaba, 'Generalize' elimina el identificador de seguridad de la máquina (SID) y limpia también todos los drivers no necesarios, dejando el sistema preparado para iniciarse por primera vez y detectar el nuevo hardware, entre otras cosas.



Cuando acabe el proceso, la máquina se apagará y quedará lista para futuros despliegues.

Cuando implementemos una nueva máquina virtual desde esta plantilla o planchemos la imagen en un PC, nos encontraremos con la OOBE (Out Of the Box Experience), la cual emula la experiencia de comprar un ordenador, sacarlo de la caja, encenderlo y especificar país, idioma, password, etc.



Después de seleccionar las opciones que nos interesen, clicamos Next:



Aceptamos el acuerdo de licencia y, a continuación, veremos una pantalla donde se nos pide un password. Aquí es donde especificamos una nueva contraseña para la cuenta de Administrador local:



Pulsamos Finish para finalizar el proceso y acceder al escritorio. Windows habrá asignado un nuevo SID a la máquina y quedará configurado como una nueva instalación independiente.


Fuentes:

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--system...
https://msdn.microsoft.com/es-es/library/windows/hardware/dn938331(v=vs.85).aspx
https://msdn.microsoft.com/es-es/library/windows/hardware/dn938334(v=vs.85).aspx
0

jueves, 12 de julio de 2018

Qué es un 'Reverse Proxy'



¿Qué diferencia hay entre un proxy y un reverse proxy? ¿Para qué sirve exactamente un reverse proxy? ¿Cuáles son los nombres de los reverse proxy más usados a día de hoy?



Antes de explicar qué es un 'Reverse Proxy', debemos tener claro qué es un proxy 'a secas', es decir, un proxy de reenvío (en inglés forward proxy). Un proxy [de reenvío] es un servidor ubicado entre un PC (o una red de PCs - LAN) e internet. Su función es filtrar las conexiones que ese PC envía hacia una página web antes de que estas lleguen a dicha página web. En entornos empresariales, este sistema es usado, por ejemplo, para bloquear determinado contenido a los trabajadores de la empresa. Los usuarios domésticos, a su vez, suelen usar proxies [de reenvío] para cambiar la IP con la que salen a internet - para evitar bloqueos regionales, evitar baneos en ciertas páginas web, etc.

NOTA: los trabajadores de una empresa también pueden usar proxies [de reenvío] para saltarse las restricciones impuestas por el proxy de su empresa, pero eso ya es otro tema...

Un Reverse Proxy (en español proxy inverso), por su parte, es un servidor ubicado entre internet y los servidores web de una empresa. Es, digamos, el punto de entrada de las peticiones dirigidas hacia las webs de una empresa antes de que estas lleguen propiamente a la web en cuestión.

Digamos que un usuario - ubicado en cualquier parte del mundo - quiere visitar una página web y esta está situada en un servidor ubicado detrás de un reverse proxy. ¿Qué camino siguen las peticiones? El usuario mandará una petición HTTP desde el navegador de su PC hacia el dominio de la web que quiere visitar diciendo "muéstrame la web". En el caso que nos ocupa, el registro DNS de ese dominio apuntará a un reverse proxy en vez de al servidor web final (NOTA: ambos servidores estarán protegidos detrás de un firewall). Este reverse proxy, a su vez, enrutará todas las solicitudes enviadas hacia ese dominio hacia el servidor web final.

Para rizar el rizo, comentar que es una situación normal en el día a día que un PC que sale a internet a través de un forward proxy quiera visitar una web ubicada detrás de un reverse proxy, en cuyo caso el esquema sería el siguiente, desde el Client hasta el Worker:




¿Para qué usar un Reverse Proxy?



Apuntar los dominios de las páginas web hacia un reverse proxy ofrece ciertas ventajas frente a apuntar los dominios web directamente a los servidores web. Las ventajas más notorias son:

Anonimización: si alguien escanea un dominio que apunta a un reverse proxy, obtendrá como respuesta el sistema operativo del reverse proxy y no el del servidor web, así como las versiones de los servicios corriendo en el reverse proxy y no en el servidor web final. Por ejemplo, podemos tener un reverse proxy con Linux que enrute peticiones a máquinas Windows. Si escaneamos un dominio que apunte a ese reverse proxy, el usuario que lo haga no sabrá que el servidor web real corre bajo Windows porque las respuestas del scanner de turno indicarán que es un sistema Linux.

Protección: enlazando con la característica anterior, si un hacker lanza un escaneo hacia un dominio y ve que la máquina donde se aloja ese dominio es Linux - cuando en realidad es Windows - raramente se le ocurrirá lanzar un ataque hacia ese dominio con un exploit orientado a Windows. Con esto, las páginas web cuyos dominios apunten al reverse proxy estarán más protegidas frente a ataques orientados a vulnerabilidades de un sistema específico.

Alta disponibilidad: si sólo usamos un servidor de aplicación y por lo que sea, este queda inservible, el servicio web quedará inmediatamente offline. Si usamos varios servidores de aplicación y uno falla, podemos usar lo que se denomina "balanceo de carga" dentro del reverse proxy, es decir, crear una lista de servidores de aplicación y si uno falla, hacer que el reverse proxy envíe las peticiones a otro de los servidores de la lista que esté activo. De este modo, el servicio web no quedará interrumpido en ningún momento (siempre que no caigan todos los servidores de aplicación de la lista al mismo tiempo).

Caché: para acelerar la conexión hacia una página web, podemos usar la opción de caché de un reverse proxy para hacer que este almacene contenido estático de una página web (imágenes, css, javascript, etc.) de forma temporal y lo sirva él mismo sin necesidad de realizar ninguna conexión hacia los servidores de aplicación. Así se puede mejorar la velocidad de acceso a una página web considerablemente.

Compresión: para servir más rápido el contenido de una página web hacia sus visitantes, se puede comprimir el contenido de dicha web mediante el protocolo gzip de modo que el envío de las respuestas HTTP hacia el navegador del usuario sea menos pesado y, por lo tanto, más rápido.

Descarga SSL: un reverse proxy puede absorver él todas las peticiones HTTPS y realizar él el handshake con el navegador del usuario. Las peticiones se convierten entonces a HTTP y se envían al servidor web. El proceso de convertir peticiones HTTPS a HTTP se llama SSL Termination. Enviando peticiones HTTP al servidor web (en vez de enviar peticiones HTTPS) evitamos que este tenga que realizar él el handshake SSL, lo cual libera recursos de la máquina que pueden ser usados para, por ejemplo, generar contenido PHP más rápidamente (recordemos que el handshake SSL consume un 20% aprox. de CPU).

Administración centralizada de certificados: un reverse proxy nos permite colocar todos los certificados SSL que usemos en nuestras páginas web en un único punto. De esta forma, cuando los certificados vayan a caducar, solo tendremos que renovarlos en un único servidor en vez de tener que ir máquina por máquina subiendo los nuevos archivos.

Liberación de IPs públicas: si cada servidor web tiene asignada una IP pública y tenemos muchos servidores web publicados en internet, el número de IPs públicas usadas se dispara. Si usamos un reverse proxy como sistema de entrada a las páginas web de una empresa, podemos reducir el número de IPs públicas usadas a una sola IP, reduciendo con ello costes, documentación adicional, etc.

Además, un reverse proxy se puede usar para hacer redirects de una URL a otra, hacer rewrites para que un dominio apunte a una ruta específica en otro dominio, etc.


Reverse proxies más usados



Los reverse proxies más usados en el mercado son:

Apache
F5 BIG-IP
HA Proxy
IIS
Lighthttpd
nginx
Squid
Varnish


Conclusión



Pienso que hoy en día debería ser obligatorio usar reverse proxies delante de los servidores web. Solo por el hecho de poder ofrecer alta disponibilidad a un sitio web, ya vale la pena usar un servidor intermedio con una solución de reverse proxy instalada. Si a esto le sumamos la administración centralizada de certificados, la posibilidad de hacer rewrites de URLs, la ocultación de sistemas operativos, etc. lo convierten en una opción muy interesante.

Personalmente, he probado algunos de los reverse proxies mencionados y me decanto por nginx como el mejor de ellos, sobretodo por su facilidad de configuración, por ser open source (también existe una licencia empresarial con soporte y características extras por una tarifa al año) y por la cantidad de documentación que se puede encontrar sobre sus opciones.
1

viernes, 6 de julio de 2018

Cómo servir páginas .asp en IIS



El módulo ASP clásico no se instala por defecto en el Internet Information Services (IIS) de Windows Server. A continuación veremos como instalar ASP clásico en IIS para servir páginas .asp.



En el año 2000, Microsoft lanzó el lenguaje ASP (Active Server Pages), un lenguaje de programación web dinámico, creado para competir con PHP. Este lenguaje fue actualizado a ASP.NET en 2002, momento en que el ASP original quedó relegado a un segundo plano, aunque Microsoft nunca canceló su soporte.

Todavía hoy es posible instalar ASP en el servidor Web Internet Information Services (IIS) de cualquier Windows Server. Esto nos permite poder servir páginas con extensión .asp desde Windows Servers de última generación, útil para, por ejemplo, migrar una página web antigua desde un Windows Server 2003 hacia un Windows Server actual.

Para instalar el módulo ASP sobre un Windows Server - en cualquiera de sus versiones - primero debemos desplegar IIS en él. Una vez instalado IIS, añadiremos un "rol o feature" al servidor (2).



Volvemos a elegir rol o feature:



Seleccionamos el servidor local (o el servidor donde queramos instalar ASP):



Seleccionamos ISAPI extensions (en la imagen aparece instalado porque ya lo instalé al desplegar IIS):



Seleccionamos, ahora sí, ASP:



Siguiente, siguiente... hasta que quede todo instalado:



Si hemos migrado una web programada en ASP a este servidor, lo más probable es que el archivo inicial sea index.asp. Por defecto, index.asp no está activo como página de inicio en IIS, por lo que debemos añadirlo a la lista de documentos a cargar por defecto. Lo haremos clicando Default Document:



Botón derecho > Add > index.asp



Reiniciamos la página en cuestión en IIS y ya deberíamos poder ver el contenido de cualquier archivo .asp contenido en este servidor si accedemos a la página web en cuestión desde un navegador.
0