Skip to content
Hospedage web

Hospedage web

Documentación del Hospedaje web de la redUI

La red de Unidades Informáticas (de la UdelaR (en el Interior)) hospeda varias decenas de sitios web. En su plataforma de computación en la nube, ofrece diferentes servicios de integración, desarrollo, hospedaje y mantenimiento de sitios web, que se describen a continuación.

Multisitio Wordpress

Tenemos un multisitio de producción. Hospedar un sitio ahí requiere utilizar ciertos temas y plugins ya instalados, o analizar con nosotros que se los pueda agregar, en función de su calidad, seguridad y mantenibilidad.

Arenero de sitios de Grupos I+D

Mucho más abierto, tenemos otro multisitio como arenero para que los grupos I+D construyan sus sitios. Puedes solicitar acceso para probar la construcción de un sitio wordpress en un entorno multisitio.

Cuentas de hospedaje LAMP

Para ir más allá del hegemónico gestor de contenidos Wordpress, la redUI ofrece toda una gama de servicios, que pueden ir hasta la provisión de un servidor dedicado, para necesidades específicas.

Más acá, luego de la posibilidad de armarse una instancia de multi-sitio Wordpress, el siguiente servicio se accede mediante una cuenta en una de nuestros [Hestia Control Panel], que ofrecen un hospedaje LAMPP (Linux / Apache / MySQL / PostgreSQL / PHP) de primer nivel.

Una cuenta de hospedaje ofrece diferentes bondades manejables por una intefaz web. Para trabajar, te podemos delegar una sub-zona DNS de una zona que manejamos, como arenero.uy. Por ejemplo, si te llamas Juan y quieres armar la web de un poyecto denominado Tobogán, te podremos dar las credenciales de una cuenta juan, y delegarte la zona tobogan.arenero.uy. A través de esta consola, podrás:

  • gestionar sitios web como https://opcion1.tobogan.arenero.uy, https://opcion2.tobogan.arenero.uy, ..., depositando los archivos por ssh o sftp,
  • crear bases de datos mysql y postgres,
  • instalar y correr en pocos clics varias aplicaciones clásicas: Wordpress, Drupal, Mediawiki, ...
  • depositar y gestionar archivos en el hospedaje,
  • acceder a un shell completo de usuarix en ssh, con una o varias claves priv/pub,
  • instalar y correr cualquier otra aplicación PHP / MySQL o Postgres,
  • gestionar cuentas de correo, que serán correctamente autenticables en internet,
  • recopilar las estadísticas de visita de tus sitios web (web analytics)

Cabe notar que los aplicativos PHP no tienen envío abierto de mail. Si un aplicativo debe enviar mails, se deberá configurar una zona DNS, con gestión de mail, al menos una casilla y utilizar su autenticación de envío, o usar un relay SMTP externo.

De esta manera, cada webmestre es responsable del tráfico de mails que emana de su aplicación. Si el monitoreo detecta un tráfico anormal, se podrá suspender sólo la casilla de la aplicación incriminada, no de todo el servidor.

Infraestructura de hospedaje LAMP, DNS, certificados SSL y mail

Para proveer una Plataforma LAMP como Servicio (PaaS), utilizamos originalmente, desde 2011, el Panel de Control AlternC y luego Hestia Control Panel, en el que se basan las instancias más recientes de hospedaje.

Tres servidores virtuales, h1.cielito.uy, h2.cielito.uy y h3.cielito.uy, ofrecen un servicio DNS como cluster de varios NS autoritativos. Cada cual tendrá un propósito de perfil y calidad de servicio:

  • h1, excelencia: hospeda los sitios institucionales y estratégicos. El de más alto nivel, el hospedaje en este host se gestiona por procesos institucionales. Debe(ría)n tener mantenimiento asegurado, por equipos de la redUI u otro personal específicamente dedicado,
  • h3, devops: Es el espacio estable de integración y pruebas. En este sentido de prod vs. stage el hestia en h3 es una "plataforma como servicio" (PaaS) de producción, pero en la que se despliegan todo tipo de entornos LAMPP, de stage o de producción, según la necesidad de los usuarixs. El mantenimiento y el servicio de los sistemas LAMPP son de responsabilidad de cada unx de lxs usuarixs.
  • h2, pragmatismo: todo el resto. Sitios web de grupos y proyectos, por ejemplo, o sitios comunitarios.

