Iniciación al Self-Hosting. Una de preguntas y respuestas (PYR)

0:00 / 0:00

Por fin. Llevaba tiempo queriendo llegar a un episodio de preguntas y respuestas, y aquí lo tienes, el número 630. Y no es que me falten temas, es justo lo contrario. Hay semanas en las que me siento delante del micrófono sin tener del todo claro de qué quiero hablar, y eso se acaba notando. En un preguntas y respuestas, en cambio, el guión ya está casi hecho: alguien se ha tomado la molestia de formular las preguntas y yo solo tengo que responderlas. Que no es tan sencillo como suena, ojo, pero el punto de partida ya está sobre la mesa.

Hay algo más que me gusta de estos episodios, y para mí vale más que la comodidad. Me gustan porque sé, de forma fehaciente, que hay alguien al otro lado. Detrás de cada pregunta hay una persona que en un momento determinado se ha sentado a escribirla, y eso demuestra que esto no es un monólogo en el vacío. Después están los retos, que son mi debilidad: alguien me pica y me reta a hacer algo concreto, y ahí me tienes, enganchado perdido.

Este episodio tiene además un ingrediente que me apasiona: el self-hosting, el autoalojamiento, o como le quieras llamar. Es una de esas cosas que, cuando te pican el gusanillo, ya no te sueltan. Porque en el fondo el self-hosting es independencia digital. Tú tienes tu servicio, tú lo gestionas, tú decides. Nadie te cambia las condiciones de un día para otro y nadie te apaga el grifo de un plumazo. Así que sí, a alguien le ha picado el anzuelo y de ahí ha salido todo lo que vas a escuchar hoy.

Así que no me voy a enrollar más. Vamos al turrón, que decimos por aquí, y empiezo directamente con la primera pregunta. Que conste que no las he reordenado, ni he quitado ninguna, ni he cambiado el sentido de nada: van tal cual me llegaron y las respondo en el mismo orden en el que me las encontré. Me parece lo honesto cuando el mérito del guión no es mío.

La primera pregunta: levantar tu propio WebDAV para Obsidian

Empiezo por lo que más me habéis pedido, tanto en el grupo de Telegram de Atareao con Linux como en distintos correos: cómo levantar un WebDAV. Y aquí tengo que hacer un poco de autocrítica, porque yo siempre he pensado que esto ya lo tenía disponible en el repositorio de GitHub. Y lo cierto es que ahí está, pero se ve que no lo he publicado como es debido o que no he dejado el enlace a mano en un sitio que se vea. Así que voy a hacer dos cosas: dejar el enlace al repositorio donde está el docker-compose para que levantes tu propio WebDAV, y enlazarlo también en las notas del podcast para que no haya ningún tipo de pérdida.

Un detalle de transparencia, porque me gusta decir las cosas como son. En el grupo comenté que había creado un WebDAV implementado en Rust, y cuando he ido a actualizarlo me he encontrado con que una de las librerías con las que estaba hecho se ha quedado desactualizada. Así que estoy trabajando en actualizar el Docker y en documentarlo todo bien, para que quede disponible y cualquiera lo pueda usar. Eso me va a retrasar un poco, lo reconozco, pero el WebDAV lo puedes montar ya mismo con lo que hay.

La pregunta la formula Juanma, y dice así: lleva muy poquito usando Obsidian, está esperando con ansias ese tutorial, había pensado en WebDAV para sincronizar, y de momento solo quiere sincronizar un ordenador y el teléfono. Lo ha conseguido con Syncthing, y sospecha, con razón, que con WebDAV le resultará más fácil, aunque todavía no sabe cómo se hace. Buena pregunta, porque toca dos maneras muy distintas de sincronizar.

Antes de meterme en faena, un poco de contexto, que casi nunca viene mal. WebDAV son las siglas de Web Distributed Authoring and Versioning, y no es más que una extensión del protocolo HTTP que permite crear, leer, modificar y borrar ficheros que viven en un servidor remoto como si fueran parte de tu sistema de ficheros. La definición formal está en la RFC 4918, por si quieres el detalle fino. Añade verbos nuevos a HTTP y ahí está su gracia: PROPFIND para listar propiedades y contenidos, MKCOL para crear colecciones, COPY y MOVE para copiar y mover, y LOCK y UNLOCK para bloquear un recurso mientras alguien lo edita y que dos personas no se pisen el mismo fichero.

