Nginx

  • Llegó la hora de renovar por primera vez el certificado SSL provisto por Let's Encrypt para el blog. Recordemos que los certificados SSL que otorga Let's Encrypt (de forma gratuita) tienen una validez de sólo tres meses, por seguridad, claro está. Este breve artículo explica cómo funciona el proceso de renovación.

  • Esta fue una semana de respuestas HTTP un tanto insólitas para mí. Luego de haber comentado mi experiencia diagnosticando una respuesta HTTP 503, esta vez me tocó solucionar el caso de una respuesta HTTP 413 en un servidor Nginx:

  • Un pregunta de un lector en la entrada Hardening de SSL/TLS en servidores HTTPS me llevó a buscar y probar una solución para este problema: cómo predecir el impacto, en los clientes de un sitio Web, al deshabilitar un protocolo inseguro dentro de la configuración de suites de cifrado de TLS.

    Este lector en particular, necesitaba saber si alguno de sus clientes se verían afectados al deshabilitar el algoritmo criptográfico de encriptación de flujo RC4, el cual es inseguro (vulnerable a un amplio abanico de ataques y ya sin soporte por los principales navegadores). La solución consiste en lograr que el servidor Web registre en el log de accesos el protocolo y suite de cifrado elegidas durante la negociación (handshake) para cada acceso. De esta forma es posible, luego de un tiempo, determinar si existen cliente que aún utilizan el protocolo/suite de cifrado que deseamos deshabilitar (para mejorar la seguridad).

  • Este artículo explica cómo compilar Nginx con soporte para SSL en Debian y derivados.

  • En este artículo voy a explicar detalladamente cómo compilar, instalar y configurar un servidor PHP FastCGI Process Manager (FPM) versión 7, desde sus fuentes. Incluyendo los cambios necesarios en la configuración de un sitio Joomla! para que funcione correctamente con PHP 7.

  • Este artículo demuestra cómo implementar un proxy reverso con soporte para SSL/TLS para una instalación de Home Assistant utilizando Nginx. Cabe destacar que no se cubre el proceso de instalación y configuración de Hass.io, sólo la configuración del proxy HTTPS reverso, la cual resulta un tanto particular a fin de que las aplicaciones conectadas funcionen correctamente.

    Home Assistant es una tecnología de automatización para aplicaciones de domótica de código abierto que permite convertir a un dispositivo embebido (como una Raspberry Pi) en un sistema de control centralizado de nuestro hogar. Las ventajas de utilizar Hass.io son muchas, entre las que se destacan su naturaleza libre y open source; el hecho de que esté optimizado para dispositivos como la Raspberry Pi; simplicidad de instalación; y la posibilidad de controlar nuestro hogar desde una interfaz Web.

    Esto suena muy bonito pero, claro está, se requiere implementar un cierto nivel de seguridad para llevarlo a la práctica. Por ello en este artículo explico cómo configurar un proxy reverso con Nginx para implementar HTTP/S y garantizar una comunicación segura entre nuestro smartphone y la Raspberry hogareña.

  • Hoy tuve la necesidad de obtener el número total de bytes transferidos por mi servidor Web, para tener una noción del volumen de tráfico saliente. Esta información es útil para estimar el consumo de ancho de banda mensual requerido por un servidor, dato de suma importancia cuando se trata de servidores en la nube, donde los servicios suelen utilizar la metodología de pago por uso.

  • Esta guía explica cómo crear un nuevo entorno de proyecto en un servidor con Trac instalado y funcionando.

    Trac es una Wiki mejorada y sistema de seguimiento para proyectos de desarrollo de software. Utiliza un enfoque minimalista a las soluciones de gestión de proyectos basadas en Web, entrometiéndose lo menos posible y manteniéndose al margen del proceso de desarrollo de proyectos establecido por un equipo.

    Trac provee una interfase a Subversion y ​Git (u otros sistemas de control de versiones), una Wiki integrada y facilidades de reporte. A su vez, permite utilizar lenguaje de markup Wiki en descripciones y mensajes de commit, crear enlaces y referencias entre bugs, tareas, etc. Incluye una línea de tiempo que muestra los eventos en orden y un roadmap.

    Trac está escrito en lenguaje Python y necesita una base de datos ​SQLite, ​PostgreSQL, o ​MySQL para su funcionamiento. Además, utiliza el sistema de plantillas ​Genshi para renderizado de HTML.

    Esta guía no incluye la instalación del Software Trac en un servidor, sino la creación de un nuevo entorno de proyecto. Para conocer el proceso de instalación de Trac, remitirse a la guía de instalación oficial: Trac Installation Guide for 1.2.

  • En el artículo anterior expliqué cómo montar una caché centralizada para paquetes de Debian implementando un proxy en Nginx. En este artículo voy a explicar cómo hacerlo para CentOS (utilizando el mismo servidor que cumple el rol de cache). La configuración de Nginx es casi idéntica, sólo que hay diferencias en la configuración de los clientes, al tratarse de un gestor de paquetes diferente.

  • Se me ocurrió crear una caché de paquetes de Debian centralizada, desde donde todos mis servidores actualicen su software. La cuestión es que, teniendo cientos de servidores y sin contar con un proxy HTTP (que haga las veces de caché), al momento de actualizar los sistemas operativos se descargan una y otra vez los mismos paquetes.

  • Se me ocurrió buscar intentos de acceso fallidos a paneles de control de diversos CMSs y no creerás lo que sucederá...

  • Otro artículo para demostrar cómo, utilizando comandos simples, es posible procesar y obtener información útil de forma rápida y sencilla. En este caso veamos cómo obtener una lista de todas las direcciones IP de los clientes de un servidor Web Apache o Nginx.

  • Se me ocurrió bloquear intentos de acceso a ciertas URLs en mi servidor Web. Al buscar alternativas para realizar esta tarea, lo primero que surge es fail2ban. Pero me pareció que, para este caso en particular, era como matar una mosca con una bazooka. Por ello decidí implementar un pequeño script bash que corra periódicamente desde cron.

  • Anteriormente expliqué cómo instalar GitLab desde los fuentes en Debian. Veamos ahora cómo habilitar el soporte para HTTPS para que el sitio sea seguro.

  • Este artículo explica cómo configurar un servidor Web Nginx de forma segura, que acepte pedidos sólo a través de TLS (redireccionando de forma automática todos los pedidos HTTP a HTTPS), de forma que todo el tráfico entre los clientes y el servidor sea encriptado utilizando sólo los protocolos TLS más fuertes. Para ello se deshabilitará la compresión SSL para evitar el ataque CRIME, también SSLv3 e inferiores debido a sus vulnerabilidades, y se configurará una suite de cifrado fuerte que permita Perfect Forward Secrecy (PFS) cuando sea posible.

  • Desde hace unos días Linuxito está hospedado en un VPS de RamNode y dado que estoy muy familiarizado con Apache, instalé un clásico esquema LAMP (Linux Apache PHP MySQL). Pero compré un VPS con poca memoria RAM (256 MB, por cuestiones de costo), y el servidor está muy al límite, consumiendo incluso algo de swap. Por ello tomé la decisión de migrar a Nginx con PHP en modo CGI, un esquema mucho más eficiente en lo que a consumo de memoria respecta.

    Nginx se vende como un servidor HTTP de alto rendimiento, estable y con muy bajo consumo de recursos (algo que me han resaltado varios colegas). Su alto rendimiento se debe a que, a diferencia de Apache que utiliza threads (o procesos, depende cómo se lo configure), Nginx posee una arquitectura asincrónica mucho más escalable y basada en eventos, lo que permite utilizar pequeñas cantidades de memoria.

    Por otro lado, el hecho de correr PHP como un servicio separado (en lugar de un módulo de Apache) utilizando PHP-FPM (FastCGI Process Manager) mejora mucho la eficiencia de memoria. Cuando se incluye a PHP como módulo de Apache, cada proceso worker (trabajado en modo MPM prefork) es una copia del espacio de memoria (fork) del proceso maestro. Esto implica que en cada worker se replica el espacio de memoria necesario para correr PHP, aunque no sea necesario (por ejemplo si se están sirviendo recursos no ejecutables como imágenes, archivos HTML, u otros). El resultado es que el consumo de memoria de PHP se replica en cada worker. En definitiva el footprint de memoria de PHP es mucho más grande.

    Al utilizar PHP-FPM, el motor intérprete de PHP corre como un servicio aparte, el cual puede recibir peticiones a través de un socket TCP/IP o UNIX tradicional. De esta forma se tienen dos servicios: Nginx para manejar el protocolo HTTP y PHP-FPM para interpretar código PHP. Lo cual resulta más eficiente, ya que se invoca a PHP sólo cuando es necesario.

    Este artículo explica detalladamente como instalar y configurar Nginx con PHP-FPM. Específicamente instalando php5-fpm desde los repositorios, pero compilando Nginx desde sus fuentes. El sistema operativo es Debian 7.

  • En esta oportunidad me tocó instalar un servidor Nextcloud, fork de ownCloud creado por su propio autor, y que mantiene la gran mayoría de los desarrolladores principales del mismo. Nexcloud es un software de gestión de archivos en la nube similar a Dropbox pero open source, lo cual permite implementar nubes privadas instalando el servidor Nexcloud en cualquiera de nuestros sistemas.

    Además de utilizar un servidor Web con Nginx y PHP-FPM, y una base de datos PostgreSQL, lo interesante de este artículo es proveer una configuración que impida el acceso público a los documentos (que no sean navegables a través de HTTP/HTTPS) sino que sólo sea posible acceder a los mismos a través de la aplicación Web.

  • Hace algunos meses expliqué detalladamente cómo instalar y configurar Nginx con PHP-FPM en Debian. En este artículo voy a explicar cómo llevar a cabo al misma tarea, pero esta vez sobre un servidor FreeBSD. A pesar de que las configuraciones son casi idénticas, la instalación de paquetes desde la colección de ports de FreeBSD es algo diferente a Debian y derivados, y a su vez se utiliza un sistema de archivos ZFS como base para el directorio de trabajo del servidor HTTP (donde se alojarán los archivos de los diferentes sitios Web).

  • En artículos anteriores demostré cómo implementar una caché de paquetes con Nginx, pero al mismo tiempo balanceando carga entre diferentes mirrors. Tal como mencioné en dicho artículo, el balanceo de carga tiene como beneficio secundario mejorar la disponibilidad. Fue por esta razón que me incliné a balancear carga entre varios mirrors. Sin embargo, esto puede traer algunos inconvenientes que es posible evitar de forma sencilla.

  • El objetivo final de compilar e instalar collectd con InfluxDB y graficar las métricas de collectd con Grafana era lograr monitorear la actividad en un servidor Web Nginx a través de gráficas y alertas en Grafana. Este artículo explica la configuración de Nginx y collectd para recopilar datos de uso del servidor Web, y la configuración de Grafana para visualizar estos datos.