Bien, llegó la hora. Es el momento de atacar el que sin duda es el anzuelo con el que el Sr. Google más nos tiene cogidos de los pelendengues. Todo ese conjunto de servicios con los que casi sin darnos cuenta nos hemos acostumbrado a vivir y que resultan más engorroso sustituir. Me estoy refiriendo, como no, a los servicios de sincronización de datos tales como calendarios, agendas telefónicas, fotografías, archivos, etc. En resumen, todo eso que de unos años a esta parte nos ha dado por llamar «la nube». Y bien llamado, porque la verdad es que es que un poco en las nubes hemos tenido que estar todo este tiempo para pensar que era buena idea dar todos nuestros datos privados a una empresa para que nos los guarde, y pensar que lo iba a hacer «gratis». En fin…
El problema
Ponga una «nube» en su vida, bien podría ser el eslógan de la última década. Práctico es, desde luego. Nos permite llevar nuestros datos de aquí para allá y mantenerlos sincronizados en distintos dispositivos, amén de proporcionarnos una sencillísima manera de mantener copias de seguridad. ¿Y qué es una «nube»? Pues lo cierto es que, en la práctica, una «nube» no es sino un ordenador conectado a internet 24×7, fiable y con buena conectividad para que esté siempre accesible. Y esto hace que la solución no sea tan inmediata como en los capítulos anteriores.
Después de darle unas cuantas vueltas, he reducido las posibles soluciones a estas tres posibilidades que voy a sugerir.
- Contratar un servicio similar a Google pero de pago. Si estás pensando que menuda melonada acabo de proponer, porque para qué voy a pagar a una empresa para obtener lo mismo que me da Google gratis, igual conviene que le eches un vistazo al capítulo 1 y luego seguimos. Obviamente Google no es gratis; le estamos pagando con nuestros datos sacrificando nuestra privacidad. Visto así, la propuesta es en realidad muy sencilla: Tener lo mismo pero pagado con dinero en lugar de en especies, y así conservamos la privacidad.
- Instalar nuestro propio servicio de sincronización en un servidor virtual alojado en un proveedor de alojamiento, similar a los que contratamos para albergar nuestras páginas web. En realidad esta sería la opción más recomendable, ya que nos permite mantener el control (casi) total de nuestros datos sin necesidad de tener que fiarnos (casi) de las políticas de privacidad de la empresa que decidamos contratar en la opción 1, y además nos vemos libres del engorro del mantenimiento del ordenador, el acceso a internet, las copias de seguridad, etc. A cambio debemos ser conscientes de que tendremos que abonar una cantidad mensual comparable a la de la opción 1, y que parámetros tales como el rendimiento de la máquina, la velocidad del acceso y, sobre todo, la capacidad del disco duro se verán muy influidos por la mensualidad que elijamos.
- Instalar los servicios de sincronización en nuestro propio servidor físico, de nuestra propiedad particular y privada, y alojado en nuestro hogar o local. De entrada yo no lo recomendaría: es engorroso de mantener, dependemos de que no se nos corte la conexión a internet ni la alimentación eléctrica y encima hay que pagar la luz, que cada vez está más cara. A cambio… tendremos un control absoluto tanto sobre los datos como sobre los ajustes del servidor, no necesitaremos fiarnos de ningún tercero que pudiera eventualmente querer acceder de manera lícita o ilícita a nuestros datos y, además, tener un servidor propio resulta ser un juguete de lo más molón.
Llegados a este punto, quien me conozca un poco seguramente ya habrá adivinado la opción que yo he elegido para mi (una pista: la 1 no es). Quien elija la uno no necesita más instrucciones, ya que el servicio se las proporcionará. Y para todos los demás, digamos que la manera de proceder es prácticamente idéntica para los casos 2 y 3. Así, que vamos allá.
La solución
Así que hemos decidido instalar nuestro propia «nube», sea un en un servidor externo o uno propio, por lo que necesitaremos el software adecuado. Y, como siempre, no me voy a detener en analizar las posibles alternativas, sino que me limitaré a señalar la que ha sido adecuada para mí. Y en este caso, el ganador es NextCloud.
Se trata de un software de código abierto que proporciona todos los servicios en nube que utilizamos de manera habitual: calendarios, contactos, archivos, correo electrónico, comunicación… Su código está disponible para la descarga en su página web y está ampliamente documentado. Para su instalación no necesitamos demasiados recursos de computación. Un mini-pc hará la función perfectamente. Como mucho tendremos que asegurarnos de disponer de suficiente espacio de disco duro para nuestras necesidades y, aún en el peor de los casos, seguro que superamos ampliamente los ridículos 15 Gb que nos «regala» el Sr. Google.
Preliminares
La instalación de NextCloud debe hacerse sobre un típico sistema LAMP, acrónimo de Linux, Apache, MySQL y PHP. Es decir, un servidor Linux con servidor web, base de datos y php. Lo mismo que se utiliza para alojar una página web promedio y que cualquier proveedor de alojamiento ya proporciona.
Cuenta la leyenda que en aquellos tiempos en los que internet comenzaba a expandirse y yo todavía tenía pelo, un grupo de programadores decidió poner un poco de orden en aquellas salvajes llanuras de la 
World Wide Web. Así que se pusieron manos a la obra para crear un servidor web potente y versátil. Pero para no reinventar la rueda, lo que hicieron fue parchear («patch», en inglés) el servidor web por entonces más popular, creado por el Centro Nacional de Aplicaciones de Supercomputación (NCSA por sus siglas en inglés), el NCSA HTTPd. Que durante su desarrollo a manos de un puñado de frikis cachondos lo que comenzara siendo conocido como un «patched server» terminara llamándose «apache server» no tiene nada de sorprendente. Puedo imaginarme perfectamente a los ingenieros partiéndose de risa haciendo el indio mientras picaban código como locos…
Apache ha sido el líder indiscutible de la WWW desde su aparición hasta ahora, si bien últimamente ha empezado a perder terreno a favor de servidores más modernos. En realidad, el Apache que vamos a instalar se llama Apache2. Se trata de la segunda versión del mítico Apache una vez que se decidieron a reescribirlo desde cero, como debe ser.
Algunas notas sobre su configuración
El directorio raíz para los archivos de los sitios web es el siguiente: /var/www/
La instalación trae un sitio por defecto que nos servirá para comprobar que el servidor está funcionando. Dicho sitio se encuentra en /var/www/html y será accesible conectándonos directamente a la IP del servidor.
En la práctica, el sitio web consiste en un único archivo index.html. En el manual de Apache2 se suele indicar que para levantar nuestro sitio web lo que tenemos que hacer es sustituir este archivo por los archivos de nuestro sitio. Sin embargo yo prefiero crear una nueva carpeta y mantener el sitio por defecto. En caso de problemas, tener disponible un sitio por defecto para comprobar el funcionamiento básico del servidor me ha resultado útil más de una vez.
En mi caso, el sitio web adicional para nextcloud irá en: /var/www/nextcloud
Sitios web
Cada uno de los sitios web que habilitemos en Apache2 lleva el nombre de Servidor Virtual (Virtual Host) Este esquema de configuración permite servir tantos sitios como queramos, distinguiendo unos de otros mediante el nombre DNS con el que accedamos al servidor y/o con el número de puerto. La configuración para cada sitio se guarda en un archivo en el siguiente directorio de sitios disponbles: /etc/apache2/sites-available/
Si miramos el contenido inicial de este directorio veremos dos plantillas preconfiguradas: una para sitios http normales y otra para sitios con SSL habilitado (sitios https). Normalmente en estos archivos especificamos cosas como el puerto, en nombre DNS con el cual nos conectamos, el directorio web, etc. Para configurar el sitio, copiaremos la plantilla deseada y la personalizaremos con un nombre de archivo que identifique a nuestro sitio y modificaremos los parámetros oportunamente.
Por ejemplo, puedo crear un sitio http en nextcloud.conf. Sin embargo, como voy a utilizar SSL, tendré que utilizar la plantilla preconfigurada para SSL que copiaré a un archivo nextcloud-ssl.conf.
Y ahora, para habilitarlo: a2ensite nextcloud.conf Y para deshabilitarlo: a2dissite nextcloud.conf
Nota: Estos comandos, en realidad, lo único que hacen es crear y destruir enlaces simbólicos en el directorio /etc/apache2/sites-enabled/ Si no utilizáramos el comando tendríamos que crear estos enlaces manualmente y el resultado sería el mismo.
Añadiendo algo de seguridad
Si queremos habilitar SSL, lo cual es sumamente recomendable, habilitaremos el siguiente módulo:
a2enmod ssl
service apache2 reload
Nota: Apache2 genera de manera automática un certificado que será utilizado por defecto cuando habilitemos ssh. Este certificado no está firmado por una autoridad de certificados («Certificate Authority, o CA), sino que está autofirmado. Básicamente, lo que esto implica es que no hay una entidad de un nivel superior que garantice que el servidor sea quien dice ser, sino que es el propio servidor el que se identifica a sí mismo. En condiciones normales esto se considera un riesgo de seguridad y el navegador que utilicemos para conectarnos al servidor nos advertirá de ello. Sin embargo, al ser nosotros mismos quienes gestionamos directamente el servidor, podemos obviar este aviso de manera segura (ya que, obviamente, nosotros ya sabemos quienes somos y no necesitemos que nadie nos lo confirme… ¿o no?). Lo importante es que el acceso a los datos se estará realizando por un canal cifrado, que es de lo que se trata. Sin embargo, si tal aviso nos resulta engorroso o somos algo maniáticos de la seguridad, podemos recurrir a un certificado gratuito generado y firmado por una CA de verdad, como es Let’s Encrypt.
Let’s Encrypt
Ahora, si quiero un certificado de verdad, instalo el programa Certbot. Se trata de un software que, mediante el protocolo ACME (Sí, no es coña) nos permite verificar que tenemos control sobre el dominio al cual irá asociado el certificado. Para ello será necesario tener previamente un sitio web funcionando con HTTP, en el puerto 80, en el mismo dominio para el cual voy a solicitar el certificado. Puede ser cualquier sitio, incluso el sitio por defecto de Apache2. Además, una vez instalado el certificado, el sitio se puede deshabilitar.
sudo apt update
sudo apt install software-properties-common
sudo apt install python3-certbot-apache
Ahora vamos a obtener e instalar el certificado. Y, como para casi todo en esta vida, hay dos posibles maneras: la fácil y la buena.
- La fácil consiste en una única instrucción que genera el certificado y configura Apache2 para usarlo, todo en uno.
- La buena: Solamente generamos el certificado y la configuración de Apache2 la gestionamos mano. Así nos enteramos de lo que estamos haciendo, lo cual es muy conveniente y tampoco es tan difícil, caramba!
Así que vamos con la buena. Primero, generamos el certificado.
sudo certbot certonly --apache
Me preguntará el dominio y una dirección de email administrativa de contacto y generará el certificado y la clave privada que dejará en los respectivos directorios:
/etc/letsencrypt/live/mi-dominio.com/fullchain.pem
/etc/letsencrypt/live/mi-dominio.com/privkey.pem
Y, ahora sí, configuramos nuestro sitio web añadiendo la ubicación del certificado al archivo de «Virtual Host» en Apache2
sudo nano /etc/apache2/sites-available/nextcloud-ssl.conf
SSLCertificateFile /etc/letsencrypt/live/mi-dominio.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mi-dominio.com/privkey.pem
Y no nos olvidemos de comentar las líneas que se refieren al certificado autofirmado, ya que no es el que queremos usar
#SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
#SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
Y ya está listo. No olvidemos recargar el servicio Apache2
Algunas utilidades
Si queremos comprobar los certificados instalados
sudo certbot certificates
Si queremos eliminar algún certificado
sudo certbot delete --cert-name <nombre-certificado>
Si queremos renovar un certificado próximo a caducar (duran 90 días)
sudo certbot renew --cert-name <nombre-certificado>
Si sólo queremos comprobar el buen funcionamiento de la renovación
sudo certbot renew --dry-run
Nota: Tanto para la generación de un certificado como para su renovación será necesario tener un sitio web habilitado en el mismo dominio en el puerto 80, es decir, accesible con HTTP. Una vez instalado o renovado el certificado, el sitio web en el puerto 80 puede ser deshabilitado.
PHP
Ningún misterio en este punto. Únicamente recordar que siempre resulta muy conveniente colocar en el directorio raíz de nuestro sitio web un archivo de tipo php que llame a la instrucción phpinfo(). De esta manera contamos con una sencilla pero eficaz herramienta de depuración que nos permita comprobar el correcto funcionamiento de nuestra instalación de PHP. Para simplificar las cosas, el archivo en cuestión se llamará, simplemente, phpinfo.php
nano phpinfo.php
<?php
// Muestra toda la información, por defecto INFO_ALL
phpinfo();
?>
MariaDB
Éste es el nombre de uno de los sistemas de gestión de bases de datos relacionales de código abierto más populares en la actualidad y que, de hecho, es el aconsejado para la instalación de Nextcloud.
Si bien en el encabezamiento del artículo hablábamos de que la M de un sistema LAMP hacía referencia a MySQL, MariaDB es una opción equivalente y que, en general, es más recomendada. Sus principales impulsores fueron los mismos que crearon MySQL con la diferencia de que ésta fue desarrollada en Oracle Corporation mientras que para MariaDB se creo una fundación que se comprometió a mantener el código bajo licencia GPL. Este compromiso nunca lo tuvo Oracle, más allá de una cierta voluntad inicial, y lo cierto es que algunos módulos de MySQL ya están bajo licencia privativa. Teniendo en cuenta que MariaDB es totalmente compatible con MySQL y que las malas lenguas dicen que rinde mejor, la elección parece clara.
Configuración
Una vez instalada, el primer paso es conectar con el motor de base de datos. Observar que ejecutamos el comando con sudo, de manera que no es necesario identificarse específicamente para la base de datos.
sudo mariadb
En primer lugar creamos la base de datos
CREATE DATABASE nextcloud_db;
A continuación creamos un usuario y le otorgamos permisos
GRANT ALL PRIVILEGES ON nextcloud_db.* TO 'nextcloud_usr'@localhost IDENTIFIED BY 'password';
Y no nos olvidemos de aplicar los cambios
FLUSH PRIVILEGES;
Y por si os lo estabais preguntando, la razón del curioso nombre de esta base de datos reside en la tradición de su principal creador, un tal Ulf Michael Widenius (al que, por razones obvias, sus amigos llaman Monty) de incluir en la denominación de sus creaciones los nombres de sus hijos. Así, su primer hijo, My, dio lugar a MySQL, mientras que su segunda hija, María, inspiró MariaDB. Muy tierno, el tío Monty.
Instalación de Nextcloud
Existen varios métodos para instalar un servidor de Nextcloud. La instalación web es posiblemente la más sencilla de todas y tiene la ventaja de que el procedimiento es idéntico tanto si la instalación la hacemos en un espacio de alojamiento compartido como en un servidor personal. Consiste, básicamente, en descargar un archivo llamado setup-nextcloud.php, colocarlo en la raíz de nuestro sitio web y dirigirnos a él desde cualquier navegador. Nos aparecerá un asistente de instalación y lo único que tenemos que hacer es seguir las instrucciones e ir aportando la información necesaria.
Por cierto, la última vez que visité la web de Nextcloud la encontré un tanto confusa, así que para ahorrar trabajo el manual de instalación se encuentra aquí. Respecto a la descarga del archivo php, el enlace proporcionado en dicho manual no es de mucha utilidad y, al final, no me quedó que recurrir a la misma página de github donde se encuentra el proyecto. En fin…
Por cierto, en mi caso, durante la instalación me encontré con un par de errores que, por si acaso, dejo documentados aqui:
Nada más conectar al php de instalación me dio un error de que faltan los drivers para conectar con la base de datos. Esto lo solucioné instalando el paquete php-mysqlnd
Y una vez en marcha el asistente, otro error me impedía introducir los datos de conexión a la base de datos. Esto lo solucioné editando el archivo /config/config.php e insertando los datos de conexión a mano. Por cierto, sustituyo mysql por mariadb.
Arranque y optimización
Una vez instalado el servidor podemos acceder al panel de control del mismo en la dirección https://<mi_dominio//index.php/apps/dashboard/
Una vez allí, una página me mostrará una lista de asuntos que resulta necesario optimizar. Esta lista puede variar de un servidor a otro. Aquí me limitaré a comentar algunos de los cambios que, según mi experiencia, suelen ser los más habituales, o bien aquellos con los que me he ido encontrando a lo largo de la experimentación con Nextcloud.
Es habitual tener que introducir algunas modificaciones en el archivo de configuración de PHP, php.ini Para ello, lo primero es localizar dicho archivo de configuración, ya que según la instalación pueden existir varios y es necesario saber cuál es el que se está cargando. La manera de averiguarlo es consultar el archivo de depuración de PHP mencionado antes, es decir, la página phpinfo.php
En mi caso: /etc/php/8.1/fpm/php.ini
Un cambio clásico suele ser el ajuste del límite de memoria al valor recomendado: 128M -> 512M
Como siempre, cualquier cambio a la configuración de PHP requiere reiniciar el servicio
sudo systemctl restart php8.1-fpm
También suele ser frecuente la recomendación de instalar algunos paquetes adicionales, tales como php-imagick y para el soporte svg, libmagickcore-6.q16-6-extra (que, por cierto, viene entre los paquetes sugeridos)
php-intl
Un mensaje importante, por cuestión de seguridad, se refiere al hecho de que los archivos se encuentran por defecto dentro del directorio web mientras que el archivo. htacces está desactivado. Recordemos que el archivo .htaccess es un método clásico que permite restringir el acceso a los directorios que se encuentran dentro del directorio de nuestra web. Sin embargo, este método no es del todo fiable y, además, compromete el rendimiento del servidor. Es por ello que, por defecto, se encuentra deshabilitado. Una discusión interesante se encuentra en el siguiente artículo:
https://httpd.apache.org/docs/2.4/howto/htaccess.html#when
Entonces, para mantener a salvo nuestros archivos, lo mejor es sacar el directorio de datos fuera de la raíz de documentos del sitio web y especificar la nueva ubicación en el archivo de configuración.
También nos podemos encontrar con un error al intentar conectar con los protocolos CalDAV. Esto es debido a que la resolución correcta de las rutas de cada protocolo se encuentran especificadas en el archivo .htaccess, el cual, como ya hemos visto, está deshabilitado por defecto. Una solución es habilitarlo sólo para nuestro sitio web añadiendo estas línes al archivo de «Virtual Host»:
<Directory /var/www/nextcloud/>
AllowOverride All
</Directory>
Cache
Instalo la cache con apt install php-apcu
Se creará el archivo de configuración de php /etc/php/8.1/conf.d/20-apcu.ini En él añado las siguientes líneas (encontradas por ahí…)
apc.enabled=1
apc.file_update_protection=2
apc.optimization=0
apc.shm_size=256M
apc.include_once_override=0
apc.shm_segments=1
apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600
apc.num_files_hint=1024
apc.enable_cli=0
apc.max_file_size=5M
apc.cache_by_default=1
apc.use_request_time=1
apc.slam_defense=0
apc.stat_ctime=0
apc.canonicalize=1
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.lazy_classes=0
apc.lazy_functions=0
Le indico a nextcloud que utilice apcu en su archivo de configuración
sudo nano /var/www/nextcloud/config/config.php
'memcache.distributed' => '\\OC\\Memcache\\APCu',
'memcache.local' => '\\OC\\Memcache\\APCu',
Reinicio, y a funcionar
sudo systemctl restart php8.1-fpm.service
sudo systemctl restart apache2.service