Syncthing, en cambio, juega en otra liga. No es un protocolo de ficheros en red, es un sistema de sincronización entre pares. Dos dispositivos se hablan directamente, sin pasar por un servidor central, y cada uno mantiene una copia completa de la carpeta. Es cómodo para un PC y un teléfono que se ven a menudo, y por eso a Juanma le ha funcionado. WebDAV es distinto: hay un servidor que guarda la verdad, y los clientes se conectan a él. Eso te da algo que Syncthing no te da, que es tener tus datos en un único sitio con tu copia de seguridad detrás.

Dicho esto, ¿cómo se levanta? Con WebDAV lo mejor es tirar de Docker, sin ninguna duda. Un contenedor y a correr. Te enseño un ejemplo mínimo, para que veas la idea, y luego montas el tuyo como más te guste.

docker run -d --name webdav \
  -e USERNAME=lorenzo \
  -e PASSWORD=cambiaesta \
  -v /srv/webdav:/var/lib/dav \
  -p 8080:80 \
  bytemark/webdav

Ahí lo tienes: un usuario, una contraseña, un volumen que apunta a la carpeta donde quieres que vivan los ficheros y un puerto de escucha. Con eso ya tienes un WebDAV funcionando. Si prefieres hacerlo a mano, sin contenedores, la vía clásica es el servidor web Apache con el módulo mod_dav, que trae el soporte de serie. Un trozo de configuración así bastaría,

<Directory /srv/webdav>
    Dav On
    AuthType Basic
    AuthName "WebDAV"
    AuthUserFile /etc/apache2/webdav.passwd
    Require valid-user
</Directory>

Y ojo con un detalle que a mucha gente le muerde: Nginx, por sí solo, no soporta WebDAV. Necesita un módulo de terceros que no viene compilado por defecto en la mayoría de distribuciones. Así que si tienes delante un Nginx y te empeñas en montarlo ahí, vas a perder la tarde. Con Apache, con un contenedor ya hecho o con alternativas como mod_dav vas mucho más rápido.

Ahora, la parte que de verdad importa, y que es la que siempre repito cuando alguien me pregunta por esto. Un WebDAV necesita estar accesible desde fuera para que tu teléfono pueda sincronizar cuando no estás en casa. Y tienes dos caminos. El primero es meter el teléfono dentro de una VPN, de manera que el tráfico viaje cifrado y el servidor no quede expuesto a todo internet; con WireGuard o con Tailscale esto te lo montas en un rato. El segundo es exponer el WebDAV directamente a internet, con su certificado y su contraseña, para que puedas entrar desde cualquier sitio.

Aquí está el meollo de todo: si lo que vas a exponer al público son datos sensibles, piénsatelo dos veces. Yo soy bastante reacio a sacar a internet según qué cosas, y no porque sea un desconfiado, sino porque cada puerta que abres es una puerta que alguien puede intentar forzar.

Yo, por ejemplo, todo lo que tengo expuesto a internet son básicamente los artículos que publico en la web. Texto que es de dominio público, o que lo va a ser en un rato. Pero si lo que vas a exponer son contraseñas, ficheros personales o tu base de datos de fotos, entonces lo más sensato es que pase por la VPN y que solo tu teléfono pueda entrar. Y sí, te confieso que yo tengo cosas expuestas que son un poco más sensibles de lo que debería, y hasta el momento he tenido suerte, las cosas como son. Que no te sirva mi suerte de ejemplo, que te sirva mi prudencia.

