Estoy realmente satisfecho con el funcionamiento del bot de Telegram para mejorar esl feedback. Tan satisfecho que esta semana tenemos un capítulo de preguntas y por otro, un capítulo de ampliación de funcionalidades. En este capítulo entre otros temas, se trata del maldito cron. Y es que, si bien el cron, es una poderosa herramienta, la realidad es que en muchas ocasiones, nos da muchos dolores y quebraderos de cabeza, por el simple hecho de que nos dejamos determinados asuntos en el tintero.

Pero no solo hay preguntas referentes al cron, también otras sobre Flatpak, el reinicio de servidores y equipos remotos, sobre copias de seguridad de VPS y por último, de Notion y bases de datos.

Preguntas y el maldito cron

Sobre Flatpak

Carlos pregunta,

Tengo instalado el navegador Google Chrome en mi Linux Mint a través de Flatpak, pero al instalar el certificado digital en el navegador y cerrarlo no se mantiene la configuracion realizada, ¿Sabéis a qué podría deberse?. Gracias

Lo cierto es que no he encontrado algún otro caso en Internet. También puede ser que no lo haya buscado correctamente o que no haya dado con la tecla.

Sin embargo, teniendo en cuenta que Google Chrome empaquetado con Flatpak corre en sandbox, es posible que no tenga acceso a la configuración de usuario, y no lo pueda guardar.

Mi recomendación es que instales flatseal, del que hablé en un vídeo reciente, y que puedes consultar tanto en YouTube como en FediverseTV. Te dejo a continuación el vídeo,

Comprueba que accesos tiene, y ves probando hasta que des con el que se corresponde con la configuración.

Reinicio remoto

Manolo pregunta,

Tengo un equipo que quiero reiniciar remotamente, pero le hago reboot now como root y se queda tan pancho. ¿Alguna sugerencia?

En general, yo hago como Manolo, utilizo sudo reboot now, para reiniciar el ordenador, servidor o equipo en general, y no recuerdo ningún caso, en el que haya tenido problemas.

En este caso, fue el propio Manolo el que dio con la solución, tan sencillo como ejecutar sudo reboot --force.

Pero, he ido al manual de reboot, y la cuestión no encontré ninguna referencia al uso de now, aunque buscando a lo largo ya ancho de Internet si que encontré referencia a reboot now, indicando que si no utilizas now deja un minuto de cortesía, y en el caso de now se hace inmediatamente.

Por otro lado, en el caso de que por alguna razón, no se reinicie como es el caso, se puede utilizar la opción -f o --force, que reinicia inmediatamente sin hacer un apagado limpio, con lo que no es nada recomendable.

Otra opción es utilizar el comando shutdown, que con la opción -r, reinicia el equipo en lugar de apagarlo. Pero tiene muchas mas posibilidades,

• shutdown -r +5 reinicia en 5 minutos
• shutdown -r +0 reinicia en inmediatamente
• shutdown -r -H +0 primero termina todos los procesos que estén corriendo y después reinicia

Incluso utilizando shutdown, es posible indicar la hora de reinicio o apagado, según necesites.

Por último, también puedes utilizar systemctl para detener o reiniciar el equipo. Así, para nuestro caso, lo puedes hacer con sudo systemctl reboot.

Sobre el cron

Ekaterina pregunta,

Tengo un cron de usuario en Centos 6.8 que no funciona bien. En el log de cron veo que las programaciones se lanzan a su hora, pero los scripts no hacen lo que tienen que hacer (no hacen nada). No tengo fichero allow y el deny está vacío. Comprobados permisos de carpeta y scripts. Alguna idea?

Respecto al cron siempre hay muchos problemas e inconvenientes, y con independecia de lo que comenta Ekaterina, lo cierto es que el primero es que nos empeñamos en ejecutar cron con el usuario root, cuando en general y en la mayoría de las ocasiones no es necesario. Y por supuesto y como te puedes imaginar, es jugar con fuego.

Mi recomendación es que siempre que puedas evites el uso de root para todas las acciones que realices, y por supuesto para ejecutar tareas programadas, salvo que sea realmente necesario.

