Nammu — CMS y CRM ligero para proyectos

Nammu condensa todo lo que esperas de un gestor contemporáneo —edición Markdown, plantillas vivas, itinerarios interactivos y automatización social— en un paquete PHP 8 sin dependencias caprichosas. Es ligero, portable y lo bastante flexible como para lanzar un blog personal, un diccionario multimedia, un podcast, una newsletter, sistemas de avisos o un curso y generar tus propias estadísticas sin compartirlas con ninguna empresa.

La plataforma se distribuye bajo licencia EUPL y corre en cualquier hosting que ofrezca PHP 8+.

Qué incluye Nammu

Nammu combina en una sola instalación:

• Blog y páginas en Markdown.
• Podcast con podcast.xml y páginas HTML por episodio.
• Newsletter y lista de avisos.
• Itinerarios, cursos y colecciones de temas.
• Perfil del fediverso con notas manuales y agregación de RSS externas.
• Nodo propio en el Fediverso mediante ActivityPub.
• Emisión y recepción de Webmention para citas entre blogs.
• Biblioteca multimedia, buscador, SEO técnico, estadísticas propias y automatización social.

Requisitos mínimos

• PHP 8.0 o superior.
• Extensiones habituales: json, mbstring, iconv.
• curl muy recomendable para integraciones externas y redes sociales.
• gd recomendable para edición de imágenes, variantes WebP e imágenes de podcast.
• openssl para notificaciones push.
• Permisos de escritura sobre config/, content/, assets/, itinerarios/ y backups/.
• Composer es opcional. El núcleo funciona sin él, pero algunas integraciones mejoran si está disponible.

Instalación

1. Clona o copia el proyecto

Si el directorio del sitio ya existe y está vacío:

cd /var/www/html/<carpeta-publica>
git clone https://github.com/ciamaximalista/nammu.git .

Si prefieres descargar un ZIP, descomprímelo en la carpeta pública del dominio.

2. Asegura la estructura básica

Nammu trabaja sobre estas carpetas:

• config/
• content/
• assets/
• itinerarios/
• backups/

Si alguna no existe, créala:

mkdir -p config content assets itinerarios backups

3. Ajusta permisos

Configuración recomendada en un servidor típico con www-data:

sudo chown -R <tu-usuario>:www-data /var/www/html/<carpeta-publica>
sudo find /var/www/html/<carpeta-publica> -type d -exec chmod 2775 {} \;
sudo find /var/www/html/<carpeta-publica> -type f -exec chmod 664 {} \;

Sustituye:

• <tu-usuario> por tu usuario del sistema.
• <carpeta-publica> por la carpeta real del sitio.

Si tu servidor usa otro grupo para PHP o Apache (apache, nginx, etc.), cambia www-data por el correspondiente.

Importante:

• Si el cron o PHP-FPM corren como www-data, www-data debe poder escribir de verdad los JSON de config/.
• Esto afecta especialmente a stores que Nammu reescribe continuamente, como fediverso-following.json, fediverso-timeline.json, snapshots, colas sociales y otros ficheros de estado.
• En entornos multiinstancia, www-data también debe poder escribir _shared-cache/ y _shared-queue/ si los activas.

Comprobación rápida recomendada:

ls -ld /var/www/html/<carpeta-publica>/config
ls -l /var/www/html/<carpeta-publica>/config/*.json
id www-data

Si el cron va a ejecutarse con www-data, esos ficheros no pueden quedarse en un grupo sin permisos efectivos de escritura para ese usuario.

4. Configura el dominio o virtual host

Tu dominio debe apuntar a la carpeta donde está Nammu y ejecutar index.php con PHP 8+.

Ejemplos habituales:

• Apache con DocumentRoot /var/www/html/<carpeta-publica>
• Nginx con root /var/www/html/<carpeta-publica>

5. Entra al panel y crea el usuario inicial

Abre:

https://tu-dominio/admin.php

En el primer acceso Nammu crea el usuario inicial y guarda la configuración básica.

6. Configura lo esencial desde el admin

Nada más entrar, revisa estas pantallas:

1. Configuración: nombre del sitio, autor, idioma, modo blog/diccionario, URL del sitio y, si hace falta, declaraciones opcionales de multiinstancia para servidores con varias instalaciones. El bloque Formas de contacto para los lectores se guarda por separado dentro de esa misma pantalla para no interferir con la configuración general del sitio. Al final de esa pestaña puedes editar también llms.txt e identity.txt, con ayuda contextual para cada archivo.
2. Plantilla: tipografías, colores, portada, footer y botones de cabecera.
3. Difusión: redes sociales, push, podcast y metadatos sociales.
4. Lista: correo saliente y suscripciones si vas a usar avisos o newsletters.

7. Activa las dependencias opcionales

Si quieres notificaciones push:

cd /var/www/html/<carpeta-publica>
composer require minishlink/web-push

Si luego activas Push en Difusión, Nammu generará las claves VAPID.

Cron, automatización y backups

Qué tareas automáticas necesita Nammu

Nammu separa la automatización en tres fases:

php /var/www/html/<carpeta-publica>/admin.php --run-scheduled

La fase ligera se encarga solo de:

• refrescar actores seguidos en Fediverso,
• recoger respuestas y reacciones nuevas,
• precalentar unos pocos hilos recientes,
• y regenerar los snapshots ligeros de Inicio y Notificaciones.

La fase de mantenimiento va aparte:

php /var/www/html/<carpeta-publica>/admin.php --run-scheduled-maintenance

Esa segunda tarea se encarga de:

• publicar contenidos programados,
• procesar avisos y colas pendientes,
• reconstruir Actualidad,
• revisar Nisaba, Telex y otras RSS configuradas,
• descubrir y enviar Webmentions pendientes,
• enviar a redes sociales lo encolado,
• repartir publicaciones federadas pendientes,
• y procesar borrados/accepts pendientes.

La fase pesada va aparte:

php /var/www/html/<carpeta-publica>/admin.php --run-scheduled-heavy

Esa tercera tarea se encarga de:

• precalentar cachés y hilos de Fediverso,
• regenerar snapshots del panel de Fediverso,
• y dejar listo el admin para lectura rápida.

Además, Nammu incluye:

• backup diario de estadísticas: core/backup-daily.php
• backup completo semanal: core/backup-weekly.php

Cómo editar el cron correctamente

La forma recomendada es editar el cron del usuario del servidor web:

sudo crontab -u www-data -e

Si usas ese comando, las líneas van sin la columna www-data.

Antes de dar el cron por bueno, conviene comprobar dos cosas:

sudo crontab -u www-data -l
sudo systemctl status cron --no-pager

Si editas el cron de www-data, las tareas se ejecutarán con ese usuario. Por tanto, todos los JSON y directorios que Nammu actualiza en caliente deben ser escribibles por www-data.

Para que Fediverso cargue ágilmente en el admin sin provocar solapes ni picos de CPU, conviene separar el cron en tres fases:

• admin.php --run-scheduled cada 5 minutos para la parte ligera de Fediverso: novedades de actores seguidos, respuestas y reacciones recibidas, precalentado de unos pocos hilos recientes y reconstrucción ligera de Inicio y Notificaciones.
• admin.php --run-scheduled-maintenance cada 15 minutos para mantenimiento no crítico: publicación programada, cola de avisos, reconstrucción de Actualidad, RSS sociales, cola social, entregas federadas pendientes y cola de borrados/accepts.
• admin.php --run-scheduled-heavy una vez por hora para la parte pesada: precalentado amplio de hilos y reconstrucción completa de snapshots del panel de Fediverso.

Las tres deben ejecutarse con el usuario del servidor web, escalonando las distintas instancias y protegiendo cada una con flock. Además, Nammu usa un lock interno común para evitar que light, maintenance y heavy se solapen entre sí aunque el cron las dispare demasiado cerca.

Bloque de cron recomendado

*/5 * * * * flock -n /tmp/<carpeta-publica>-run-scheduled.lock php /var/www/html/<carpeta-publica>/admin.php --run-scheduled >> /var/www/html/<carpeta-publica>/backups/cron.log 2>&1
12,27,42,57 * * * * flock -n /tmp/<carpeta-publica>-run-scheduled-maintenance.lock php /var/www/html/<carpeta-publica>/admin.php --run-scheduled-maintenance >> /var/www/html/<carpeta-publica>/backups/cron.log 2>&1
7 * * * * flock -n /tmp/<carpeta-publica>-run-scheduled-heavy.lock php /var/www/html/<carpeta-publica>/admin.php --run-scheduled-heavy >> /var/www/html/<carpeta-publica>/backups/cron.log 2>&1
15 3 * * * flock -n /tmp/<carpeta-publica>-backup-daily.lock php /var/www/html/<carpeta-publica>/core/backup-daily.php --retention=7 >> /var/www/html/<carpeta-publica>/backups/backup.log 2>&1
30 3 * * 0 flock -n /tmp/<carpeta-publica>-backup-cleanup.lock php /var/www/html/<carpeta-publica>/core/backup-daily.php --cleanup-only --retention=7 >> /var/www/html/<carpeta-publica>/backups/backup.log 2>&1
45 3 * * 0 flock -n /tmp/<carpeta-publica>-backup-weekly.lock php /var/www/html/<carpeta-publica>/core/backup-weekly.php --retention-weeks=8 >> /var/www/html/<carpeta-publica>/backups/backup-full.log 2>&1