Una última cosa para Juanma, ya que habla de Obsidian. La sincronización de Obsidian por WebDAV no viene de fábrica; el programa solo trae su servicio de pago y poco más. Para WebDAV necesitas un plugin de la comunidad. El que más se usa para esto es Remotely Save, que se configura con la URL del WebDAV, un usuario y una contraseña, y a partir de ahí te sincroniza la bóveda. La ventaja de hacerlo así es que la bóveda son ficheros de texto planos, así que cualquier herramienta de copia de seguridad te los va a pillar sin dramas. La pega es que estás exponiendo tus notas, que son todo menos públicas. Sopesa las dos cosas.

Álex y la chispa que encendió este preguntas y respuestas

La siguiente pregunta es de Álex, y tengo que decir que es la que ha encendido la chispa de este episodio. Él mismo lo cuenta: hacía tiempo que no escuchaba un capítulo de preguntas y respuestas, le parecían muy interesantes, y quería hacerme unas consultas o bien para un capítulo de estas características o simplemente para conocer mi opinión. Pues Álex, gracias a tu pregunta tienes aquí tu episodio, y te lo digo en serio: cuantas más preguntas me lleguen, más episodios de este tipo van a salir. Así que queda dicho.

Su pregunta, resumida, es esta: lleva tiempo queriéndose meter de lleno en el autoalojamiento, pero le surgen dudas. Quiere montar un Nextcloud para hacerse su propio Google Drive y no depender tanto de Google, y además ganar espacio de almacenamiento. Por otro lado, quiere un servicio de fotos para sustituir a Google Fotos, y menciona que vio Chevereto en un tutorial mío. Su intención, y esto es importante, es buena.

Antes de meterme con el dónde montarlo, quiero hacer una mención sobre el motivo, porque me parece que aquí hay un matiz que se nos escapa a todos. No se trata de sustituir Google Drive por ser de Google, ni Google Fotos por ser de Google. Se trata de sustituirlo porque tienes una solución que te parece más interesante, que te da algo que la de Google no te da. Ese es el criterio. Si cambias de herramienta solo por dogma, acabas cambiando comodidad por incomodidad sin ganar nada a cambio.

Te lo digo con mi propio ejemplo, que es el más honesto que puedo darte. Yo no he sustituido Google Fotos. No lo he hecho con Immich, que es lo que pondría hoy si tuviera que decidirme, y no lo he hecho por una razón muy sencilla: ahora mismo Google Fotos me resulta más cómodo que tener montado Immich en casa, y además lo tengo compartido con mi mujer y con la familia. Son una serie de ventajas que, en mi caso concreto, hoy pesan más que el control total. Mañana igual pienso otra cosa, pero hoy es lo que hay.

Sin embargo, en lugar de Google Drive sí que estoy usando File Browser. No es exactamente lo mismo, ni pretende serlo, pero para lo que yo quiero File Browser me funciona mucho mejor. Y fíjate en la lección: la decisión no es ideológica, es práctica. Tienes que valorar tanto los beneficios como las contrapartidas de alojar cada cosa por tu cuenta. El control no es gratis. Cuesta tiempo, cuesta mantenimiento y cuesta dinero. Un autoalojamiento mal elegido te hace la vida más complicada que el servicio que venías usando, y eso no lo queremos.

Dónde montar todo esto: VPS, netbook o mini PC

La primera duda concreta de Álex es dónde colocar todo este tinglado. Tiene desde hace unos meses un VPS de OVH alquilado al que no le está sacando rendimiento, pero con el plan más básico solo dispone de 10 gigas de almacenamiento, así que no puede alojar muchos datos. Ha pensado también en usar un viejo netbook como servidor, aunque le preocupa el poco rendimiento y el sobrecalentamiento de tenerlo encendido 24 horas al día. Y la tercera opción, que es la que más le tienta, es comprarse un mini PC, solo que no tiene claro qué especificaciones necesita para mover estos servicios ni cuánto va a consumir de electricidad. Quiere, además, que consuma lo mínimo. Vaya por delante que es una pregunta muy bien planteada.

Vamos por partes, porque el alojamiento es algo muy particular y no hay una respuesta única. Yo, y esto lo he comentado ya en varias ocasiones, utilizo Contabo. Y lo uso porque, para mí, la relación calidad-precio es la mejor que he encontrado. Es mi experiencia, nada más. En el grupo de Atareao con Linux hay usuarios que han tenido problemas serios con Contabo, y quiero decirlo bien claro para que no quede ninguna duda: yo no me llevo ninguna comisión, no tengo afiliados ni nada por el estilo. Cuento mi experiencia y punto. Actualmente tengo alojadas seis páginas web directamente en Contabo, algunas en sus propios VPS y otras en VPS compartidos, y a mí me funciona.

El detalle del precio merece la pena, aunque te aviso de que hablo de memoria y puedo bailarme una cifra. Estamos hablando de unos cinco euros al mes por 200 o 400 gigas, no recuerdo exactamente, en disco SSD. Si quieres NVMe, el espacio es más reducido. Pero para que te hagas una idea del orden de magnitud, ya te vale. Compáralo con lo que te costaría el hierro y verás por dónde van los tiros.

Respecto al netbook, lo descarto. Y lo descarto de plano: para mí no es una buena solución. Un netbook viejo arrastra un procesador flojo, poca memoria, un disco lento y un sistema de refrigeración pensado para sesiones cortas, no para estar meses encendido. El sobrecalentamiento que teme Álex es real, y un disco mecánico sufriendo las 24 horas es una bomba de relojería. Puede funcionar para trastear, para aprender, para un primer contacto. Como servidor de producción, no.

Mi recomendación, si el objetivo es tenerlo encendido siempre, es un mini PC. Y aquí puedo contarte mi propia experiencia, porque tengo uno funcionando las 24 horas del día sin problemas. En mi caso, está levantando un minikube y demás servicios, y viene a consumir unos cinco vatios más o menos en reposo, aunque ese consumo sube cuando le pides caña. Lleva 8 gigas de RAM y creo que 128 gigas de SSD, y con eso me funciona bien. No te vayas a creer que es una máquina de la NASA; es un cacharro modesto que hace su trabajo.

Y ahora la pregunta del millón: ¿VPS o mini PC? Pues depende de tu situación, pero yo te voy a dar mi criterio. Si puedes, tira de VPS. Y el argumento es puramente económico y de mantenimiento. Si te compras un mini PC que te cuesta 150 euros, piensa que por cinco o seis euros al mes tienes un VPS en Contabo, que es el que yo tengo. Divide los 150 euros entre esos cinco o seis al mes y calcula cuántos meses de VPS te salen. Muchos. Y hay otro factor que se olvida: si un día dejas de sacarle partido al autoalojamiento, con el VPS simplemente dejas de pagar y ya está. Con el mini PC te quedas con el cacharro encima de la mesa, ocupando sitio y gastando luz, y te da pena tirarlo. Por eso, si dudas, VPS.

Dicho esto, el mini PC tiene una ventaja que el VPS no tiene, y es que los datos son tuyos de verdad, en tu casa, sin depender de que un proveedor siga existiendo mañana. Y el consumo importa. Un equipo de bajo consumo, tirando de un procesador eficiente, te puede salir por unos pocos vatios, que al cabo del año son unos euros de luz. Si te decides por el mini PC, mira bien las especificaciones: cuánta RAM admite, si el disco es SSD o NVMe, cuántos puertos de red tiene, y sobre todo que sea de bajo consumo. Si no encuentras las especificaciones de algo, me lo dices y te echo una mano a mirarlo.

Copias de seguridad y migrar sin perder nada por el camino

La segunda duda de Álex es la seguridad de los datos, y es la que más me gusta responder porque toca el corazón de todo esto. Él lo dice muy bien: alojar tus propios servicios conlleva una gran responsabilidad. Su pregunta es cómo de fácil resulta restaurar una copia de seguridad de un servicio y de sus datos. Y añade un escenario muy concreto: si pasados unos meses se da cuenta de que el rendimiento es pobre y quiere migrar los servicios a otra máquina, ¿tendría que instalar todo otra vez y copiar los datos para seguir usándolos de forma transparente, sin perder las fotos que ya tiene subidas?

