Nube

De como me independicé de Google (iii) РLa nube

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

nube a la brasa

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.

  1. 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.
  2. 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.
  3. 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.

Apache

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

Los dos directorios con los que hay que bregar son los siguientes:

  • La ra√≠z para los archivos de los sitios web. Aqu√≠ crearemos un subdirectorio nuevo para cada nuevo sitio web que queramos servir.
cd /var/www/
  • El directorio de configuraci√≥n. Aqu√≠ hay subdirectorios para configurar tanto los m√≥dulos que queremos que use el servidor como los par√°metros de funcionamiento de cada uno de los sitios web.
cd /etc/apache2

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

sudo mkdir 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 disponibles: /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 habilitar el sitio:

sudo a2ensite nextcloud.conf
sudo systemctl reload apache2

Y para deshabilitarlo:

sudo a2dissite nextcloud.conf
sudo systemctl reload apache2

Notar que después de habilitar o rehabilitar un sitio, es necesario recargar la configuración

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. El mismo esquema es el que se utiliza para habilitar y deshabilitar m√≥dulos, como veremos a continuaci√≥n.

A√Īadiendo algo de seguridad

Si queremos habilitar SSL, lo cual es sumamente recomendable, habilitaremos el siguiente módulo:

sudo a2enmod ssl
sudo systemctl reload apache2

 

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, somos un poco obsesivos o el servicio lo van a utilizar terceras personas que no tienen por qu√© fiarse de nosotros, podemos recurrir a un certificado gratuito generado y firmado por una CA de verdad, como es Let’s Encrypt.

 

Let’s Encrypt

ACMEAhora, s√≠, resulta que quiero un certificado de verdad. En primer lugar 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, sobre todo si seguimos las instrucciones de instalaci√≥n de Nextcloud en las que se instalan todos los m√≥dulos recomendados. √ö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, en el momento de escribir esta entrada lo cierto es que encontré la web de Nextcloud un tanto confusa, así que para ahorrar trabajo el manual de instalación se encuentra aquí, con un práctico ejemplo de instalación en Ubuntu. Respecto a la descarga del archivo php para la instalación en web, el enlace proporcionado en dicho manual no es de mucha utilidad, y al final no me quedó otra que recurrir a la misma página de github donde se encuentra el proyecto. Supongo que poco a poco irán poniendo orden.

Ubicación del directorio de datos

Un tema 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 colocar el directorio de datos fuera de la ra√≠z de documentos del sitio web. El problema es que, una vez realizada la instalaci√≥n, para mover el directorio de datos no basta con modificar la entrada en el archivo de configuraci√≥n, sino que habr√≠a que corregir m√ļltiples entradas en la base de datos. Este procedimiento est√° oficialmente desaconsejado por el equipo de Nextcloud, que recomienda, en su lugar, seleccionar el directorio definitivo durante la instalaci√≥n.

Nota sobre permisos: Es importante que el directorio de datos pertenezca al usuario y grupo www-data que es bajo el que se ejecuta Apache2. También es importante que dicho directorio no se encuentre dentro de una ruta que lo haga inaccesible debido a la falta de acceso de ejecución sobre alguno de los directorios de la misma. En mi caso, el directorio de usuario pertenece a www-data:www-data con permisos 750 y se encuentra dentro de una unidad de disco montada en un directorio con propiedad root:root y permisos 755. Si nos fijamos, es el mismo esquema que siguen los directorios de usuario dentro de /home en una instalación regular de Linux.

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

A vueltas con Cron

Un error com√ļn que se nos muestra en la secci√≥n de vista general incluye el siguiente mensaje:

No se ha podido ejecutar el trabajo cron vía CLI. Han aparecido los siguientes errores técnicos:
Tu directorio de datos es inv√°lido Aseg√ļrate de que existe un archivo llamado ¬ę.ocdata¬Ľ en la ra√≠z del directorio de datos.

Y adem√°s en rojo, lo que acojona un poco. Al parecer tiene que ver con la manera en la que el servidor ejecuta las tareas de manera peri√≥dica. Desconozco la raz√≥n del aviso, pero una manera de solucionarlo es seleccionar CRON en la secci√≥n de Ajustes b√°sicos y a√Īadir una tarea que viene en el propio directorio de instalaci√≥n de Nextcloud ya que, al parecer, esta tarea no se registra sola:

sudo su

crontab -u www-data -e

*/5 * * * * /usr/bin/php /var/www/nextcloud/cron.php

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 

 

Deja una respuesta