{"id":711,"date":"2022-01-12T15:19:51","date_gmt":"2022-01-12T14:19:51","guid":{"rendered":"https:\/\/esferas.org\/mldt\/?p=711"},"modified":"2022-01-12T15:19:51","modified_gmt":"2022-01-12T14:19:51","slug":"tareas-miercoles-12-de-enero-de-2022","status":"publish","type":"post","link":"https:\/\/esferas.org\/mldt\/tareas-miercoles-12-de-enero-de-2022\/","title":{"rendered":"Tareas: mi\u00e9rcoles, 12 de enero de 2022"},"content":{"rendered":"\n<p>Empezamos fino. Ten\u00eda pensado dedicarme a cerrar asuntos de administraci\u00f3n e infraestructuras (pomposo nombre) y resulta que tengo que apagar fuegos.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h3 class=\"wp-block-heading\">Servidor ss.venexma.net<\/h3>\n\n\n\n<p>Aqu\u00ed s\u00ed que me he llevado una buena sorpresa. Estas m\u00e1quinas llevan instalado un paquete m\u00edo llamado recolector que se encarga de recopilar informaci\u00f3n en un formato plano, o lo m\u00e1s plano posible, para que sean recuperadas por el sistema de copias de seguridad y est\u00e9n m\u00e1s a mano. <\/p>\n\n\n\n<p>Hasta ahora he tenido varios problemas de todo tipo con ellas pero eran m\u00e1s bien comprensibles. Hoy y ayer, sin embargo, veo que la recolecta que comienza a las nueve de la noche y que dura diez o quince minutos a lo sumo est\u00e1 atascada hasta la hora de inicio de trabajo o incluso m\u00e1s. Tanto que hay que matar los procesos. \u00bf El atasco ? En el volcado de la base de datos de PostgreSQL y su proceso de compresi\u00f3n. Sin m\u00e1s pistas por ahora. No se me ocurre nada m\u00e1s que ver qu\u00e9 opciones estoy empleando con <em>pg_dump<\/em> y ver si es posible que se quede congelado por alguna otra circunstancia como un bloque a nivel de base de datos. <\/p>\n\n\n\n<p>Una vez que he detenido el proceso de recolecci\u00f3n me he dado cuenta de que la carga del sistema sigue estando disparada: entre 3,5 y 5,9 (m\u00e1s o menos). Me he puesto a investigar y he visto que es cosa del acceso a disco. CPU relajada y feliz, memoria m\u00e1s que descargada y procesos que no sobrepasan el 5% de uso. \u00bf Entonces ? Pues observando con el programa <em>iotop<\/em> he visto cosas como la siguiente:<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><a href=\"https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/imagen-6.png\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"169\" src=\"https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/imagen-6-1024x169.png\" alt=\"\" class=\"wp-image-715\" srcset=\"https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/imagen-6-1024x169.png 1024w, https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/imagen-6-300x50.png 300w, https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/imagen-6-768x127.png 768w, https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/imagen-6-1536x254.png 1536w, https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/imagen-6-960x159.png 960w, https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/imagen-6.png 1566w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/a><\/figure><\/div>\n\n\n\n<p>Esto es, el disco ocupado casi el 100% del tiempo y r\u00e1fagas de lecturas continuas que superan los 100M\/s. Pues mira, ah\u00ed est\u00e1 el problema. O al menos el causante. Ahora a ver qu\u00e9 hace odoo, qu\u00e9 hace PostgreSQL o qu\u00e9 hacen los dos para estar continuamente as\u00ed. Y supongo que el problema anterior viene de ah\u00ed. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Fotocopiadora Kyocera y el env\u00edo de correos desde el esc\u00e1ner<\/h3>\n\n\n\n<p>Este problema me lo comunicaron ayer. No es nuevo y tiene ya unos cuantos d\u00edas pero cuando se es t\u00edmido no se puede esperar mucho m\u00e1s. <\/p>\n\n\n\n<p>La fotocopiadora tiene la opci\u00f3n de escanear documentos, empaquetarlos en un PDF y enviarlos por correo electr\u00f3nico. Esto es lo que falla. Y creo que falla desde que migr\u00e9 el servidor a Debian 11. No he querido que la m\u00e1quina enviase directamente a Google por no tener que definir una cuenta de conexi\u00f3n. Me limito a enviarlo al servidor interno y de ah\u00ed, tras ser encolados, salen hacia Google. <\/p>\n\n\n\n<p>Y, claro, Google como que pasa de nosotros y muchos de ellos vuelven a sufrir el misterioso corte en la transmisi\u00f3n TLS y nos dejan colgados. Supongo que tendr\u00e9 que desviar el correo hacia Google a trav\u00e9s Gandi como he hecho en otras instalaciones. No me hace gracia porque pierdo control sobre entregas pero tampoco es que vea otra. <\/p>\n\n\n\n<p>El caso es que algunos mensajes llegan. Otros no, se interrumpen. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Servidor sigfrido.venexma.net<\/h3>\n\n\n\n<p>Inspeccionando la cola de mensajes en el servidor interno de correo he visto que hay muchos que est\u00e1n atascados porque la direcci\u00f3n de entrega no existe. Y es verdad, son direcciones que en esa m\u00e1quina no tienen ning\u00fan sentido. Al parecer algunos de los servidores virtuales no est\u00e1n correctamente configurados para enviar los correos hacia root. Lo hacen con la direcci\u00f3n <code>root@$(hostname -f)<\/code> en lugar de root@venexma.net que es la que recibe todos los mensajes de este tipo. <\/p>\n\n\n\n<p>He alterado la configuraci\u00f3n del programa nullmailer que utilizo en todas ellas para que env\u00eden correctamente y s\u00ed que funcionan. Las m\u00e1quinas afectadas son: monitor.venexma.net, docs.venexma.net y almacen.venexma.net. Esas por el momento. Ahora limpiar\u00e9 la cola de mensajes lo m\u00e1s que pueda porque no veo otra forma (ni inter\u00e9s) en que se cambie la direcci\u00f3n de entrega de mensajes ya encolados.<\/p>\n\n\n\n<p>La forma de limpiar los mensajes ha sido:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"># exim4 -Mrm $(exiqgrep -z -i -r 'root')<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Servidor docs.venexma.net<\/h3>\n\n\n\n<p>Estaba recibiendo mensajes de error del proceso que crea instant\u00e1neas del sistema de archivos btrfs en esta m\u00e1quina pero ve\u00eda que el trabajo se estaba haciendo. He descubierto que el que funcionaba era el trabajo de root. El que fallaba era una versi\u00f3n antigua en el directorio <em>\/etc\/cron.d<\/em>. He movido uno sobre otro y lo he retocado para a\u00f1adir el usuario porque no entend\u00eda nada de lo que pasaba. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Servidor backups.venexma.net<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li>He desactivado la copia de seguridad de la m\u00e1quina proyectos.venexma.net porque a\u00fan no quiero ponerla en marcha. Tampoco es que est\u00e9 muy seguro, dado el ritmo que llevo \u00faltimamente, de que me haga falta un gestor de proyectos. As\u00ed que de momento parado.<\/li><li>Las copias de docs.venexma.net est\u00e1n fallando continuamente. No me gusta un pelo porque los archivos y directorios est\u00e1n -son unas 450 gb extra\u00eddas- pero la copia falla de forma muy rara. Lo aparco de momento. <\/li><\/ul>\n\n\n\n<p>El registro de transferencia es la siguiente: <\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">2022-01-12 06:00:00 Renaming \/var\/lib\/backuppc\/pc\/docs.venexma.net\/XferLOG.1.z -> \/var\/lib\/backuppc\/pc\/docs.venexma.net\/XferLOG.1.z.tmp\n2022-01-12 06:00:09 incr backup started for directory \/etc\n2022-01-12 06:00:29 incr backup started for directory \/usr\/local\/sbin\n2022-01-12 06:00:29 incr backup started for directory \/usr\/local\/bin\n2022-01-12 06:00:30 incr backup started for directory \/root\n2022-01-12 06:00:30 incr backup started for directory \/home\n<strong>2022-01-12 06:00:31<\/strong> incr backup started for directory \/srv\n<strong>2022-01-12 06:06:04<\/strong> Got fatal error during xfer (rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3.0])\n2022-01-12 06:06:09 Backup aborted (rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3.0])<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Varios <\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li>Recibo un mensaje de gandi con el aviso de la renovaci\u00f3n del dominio suelaexpress.com. Como no tenemos una tarjeta de cr\u00e9dito asociada a la empresa (y mira que tenemos cuatro dominios con ellos y ser\u00eda \u00fatil, pues no) he tenido que pagarla yo de mi bolsillo (14\u20ac) y pasarle la factura proforma al contable para que me la abone. <\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">El modelo 347: la tragedia anual<\/h3>\n\n\n\n<p>Ya ni recuerdo el n\u00famero de veces que me he enfrentado a este problema. No deber\u00eda serlo porque en el fondo son habas contadas pero lo es. Este a\u00f1o he tenido que volver a ponerme a los mandos y ahora mismo estoy mentando a los antepasados de los mercenarios que montaron el pollo que tenemos montado. Como lo que m\u00e1s corre prisa es generar las cartas para avisar a clientes y proveedores de sus cifras y poder contrastarlas, as\u00ed que me encuentro enfangado en el infierno de m\u00f3dulos y subm\u00f3dulos de odoo y su est\u00fapido modelo orientado a objetos y no s\u00e9 ni d\u00f3nde estoy ni a d\u00f3nde voy a llegar. <\/p>\n\n\n\n<p>De momento me he dado cuenta de que tras la migraci\u00f3n no funciona ninguno de los programas web de acceso a las bases de datos y, demonios, me hacen mucha falta. <\/p>\n\n\n\n<p>Si esta tarde puedo avanzar lo apunto aqu\u00ed. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Empezamos fino. Ten\u00eda pensado dedicarme a cerrar asuntos de administraci\u00f3n e infraestructuras (pomposo nombre) y resulta que tengo que apagar fuegos.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"webmentions_disabled_pings":false,"webmentions_disabled":false,"footnotes":""},"categories":[121],"tags":[126,14,215,13,224,172,35,94],"class_list":["post-711","post","type-post","status-publish","format-standard","hentry","category-el-dia-a-dia","tag-administracion","tag-backups","tag-btrfs","tag-gandi-net","tag-iotop","tag-modelo-347","tag-odoo","tag-postgresql","content-box"],"_links":{"self":[{"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/posts\/711","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/comments?post=711"}],"version-history":[{"count":12,"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/posts\/711\/revisions"}],"predecessor-version":[{"id":726,"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/posts\/711\/revisions\/726"}],"wp:attachment":[{"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/media?parent=711"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/categories?post=711"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/esferas.org\/mldt\/wp-json\/wp\/v2\/tags?post=711"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}