La respuesta corta es que sí, que es realmente sencillo, y que lo he hecho más veces de las que recuerdo. Te pongo el caso de un blog, que es el ejemplo que suelo usar. Yo he migrado un blog de un sitio a otro de forma completamente transparente, y el truco no tiene nada de misterio: hago una copia de seguridad todos los días, y cuando quiero moverlo, restauras esa copia en el sitio nuevo y ya está. Toda la magia está en la copia diaria, no en el día de la mudanza. De hecho, en uno de los proyectos lo que hice fue levantar una segunda instancia exacta de la página web para hacer pruebas, porque queríamos cambiar el tema. Cloné el sitio con sus temas y con sus datos y sobre esa copia se fue probando, para no tocar el de producción. Eso, con una copia de seguridad en condiciones, es media hora de trabajo.

Con las fotografías pasa exactamente lo mismo. Lo que estoy haciendo es una copia de seguridad de todo, y esas copias las estoy mandando a otro VPS y también las estoy mandando a casa. Es decir, no confío en un solo destino, tengo varias operaciones en paralelo para asegurarme de que siempre hay una copia a salvo. Y al final, restaurar una copia es tremendamente sencillo. Si no sabes cómo hacerlo, me lo dices, o echa un vistazo a los episodios que he dedicado al tema, porque he creado incluso mis propios volúmenes de Docker para hacer las copias de los datos de los contenedores.

Te enseño la idea de una copia de un volumen de Docker, que es el patrón que más me ha salvado. Levantas un contenedor temporal con el volumen montado en modo lectura y lo empaquetas en un tar.gz dentro de tu carpeta de respaldos,

docker run --rm \
  -v mi_volumen:/datos:ro \
  -v /backups:/backup \
  alpine tar czf /backup/mi_volumen-$(date +%F).tar.gz -C /datos .

Y para llevarte los ficheros a otro sitio, rsync sigue siendo el rey. Con -a conservas permisos y propietarios, con -z comprimes el tráfico y con -v ves lo que va pasando por pantalla,

rsync -avz --delete /srv/datos/ usuario@otro-vps:/srv/respaldo/datos/

Si quieres algo más serio, con versiones históricas y deduplicación, tienes restic o BorgBackup, que te permiten volver a cualquier punto en el tiempo y no te comen el disco. Para un blog o una nube de fotos, cualquiera de los dos te sobra.

La copia de seguridad no se hace el día que migras. Se hace todos los días. El día que migras, lo único que haces es restaurar. Si esperas a tener el problema para pensar en las copias, ya llegas tarde.

Y ahora la migración en sí. Álex teme tener que reinstalar todo desde cero. Pues mira, yo he hecho migraciones así y tienen su gracia. Por ejemplo, uno de los proyectos que migré pasó de un VPS a mi entorno autoalojado, y lo más costoso fue precisamente volver a montarlo, porque el servicio estaba instalado directamente sobre la máquina y yo lo quería dejar montado sobre Docker. Una migración de esas, de hierro a contenedores, siempre es peculiar, pero al final lo conseguí. Es cuestión de dedicarle tiempo, no de tener un don especial. Y por eso yo cada vez lo tengo más claro: lo montaría en un VPS, lo montaría con Docker y lo dejaría todo cubierto con copias de seguridad. Te lo digo así porque es lo más sencillo, y luego cada uno hace lo que quiere.

Lo mejor de montarlo todo con Docker es que la migración se convierte casi en copiar ficheros. Te llevas la carpeta del proyecto, los volúmenes y el docker-compose, y en la máquina nueva levantas el mismo tinglado con un comando. Nada de pelearte con dependencias, ni con versiones de PHP, ni con módulos del sistema. Eso sí, asegúrate de que los datos viven en volúmenes o en carpetas montadas, y no dentro del contenedor, porque si viven dentro, el día que borres el contenedor se van contigo.

Y cierro la pregunta de Álex dándole las gracias, porque ha revivido el formato de preguntas y respuestas en mi memoria, y ya te digo que me resulta muy interesante. Estas dudas son exactamente el tipo de cosa que me gusta contestar, porque no son teóricas, son las que te encuentras de verdad cuando empiezas.