Por otro lado, hay que tener en cuenta, que no todas las variables de entorno están disponibles cuando se ejecuta el cron. Yo en general, suelo pensar que no tengo ninguna disponible y siempre que puedo las exporto para usarlas.

Otro de los problemas está asociado con el anterior, y es que pensamos que el PATH es exactamente el mismo, que cuando ejecutamos en local. La cuestión es que no siempre cargamos las mismas variables. Por esta razón, la recomendación es que utilices rutas absolutas en lugar de rutas relativas. De esta manera te abstraes por completo del PATH y de los posibles problemas que puedas tener.

Otra cuestión es que siempre podemos recurrir a los logs que escribe cron. Para ello simplemente tienes que consultar en /var/log/syslog, o si solo quieres ver lo relativo a cron, grep CRON /var/log/syslog.

Por supuesto que otra opción es enviarlo a un archivo de log, por ejemplo,

* * * * * echo "Hola" >> /home/lorenzo/test.log 2>&1

Aunque mas elegante, o por lo menos así lo veo yo, es que vaya también al syslog. Por ejemplo,

* * * * * echo "Hola" 2>&1 | logger -t etiqueta

Y luego para consultarlo, tan sencillo como

grep etiqueta /var/log/syslog

Todo esto tiene la ventaja de que no te tienes que preocupar por el rotado de los logs, porque se supone que ya lo configuraste con el syslog.

Interfaz gráfico

Otro problema mas es interactuar con el interfaz gráfico. Aquí la cosa se complica mas, y ya he ido adoptando diferentes soluciones en función de lo que necesitaba. El problema, es que la solución no vale para todos los entornos de escritorio, con lo que para esto vale la pena que le dedique un episodio completo, y que te muestre la última solución que estoy adoptando y que creo que es las más práctica, cómoda y segura.

Sobre copias de seguridad en VPS

Mauri pregunta,

Tengo varias instancias en un vps, una raspberry y mi servidor principal, todos con contenedores docker. Se que varios por aquí tenéis cosas parecidas. No se como afrontar las copias de seguridad de todo esto.
Había pensado en un rsnapshot con rclone con docker, pero estoy abierto a todas las sugerencias que me digáis.

En general, solo hago copias de las bases de datos, y hasta el momento de las bases de datos de MariaDB. Una vez hecha la copia de seguridad de la base de datos, lo que suelo hacer es enviarla vía rsync, dependiendo de donde quiera acceder.

Para el caso de mi ordenador personal, y como he comentado en otras ocasiones, lo que hago es utilizar Borg, y el se encarga de realizar la sincronización. Con la ventaja de que Borg, versiones y deduplicación.

Esta podría ser una forma muy interesante de realizar las copias de seguridad de tus contenedores, en lo que a configuración se refiere, y por otro lado realizar copias de las bases de datos.

Sobre una base de datos a lo Notion

Juandi pregunta,

Les cuento que soy usuario y realmente me gusta de la forma en que puedo gestionar mis tareas en Notion. Pero la verdad es muy lento y quién sabe en el futuro si podría ser de costo, etc. Así que a sabiendas de que Notion es solo una base de datos. Quiero tener mi propia BD universal en un server. En ella poner todas mis tareas con la cantidad de variables que se me ocurran y bueno lo que sigue después. Filtros 😃.
¿Alguien ha pasado por ésto? Es decir: ¿Has decidido crear, correr y administrar tu propia BD para tu gestión personal?

No he utilizado hasta el momento Notion, pero estoy en camino de probar una alternativa Open Source. Cuando lo tenga comentaré a ver que tal.

Respecto a utilizar una base de datos. Te confesaré que lo he pensado en mas de una ocasión, y sobre todo viendo lo bien que está funcionando esto del feedback, todavía me reafirma mas en ello. Aquí, lo que me para, es que también sería necesario la aplicación en Android que me permitiera relacionarme facilmente con la base de datos.

Esto es lo que realmente me para, por el resto, me parece una idea excelente, porque de nuevo, la controlas como tu quieres.

---

Espero que te haya gustado este nuevo episodio del podcast. Si puedes, te agradecería una valoración en iVoox y/o en Apple Podcast.