h1 y h2 son VMs, con un almacenamiento masivo en redota, h3 será un contenedor.

Hestia templates

Un elemento muy importante en el entorno de HestiaCP son las plantillas (templates). La instalación trae varios por defecto, pero también permite personalizar las plantillas que se van a utilizar en cada uno de los servidores virtuales.

Plantillas de proxy Nginx

Un caso de uso frecuente es el de las plantillas de Proxy Nginx, utilizadas cuando Nginx actúa como frontal de un servidor de aplicaciones. Varios servidores, como Tomcat/Java, dan servicio en puertos web alternativos, como 8080 y 8083, y se les suele poner por delante un servidor web que juegue un papel de reverse proxy, efectuando previamente todos los controles de sanidad oportunos.

Plantilla default de proxy Nginx

Esta plantilla define la forma en la que Nginx actua por delante del backend configurado. Cumpliendo con la funcionalidad de manejar las peticiones HTTP/HTTPS, servir contenido estático y reenviar el tráfico correspondiente al backend.

La plantilla default define la forma estándar mediante la cual Nginx:

  • Maneja las peticiones HTTP/HTTPS.
  • Sirve contenido estático.
  • Reenvía el tráfico al backend (generalmente Apache) mediante proxy_pass.

El objetivo principal es brindar una configuración genérica que funciona para la mayoría de sitios sin configuraciones especiales.

Plantilla personalizada "Luca"

Hicimos uso de la posibilidad de customizar las plantillas para elaborar la plantilla proxy luca, que permite

  • Configurar en un dominio web un reverse proxy nginx al host luca.interior.edu.uy,
  • Filtrar la direcciones de app (el script de la url) mediante una lista de valores o patrones de regex, en un archivo `/home/cseam/conf/web/extension.arenero/nginx.luca_apps.conf, que se puede actualizar desde la consola o por ssh con una cuenta hestia.
  • Personalizar las páginas de error, que se sirven desde este frontal, en particular fuera de la precedente lista.

Plantilla personalizada con funciones de WAF (Web Application Firewall)

Si bien un proxy no debe ni puede cumplir el rol de WAF, puede realizar funcionalidades de lógica simple que le quitan carga al backend.

Partiendo del template default de Nginx proxy, se creó una plantilla destinada principalmente a sitios WordPress que bloquea el tráfico a ciertas rutas vulnerables, propias del sistema de gestión como lo son

  • El archivo xmlrpc.php
  • Archivos de extensión .xml que no son necesarios para el funcionamiento de Wordpress pero que son comúnmente escaneados por bots que buscan sitios vulnerables.

Limitar acceso de un sitio a la RAU

Si bien los servidores de hospedaje son accesible globalmente en sus puertos web, es posible limitar el acceso de un sitio en particular a una red, utilizando la configuración de un .htacces Apache. Ver los foros Hestia.

Por ejemplo, con el archivo:

csic@h2:~/web/dt.arenero.uy/public_html$ cat .htaccess 
####################################################
## RedUI - limitación de acceso a la RAU y VPN  
####################################################

<RequireAny>
  Require all denied
  # RAU - IPv4
  Require ip 164.73.0.0/16
  # VPN RedUI
  Require ip 10.X.Y.0/22
  # Otras IPs privadas de VPN que circulan en la RAU
  Require ip 10.Z.T.0/24
  Require ip 192.168.U.0/24

</RequireAny>

limitamos el acceso a dt.arenero.uy a las IPs listadas. Cabe recordar que hasta ahora Hestia sólo maneja IPv4, pero respecto a esta función, bien podría haber acá alguna IPv6.