Configurar Neovim para Laravel y Vue: el reto

Ahora viene una pregunta que no voy a poder atribuir, y te explico por qué. En la web de atareao.es, en el formulario de comentarios, no hace falta que pongas ni el correo electrónico ni nada de nada. Solo tu nombre, o un seudónimo, o lo que tú quieras, y el mensaje. Aquí no estoy utilizando el correo para nada. En otros sitios el correo sirve para filtrar si quien escribe es un ser humano o un bot, pero aquí ya tengo puesto un captcha, así que no te preocupes por eso. El caso es que este lector dejó su correo, y como no voy a ponerme a hablar de su correo, me quedo sin poder decir quién es. Cosas del directo.

Y la pregunta, que no tiene desperdicio, es sobre configurar Neovim para trabajar con Laravel y con un frontend de Vue. Dice que hace días que intenta configurarlo, que consigue el LSP, pero que se le cuela un formateador que le formatea como le da la gana, y que no ha conseguido dejarlo fino ni con lspconfig, ni con mason, ni con Volar. Cuenta también que no encuentra en toda la web un tutorial debidamente actualizado, y me reta a hacerlo, con unas cuantas condiciones que me apunto. Reto aceptado, por cierto, así que apúntalo en la lista de pendientes.

Antes de responder, sitúo el terreno, porque aquí hay varias piezas que conviene no mezclar. Neovim trae un cliente LSP integrado desde hace varias versiones; eso es lo que te da el autocompletado, los diagnósticos y el salto a definición. Encima se suele montar nvim-lspconfig, que no es el servidor, sino una colección de configuraciones listas para arrancar los servidores más habituales. Luego está Mason, que es el que te instala esos servidores y esas herramientas sin que tengas que compilarlos a mano. Y por último los formateadores, que son otra cosa distinta. Confundir el servidor de lenguaje con el formateador es, casi siempre, el origen del problema.

Para Laravel, el protagonista en PHP suele ser un servidor como intelephense o phpactor. Para Vue, el servidor es Volar, que ahora se llama Vue Language Tools. Y para instalar todo eso desde Neovim, Mason te lo pone fácil,

:MasonInstall intelephense vue-language-server lua-language-server

Ahora, contesto a la pregunta de verdad. Yo actualmente estoy programando en paralelo con PHP, concretamente con WordPress, que no es Laravel, pero es PHP; y también con JavaScript puro y duro, en concreto para GNOME con GJS, que es JavaScript al fin y al cabo. Y tengo todo lo que me hace falta: un analizador sintáctico de código, y luego, si quiero o no quiero, un formateador. Lo que pasa es que todo esto no lo estoy haciendo con LazyVim. Lo estoy haciendo con Neovim directamente y con lazy.nvim, que es el gestor de paquetes que uso ahora.

Y aquí está mi recomendación, que va en la línea de lo que me preguntas: usa lazy.nvim, no LazyVim. ¿Por qué? Porque LazyVim ya te lo da todo configurado, y eso es maravilloso para empezar. El problema es que te lo da configurado como lo han decidido sus desarrolladores, y cuando quieres una cosa particular, como meterte con Laravel y con Vue a la vez, puede que te funcione o puede que te pelees con la capa de encima. Con lazy.nvim construyes desde abajo: pones el cliente LSP, pones Mason, pones cada servidor donde lo quieres y, sobre todo, decides tú quién formatea y cuándo. Que es justo el problema que tienes.

LazyVim: distribución completa, arrancas en cinco minutos, pero con opiniones muy marcadas. Ideal para empezar y para quien no quiere pelearse con la configuración.
lazy.nvim: solo el gestor de paquetes. Tú decides cada pieza. Más trabajo al principio, control total después.
Mason: instala servidores LSP, linters y formateadores sin compilar nada a mano.
conform.nvim: un gestor de formateo que te deja decir, por tipo de fichero, qué herramienta se usa y cómo. Es la pieza que suele resolver el «se me cuela un formateador».

