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 …

CephFS: Montar ceph en local con Proxmox

Telita las vueltas que he dado para encontrar esta solución y todo por no fijarme bien!

Muy bien, partimos de que tenemos un Ceph funcionando correctamente y lo estamos usando para poner ahí nuestros contenedores y máquinas virtuales. Pero al hacer el backup nos interesa los datos pesados dejarlos fuera y tener un disco compartido en red es algo que es una maravilla para poder migrar libremente maquinas de un nodo a otro y además de forma muy rápida ya que no tiene que copiar los datos.

Hace días que me pregunto, ¿y cómo se hace para montar un pool de ceph como mountpoint para los datos mas pesados? Había buscado donde se montaban los datos, nada de nada, si proxmox daba alguna opción, no se daba la opción de montar ceph como mountpoint ni tampoco te deja usar este pool para hacer backups. Así que llevo con la mosca en la nariz unos días con este tema… hasta que hoy! tras instalar un nuevo cluster y poder jugar (sin romper) una instalación nueva me he puesto a mirar a fondo y tras unas horitas, al clavo!

Ceph lleva bastante tiempo en marcha y hay documentación de hace 4 años, además ha ido evolucionando muy rápido y en las últimas versiones han cambiado incluso de tecnología para escribir a disco, siendo bluestore la actual.

Tras muchas formas de hacerlo (desde el kernel, desde fstab, que crear el volumen a mano desde el servidor, etc.), ninguna me parecía muy fiable …

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 …

Servidor y cliente REST: Django REST framework + requests

Muchos de los posts de éste blog son pequeñas píndolas y recordatorios que me dejo para facilitarme mi tarea diaria de administración de sistemas y últimamente de desarrollo, los comparto públicamente porque al servirme a mi, espero que sirvan a otros. Hoy os traigo un nuevo post de éstos últimos, precisamente de uno que ha sido durante varios años una espinita clavada, programar un servidor API. Hace 3 años hice un módulo de interacción con la API de un proveedor con uno de los programas que tengo en PHP, pero me quedaba lo que era realmente la espinita, la de crear yo el servidor API y permitir que otros programas interactuasen con el mío.

Hace alrededor de 5 años, un cliente que usaba un programa mío me pidió de la posibilidad de interactuar con el programa mediante una API. En aquel entonces traté de desarollarlo, pero con el lenguaje que estaba usando (PHP) y los conocimientos que tenía entonces me resultó tarea imposible, además de la actitud del desarrollador web del cliente. En fin. Así que haber superado éste hito es una inyección de felicidad, superación y autoconfianza.

Vamos a empezar.

Marco y necesidad
Me encuentro con dos aplicaciones que estoy desarrollando con django, voy a llamarlas por su nombre, colibrí y cóndor. Colibrí es un programa experto para hacer auditorías compliance y para cada empresa permite tener un inventario de máquinas. Por otro lado está Cóndor que es un programa de comunicación cliente-empresa. Lo que queremos hacer es que …

Múltiples idiomas en django

No hay momento mas dulce en el desarrollo de un programa el ver que va tomando solidez y que puedas implantar detallitos interesantes en la generación de pdf, navegar por el programa que va a los sitios que tiene que ir, etc. Hoy vamos a hablar de una de estas otras cosas que señalan el avanzado estado de nuestro programa, la internacionalización, el disponer la página en varios idiomas. Vamos a contarlo!

Primero de todo recomiendo tener a mano la documentación de django y éste otro artículo de Alex Dzul al que le he copiado el título y la metedología.

Para resumir, lo que tendremos que hacer será configurar el settings.py, preparar y traducir la interfaz y finalmente generar los ficheros .po. En la documentación te habla primero de la generación de los ficheros de traducción y después desarrollar la traducción en la interfaz (templates), luego contaré porqué es mejor hacerlo al revés.

Así que empezamos

Primero modificaremos el fichero settings.py de nuestro proyecto

(venv) laura@melatonina:~/dev/colibri$ vi colibri/settings.py 
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))

[...]

MIDDLEWARE_CLASSES = (
    # ...
    'django.middleware.locale.LocaleMiddleware',
    # ...
)

[...]

# Internationalization
# https://docs.djangoproject.com/en/2.1/topics/i18n/
# https://www.pythoniza.me/multiples-idiomas-en-django/

LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'Europe/Madrid'
USE_I18N = True
USE_L10N = True
USE_TZ = True

from django.utils.translation import ugettext_lazy as _
LANGUAGES = (
    ('en', _('English')),
    ('es', _('Spanish')),
    ('ca', _('Catalan')),
)

# Definimos la ruta de los archivos de idiomas
LOCALE_PATHS = (
    os.path.join(BASE_DIR, 'locale'),
)

# Definimos el procesador de contexto para i18n
#from django.conf.global_settings import TEMPLATE_CONTEXT_PROCESSORS 

Generar pdf con pie/cabecera con python, pdfkit y wkhtmltopdf

Ya llevo varios meses peleándome con pdfkit, al tener que atender otras partes de mi programa lo he ido dejando hasta que realmente he tenido la necesidad de ponerme a hacer funcionar correctamente pdfkit. La documentación que he encontrado por ahí ha sido un poco confusa, además de que estaba teniendo problemas con la versión del wkhtmltopdf y me estaba volviendo loca!

Ahora mismo tengo la necesidad de crear un pdf con sus márgenes, cabecera, pie y numero de página, además no quiero que salga la cabecera y pie de página en la primera página.

Primero de todo tendremos que tener en cuenta que pdfkit hace uso del programa wkhtmltopdf, que está en los repositorios de debian, pero me encuentro que éste no está compilado con qt, como tal al usar según que opciones de la configuración de wkhtmltopdf me soltaba un error similar a éste:

The switch --enable-internal-links, is not support using unpatched qt, and will be ignored.
The switch --footer-center, is not support using unpatched qt, and will be ignored.
The switch --header-html, is not support using unpatched qt, and will be ignored.
The switch --footer-html, is not support using unpatched qt, and will be ignored.

Para ello lo que haremos será primero de todo desinstalar wkhtmlpdf instalado en el sistema e instalar el .deb que nos ofrecen en la página del proyecto de wkhtmltopdf.

# apt remove --purge wkhtmltox
# wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-1/wkhtmltox_0.12.6-1.buster_amd64.deb
# dpkg -i wkhtmltox_0.12.6-1.buster_amd64.deb

UPDATE Para debian 12 bookworm mirar éste repositorio

# wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-3/wkhtmltox_0.12.6.1-3.bookworm_amd64.deb

Proxmox: iptables nat vmbr0 y vmbr11

En éste caso la configuración que tenemos del servidor tenemos como siempre en vmbr0 una IP de guifi.net (que trato como ip local) y debido a que el numero de IPs públicas que tengo es limitada, tengo otro bridge vmbr11 con una red interna para comunicar las aplicaciones que sirven HTTP, luego tengo un contenedor con nginx y acceso a las 3 redes, la de guifi, la pública y la interna de las aplicaciones.

Para que las máquinas que están en la red de guifi y la de las aplicaciones puedan acceder a internet tendremos que configurar el NAT, para ello haremos lo siguiente:

En /etc/network/interfaces

root@wezen1A:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
	address 10.90.234.166
	netmask 255.255.255.224
	gateway 10.90.234.161
	bridge_ports eth0
	bridge_stp off
	bridge_fd 0
	post-up echo 1 /proc/sys/net/ipv4/ip_forward

iface eth1 inet manual

auto vmbr1
iface vmbr1 inet static
        address 192.168.10.1
        netmask 255.255.255.0
        bridge_ports eth1     
        bridge_stp off
        bridge_fd 0

auto vmbr138
iface vmbr138 inet manual
        bridge_ports eth0.138
        bridge_stp off
        bridge_fd 0

auto vmbr11
iface vmbr11 inet static
        address 192.168.100.1
        netmask 255.255.255.0
        bridge_ports eth0.11
        bridge_stp off
        bridge_fd 0

La vmbr1 la tengo destinada a ceph, para que las maquinas compartan el disco ahí, además con su switch a parte! :) la vmbr138 es la que uso para las IPs públicas, en ésta red no vamos a aplicar NAT porqué las máquinas que estén en ésta red tendrán como gateway la IP del router. En vmbr0 ponemos en post-up el …

Proxmox: habilitar virtualización anidada (nesting virtualization)

