ip real con frontal proxy nginx, backend apache y wordpress

Por fin he encontrado la solución! otra de estas tareas pendientes que hacía que una instalación no funcionase como era esperado! en este caso me encuentro con dos frontales de nginx que actúan como proxy http y detrás de ellos está un wordpress sobre apache. Hace un tiempo, hice un post similar a éste, pero detrás estaba otro nginx.

Así que aquí dejo la solución.

Frontal nginx
En este caso tengo 2 ficheros, el de la configuración del dominio y otro con la configuración específica para los wordpress almacenado en el directorio snippets

# vi /etc/nginx/sites-available/lamardebits.org
server {
    listen 80;
    listen [::]:80;

    server_name lamardebits.org
                www.lamardebits.org;
    return 301 https://lamardebits.org$request_uri;

    #root /var/www/html/;
    include snippets/certbot.conf;
}


server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name lamardebits.org;

    include snippets/certbot.conf;

    # Aquí s'inclou el servidor intern i la protecció específica de WP
    include snippets/wordpress10.conf;

    ssl_certificate /etc/letsencrypt/live/lamardebits.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lamardebits.org/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_trusted_certificate /etc/letsencrypt/live/lamardebits.org/chain.pem;
}

Y la configuración específica para los wordpress

# vi /etc/nginx/snippets/wordpress10.conf
include conf.d/external-log.conf;
location / {
    proxy_pass http://172.31.0.145:6081;
    include proxy_params;

    location ~ \.php$ {
        proxy_pass http://172.31.0.145:6081;
        include proxy_params;

        location ~* wp\-login\.php {
            client_max_body_size 40M;
            proxy_pass http://172.31.0.145:6081;
            include proxy_params;
            include snippets/lmdb-protected.conf;
        }
    }

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    fastcgi_read_timeout 300;
    proxy_read_timeout 300;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP       $remote_addr;
    proxy_set_header  X-Forwarded-For $remote_addr;
    proxy_set_header  X-Forwarded-Host $remote_addr;

    add_header X-Frame-Options SAMEORIGIN;

}

La configuración de proxy de nginx la tengo así

# vi /etc/nginx/conf.d/proxy.conf
proxy_buffer_size         128k;
proxy_buffers           4 256k;
proxy_busy_buffers_size   256k;
client_max_body_size      32M;

proxy_read_timeout 1800;
proxy_connect_timeout 1800;
proxy_send_timeout 1800;
send_timeout 1800;             

Backend apache + wordpress

A …

WordPress: migrar sitios de un multisite a otro

Pues la de hoy (de las últimas semanas mas bien), es la de que tengo que migrar los sitios de un wordpress multisite a otro. El multisite actual lleva muchos años en funcionamiento y tras toquetear hace unos años arrastro algunos problemas que espero que se solucionen con la migración de los sitios a otro wordpress multisite nuevo. Para hacer la migración ambos wordpress deben estar en la última versión y actualizados.

El wordpress multisite de origen lleva 10 años funcionando y hay mogollón de basurilla en la base de datos, sitios que ya no existen, usuarios que pasaron a mejor vida y tablas de plugins que ya no se usan. Además aprovecho para hacer limpieza de plugins y temas que ya no se usan.

Lo primero de todo es hacer un backup del sitio de origen, tanto de la base de datos como de los datos.

A continuación instalo el nuevo en un nuevo contenedor (servidor), en mi caso, lo configuro tal como indico en este otro post que hice hace unos días sobre como montar el varnish y el apache. Anoto que para hacer la instalación del multisite es posible e incluso por mi experiencia recomendable hacerlo sobre el varnish configurado, así nos daremos cuenta de si algo está fallando desde el principio. A fecha de hoy poner PHP8 no es buena idea, hay muchos plugins y temas que aún no están adaptados a esta versión de PHP, así que mejor usar la 7.3 o la 7.4.

Lo …

WordPress + apache + varnish + frontal nginx

Hoy os traigo un post completito sobre la parte de sistemas de WordPress.

Hace ya demasiados días que tenía pendiente la actualización de las debian que alojaban mi wordpress multisite y la base de datos mysql (que las tengo en dos contenedores separados). No digo las versiones porqué se me cae la cara de vergüenza :P

El wordpress que tengo en La Mar de Bits tiene por delante 2 frontales haciendo de proxy http con nginx (donde además hago la gestión de los certificados de letsencrypt y redirección de puerto 80 a 443). Éstos apuntan al puerto expuesto de Varnish (servicio de cache) dentro del contenedor donde está el wordpress (puerto 6081). El varnish apunta en el apache y el apache sirve en el puerto 80 las páginas web de wordpress.

Vamos un cristo para llegar al wordpress que no veas :)

Voy a ir detallando las configuraciones que tengo en cada una de las partes de esta máquina

nginx (frontales)

Estas dos maquinas son las que están expuestas a internet y comparten el directorio de configuración gracias a glusterfs.

Para exponer ambas maquinas en internet en bind lo hago así:

@                               IN      A       109.69.10.251
@                               IN      A       109.69.10.241
@                               IN      AAAA    2a00:1508:6000:501::a1
@                               IN      AAAA    2a00:1508:6000:501::a2

frontal                 1H      IN      A       109.69.10.241
frontal                 1H      IN      A       109.69.10.251
frontal                 1H      IN      AAAA    2a00:1508:6000:501::a1
frontal                 1H      IN      AAAA    2a00:1508:6000:501::a2

www                     1H      IN      CNAME   frontal