El asunto del formateador que se cuela tiene truco. En Neovim puedes tener formateo automático al guardar, y si hay varios formateadores activos a la vez, o alguno heredado de una configuración ajena, se pelean por tus ficheros y cada uno los deja a su manera. La solución no es pelear con ellos, es centralizar. Con conform.nvim declaras, por ejemplo, que para ficheros de PHP quieres intelephense o pint, y para ficheros de Vue quieres prettier con su plugin para Vue, y que para los ficheros de Lua quieres stylua. Un fichero, un formateador. Y si no quieres formateo automático, lo desactivas y lo lanzas a mano cuando te apetezca.

return {
  "stevearc/conform.nvim",
  opts = {
    formatters_by_ft = {
      php = { "intelephense" },
      vue = { "prettier" },
      lua = { "stylua" },
    },
    format_on_save = { timeout_ms = 500 },
  },
}

Con eso ya tienes el formateador domesticado. Y ojo, que Volar también trae su propio formateo para la parte de la plantilla de Vue, así que revisa que no se te estén solapando Volar y Prettier en el mismo tipo de fichero. Ese solape es exactamente el síntoma que describes: el código te queda bien en un sitio y raro en otro, según quién llegue primero.

Así que sí, me atrevo, y me lo apunto como reto: montar Neovim desde lazy.nvim, con Laravel y con Vue, y documentarlo bien para que no te tengas que pelear con tutoriales de hace tres años. Reconozco que tiene su enjundia, porque Neovim es un mundo y cada versión mueve piezas, pero para eso estamos. Y con esto cierro la pregunta, gracias por el reto, que me ha puesto las pilas.

El «Linkedin» del pie de página que no es un error

Y por último, y un poco para sacarte una sonrisa, llega el comentario de Mark. Dice que cree que no me he dado cuenta, pero que tengo un fallito en el pie de página: en lugar de decir LinkedIn, dice «Linkedin», y añade que además falta el icono de LinkedIn. Pues mira, Mark, tengo que darte una respuesta y no es la que esperas.

No es un fallo. Está puesto a propósito. En un momento dado yo le llamé «linkedin», a la manera castellana, y no fui solo yo: un grupo de amigos le llamamos así, a modo de coña, y al final lo dejé tal cual en la web. Sí que es verdad que me he dejado el icono por el camino, eso te lo reconozco, pero el nombre no está mal escrito por descuido. Está así adrede, con toda la tontería de la que soy capaz. Así que muchas gracias por el aviso, porque significa que te fijas en los detalles, que es exactamente lo que quieres de alguien que te lee.

Gracias, reseñas y el recordatorio de siempre

Toca dar las gracias, que es lo justo. En principio, a Mark, a ese usuario que no puso su nombre y que me retó con Neovim, a Álex, que revivió el formato, y a Juanma, que abrió el episodio con el WebDAV. A los cuatro os doy las gracias por haberme permitido este pedazo de episodio. De verdad que para mí es un regalo, porque el trabajo de pensar las preguntas lo habéis hecho vosotros.

Tengo que pedir disculpas por una cosa de calendario. Este episodio se va a publicar el martes, no el lunes como toca, y el episodio del jueves todavía no tengo del todo claro si se va a publicar el jueves o no, porque va a depender de si saco tiempo para grabarlo. Así está el asunto. Lo importante es lo de siempre: gracias por esta pedazo de excusa para sentarme al micro.

Y ya que estamos, tres peticiones de la casa, que no cuestan nada. Si puedes dejar una reseña, ya sea en iVoox o en tu aplicación de podcast, esas cinco estrellitas en Spotify me vienen fenomenal y ayudan a que más gente encuentre el programa. Si quieres dejarme preguntas, retos o lo que se te ocurra, tienes el formulario en atareao.es/contactar, y ya te digo que no hace falta que dejes tu correo: solo tu nombre y lo que quieras contarme. Y si te apetece, recuerda que este es un podcast de la red de Sospechosos Habituales, donde vas a encontrar un montón de podcasts magníficos; puedes suscribirte a esa red entrando en wintablet.info, y participar en el grupo de Atareao con Linux entrando en Telegram en la comunidad de Atareao con Linux.