Uno de los problemas que me estoy encontrando últimamente es que los contenedores lxc que instalo con debian 10 no arrancan los servicios porque tengo que reconfigurar systemd para decirle que el PrivateTmp es false, por ejemplo para poder levantar apache2 tendría que hacer ésto

Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.
invoke-rc.d: initscript apache2, action "start" failed.
* apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2020-07-01 16:35:29 UTC; 9ms ago
     Docs: https://httpd.apache.org/docs/2.4/
  Process: 11730 ExecStart=/usr/sbin/apachectl start (code=exited, status=226/NAMESPACE)

Jul 01 16:35:29 wordpress systemd[1]: Starting The Apache HTTP Server...
Jul 01 16:35:29 wordpress systemd[11730]: apache2.service: Failed to set up mount namespacing: Permission denied
Jul 01 16:35:29 wordpress systemd[11730]: apache2.service: Failed at step NAMESPACE spawning /usr/sbin/apachectl: Permission denied
Jul 01 16:35:29 wordpress systemd[1]: apache2.service: Control process exited, code=exited, status=226/NAMESPACE
Jul 01 16:35:29 wordpress systemd[1]: apache2.service: Failed with result 'exit-code'.
Jul 01 16:35:29 wordpress systemd[1]: Failed to start The Apache HTTP Server.

# vi /lib/systemd/system/apache2.service
PrivateTmp=false
:wq
# systemctl daemon-reload
# systemctl start apache2.service

Pero me encuentro el mismo problema con otros servicios que instalo.

Por lo que entiendo systemd crea como una especie de “entorno virtual” para cada uno de los servicios y para que funcione correctamente, leyendo documentación veo que la solución es habilitar la virtualización anidada.

Así que en la documentación de proxmox encontramos ésta página que nos dice como hacerlo.

Tendremos …

Instalar entorno de producción de python

Una vez hemos desarrollado una aplicación con django nos interesará ponerla en producción. La forma correcta de hacerlo es usando uwsgi + nginx. Así que vamos a ello.

Mi aplicación corre sobre postgresql así que instalaremos los siguientes paquetes

# apt -y install nginx uwsgi uwsgi-plugin-python3 postgresql python3-psycopg2 libpq-dev git virtualenv memcached

Creamos el usuario y la base de datos postgresql

# su - postgres
$ createuser colibri_user
$ createdb -O colibri_user colibri_db
$ psql colibri_db
colibri_db=# alter user colibri_user with encrypted password 'XXXXXXXX';
colibri_db=# grant all privileges on database colibri_db to colibri_user;

Ahora clonamos el código del programa en /var/www

# cd /var/www/
# git clone git@git.capa8.net:blackhold/colibri.git

Creo el entorno virtual

# cd colibri
# virtualenv -p python3 venv

Entro en el entorno virtual y ejecuto los comandos necesarios para iniciar la aplicación

# source venv/bin/activate
# pip install -r requirements.txt
# ./clean.sh
# python manage.py runserver 0.0.0.0:5001

Ahora configuramos uwsgi para que apunte donde está nuestra aplicación de django

# cd /etc/uwsgi/apps-available
# vi colibri.ini
[uwsgi]
master = true
processes = 10
socket = /tmp/uwsgi-colibri.sock
uid = www-data
gid = www-data

;# with appropriate permissions - *may* be needed
;chmod-socket    = 664

chdir = /var/www/colibri
module = colibri.wsgi
home = /var/www/colibri/venv/
vacuum = true
env = DJANGO_SETTINGS_MODULE=colibri.settings
safe-pidfile = /tmp/uwsgi-colibri.pid
;harakiri = 20 # respawn processes taking more than 20 seconds
;limit-as = 128 # limit the project to 128 MB
max-requests = 5000
daemonize = /var/log/uwsgi/colibri.log
;callable = application
plugin = python37

Guardamos y lo activamos en …

Pyocclient: Apuntes

Abro éste post para ampliar un poco como se usa pyoocclient, una librería de python para gestionar un nextcloud. En éste post voy a mostrar como he solucionado el tema de crear directorios, subir ficheros, compartir ficheros, descargar un fichero (binario) y eliminar ficheros, pero la librería permite incluso hacer gestión de usuarios y algunas cosas mas, realmente da para seguir jugando :) En página podéis ver el código de la librería.…