Tutorial: Solución para problemas de actualización en NextCloud

NextCloud es una plataforma de almacenamiento en la nube basada en PHP que por muchas situaciones, incluido el ser un fork de OwnCloud, han causado que tenga una comunidad mas pequeña de lo que merece, por lo que es posible encontrarse problemas básicos, que requieren mayor investigación y conocimiento técnico para resolverlos.

Al ser una solución SelfHosted, es normal encontrarse instancias de NextCloud en Raspberry Pi o computadoras de bajos recursos. Esto incide directamente en situaciones que no se darían al ser administrados de forma profesional, como es el caso del error que vamos a revisar hoy.

Según la Wikipedia:

Nextcloud es una serie de programas cliente-servidor que permiten la creación de servicios de alojamiento de archivos. Su funcionalidad es similar al software Dropbox, aunque Nextcloud es en su totalidad software de código abierto. Nextcloud permite a los usuarios crear servidores privados. Su modelo de desarrollo abierto permite añadir y/o modificar la funcionalidad del software del servidor en forma de aplicaciones. Nextcloud es una bifurcación de ownCloud, que también es un software de servicio de alojamiento en la nube

Nextcloud en la Wikipedia. Consultado al 2/12/2022

El problema

Hasta el momento no he encontrado una explicación razonable para este problema, pero ha aparecido en todas mis instalaciones hasta el momento según las siguientes configuraciones:

  1. VPS 1GB de RAM
    • PHP + Apache + NGINX + Subdominio
    • PHP + Apache + Subdominio
    • PHP + NGINX + Subdominio
  2. Raspberry Pi Modelo B 512 MB de RAM
    • PHP + Apache en Localhost
  3. Pine A64 1GB de RAM
    • PHP + Apache en Localhost
  4. Laptop Core i7 séptima generación 12GB de RAM
    • PHP + Apache en Localhost + túnel SSH inverso + NGINX (proxy inverso) + Subdominio (si, ha sido la configuración mas loca que he hecho)

Claro, cada instalación ha tenido sus diferentes problemas, pero en general, el actualizador es el problema principal. Actualmente la configuración mas efectiva que tengo funcionando es la de VPS 1 GB de RAM con PHP-FPM con NGINX.

Aunque en un principio pensé que podría ser cosa de la RAM, el haber tenido el mismo problema con una computadora de 12GB me hizo entender que tal vez haya algo mas de fondo. Aun así, lo mejor es resolver y seguir y ya encontraré la razón después.

Error: Step 5 is currently in process. Please reload this page later.

Este error aparece al intentar actualizar NextCloud con la interfaz web por primera vez al atascarse en el paso 5 del proceso de actualización.

Error Step 5 is currently in process. Please reload this page later

Luego de fallar en la actualización, el actualizador web deja de funcionar.

Step 5 is currently in process. Please reload this page later

Este error es bastante curioso pues no afecta al funcionamiento de NextCloud. Aun así, lo recomendable es mantenerse al día con las actualizaciones correspondientes

Si buscas en la carpeta de datos de tu instancia de NextCloud, puedes encontrar este registro, indicando que se ha atascado en el paso 5. Puedes borrarlo y el actualizador volverá a comenzar, aunque se atascará en el mismo paso.

Step 5 is currently in process. Please reload this page later

Para corregir el problema, debes hacer lo siguiente:

Elimina el archivo updater.log en el directorio de datos.

En el mismo directorio, elimina la carpeta updater_ocheg, este proceso puede tomar algún tiempo.

A partir de aqui, puedes seguir los pasos de la documentacion oficial para la actualizacion por consola, como esta descrito en este enlace:

https://docs.nextcloud.com/server/latest/admin_manual/maintenance/update.html

sudo -u www-data php --define apc.enable_cli=1 /var/www/nextcloud/updater/updater.phar

Este comando permite ejecutar el actualizador mediante la lineal de comandos y se mostrará el asistente de actualización por línea de comandos. Sigue los pasos indicados.

Asistente de actualizacion de NextCloud por Interfaz de linea de Comandos (CLI)
Asistente de actualizacion de NextCloud por Interfaz de linea de Comandos (CLI)
Actualizacion NextCloud completa

Una vez terminada la actualización, se mostrará un mensaje de éxito y la actualización estará completa.

Conclusiones

