Webinoly

Optimized WebServer

Inicio » Documentación » Administrar Sitios

Administrar Sitios

El comando “Site” nos permite administrar los sitios web hospedados en el servidor. Crea cualquier tipo de sitio en tu nuevo servidor, añade un certificado SSL, activa FastCgi Cache para tu instalación WordPress y más funciones que te permitirán tener control total sobre tus sitios de manera fácil y confiable, siempre a un comando de distancia y sin complicaciones.

Sintaxis:

sudo site <dominio> <opcion> <opcion2>

Opciones:

  • -cache
  • -clone-from
  • -delete
  • -delete-all
  • -empty
  • -force-redirect
  • -forward
  • –html
  • -info
  • -list
  • -multisite-convert
  • –mysql
  • -on
  • -off
  • -parked
  • –php
  • -proxy
  • -redirection
  • –ssl
  • -wp

Ejemplos:

# Crear sitio PHP
sudo site example.com -php

# Crear sitio WP con cache
sudo site example.com -wp -cache=on

# Desactivar cache
sudo site example.com -cache=off

# Certificado SSL
sudo site example.com -ssl=on

# Listado de tus sitios
sudo site -list

# Clonar un sitio WP
sudo site example.com -clone-from=staging.example.com

# Redireccionar una página
sudo site example.com -redirection

Crear un nuevo sitio web

Crea cualquier sitio web: HTML, PHP, WordPress, Reverse Proxy, etc.

Para crear un sitio HTML básico, utiliza el siguiente comando:

sudo site example.com -html

Para crear un sitio con soporte PHP.

sudo site example.com -php

Todos los sitios usando el dominio principal (no un subdominio) están configurados para responder a solicitudes example.com y www.example.com (Ver la opción force-redirect).

Para crear un sitio PHP en conjunto con una base de datos:

sudo site example.com -mysql

Los datos para conectar con la base de datos se mostrarán al ejecutar el comando.

También puedes usar la opción “custom” para introducir tus propios datos para crear la base de datos sudo site example.com -mysql=custom o de igual manera puedes pasar los datos directamente.

# TIP Hack
# Usa la opción -mysql sin dominio para crear una DB y User (MySQL) 
sudo site -mysql

# Custom
sudo site example.com -mysql=custom

# O con datos personalizados
sudo site -mysql=[host,dbname,dbuser,password]
sudo site example.com -mysql=[host,dbname,dbuser,password,external_dbuser,external_dbpass]

# TIP
Usa "random" (sin commillas) como password o clave para generar de manera automatica una clave aleatoria.

WordPress

Instalar WordPress nunca había sido tan sencillo, Webinoly configura de manera automática toda la instalación.

sudo site example.com -wp

Usa la configuración “custom” para modificar algunos aspectos de la base de datos, de cualquier manera puedes simplemente presionar <Enter> en cada pregunta para usar los datos sugeridos.

# Script de instalación de un sitio WordPress usando la configuración "custom"
sudo site example.com -wp=custom -cache=on

De igual manera puedes pasar los datos directamente desde la línea de comandos:

# Script de instalación de WordPress con datos personalizados.
sudo site example.com -wp=[<setup_db>,<setup_wp>,<host>,<dbname>,<dbuser>,<dbpass>,<wp_prefix>,<external_db_user>,<external_db_pass>]

# Ejemplo:
sudo site example.com -wp=[true,true,localhost,example_com,example_user,password,wp_]

# TIP
Usa "random" (sin commillas) como password o clave para generar de manera automatica una clave aleatoria.

Base de datos externa

Webinoly soporta el uso de bases de datos externas para tu sitio WordPress, por ejemplo Amazon RDS. Es muy sencillo de configurar, durante la instalación “custom” de tu sitio se te preguntará por el “dbhost”, por default se configura como localhost, pero en caso de requerir el uso de una base de datos externa solo debes agregar la ruta de acceso en el formato example.com:port.

  • myinstance.123456789012.us-east-1.rds.amazonaws.com:3306

Incluso puedes guardar los datos de tu base de datos externa: sudo webinoly -external-db-save=[user,pass,host:port] y de esta manera Webinoly la usará de manera predeterminada (como si fuera localhost). Usa el parámetro -purge para remover cualquier dato guardado previamente.