Si usas el planificador central multiinstancia, la forma más robusta es ejecutarlo con rutas absolutas y timeout:

* * * * * /usr/bin/timeout -k 10s 50s /usr/bin/flock -n /tmp/<cluster>-run-cluster.lock /usr/bin/php /var/www/html/<carpeta-publica>/admin.php --run-cluster-scheduled >> /var/www/html/<carpeta-publica>/backups/cluster-cron.log 2>&1

Así evitas que un proceso colgado retenga el lock indefinidamente.

Si además quieres refrescar en segundo plano las link cards del Fediverso para recuperar og:image sin cargar la petición web ni las fases light, maintenance o heavy, añade un cron separado y escalonado por blog. Ese proceso:

• solo descarga el HTML de la URL remota, no la imagen binaria,
• resuelve og:title, og:description y og:image,
• guarda el resultado en caché,
• y deja que la página pública del perfil/hilos lea solo esa caché.

Bloque recomendado para link cards federadas

5-55/10 * * * * /usr/bin/flock -n /tmp/memoria-fediverse-link-cards.lock /usr/bin/php /var/www/html/blogs/memoria/admin.php --run-fediverse-link-card-refresh >> /var/www/html/blogs/memoria/backups/fediverse-link-cards.log 2>&1
6-56/10 * * * * /usr/bin/flock -n /tmp/maximalismo-fediverse-link-cards.lock /usr/bin/php /var/www/html/blogs/maximalismo/admin.php --run-fediverse-link-card-refresh >> /var/www/html/blogs/maximalismo/backups/fediverse-link-cards.log 2>&1
7-57/10 * * * * /usr/bin/flock -n /tmp/terceroslugares-fediverse-link-cards.lock /usr/bin/php /var/www/html/blogs/terceroslugares/admin.php --run-fediverse-link-card-refresh >> /var/www/html/blogs/terceroslugares/backups/fediverse-link-cards.log 2>&1
8-58/10 * * * * /usr/bin/flock -n /tmp/lacandela-fediverse-link-cards.lock /usr/bin/php /var/www/html/blogs/lacandela/admin.php --run-fediverse-link-card-refresh >> /var/www/html/blogs/lacandela/backups/fediverse-link-cards.log 2>&1
9-59/10 * * * * /usr/bin/flock -n /tmp/communalia-fediverse-link-cards.lock /usr/bin/php /var/www/html/blogs/communalia/admin.php --run-fediverse-link-card-refresh >> /var/www/html/blogs/communalia/backups/fediverse-link-cards.log 2>&1
0-50/10 * * * * /usr/bin/flock -n /tmp/juan-fediverse-link-cards.lock /usr/bin/php /var/www/html/blogs/juan/admin.php --run-fediverse-link-card-refresh >> /var/www/html/blogs/juan/backups/fediverse-link-cards.log 2>&1

Ese escalonado evita que todas las instancias resuelvan metadata remota a la vez y deja la carga separada del planificador central del cluster.

Si además quieres dejar constancia explícita en el log cuando el lock esté ocupado o salte el timeout, puedes envolver esa misma línea con un bash -lc, pero la variante simple de arriba suele ser la más fácil de guardar y mantener en crontab.

Si mantienes varias instalaciones Nammu en el mismo servidor, no las lances todas en el mismo minuto. Lo recomendable es escalonarlas con ejemplos genéricos como