Es probable que para cada necesidad haya software que la resuelva, y para cada software pagado haya una version libre. Y aunque libre suela estar asociado a gratis, aunque no haya un costo real, fisico o tangible, es cierto que terminamos pagando de otras formas, por ejemplo, estudiando muchas cosas tecnicas, pagando por VPS, invirtiendo tiempo que podriamos estar gastando en algo mas productivo y cosas asi.

El selfhosting es una iniciativa que me ha encantado. Es divertido experimentar y descubrir soluciones a problemas extraños y, aunque haya mucha, muchisima frustracion, es algo que siempre termino repitiendo. Probablemente haga un post hablando sobre el selfhosting mas adelante, pero por ahora, aqui queda esta entrada.

Anécdota: ¡Out of Memory! ¡Sacrifiquen a los niños!

Esto puede ser una lección sobre como las copias de respaldo pueden salvar vidas.

Introducción

Debido a diversas circunstancias, actualmente tengo dos instancias VPS de idénticas características, cada una destinada a diferentes propósitos que en la practica resultan difusos; una para experimentos, otra para servicios web persistentes(paginas, blogs, herramientas)

CaracterísticaCantidad
CPU1 vCPU compartido
RAM1 GB
Disco Duro25 GB disco duro (no SSD)
Droplet ultra básico en Digital Ocean. Al momento de escribir este post, su precio es de $5 mensuales.

Yo no tengo experiencia administrando servidores de forma profesional, pero a medida que he ido aprendiendo cosas, he caído en cuenta de que es necesario tener tanto una IP publica, como un equipo permanentemente conectado a la red, para lograr algunas cosas así que he ido aprendiendo cosas nuevas vez tras vez. Algunas, a costa de todos mis datos almacenados.

La historia de hoy comienza con un error común, que he subestimado al pensar que no pasaría nada:

Sep 29 12:52:46 archvb systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Sep 29 12:52:46 archvb systemd[1]: mariadb.service: Failed with result 'exit-code'.
Sep 29 12:52:46 archvb systemd[1]: Failed to start MariaDB 10.4.8 database server.

Este error se solucionaba simplemente reiniciando el servicio, pero esta vez, en lugar de encender el servicio, la respuesta fue esta:

Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

Este error no me resultaba nuevo puesto que también es un error normal, pero resultaba inesperado debido a que al volver a intentar reiniciar el servidor, salía de nuevo el mismo error. Algo no estaba yendo bien.

Mi falta de experiencia me condujo a hacer lo mismo que incluso un profesional haría; buscar en Google.

Por supuesto, Google me respondió de la misma forma fatalista como lo haría con una persona preocupada por su salud, solo que en mi caso, todas las soluciones pasaban por borrar la base de datos por completo e iniciar de cero. Terror y depresión instantánea.

Dado que esa instancia la utilizo para hacer experimentos, no hay muchos datos que valgan la pena ahí. A lo mucho los Logs del sistema domótico y los del bot para descargar música, que en general solo es información estadística (que ya perdí en otro evento catastrófico anterior). El problema era que también cree una instancia de Nextcloud, especialmente complicada de mantener.

Entre practica y practica le había tomado cariño y agregando plugin, empecé a agregar datos que puedo rescatar sin problema alguno. Lo complicado era volver a configurar todo Nextcloud de cero.

Busque en los logs del sistema tratando de entender lo que sucedía, pero no he habilitado un log de archivo por parte del servicio. Por supuesto, la carpeta estaba vacía.

Echándole un ojo al dmesg, encontré este mensaje:

[11668880.114121] Out of memory: Kill process 25000 (mariadbd) score 96 or sacrifice child
[11668880.118537] Killed process 25000 (mariadbd) total-vm:1085072kB, anon-rss:97060kB, file-rss:0kB, shmem-rss:0kB

Esta información solo confirmaba mis sospechas, pero seguía sin dar con una solución. Decidí entonces apagar todos los servicios para empezar a borrar los archivos como decían las instrucciones. Hasta que se me ocurrió intentar por ultima vez levantar el servicio de mysqld. ¡Y se levantó!

A salvo. ¿Ahora que?