Conclusiones

Hagamos balance de este episodio de preguntas y respuestas, que ha dado para mucho. Cuatro conclusiones me llevo, y me las apunto para no olvidarlas.

La primera, sobre el WebDAV. Es una manera sencilla y estandarizada de tener tus ficheros en un servidor, y con Docker lo montas en un rato. Pero la decisión de verdad no es técnica, es de exposición: o lo metes detrás de una VPN y solo entra tu teléfono, o lo abres a internet y aceptas el riesgo. Con datos sensibles, yo lo tengo claro.

La segunda, sobre el dónde. Un VPS te da comodidad y, sobre todo, libertad para dejarlo cuando quieras. Un mini PC te da soberanía y te cuesta un poco más de dinero por adelantado. El netbook, por muy tentador que parezca para aprovechar algo viejo, no es una buena idea para tenerlo encendido meses. Y si dudas entre VPS y mini PC, echa las cuentas: cinco o seis euros al mes tardan mucho en igualar el precio de un equipo que, además, va a consumir luz.

La tercera, y para mí la más importante, sobre las copias de seguridad. Alojar tus propios servicios es una responsabilidad, y la responsabilidad se paga con copias. Copia diaria, en varios destinos, y restaurar el día de la mudanza, no al revés. Un servicio sin copias no está autoalojado, está en el aire.

Y la cuarta, sobre Neovim. No hace falta una distribución que lo traiga todo masticado. Con lazy.nvim y un poco de paciencia montas justo lo que necesitas, y el truco para que los formateadores dejen de pelear es centralizarlos. Queda apuntado el reto, y prometo documentarlo para que no dependas de tutoriales desactualizados.

Más información

RFC 4918 — HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) — la especificación oficial del protocolo
Apache mod_dav — el módulo de Apache que implementa WebDAV
Obsidian — la aplicación de notas en ficheros de texto con la que Juanma quiere sincronizar
Syncthing — sincronización entre pares, la alternativa que ya usa Juanma
Nextcloud — la nube autoalojada para hacerse un Google Drive propio
Immich — el servicio de fotos autoalojado que pondría hoy en lugar de Google Fotos
Chevereto — el alojamiento de imágenes al que se refería Álex
Contabo — el proveedor de VPS que yo uso, con el aviso de que hay quien ha tenido problemas
OVHcloud VPS — el proveedor donde Álex tiene su VPS sin aprovechar
WireGuard — la VPN que te permite acceder a tus servicios sin exponerlos
Tailscale — VPN de malla basada en WireGuard, muy cómoda para el móvil
Docker — la pieza que convierte la migración de servicios casi en copiar ficheros
restic — copias de seguridad con versiones y deduplicación
BorgBackup — la otra gran herramienta de copias deduplicadas
Neovim — el editor sobre el que va el reto de Laravel y Vue
LazyVim — la distribución con todo configurado de fábrica
lazy.nvim — el gestor de paquetes con el que yo construyo mi configuración
Mason — instalador de servidores LSP y herramientas desde Neovim
Vue Language Tools (Volar) — el servidor de lenguaje para Vue
Laravel — el framework de PHP del que hablaba la pregunta del reto
Contacta con Atareao con Linux — preguntas, retos y comentarios, sin correo de por medio
Red de podcasts Sospechosos Habituales — el resto de podcasts de la red

Y hasta aquí el preguntas y respuestas. Ha sido un ratito entretenido, y como te decía, sin vosotros esto no existe, así que siguen siendo bienvenidos los retos. Si me da tiempo, en el próximo episodio me pongo con el reto de Neovim para Laravel y Vue, y si no, te contaré por dónde ando, que al final lo importante es seguir dándole vueltas a esto del autoalojamiento. Y no me olvido del recordatorio de siempre, porque me gusta decirlo: la vida son dos días y uno ya ha pasado, así que disfruta como si hubiera mañana, y si puede ser con Linux, y en este caso con WebDAV y con self-hosting, mejor que mejor. Nos escuchamos en el próximo podcast. 🐧