Nginx

  • Tal vez recordarán que hace algunos días publiqué mi artículo explicando detalladamente cómo instalar y configurar Nginx con PHP-FPM. También supongo recordarán que había prometido hacer una comparación con Apache MPM prefork con PHP como módulo, en lo que a consumo de memoria respecta. Cumplo entonces mi promesa con este breve artículo, donde además comparto mi configuración final de PHP-FPM.

  • Gracias a un artículo del blog Un lugar en el mundo... descubrí que StartSSL se ha renovado para tratar de competir con Let's Encrypt (el cual tuvo gran aceptación en Internet gracias a su simplicidad y facilidad para obtener un certificado SSL). Así que decidí probarlo y generé un certificado para linuxito.com. Aquí el tutorial completo.

  • Actualmente me encuentro con la oportunidad de ver nacer una startup. Más bien me toca ser parte de una startup, como responsable de toda decisión tecnológica sobre el proyecto, y participando activamente en su desarrollo como líder de un equipo de 1 integrante (yo :P estamos en proceso de reclutamiento de desarrolladores).

    Es común que cuando alguien tiene experiencia con PHP, al momento de encarar un nuevo desarrollo Web vaya como burra al trigo a lo que ya conoce. PHP es una porquería pero al final de día logra hacer el trabajo, mal que mal. Sin embargo, en esta ocasión me zambullí a la pileta y aposté todo por Python. Creo que dada la potencia de Python, disponibilidad de módulos y muchas otras ventajas, vale la pena la apuesta a largo plazo. Además creo personalmente que, más a corto que largo plazo, me va a permitir desarrollar componentes mucho más rápido que PHP.

    Ahora bien, para implementar aplicaciones Python en Internet es necesario contar con una interfaz al lenguaje, similar a CGI: WSGI. Y también es necesario un servidor HTTP frontend (para servir contenido estático e incluir soporte para TLS, mecanismos de caching, etc.): Nginx. ¿Por qué Nginx y no Apache? Porque es un servidor HTTP más flexible, eficiente y liviano.

    Por último, es altamente recomendable contar con algún tipo de middleware que presente una capa de abstracción a la aplicación Python, para no tener que lidiar con los detalles de bajo nivel de WSGI (parseo de URLs, recuperación de parámetros GET/POST, cookies, headers HTTP, y toda la "magia" que ignoramos al momento de desarrollar en lenguaje PHP porque la hace por nosotros). Cabe destacar que WSGI es una interfaz de más bajo nivel que CGI y se desentiende de su implementación (puede ser multi-procesos o multi-hilada). Para este desarrollo decidí inclinarme por Flask, un microframework de desarrollo de aplicaciones Python basado en el middleware Werkzeug.

    En este artículo voy a compartir mi experiencia montando un servidor Web Nginx con soporte para Python a través de uWSGI, con el objetivo de servir una aplicación desarrollada utilizando el microframework Flask.

  • Hoy me encontré con un problemita interesante. Al intentar ingresar a este sitio, la conexión SSL fallo por estar el certificado de Let's Encrypt expirado. Pero ¿cómo pudo haber expirado si se renueva automáticamente dos veces por día?

  • Revisando las estadísticas de visitas a Linuxito en Google Analytics, me encontré con la siguiente notificación:

    Este mensaje básicamente dice que se están recibiendo estadísticas desde más de un dominio, en este caso "linuxito.com" y "www.linuxito.com", lo cual puede alterar la visualización de datos en los reportes de Analytics. Pero además (peor aún) puede traer problemas de contenido duplicado. Tal como mencioné en mi guía básica para SEO y posicionamiento, y tal como recomienda Google, es conveniente indicar cuál es el dominio "preferido" para nuestro sitio Web a través de una redirección permanente (301).

  • Me encontré con este error al intentar subir contenido de más de 8 MB a mi servidor Nginx con PHP-FPM:

    2016/12/19 06:21:09 [error] 32610#0: *286 FastCGI sent in stderr: "PHP message: PHP Warning:  POST Content-Length of 10857140 bytes exceeds the limit of 8388608 bytes in Unknown on line 0" while reading response header from upstream, client: 6.6.6.6, server: www.linuxito.com, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/run/forest/php5-fpm.sock:", host: "www.linuxito.com", referrer:"https://www.linuxito.com/index.php"
    
  • Mi recientemente publicado script GTFO lleva ya dos días corriendo cada dos minutos. Estos son los resultados.

  • Este artículo explica cómo realizar una limpieza de un archivo de configuración de Nginx demasiado extenso, implementando una estructura de vhosts como la que utiliza Debian para los servidores Apache, mediante el uso de los subdirectorios sites-available y sites-enabled. Esto permite lograr una mejor organización de la configuración y facilita el mantenimiento de un servidor Nginx (algo muy importante para simplificar la tarea del SysAdmin y evitar errores), especialmente cuando se poseen múltiples instancias para un mismo puerto/protocolo (lo que se conoce como VirtualHost en jerga Apache).

  • Hace algunos días, un usuario de Nextcloud se comunicó conmigo para indicarme que la aplicación le estaba arrojando error al tratar de subir un archivo. Este usuario estaba intentando subir un archivo de unos 200 MB (por supuesto el usuario en cuestión debía poder subir dicho archivo, con lo que su solicitud era correcta). Sin embargo la configuración por defecto de Nextcloud permite subir archivos de hasta 512 MB.

  • Al momento de configurar los fuentes de Nginx en Debian, me encontré con que lo compilaría sin soporte para SSL, a pesar de contar con la librería de OpenSSL instalada, porque el script de configuración no detectaba la existencia de dicha librería, por estar en una ruta desconocida.

    
    Configuration summary
      + using system PCRE library
      + OpenSSL library is not used
      + using builtin md5 code
      + sha1 library is not found
      + using system zlib library