Pues después de un fin de semana extraño y triste llego al lunes intentando ocuparme de muchas cosas al mismo tiempo para no volver a sentir lo de estos días atrás.
Fotocopiadora
El envío de documentos escaneados por correo electrónico (a nuestro dominio gestionado por el puto Google) se ha vuelto imposible. Imposible de predecir, además. Hay algunos que entran, otros que no, otros que tal vez (y permanecen días en la cola de envíos de exim4). Y así no puedo vivir porque mis homínidos me reclaman atención cada pocos días.
Una de las posibilidades era emplear el complejo y absurdo panel de control web de la impresora para configurar el envío directo a Google. Y no, ni de coña, porque cosas como la validación Oauth2 ni la mencionan. Vale, pues eso no. Volvemos a enviar sin identificación a nuestro servidor interno y que él se las apañe. Pero para eso no podemos hacer como ahora y enviárlo directamente a Google. Empleemos entonces el truco de usar un servidor de envío (un mailer) y nos creamos una cuenta de correo en el registrador de dominios gandi.net, que tan buenos resultados nos ha dado en el pasado con otros entornos.
Y en eso estoy por ahora. En enviar todos los correos que partan de nuestro servidor venexma.net a nuestro buzones de venexma.es a través de mail.gandi.net.
Correo electrónico desde odoo
Desde el principio odoo ha necesitado una cuenta propia para enviar todos los documentos a clientes y proveedores. Eso ha funcionando más o menos bien hasta que nos dimos cuenta de que al ser una cuenta real de Gmail (y pagada) también podía recibirlos. Y lo hacía. Muchos clientes contestaban a los mensajes recibidos y al no haber la posibilidad fácil de poner una cuenta de contestación pues los mensajes se almacenan en su buzón de entrada.
Tuve que conceder, tiempo atrás, acceso a varias cuentas de mis homínidos a la cuenta de odoo y parece que todo marchaba. El problema, claro, es que tenían que acordarse de acceder a dicha cuenta regularmente. Y no lo hacen.
Así que he aprovechado que tenemos un grupo de correo (una lista de toda la vida excepto para Google) y he indicado que todo lo que llegue a la cuenta de odoo se reenvíe a dicho grupo y se marque como leído.
Esperemos que eso funcione por ahora, que ya se me están acumulando las tareas y las quejas.
Réplica de ss.venexma.net
Como ya mencioné el pasado sábado tengo que crear una réplica de la réplica de la instalación principal de odoo. Para ello he utilizado ss.venexma.net y me he encontrado con el problema de falta de espacio en disco. Al ser una máquina de sobremesa del tipo SFF (porque es de segunda o tercera mano y es lo que compramos por precio) no me cabe ningún disco más de 3,5″. Pues vaya. Como tampoco tengo opción de poner uno externo he pensado que estaría bien un acceso NFS a otra de las máquinas que tienen algo más de espacio. Esta solución es muy rápida y fiable pero enmaraña bastante el diagrama de red. Qué le vamos a hacer. Al menos con Linux es factible.
Y no ha costado mucho. En la máquina que ofrece el servicio he creado dos juegos de directorios: uno real y otro para construir la exportación de datos:
$ sudo install -d /nfs/beta $ sudo install -d /var/nfs/beta $ tail fstab # Montajes NFS: directorio real -> directorio exportado /var/nfs/beta /nfs/beta none rw,bind 0 2 $ tail exports /nfs 192.168.100.12(ro,sync,insecure,root_squash,no_subtree_check,fsid=0) /nfs/beta 192.168.100.12(rw,nohide,sync,insecure,no_root_squash,no_subtree_check)
Se reinician servicios y ya está listo para ofrecer espacio en disco gratis. Ahora en la máquina destino tenemos dos opciones: montaje fijo o montaje a demanda. Y en este caso creo preferible el montaje a demanda porque estoy seguro de que la réplica de la réplica de la instalación principal se va a emplear muy poco y no quiero comprometer el arranque del sistema porque el servidor de NFS está parado o algo similar.