No es la primera vez en la que mi servidor cae. Pero si es la primera en la que lo hace tras optimizarlo y mimarlo tanto, por lo que pensé que lo mejor seria realizar un respaldo regular de las bases de datos para empezar. ¿Pero donde?

  • Es posible crear una tarea programada con CRON para extraer una copia de seguridad en el mismo servidor, pero ¿de que serviría si esta cae junto a el?
  • Para empezar, de todas formas, comenzare haciendo una copia de seguridad local regular.
  • Es posible, mediante SSH, crear una copia de seguridad en un equipo físico, también con CRON. Hacerlo de forma regular permite poder restaurar hasta algún punto en el que no haya arruinado algo al travesear con las configuraciones.
  • Debo investigar si es posible utilizar otros servicios en la nube para crear respaldos. Tal vez Google Drive o OneDrive, puesto que tampoco tengo algo tan valioso como para pagar un servicio en la nube.
  • Y por supuesto, Todos los respaldos deben ser automáticos. Hacerlo de forma manual es probablemente mas inseguro que no hacerlo.

Consideraciones

Por el momento estoy investigando como hacer respaldos regulares, Locales, pero regulares, utilizando el cliente de consola MySQL y el automatizado de procesos CRON. Y realmente me esta gustando CRON. No entiendo por que le tuve tanto miedo si ha sido tan fácil de usar. Aunque tengo que conceder que todo lo que se maneje por consola es aterrador y mas si es poco o nada intuitivo.

Incidente: Colapso de instalación de WordPress al actualizar Jetpack

A veces es fácil olvidar que los programas que utilizamos a diario son escritos por humanos, así que nos suele tomar por sorpresa cuando estos fallan. Se nos suele advertir que hagamos copias de respaldo de nuestros datos, pero el engorroso proceso para restaurar estos datos, hace que descuidemos toda medida preventiva y todo va bien, hasta que empieza a ir mal.

El caso de hoy es uno que me sirve de advertencia sobre las actualizaciones automáticas. En general funcionan bien, pero pueden haber sorpresas. Incluso WordPress nos lo advierte cuando las activamos. En mi caso, he hecho caso de la advertencia, activándola únicamente para la extensión que menos creí posible que falle; Jetpack.

Si, es cierto que las actualizaciones de Jetpack suelen estar cargadas de nuevas funcionalidades, pero no era difícil confiarse. Especialmente cuando se lidia con otros problemas, que se suelen resolver con un solo click.

Usualmente resuelvo los problemas del servidor luego de echarle un ojo a los logs del sistema y reiniciar los servicios, pero esta vez no tenia tiempo asi que solo reinicie los servicios sin revisar los logs y me olvide del asunto. Entonces una hora luego, me aparecio este mensaje:

El sitio estaba una hora caído. Mi pequeño blog no tiene muchas visitas y (por ahora) no esta monetizado, así que no me preocupaba. Volví a reiniciar los servicios y continúe resolviendo otros problemas.

La notificacion de que el sitio continuaba caido me atormentaba hasta que por fin tuve tiempo para dedicarle al servidor y comence el diagnostico.

Primero, revisar que mensaje de error muestra el navegador:

Ha habido un error critico en esta web. Si los servicios estuvieran caídos, el error debería ser de conexión rechazada, así que no era cuestión de los servicios.

Lo segundo a hacer es acceder a la consola del servidor y buscar en los logs algún patrón que parezca sospechoso en el log de errores e /var/log/apache2/error.log y encontré lo siguiente:

PHP Fatal error:  Uncaught Error: Failed opening required '/var/www/interlan.ec/wp-content/plugins/jetpack/jetpack_vendor/automattic/jetpack-waf/src/../rules/allow-ip.php'

Este error no tiene misterios. Lo único que habría que hacer era desactivar el plugin de Jetpack para resolver el problema y reinstalarlo. Un plan perfecto, sin fisuras.

Desafortunadamente era imposible entrar al panel de administración de wordpress.

Mi otro blog pasó por exactamente el mismo problema, pero a diferencia del primero, alcanzó a enviarme un enlace al modo de recuperacion que existe desde la versión 5.1 de WordPress, así que al usarlo, bastó con desinstalarlo y reinstalarlo. Esta es una funcion muy util, si el colapso da el tiempo a mandar el correo con la ulr de rescate.

En el caso de mi blog principal, la URL no fue enviada, asi que tuve que buscar el plugin y borrarlo manualmente, con lo que recuperaría el control y volvería a abrirlo al publico.

Por supuesto, fue necesario algo de limpieza adicional para que todo vuelva a esta en orden. Al menos por un tiempo.