A continuación, en nginx para cada sitio del wordpress tengo un fichero de configuración similar a éste …

Traducir template de wordpress

Estoy administrando un conjunto de webs multiidioma con el template panaroma, tenía toda la web traducida pero se me resistían algunos textos que vienen incrustados en el tema. El otro día buscando llegué a una página de wordpress donde estaban los ficheros de traducción de dicho tema, así que si existían traducir el template era posible, pero ¿cómo?

Simple aunque poco documentado y después de estar paseándome entre los directorios de wordpress porfín he hallado la solución! :D

En wp-content/languages/themes/ se hallan los ficheros de traducción de cada uno de los temas, algunos temas al instalarlos te los dejan ahí, pero normalmente no y tienes que añadirlos manualmente. Haz un ls antes de preguntar nada mas!

Así que simplemente nos vamos a éste directorio y nos descargamos los paquetes de idioma .po y .mo de translate.wordpress.org que corresponda a nuestro tema. Si el tema no está como proyecto (o la traducción es tan mala que mejor meterle mano uno mismo), en el directorio languages del tema encontraremos el fichero .pot (template) para traducir nosotros mismos el tema.

Recuerdo vagamente las veces que he traducido software el uso de poedit un software para traducir programas y luego que pasarlo a .mo era un coñazo, así que os dejo ésta web (po2mo.net) para pasar los .po a .mo sin muchas complicaciones :)…

WordPress multi-site + JetPack

Todos los que tengáis un wordpress sabréis las ventajas de usar los plugins “de la nuve”, aquellos que te permiten estadísticas, filtros de spam, instalación de extensiones desde el cms, etc. etc. pero también tiene sus desventajas y es que dependes de wordpress.com.
Hace ya unos días el servicio con wordpress.com era un poco malo, pero parece que finalmente han desarrollado otra plataforma para gestionar todos estos plugins, el jetpack.

Lo primero que tendremos que hacer es descargar el jetpack de forma manual (cuando iba a instalarlo automáticamente no me dejaba conectar, ya que me decía que la clave API era incorrecta).

Jetpack te agrupa las distintas herramientas de “la nuve” en un menú nuevo en la barra izquierda, pero una vez instalado falta activarlo y aquí el problema :( Todo el rato me soltaba este mensaje:

Jetpack could not contact WordPress.com: token_http_request_failed. This usually means something is incorrectly configured on your web host. name lookup timed out

Liada con el plugin wp-stats y varios sitios

Muchas veces pienso en que tendría que meter alguna operación matemática medio compleja a los botones de formulario que aparecen en mi ordenador, pero bueno, a más fallos, más soluciones. No hay mal que por bien no venga.

La cuestión es que tenemos un wordpress con un porrón de blogs y queremos activar el plugin wp-stats para saber las visitas que recibimos y cosas de estas, pero por algun motivo y por alguna cuestión esotérica, un blog ha empezado a compartir estadísticas con otro blog (por lo menos, hasta el momento sabemos que es posible hehe), pero tenemos que separarlos.

¿Cómo lo hacemos?…

Resumir los feeds en wordpress

Pues aquí vengo con una gran mejora y un gran alivio para estos planets que me siguen, a partir de ahora ya no os voy a torturar más con mis posts quilométricos ;)

El secreto está en Opciones > Reading > For each article in a feed, show > Summary

Y ale a correr.…

Spaces de microsoft usará wordpress

Pues aquí tenemos una noticia de estas que nos dejan perplejos pero aunque vengan de nuestros mayores enemigos, las aplaudimos, ya que esto hace que se acerquen un poquito mas a la mentalidad que tendría que predominar algún día, el todo libre y abierto.

No me enrollo mucho ya que aquí tenéis el artículo :)

http://www.enriquedans.com/2010/09/microsoft-adopta-wordpress-para-sustituir-a-sus-spaces.html

Gracias Edu ;)…

Subir ficheros desde el panel de wordpress sin cuenta FTP

Cabe decir que la versión 3 de wordpress está realmente fina y es realmente agradable trabajar con ella, pero cuando tienes que subir los ficheros te obligan de alguna forma a tener un arcaico servidor de FTP para subir las actualizaciones, temas y plugins y es un engorro. Pero hay un pequeño truquillo para poder subir los ficheros por HTTP directamente:

añadimos esta línea en nuestro wp-config.php

define('FS_METHOD','direct');

este sistema por contra va a permitir a cualquiera que tenga permisos de administrador o simplemente que se entre en una cuenta por fuerza bruta, exploiting o XSS sea mas sencillo subir ficheros al directorio wp-config.
Ante todo mi recomendación es la de siempre, passwords seguros, no seguir los links desde los mails sin estar seguro de su procedencia y mantener los sistemas al día y si es posible con sistemas de detección de exploits y auditoría del cms (esto irá en otro post :P).…

WordPress 3.0.1 multidominio

El wordpress como sabréis es un cms que permite montar un sistema de blogs realmente interesante, además a partir de la versión 3.0 el wordpress lleva algunas propiedades de wordpress mu, la versión para tener varios blogs bajo la misma instalación, pero esta versión peca de una mala gestión de los dominios, sólo es capaz de gestionar subdominios y directorios, pero a nosotros nos interesa otra cosa, así que vamos por la labor.

Lo primero de todo es instalar un wordpress 3.0.1: descargar de la web, descomprimir en el servidor, configurar la base de datos y hacer la instalación. A partir de ahí ya tenemos un wordpress funcional.…