* Es importante considerar que la url no debe contener el esquema (http/https) al inicio, para conectar con la base de datos externa y debe tenerse en cuenta que un diseño o implementación deficiente en la arquitectura de una solución de este tipo puede tener un impacto negativo en la velocidad de tu sitio, alta latencia o incluso múltiples errores o “timeouts” en la conexión.

** Se ha probado de manera exitosa con Amazon RDS usando como motor de base de datos MySQL, MariaDB y Amazon Aurora.

*** Webinoly no soporta Unix sockets en WP db_host.

WordPress Multisite

Es muy fácil convertir tu sitio WordPress en Multisite.

sudo site example.com -multisite-convert

Te solicitará y deberás ir a “Herramientas -> Configuración de la Red” y seleccionar el tipo de instalación (subdominio o subdirectorio); Webinoly hará toda la configuración de manera automatica una vez que hayas seleccionado el tipo de configuración.

* Si tu sitio ha sido instalado con la opción -subfolder únicamente estará disponible la opción “subdirectory” cuando hagas la conversión a multisite, WordPress no permite la configuración en subdominio en este tipo de instalación.

Remplazar Contenido

La función para remplazar contenido puede ser usada de manera independiente en cualquier otro sitio WordPress para buscar y remplazar cualquier palabra o cadena de caracteres en el contenido.

sudo site example.com -replace-content
# Saltar preguntar
sudo site example.com -replace-content=[buscar-esto,remplazar-con]

En caso de que tu sitio WP para clonar o remplazar contenido esté conectado a una base de datos externa será necesario introducir el usuario y password. Para omitir estas preguntas puedes usar la opción -external-db=[user,pass].

Tipo de Entorno en WordPress

Configura la variable WP_ENVIRONMENT_TYPE en WordPress:

  • production
  • staging
  • development
  • local
sudo site example.com -env=staging

En staging, development y local la FastCGI Cache se desactiva automáticamente. Además, la opción “Disuade a los motores de búsqueda de indexar este sitio” de WordPress “Ajustes > Lectura” se activará de manera automática.

En development y local el modo “debug” de WordPress se activa automáticamente. Y se desactiva al cambiar a “staging” o “production”.

# Ejemplos:

# Mantener activada la cache
sudo site example.com -env=staging -cache=on

# Crear sitio WordPress
sudo site example.com -env=development -wp

# El sitio clonado será configurado como "staging"
sudo site example.com -env=staging -clone-from=sub.example.com -overwrite=on

Subdirectorios Configurables

Una de las herramientas más poderosas para configurar tus sitios en el servidor es la capacidad para configurar de manera independiente cada subdirectorio de un sitio en particular.

sudo site example.com -html -subfolder=/one
sudo site example.com -php -subfolder=/two
sudo site example.com -wp -subfolder=/three
sudo site example.com -proxy -subfolder=/four

# Eliminar sitio en subdirectorio
sudo site example.com -delete -subfolder=/xxx

Incluso, es opcional tener un sitio en la raíz del dominio, es decir, es posible únicamente tener soporte en los subdirectorios configurados en cualquier combinación de configuraciones que sean necesarias.

# Ejemplo con subdirectorios y raíz vacía
+ example.com <empty>
  - /blog <wp>
  - /downloads <proxy>
  - /tickets <php>

# Otro ejemplo con un sitio estático en la raíz
+ example.com <html>
  - /news <wp>
  - /clientes <php>

Instalar WordPress en un subdirectorio

Puedes tener más de una instalación de WordPress en el mismo dominio.

sudo site example.com -wp -subfolder=/test

Siempre deberás especificar el argumento -subfolder para hacer referencia a este sitio y de esta manera diferenciarlo de una instalación común en la raíz del dominio.

sudo site example.com -delete -subfolder=/test
sudo site example.com -cache=on -subfolder=/test
sudo site example.com -multisite-convert -subfolder=/test
sudo site example.com -clone-from=dev.example.com -subfolder=/test
sudo site example.com -replace-content -subfolder=/test
sudo site example.com -env=staging -subfolder=/test
sudo site example.com -info -subfolder=/test
sudo webinoly -backup=local -wp=example.com -subfolder=/test
sudo webinoly -backup=s3 -add-db-pre=example.com -subfolder=/test
sudo webinoly -clear-cache=example.com -subfolder=/test
sudo httpauth example.com -wp-admin=on -subfolder=/test
sudo httpauth example.com -path=/test/folder/ -subfolder=/test
sudo log example.com -wp=on -subfolder=/test

Dominio parqueado o alias

Un dominio parqueado es un dominio adicional o alternativo que apunta hacia un sitio principal. Es una manera simple de acceder a tu sitio desde diferentes nombres de dominio.

sudo site example.com -parked

Al ejecutar el comando te pedirá ingresar el nombre del dominio principal hacia donde apuntará tu nuevo dominio parqueado. De igual manera puedes utilizar el comando de la siguiente manera para facilitar su uso:

sudo site example.com -parked=mainsite.com

Asegúrate de que el sitio principal se encuentre alojado en el mismo servidor.

Redireccionamiento de dominio

Todas las solicitudes a este dominio serán redireccionadas o reenviadas a otro dominio.

sudo site example.com -forward=example.org

Todos los parámetros de la solicitud son pasados al nuevo dominio. Si deseas eliminar estos parámetros y forzar la redirección a un único sitio puedes usar la opción -root=on.

# sudo site example.com -forward=https://example.org
example.com/news  -->  example.org/news

# sudo site example.com -forward=https://example.org -root=on
example.com/news  -->  example.org

Configuración Reverse Proxy

Para crear un sitio con la configuración de Reverse Proxy en Nginx:

sudo site example.com -proxy=[localhost:8080]
# Ejemplos:
sudo site example.com -proxy=[127.0.0.1:8080]
sudo site example.com -proxy=[https://example.com]
sudo site example.com -proxy=[http://example.com:8080]

# Ejecutas tu app Node.js en el puerto 3000
sudo site example.com -proxy=[localhost:3000]

# Ejecutas tu app Java en el puerto 8082
sudo site example.com -proxy=[localhost:8082]

# Ejecutas tu app Vue en el puerto 8080
sudo site example.com -proxy=[localhost:8080]

De la misma manera que en los demás sitios, los Reverse Proxy también cuentan con algunas reglas de básicas de seguridad, archivos con puntos (ocultos), así como algunos nombre y extensiones están bloqueados de manera predeterminada, lo cual es perfecto cuando tienes un sitio web detrás de tu Reverse Proxy, pero de igual manera este comportamiento puede no ser lo deseado en algunos casos. Es por eso que hemos creado los sitios “Reverse Proxy Dedicados” descritos abajo.

Reverse Proxy Dedicados

A diferencia de los anteriores, esta configuración es completamente transparente, lo cual puede ser lo ideal en algunos casos como por ejemplo en repositorios de archivos.

sudo site example.com -proxy=[https://repo.example.org] -dedicated-reverse-proxy

Cuando se crea un sitio “Reverse Proxy Dedicado”, entonces solo sitios “Reverse Proxy Dedicados” serán permitidos en los subfolders de este dominio y de la misma manera estos sitios dedicados no serán permitidos en los subfolders de cualquier otro tipo de sitio ya existente.

# Ejemplo: Repositorio S3 detrás de un Reverse Proxy
sudo site example.com -proxy=[https://s3.bucket1.aws.com] -dedicated-reverse-proxy

# Agregar un certificado SSL
sudo site example.com -ssl=on -manual=http

# Agrega un segundo bucket de S3 en un subfolder
sudo site example.com -proxy=[https://s3.bucket2.aws.com] -dedicated-reverse-proxy -subfolder=/images

Otro ejemplo usando una aplicación web:

# Ejemplo: Website APP en localhost
sudo site example.com -proxy=[localhost:8082]

# Agregar un certificado SSL
sudo site example.com -ssl=on -root-path=/opt/app/web

# En este caso puedes agregar cualquier otro tipo de sitio en un subfolder
sudo site example.com -wp -subfolder=/blog

Sitios Completamente Personalizados

Esta es la opción perfecta si deseas empezar a construir la configuración Nginx de tu sitio desde cero.

sudo site example.com -empty

Listo, ahora solo debes incluir tu configuración Nginx usando un archivo personalizado.

# Ejemplo
sudo site example.com -empty

# Archivo de configuración personalizada
sudo nano /var/www/example.com/custom-nginx.conf

# Configuración basica en /var/www/example.com/custom-nginx.conf
location / {
    try_files $uri $uri/ =404;
}

El nuevo sitio creado tiene su propio “server block” como cualquier otro sitio, dependiendo de tus necesidades es probable que requieras agregar al menos un bloque location / en tu configuración personalizada como se muestra en el ejemplo anterior.

De la misma manera que hacemos en todos los sitios, algunas ubicaciones básicas locations.conf son incluidas de manera predeterminada. Puedes usar -empty=blank para no incluir todas estas configuraciones predeterminadas, además algunas cabeceras HTTP serán removidas.

Herramientas de Administración

Algunas herramientas para facilitar la administración de tus sitios.

Clonar un sitio

Ahora puedes clonar cualquier tipo de sitio, no solo WP.

Esta función es también conocida por su uso en sitios de prueba durante la etapa de desarrollo.

sudo site example.com -clone-from=dev.example.com

Las siguientes características no serán heredadas al sitio clonado si se encuentran presentes: Certificado SSL, force-redirect, configuración de default-site o tools-site, o cualquier archivo “custom” de configuración Nginx.

Para sitios WordPress tome las siguientes consideraciones:

  • Todos los enlaces en el contenido de tu sitio serán actualizados automáticamente, puedes desactivar esta opción con el parámetro -replace-content=off.
  • Tome en cuanta que los sitios WordPres Multisite no pueden ser clonados, ya que cada sitio en la red es como si fuera independiente, lo que hace que no sea práctica clonar una red completa de sitios. Si solo quieres clonar un sitio de la red multisite, te recomiendo usar algún plugin gratuito de WordPress.
  • Además, puedes modificar el Tipo de Entorno en WordPress del sitio clonado usando el parámetro -env=staging.

Para clonar y sobrescribir un sitio existente puedes usar el parámetro -overwrite=on.

Ejemplo: Ciclo de Desarrollo

# Crea un nuevo sitio de desarrollo
# WP debug activado, cache desactivada y noindex para buscadores
sudo site dev.example.com -wp -env=development

# Sitio de muestra "staging"
# Debug desactivado, cache activada and noindex
sudo site staging.example.com -env=staging -clone-from=dev.example.com

# Sobrescribe tu sitio anterior en producción
# Cache activada, debug desactivado e index activado
sudo site example.com -clone-from=staging.example.com -cache=on -env=production -overwrite=on

# Actualiza el sitio en ambiente local
sudo site local.example.com -env=local -clone-from=example.com

# Envía las actualizaciones a producción
sudo site example.com -clone-from=local.example.com -cache=on -env=production -overwrite=on

¿Cómo puedo desactivar de manera temporal un sitio?

En cualquier momento puedes activar o desactivar un sitio alojado en tu servidor sin necesidad de borrarlo.

sudo site example.com -on
sudo site example.com -off

Eliminar un sitio web

Debes usar con precaución esta opción, ya que una vez eliminado un sitio no será posible recuperar los archivos.

sudo site example.com -delete

También puedes usar la opción “force” para omitir las preguntas sudo site example.com -delete=force.

# Tip - Bases de datos externas (Omitir preguntas)
# No borrar Base de Datos
sudo site example.com -delete=keep-db

# Base de Datos externa
sudo site example.com -delete=force -external-db=[user,pass]

# Revocar Certificado SSL
sudo site example.com -delete=force -revoke=on

Para eliminar todos los sitios hospedados en tu servidor:

sudo site -delete-all

Las bases de datos de tus sitios WordPress que estén actualmente en uso también serán eliminadas. Algunas otras DB’s podrian no ser eliminadas, por lo que es posible que queden datos almacenados remanentes de tus sitios eliminados.

# Ejemplo extendido
sudo site -delete-all=force -external-db=[user,pass] -revoke=on

# No borrar las bases de datos
sudo site -delete-all=keep-db

Durante el borrado de un sitio, si se encuentra una base de datos externa se intentara usar los datos de -external-db, si no se encuentran se preguntará al usuario que introduzca los datos necesarios. El parametro -revoke=on borrará el certificado SSL de un sitio si se encuentra, usa la opción “off” para conservar el certificado.

Los sitios configurados como default-site o tools-site no pueden ser borrados. Cuando la opción force o -delete-all es usada, se forzará el borrado de estos sitios y se configurará como default la opción correspondiente para prevenir errores.

Información de un sitio

Despliega un listado con información de tu sitio.

sudo site example.com -info

Lista de tus sitios

Para ver una lista de todos tus sitios alojados en el servidor, utiliza el siguiente comando:

sudo site -list

En la lista verás información de tu sitio:

  • Tipo de sitio: WordPress, HTML, PHP, Parked, Proxy, Forward, Subfolders.
  • Asignación: Si el sitio ha sido asignado como sitio “Default” o para acceso a las herramientas de Webinoly “Tools”.
  • Alertas: NoSSL, SSL-Staging, AccessLog, NoCache, NoAdminAuth, Debug.
# Lista filtrada

sudo site -list=nossl

Opciones de filtrado: disabled, main, html, php, wordpress, parked, proxy, forward, tools, default, ssl, nossl, sslstaging, accesslog, noaccesslog, cache, nocache, adminauth, noadminauth, debug, nodebug, wpenv.

Además, la opción -raw es soportada para eliminar el formato de la lista.

Para sitios con WP Environment Type que no sea “production” el tipo de sitio lo indicará de la siguiente manera: (WordPress:staging). Para filtrar estos sitios puedes usar la opción “wpenv”.

Configuración Personalizada

Configura tus sitios de acuerdo a tus necesidades.

Forzar WWW o no-WWW en un sitio

De manera predeterminada Webinoly configura tu sitio para aceptar ambas peticiones en tu dominio, es decir, example.com y www.example.com serán ambas validas cuando un dominio principal es usado, por ejemplo: example.com, (NO aplica en subdominios: sub.example.com).

Puedes forzar el uso y redireccionar las peticiones hacia cualquiera de tu preferencia.

sudo site example.com -force-redirect=<option>

Opciones:

  • www
  • root
  • off

En casos especiales donde un certificado SSL ha sido importado de otro proveedor y este no incluye el sudominio “www” o viceversa, podemos usar la opción -ignore-ssl de la siguiente manera: sudo site example.com -force-redirect=root -ignore-ssl.

Nginx FastCGI Cache

La herramienta más fácil y poderosa para optimizar tus sitios web:

  • FastCGI Cache for WordPress
  • Custom Nginx Cache

FastCGI Cache for WordPress

Junto con Nginx esta es la mejor optimización que puedes hacer para acelerar tu sitio WordPress. Olvídate de usar plugins obsoletos como W3 Total Cache, Super Cache o WP Rocket. FastCGI ha demostrado un rendimiento muy superior al momento de servir contenido en cache desde tu servidor.

Para activar/desactivar (on/off) FastCGI:

sudo site example.com -cache=on

De igual manera puedes activarlo desde la creación de tu nuevo sitio de la siguiente manera:

sudo site example.com -wp -cache=on

Puedes usar el parámetro -wp-cache-plugins (on/off) para omitir la pregunta sobre la instalación de los plugins sugeridos: sudo site example.com -cache=on -wp-cache-plugins=on.

Nginx Helper Plugin
Es altamente recomendable usar el plugin Nginx Helper para renovar o purgar el contenido en cache de manera dinámica y automática; de esta manera aseguramos mostrar siempre el contenido más actualizado cuando sea necesario.

Es importante configurar el “Purge Method” del plugin como “Delete local server cache file”, el soporte para el método purge/url lo hemos desactivado por considerarlo un riesgo de seguridad. De igual manera el “Caching Method” deberá estar configurado como “Nginx FastCgi Cache”.

Para modificar la configuración global de NGINX & FastCGI Cache consulta la documentación.

Custom Nginx Cache

La misma Cache de Nginx con todo el poder que ya conoces, ahora con el poder de una configuración independiente y aislada para cada sitio.

  • Sitios soportados: PHP, WordPress y Reverse Proxy
  • Configuración de cache independiente para cada sitio.
sudo site example.com -cache=custom

Cuando la Custom Cache es activada por primera vez en un sitio tomará la configuración global actual, despues de esto, puede iniciar a configurar la cache de su sitio usando las mismas opciones descritas en sección de configuracion global de FastCGI Cache y en este caso solo será aplicada a un sitio en especifico.

# Ejemplo

# Activar Custom Cache
sudo site example.com -cache=custom

# Configuración Personalizada
# Todas las mismas opciones disponibles: -delete, -list, -regex, etc.
sudo site example.com -cache=custom -times
sudo site example.com -cache=custom -skip-cache=/subfolder
sudo site example.com -cache=custom -skip-cookie-cache=app_logged_in
sudo site example.com -cache=custom -query-string-cache=one
sudo site example.com -cache=custom -query-string-never-cache=two

Cuando la Custom Cache es desactivada se guardará la configuración personalizada para usarse la siguiente vez que sea reactivada.

# Desactivar Custom Cache
sudo site example.com -cache=off

# En caso de que necesites remover completamente la configuración guardada para iniciar desde cero.
sudo site example.com -cache=custom -reset

Es importante tener en cuenta que cuando se usa Custom Cache en un sitio WP, este NO será preconfigurado para el uso de WP y debe comenzar esta configuración desde cero.

Además, cuando la Custom Cache es usada en un sitio que fue creado usando la opción -subfolder=/test, es importante tener en cuenta que solamente ese subfolder será guardado en cache y NO todo el dominio. Por ejemplo: sudo webinoly -clear-cache=example.com -subfolder=/test solo tendrá efecto sobre ese subfolder en especifico. Cada sitio es independiente y aislado, incluso si es un sitio en un subfolder configurado dentro de otro dominio.

Certificados SSL con Let’s Encrypt

Aprovechamos las facilidades que brinda Let’s Encrypt para generar certificados gratuitos para tu sitio y lo hacemos aún más sencillo para configurar tu sitio de manera fácil y rápida.

No hay pretexto para no migrar tu sitio a HTTPS, con solo ejecutar el siguiente comando tu nuevo sitio web estará completamente configurado para navegar de manera segura sobre HTTPS.

sudo site example.com -ssl=on

Durante la creación del certificado Webinoly te solicitará tu cuenta de correo electrónico, este correo se utilizará para registrar el nuevo certificado, además de ayudarte a darle seguimiento a la renovación periodica del mismo.

Si lo prefieres, puedes guardar tu cuenta de correo: sudo webinoly -email=user@example.com para omitir las preguntas durante la solicitud del certificado.

* En servidores existentes este comando actualizará el email registrado en Let’s Encrypt.
** El correo interno de Ubuntu root será configurado para redirigirse a esta dirección.

Los certificados expedidos por Let’s Encrypt tienen validez por un periodo de 90 días y antes de ese periodo se recomienda solicitar la renovación para mantenerlo actualizado. Webinoly de manera automatica checa una vez a la semana el estado de los certificados de todos tus sitios y los que presentan menos de 30 días de periodo de validez se solicita de manera automática su renovación. Por lo tanto, tu no deberás preocuparte, ya que Webinoly realiza todo el proceso de manera automática para mantener tus certificados y tus sitios siempre vigentes.

Durante cada chequeo de renovación semanal recibirás un correo en la cuenta que hayas registrado con el estado actual de cada certificado.

Una vez activado el certificado SSL, Webinoly configurará Nginx de manera automática para redirigir todo el tráfico de tu sitio de HTTP a HTTPS.

* La opción Must-Staple ha sido desactivada de manera predeterminada, si desea usar esta característica en sus certificados debe incluir el parámetro -must-staple=on.

Desactivar SSL en un sitio

Si por alguna razón necesitas desactivar el uso del certificado SSL en tu sitio, solo ejecuta el siguiente comando.

sudo site example.com -ssl=off
# Usa la opción "revoke=(on/off)" para omitir preguntas.
sudo site example.com -ssl=off -revoke=on

Puedes usar la opción -ssl=off incluso cuando el sitio ya no existe para eliminar certificados remanentes.

Certificados en sitios parqueados

La opcíon “-root” nos permite crear certificados para sitios en los cuales la raiz de sus archivos se encuentra en un lugar distinto al habitual; este es el caso de los sitios parqueados, ya que el dominio parqueado ni siquiera cuenta con un directorio raíz o archivos propios, sin embargo, apunta hacia otro sitio alojado en el mismo servidor.

sudo site example.com -ssl=on -root=mainsite.com

Un ejemplo práctico y común del caso anterior es en instalaciones WordPress Multisite con Domain Mapping, donde tienes uno o varios dominios parqueados (mapeados) en tu servidor apuntando a un sitio principal. Primera deberá hacer el proceso de mapear el dominio en WP antes de solicitar un certificado.

Certificados en sitios Reverse Proxy

La opcion “-root-path” nos permite especificar una ruta diferente como es el caso de los sitios en configuración Reverse Proxy donde los archivos no están guardados en una ubicación distinta a /var/www.

sudo site example.com -ssl=on -root-path=/opt/myapp/web

Únicamente para aplicaciones hospedadas en el mismo servidor, para servidores externos se debiera usa la validación manual descrita abajo.

Validación manual

Si deseas obtener un certificado en un servidor o para un sitio que no por alguna razón no es accesible de manera directa desde el exterior, puedes usar el método de validación manual.

sudo site example.com -ssl=on -manual=http

El método manual soporta la validación “http” y “dns”.

La validación “http” te solicitará colocar un archivo con un nombre y contenido especifico en tu sitio. Y la validación “dns” te solicitará colocar un registro TXT en tu DNS con un nombre y contenido especifico.

Certificados Wildcard

Cuando necesitamos un solo certificado para cubrir todos los subdominios (*.example.com). Este es el tipo de certificado que necesitamos en instalaciones WordPres Multisite en configuración de sub-dominio.

sudo site example.com -ssl=on -wildcard

Durante la creación del certificado Wildcard será necesario crear un registro DNS para comprobar la propiedad del dominio.

Para agregar un sitio a un certificado Wildcard existente:

sudo site sub.example.com -ssl=on -add-to-wildcard=example.com

Solo soporta sub dominios de primer nivel.

Renovación de certificados

Aunque Webinoly cuenta con un sistema redundante para la renovación automática de los certificados, tenemos la opción para forzar dicha renovación.

sudo site -ssl=renew

Este comando intentará renovar cualquier certificado disponible que vaya a expirar en menos de 30 días.

También podemos forzar la renovación todos los certificados:

sudo site -ssl=force-renewal-all

O de un certificado en especifico:

sudo site example.com -ssl=force-renewal

En el caso de dominios parqueados, sitios “reverse proxy” o certificados con validación manual, se debe incluir el parámetro -root, -root-path o -manual respectivamente necesario para forzar la renovación.

Entorno de pruebas de Certificados

Recomendamos encarecidamente realizar pruebas de tus proyectos usando el entorno de ensayo antes de utilizar usar certificados reales en el entorno de producción. Esto le permitirá hacer las cosas bien antes de emitir certificados de confianza y reducirá la posibilidad de que se enfrente a los límites de solicitudes.

sudo webinoly -conf-value_debug=true

Solo debes usar la variable “debug” en el archivo de configuración de Webinoly para activar el entorno de pruebas de Let’s Encrypt, usa el valor “false” para desactivar el ambiente de pruebas.

Certificados SSL Custom

¡Trae tu propio Certificado!

Puedes usar cualquier certificado de cualquier proveedor de tu preferencia.

Estos no son certificados reales, solo están destinados a ser utilizados con fines de prueba, obtendrá errores si intenta acceder a su sitio utilizando este certificado. Nunca debe usar estos certificados en un entorno de producción.

sudo site example.com -ssl=on -ssl-key=/path/cert.key -ssl-crt=/path/cert.crt -ssl-ocsp=/path/cert.pem

El parámetro -ssl-ocsp es opcional para soporte de OCSP.

Administrar Redirecciones

Crear una redirección es fácil, solo ejecuta el siguiente comando y sigues las intrucciones:

sudo site example.com -redirection

Remover una redirección:

sudo site example.com -redirection -delete
# Omitir preguntas
sudo site example.com -redirection -from=/path -to=/test -http-code=308

sudo site example.com -redirection -from=/path -to=http://example.com

sudo site example.com -redirection -from=/path -http-code=410

sudo site example.com -redirection -delete -from=/path

El parámetro -http-code es opcional, el valor default es 302. Los códigos HTTP soportados son: 301, 302, 303, 307, 308. Además y aún cuando no son propiamente redirecciones: 410, 444 y 451 son soportados (el destino “to” es omitido o ignorado).

También puedes usar la opción -exact para especificar una coincidencia exacta.

¿Que hace la opción "EXACT"?

Ruta: /news

https://example.com/news (match)
https://example.com/news/local/our-city (match)

Usando la opción "EXACT":
https://example.com/news (match)
https://example.com/news/local/our-city (no-match)

No es necesario especificar el parámetro -exact cuendo se use -delete, simplemente se removerán todos los “path” que coincidan.

La opción -regex nos permite usar expresiones regulares.

# Ejemplo
sudo site example.com -redirection -from='^\.(gif|jpg|jpeg)$' -to=/test -regex=insensitive

Las expresiones regulares en la linea de comandos deben escribirse usando comillas simples, como en el ejemplo anterior. Y soporta las siguientes opciones:

  • sensitive – Que es sensible a mayúsculas y minúsculas.
  • insentive – Que no es sensible a mayúsculas y minúsculas.
  • longest – Especifica la mejor opción y no continua evaluando las expresiones regulares.

Consulta la documentación oficial y algunos ejemplos sobre el uso de expresiones regulares en Nginx.

Listado de redirecciones:

sudo site example.com -redirection -list

Puedes usar -list -raw para remover el formato.

Configuración NGINX

Si necesitas agregar algunos parámetros a la configuración NGINX de tu sitio, puedes tener un archivo de configuración adicional localizado en el directorio /var/www/example.com el cual deberá ser nombrado de la siguiente manera: *-nginx.conf.

Estos archivos personalizados son soportados por todos los sitios de cualquier tipo.

¿Cómo agregar una configuración NGINX personalizada?

  • Por ejemplo /var/www/example.com/custom-nginx.conf sería un archivo válido.
  • Puedes agregar múltiples archivos de configuración: another-nginx.conf.
  • Los sitios creados como “subfolders” se regirán por la configuración del sitio principal.
  • Los sitios “parkeados” se regirán por la configuración del sitio principal.
  • No se recomienda modificar los archivos de NGINX actuales incluidos, ya que los cambios se perderán durante algunas actualizaciones. Existen algunas excepciones que pudieras tomar en consideración:
    • Archivos de configuración de Reverse Proxy pueden ser modificados de manera segura: /etc/nginx/apps.d/example.com-proxy.conf
    • Archivos de configuración de Custom Cache pueden ser modificados de manera segura: /etc/nginx/apps.d/example.com-wpcache.conf o/etc/nginx/apps.d/example.com-phpcache.conf
    • De hecho, todos los archivos en la carpeta apps.d de Nginx no se sobrescriben durante el proceso de actualización y pueden modificarse bajo su propio riesgo, en algunos casos Webinoly usa algunas líneas de código y texto como comentarios como referencias, cualquier cambio puede causar un comportamiento inesperado.

Webinoly detecta de manera automática si tu sitio es un dominio example.com (configura example.com y www.example.com) o subdominio sub.example.com (únicamente sub.example.com), esto para determinar la configuración más apropiada en Nginx de cada sitio. Dominios con un TLD no valido serán configurados como subdominio. Si por alguna razón necesitas forzar una determinada configuración, puedes hacerlo usando la opción -subdomain al momento de crear tu sitio o solicitar un certificado SSL.

Ejemplo: sudo site example.com -html -subdomain=true, o de igual manera sudo site sub.example.com -ssl=on -subdomain=false.

El comando sudo webinoly -external-sources-update es de uso interno para actualizar algunas listas externas (public-suffix y zonas horarias).

Si tienes alguna sugerencia, idea o comentario, por favor visita nuestro foro de soporte.