lunes, 8 de junio de 2020
Siguiendo los pasos de la semana pasada he consultado mi buzón de entrada del usuario root centralizado y hay cuarenta mensajes del tipo automático.
Continuelunes, 8 de junio de 2020
Siguiendo los pasos de la semana pasada he consultado mi buzón de entrada del usuario root centralizado y hay cuarenta mensajes del tipo automático.
Continue4 de junio de 2020
Varios mensajes de correo que se repiten casi a diario me han hecho que visite con más detenimiento la configuración de este programa.
Continue3 de junio de 2020
Pues ha fallado. Y lo habían avisado tiempo atrás, que aquellas aplicaciones que no empleasen la autentificación OAuth2 no podrían utilizarse.
Continue3 de junio de 2020
Después de casi tres meses de estar en un ERTE hoy vuelvo al trabajo.
Me he encontrado con algunos problemas menores que estoy resolviendo antes de ponerme a trazar planes a corto y medio plazo.
ContinueEl miércoles pasado tuvimos un corte de luz y aunque apagué los servidores a tiempo uno de los discos de sigfrido, aquél donde se recibían las copias hechas con attic dejó de funcionar.
Estuve el domingo echándole un vistazo con ayuda de un conector USB-SATA externo y no hubo forma. La tabla de particiones había volado y el resto del disco no reaccionaba. Cuando lo extraje, antes de apagar la alimentación del conector USB, me encontré con que el disco se movía de un lado a otro como si tuviese un peso en uno de los extremos. Muy raro todo.
He enviado aviso al que creo que me lo vendió para ver si está en garantía por si acaso, y he usado otro como reemplazo del que también tengo mis dudas.
… ambos dos me han estado molestado pero ya lo he arreglado.
Es un error un tanto estúpido que impide que algunas expediciones no puedan ser modificadas. El error concreto salta cada vez que se entra en la modificación de un destinatario y se pasea por el formulario.
Tras probarlo varias veces y depurarlo otras tantas he visto que el error estaba principalmente sobre el campo año del número de albarán. He supuesto que se debía a que no había sido recompilado por completo y estaba tomando la validación antigua, aquella que limitaba los años a 2015, y que cambié hace poco.
He forzado una compilación y he vuelto a instalar el programa expediciones. Parece que ahora funciona (al menos en mis pruebas, ayer no terminé de recibir confirmación de Luismi).
… pero aún no sé con cuales. En mi máquina, sarajevo, tengo instalados demasiados y el rastro que deja el inicio del programa no es muy allá.
$ firefox JavaScript warning: chrome://savetextarea/content/savetextarea.js, line 26: unreachable code after return statement JavaScript warning: chrome://web-developer/content/common/jquery/jquery.js, line 1: Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //# instead JavaScript error: chrome://web-developer/content/overlay/javascript/overlay.js, line 7333: TypeError: document.getElementById(...) is null JavaScript warning: file:///home/victor/.mozilla/firefox/v71fg0fm.default/extensions/https-everywhere-eff@eff.org/components/ssl-observatory.js, line 326: flags argument of String.prototype.{search,match,replace} is deprecated Violación de segmento $
Pero el caso es que Firefox emite tantos avisos de problemas que es muy difícil saber quién es el que provoca la muerte del proceso.
Y sé que son los complementos porque si se ejecuta con
$ firefox -safe-mode
funciona, aunque sigue generando avisos y mensajes.
No puedo instalarlo de momento en las máquinas cliente o tendré un motín.
Copio y pego el mensaje que he enviado hoy a la lista de usuarios de facturación.
Debido a un pequeño error por mi parte he tenido que lanzarme con el proceso nuevo de impresión de facturas que llevaba algunos días preparando.
Este nuevo mecanismo de impresión persigue, sobre todo, la impresión de facturas a doble cara para ahorrar papel. Para ello he tenido que cambiar las siguientes cosas:
- Cada factura se imprime como un trabajo de impresión individual. Antes se enviaban todas en bloque, lo que imposibilitaba la impresión a doble cara.
- Cada factura, además, envía tres trabajos de impresión continuos, uno por cada pié de página distinto: cliente, archivo y administración. Eso significa que las facturas aparecen mezcladas según su destino.
Como resultado de estos cambios tenemos ahora mismo:
- El sistema es muchísimo más lento que antes para imprimir. La carga sube de tal manera que es muy difícil trabajar con Adriano o Conta mientras se crean las facturas.
- Por lo que acabo de saber algunos trabajos de impresión se pierden y no aparece la correspondiente copia de la factura.
- Las impresoras cuyo nombre terminan en -fac1 o -fac3 ya no son necesarias; por tanto:
- Todas las facturas deben enviarse a partir de ahora por la impresora sin terminación: im0, im1, …
- Es necesario cambiar las opciones de impresión en Adriano para cuando se imprime facturas en grupo.
- Desaparece la opción de imprimir una copia de la factura: a cambio va a existir la copia a PDF.
- Todos los listados que genere Adriano van a ser impresos a doble cara siempre.
Y lo que voy a hacer a continuación es:
- Mover la generación de facturas desde el servidor donde funciona Adriano al servidor principal de manera que se baje la carga de sistema. Esto va a llevar un poco de tiempo porque es un poco delicado.
- Reorganizar la impresión de facturas para que se impriman por bloques como antes.
- Terminar la impresión a PDF de las facturas.
Aunque creo que he encontrado el problema con los trabajos perdidos. En los registros del servidor CUPS principal me he encontrado con cosas como:
D [26/Mar/2015:10:53:14 +0100] Create-Job ipp://localhost/printers/canon D [26/Mar/2015:10:53:14 +0100] Create-Job client-error-not-possible: Demasiados trabajos activos. E [26/Mar/2015:10:53:14 +0100] Returning IPP client-error-not-possible for Create-Job (ipp://localhost/printers/canon) from localhost D [26/Mar/2015:10:53:14 +0100] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Active clients, printing jobs, and dirty files"
Así que me he visto obligado a aumentar drásticamente el límite de CUPS, que pasa de 50 a 500 trabajos activos. No llegaremos a tanto, creo, pero así por lo menos esquivaremos el problema de que el servidor LPRng de Helena ignora a CUPS y no se guarda el trabajo en cola hasta tener el visto bueno del otro extremo.
Otro problema añadido es que no hay garantías de que los trabajos salgan en el orden adecuado. Si son de mayor tamaño algunos trabajos pueden salir más tarde que otros que se han enviado antes: cosas de la multitarea.
Un nuevo correo (que con suerte leerán) les informa del último arreglo.
Las máquinas facturacion1 y extranjero se han quedado sin poder imprimir en la red esta mañana. Después de varios reintentos he conseguido que vuelvan a aparecer las impresoras pero no estoy seguro de qué lo ha causado y cómo se ha arreglado.
El problema se encuentra en que cups, el servidor local de impresión, no puede acceder a ciertos puertos en la red para escuchar qué impresoras se ofrecen. He reiniciado los servicios rpcbind, avahi-daemon y cups con varias combinaciones hasta que lo he conseguido.
Sí que he visto en los registros mensajes que hacía tiempo que no veía. Concretamente algo como:
Sep 10 09:49:06 extranjero rpc.idmapd[1783]: nss_getpwnam: name ‘alfredo@venexma.net’ does not map into domain ‘localdomain’
Y es algo que he visto antes pero no consigo saber dónde. Algún detalle de la última instalación, supongo.