Necesito cambiar la raíz de WordPress …

Posted on by

… en la instalación multisite que mencioné aquí, dado que, por ahora, vamos a mantener la página web estática de la que me quejé.

El escenario

No sería mayor problema si no fuese porque la administración principal de la instalación está en empresa.net y yo necesito moverla a blog.empresa.net o no podré añadir nuevos complementos, ni temas, ni actualizar, ni nada (un drama).

Por lo que he podido entender de la lectura de la documentación, existen dos URL importantes en una instalación de este tipo.

  • El URL del sitio (site address) que es donde se espera que la gente acceda al contenido.
  • El URL de la instalación (wordpress address) que es donde residen los programas del núcleo.

Las opciones que tengo, sin añadir un nuevo servidor virtual al DNS, son:

  1. Emplear el nombre de la máquina principal (http://tlp.empresa.net) como sede del núcleo de WordPress.
  2. Seguir usando el mismo URL pero cambiando el puerto (http://empresa.net:9999 por ejemplo).

La primera opción tiene la dificultad de que tengo varios servicios más allí situados, en directorios, y me vería obligado a quitárselos a WordPress con redirecciones desde el servidor web. No es complicado pero no me termino de sentir a gusto. También es cierto que ya de paso podría situarlos todos bajo un lugar y así minimizar la configuración. Algo como https://empresa.net/admin/mysql para el programa phpmyadmin y demás.

La segunda opción parece menos farragosa pero tengo mis dudas acerca de si en el URL base de WordPress se admite bien el puerto. Y tampoco las tengo todas conmigo dado que la instalación es multiblog y se menciona mucho la actualización de la base de datos como solución a éste problema.

He estado mirando la configuración estándar de WordPress para un sitio multiblog y se presenta así en el archivo .htaccess:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

Esto es, si lo que solicitan es un archivo o un directorio existente se usa como definitivo. En caso contrario entra dentro de los mecanismos del programa y lo gestiona WordPress.

Nota: Por si acaso he realizado una prueba creando un enlace simbólico en /var/www/wordpress/ldap a /usr/share/phpldapadmin/ y, solicitando la página principal del blog de esta forma https://blog.empresa.net/ldap, se accede directamente al programa phpldapadmin.

Así que el plan es el siguiente:

  1. Mover todas las aplicaciones web que están ahora en el raíz de tlp.empresa.net a una ruta especial (/admin):
    1. La mayor parte de estas aplicaciones web (piwik, phpldapadmin y demás) son simples enlaces simbólicos al directorio donde residen los archivos correspondientes
    2. También me permite someterlos todos a un control extra de acceso para que no estén tan expuestos.
  2. Cambiar el URL del blog principal de WordPress para dejar libre el dominio raíz hasta que tengamos alguna solución alternativa.

Moviendo aplicaciones web

Con más o menos acierto he conseguido que las aplicaciones web que utilizo para administrar ciertos aspectos del servidor aparezcan ahora reunidas bajo una misma URL: https://tlp.empresa.net/admin.

Para ello he tenido que crear un directorio con enlaces a todos ellos

root@tlp:/var/www# ls -ltra webapps/
total 8
drwxr-xr-x 8 www-data root 4096 oct 19 10:11 ..
lrwxrwxrwx 1 root     root   24 oct 19 10:11 ldap -> /usr/share/phpldapadmin/
lrwxrwxrwx 1 root     root   22 oct 19 10:11 mysql -> /usr/share/phpmyadmin/
lrwxrwxrwx 1 root     root   11 oct 19 10:18 piwik -> /opt/piwik/
lrwxrwxrwx 1 root     root   31 oct 19 10:19 users -> /usr/share/ldap-account-manager
drwxr-xr-x 2 root     root 4096 oct 19 10:19 .
root@tlp:/var/www#

y un archivo de configuración en el servidor web:

Alias /admin /var/www/webapps

<Directory "/var/www/webapps">
        Options Indexes FollowSymLinks
</Directory>

Aunque ésto es sólo para que se pueda acceder a las aplicaciones bajo un único punto. Queda el detalle de conservar la configuración específica de cada una de ellas, compleja en algunos casos, que suele estar en un archivo de nombre apache.conf en su directorio de configuración.

Por ejemplo la aplicación phpldapadmin define sus ajustes en /etc/phpldapadmin/apache.conf  así que lo que hacemos es incluirla de forma global en la configuración del servidor. Esto es, copiamos el archivo a /etc/apache2/conf-available y la activamos con el programa a2econf. Con el resto seguimos el mismo procedimiento.

Protegiendo aplicaciones web

Dado que tengo instalado en el servidor un directorio LDAP contra el que verifico la identidad de los usuarios he buscado lo mismo para proteger un URL del servidor web. El módulo authnz_ldap viene incluido en la instalación del paquete Debian por lo que no hay más que pasar a configurarlo y asignarlo a la zona que queremos proteger.

En este caso lo que he hecho ha sido añadir la siguiente estrofa a la configuración del directorio de estas aplicaciones:

Alias /admin /var/www/webapps

<Directory "/var/www/webapps">
        Options Indexes FollowSymLinks
</Directory>

<Location /admin>
        AuthType Basic
        AuthBasicProvider ldap
        AuthName "Herramientas administrativas"
        AuthLDAPURL "ldap://localhost/ou=users,dc=empresa,dc=net?uid?sub?(objectClass=*)"
        Require valid-user
</Location>

Y funciona estupendamente; me he limitado a indicar que cualquier usuario registrado en el directorio LDAP pueda entrar dado que me parece que como primera barrera es más que suficiente. Se pueden usar grupos o cuentas específicas pero está más allá de lo que pretendo.

Cambiando la URL principal de WordPress

En las instalaciones simples, las que sólo gestionan un blog, es más sencillo realizar los cambios dado que no es necesario internarse en la base de datos y se pueden cambiar los valores en la configuración. Ojo que ésto es lo que he leído, no he llegado a comprobarlo porque no he tenido necesidad.

En este caso actuaré en dos sitios: la base de datos y la configuración.

En la base de datos

Respecto a la base de datos existen algunos complementos que permiten realizar búsquedas y sustituciones de valores en las tablas, pero en mi caso prefiero estudiar primero la estructura y realizar los cambios empleando un acceso directo a la base de datos.

Según la documentación referente a las instalaciones multi-blog existen tablas globales y tablas particulares para cada blog. Dado que la característica multisite es un añadido, las tablas particulares sin un número en el nombre hacen referencia al primer blog (wp_options); las siguientes comienzan por el número dos y lo intercalan en el nombre. Esto es, los parámetros del segundo blog se guardarían en wp_2_options y así sucesivamente.

  • Tablas globales
    • wp_blogs: cada blog creado queda registrado aquí con su identificador numérico global, el dominio bajo el que se aloja y la ruta dentro de él.
    • wp_site: contiene la dirección del blog principal y, por ende, la que da acceso al escritorio principal de la instalación. Contiene el identificador numérico del blog, el dominio y la ruta.
    • wp_sitemeta: conserva los parámetros generales de cada blog, incluyendo el usuario administrador, el nombre del blog y la descripción.
  • Tablas específicas
    • wp_options o wp_N_options: almacenan los parámetros del menú de administración del blog que pueden consultarse en la referencia oficial, y otros detalles como la URL del blog (siteurl) y la URL de la instalación (home).

En mi caso necesito que el blog principal que estaba situado en https://empresa.net pase a estar en https://tlp.empresa.net. Sé que voy a tener un problema después, al crear otros blogs, porque WordPress, en las instalaciones basadas en subdominios, considera que los otros blogs se situan siempre en un dominio de nivel superior al indicado en el principal. Si éste se encuentra en empresa.net los siguientes blogs estarán en nombre.empresa.net y no al mismo nivel. Cruzaré ese puente cuando llegue a él. Por ahora voy a cambiar las URL en las siguientes tablas:

  1. wp_site porque guarda el dominio principal.
  2. wp_sitemeta porque el URL del blog está almacenado allí.
  3. wp_blogs porque es dónde se localizan todos los blogs por URL.
  4. wp_options por la misma razón pero ya a nivel local del primero de los blog.

En la configuración

En el archivo /var/www/wordpress/wp_config.php me he asegurado de definir lo siguiente:

define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'tlp.empresa.net');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

Y eso es todo. He reiniciado por si acaso el servidor web y accedido al sitio sin ningún problema; los URL de las entradas y los programas se construyen al vuelo e incluso he podido recuperar contraseñas.

Sólo queda recordarme que para gestionar la red no vale con un usuario con rol administrativo, es necesario que sea el super administrador, esto es, el usuario con el identificador con valor 1 en la tabla wp_users.

Enlaces y referencias