Cuando otra vez colapso con el mismo problema, habia una tercera cosa que quedaba por hacer para entender lo que estaba pasando. Recurrir a google.

Una de las cosas que mas me fastidia del internet actual es que la gente ya solo hace consultas en redes sociales, por lo que buscar en google puede dar resultados muy antiguos, de la epoca en la que los foros publicos estaban mas activos.

Minar preguntas en stack overflow llevaria mucho tiempo, asi que tras borrar jetpack otra vez, abri el instalador de su plugin y me encontre con que habian sacado una nueva version, apenas una hora antes. Era evidente de que ellos estaban consientes del problema que habían causado.

El unico bug que arreglaron era justamente uno sobre mi problema actual:

Firewall: prevent sites from crashing when updating Jetpack versions due to a missing generated file.

Explorar los comentarios fue suficiente para saber que no era el único con el problema y tras deleitarme un poco con las quejas de otros, decidí que lo mejor seria dejar deshabilitado jetpack hasta que salga una nueva actualización que corrija lo que la actualización para corregir un problema, había dañado.

Por supuesto, resolver este problema me ha enseñado algunas lecciones y espero que si alguien tiene el mismo problema, se pase por mi solución antes de intentar resolverlo con medidas desesperadas.

El Voltaje de salida del modulo regulador cn2596-2 es igual al de entrada

cn2596-2
cn2596-2

He tenido este pequeñín durante algunos años dando vueltas por ahí, sin uso, debido a que al conectarlo, el voltaje de salida es igual al voltaje de entrada, por lo que siempre pensé que su uso no seria diferente de un cable, aun así, lo he conservado y he dedicado algo de tiempo a investigar su funcionamiento, hasta que finalmente encontré la respuesta en un video ruso que obviamente no logro entender, pero me hizo dar cuenta del problema.

Usando un multímetro midiendo los pines de salida, hay que girar el potenciómetro en sentido contrario a las manecillas del reloj hasta que el voltaje medido comience a cambiar.

Esto causara que el voltaje de salida medido por el aparato también cambie y se desajuste, por lo que por ahora, no confiaría en ese resultado, debido a que no es el dado por las pruebas.

Pongo las especificaciones técnicas y unas cuantas fotos de una tienda random donde lo encontré:

  1. Voltaje de entrada: 4-40 v (40 v máximo voltaje)
  2. Voltaje de salida: 1.25V – 37V (En el modo de descomprensión, la entrada debe ser superior a los dos voltios)
  3. Corriente de salida: 2 A salida continua.
  4. Potencia de salida: Máximo 15 w.
  5. Frecuencia: 150 KHZ.
  6. Pico de onda: 100 mv.
  7. Precisión del voltímetro: ± 5 ‰
  8. Potencia estática: 20 ma (desviación por voltaje de entrada, salida y display)
  9. Peso: 33g.10.
  10. Tamaño: 7cm*4cm.
  11. Con la función de display de voltaje, la precisión es de ± 0.05V, y el rango es de 0 – 40V.( Nota: para asegurar la máxima precisión, el voltaje de entrada debe ser superior a 4V)
  12. Botón para cambiar la medida del voltaje de entrada o salida y un led que indica el actual modo de medición, las configuraciones no se pierden al desconectar la alimentación
  13. Voltaje continuo ajustable de salida en un rango de 1.25V -37V, 4-40V de entrada. El voltaje de entrada debe ser superior a 1.5V)
  14. Oscilador de alta eficiencia ajustado a 150 kHz f
  15. Garantizado 3A de carga de corriente de salida.
  16. Protección por temperatura y limite de corriente.

Bibliografia/Webgrafia

Datasheet del modulo lm2596-d:

El video ruso que me sirvió:

Próximo material de estudio:

https://www.instructables.com/The-Introduction-of-LM2596-Step-Down-Power-Module-/

Notas adicionales

Yo compre este aparato en Banggood hace algunos años, pero no estoy seguro de si aun lo venden. Como mi pais tiene problemas de comercio exterior, banggood ya no manda casi nada aquí, y encima me bloquea los productos que sabe no me puede enviar.

Me interesa también la idea de hackearlo, pero por ahora me conformare con que pueda regular los voltajes de salida de forma correcta.

https://hackaday.io/project/19647-low-cost-programmable-power-supply/details
Interlan
A %d blogueros les gusta esto: