-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-06-23 a las 23:54 +0200, Camaleón escribió:
El 2009-06-23 a las 21:57 +0200, Carlos E. R. escribió:
El 2009-06-23 a las 21:34 +0200, Camaleón escribió:
Pues que avise cuando pete, no antes.
Si está "caído" ya no puede avisar >X-)
Pos entonces "algo" avisará de que está caído, aunque sean los usuarios a tu móvil >:-)
Pero si se dan cuenta los usuarios de que "pasa algo" es que entonces el mal ya está hecho. Se trata de que tú enteres antes que ellos :-P
Cuando pase algo de verdad no lo va a reportar, se caerá. Entonces los programadores lo corregirán y pondrán un mensajito en el log para que nos enteremos.
Si un mensaje tiene URLs mayores de la cuenta, que lo diga en el informe que emite con cada correo:
X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,RDNS_NONE autolearn=disabled version=3.2.4
y no lo dice.
Porque esa información no es relevante para el usuario y no debe ir en las cabecereras de los mensajes, por seguridad :-/. Tiene que ser visible para el administrador.
Y lo es... en el mail.debug.
Vamos a ver, te mandan correos con cienes de virus a los usuarios. ¿Quieres ver eso en el log/warn? Pues no. Que lo pongan en el /var/log/mail.warn (que yo lo tengo y ahí están los mensajes).
¡No es lo mismo!
Un virus en un mensaje o cienes de correos de spam son procesos que *no* afectan directamente al servidor, ni te deja tirado un servicio, salvo que se trate de un ataque dirigido.
Pues es lo mismo. Que alguien me mande algo que parezca un enlace demasiado largo no es un error "crucial" para el sistema.
Jo, si acabas de decir que tú mismo reportaste un bug que hacía saltar al SA ¡y era precisamente por esto mismo! Yo creo que sí es serio.
¡Era! Era serio. No comprobaban la longitud del posible enlace antes de pasárselo al módulo de comprobación de URLs, el cual cascaba. Había dos errores: no mirar la longitud antes de enviarlo, y no mirarla y petar antes de analizarla, en dos módulos distintos. Ahora sí se comprueba la longitud, e informan de ello, lo cual es pasable. ¡Lo que no es pasable es que me avisen con nivel de emergencia! Es un problema corregido, no un aviso de problema.
Jun 23 19:58:00 nimrodel spamd[996]: bayes: cannot open bayes databases /home/cer/.spamassassin/bayes_* R/W: lock failed: File exists Jun 23
Bueno, depende de los efectos secundarios que tenga el que no pueda acceder al archivo de bdd bayesiana :-?
Ninguno. No puede escribir, pero puede leer, y lo hace. Encima, tengo el SA configurado para que no escriba automáticamente en el bayes.
Bueno, si no puede escribir, no puede aprender, y si no puede aprender y tienes al bayes configurado y activado, eso es una anomalía para el SA porque el SA está usando ese archivo. Tiene que avisar de que algo no está bien. En tu caso puede que no sea urgente, en el caso de GMail, o si se tiene activado el "bayes_autolearn", pues imagina >:-)
No es eso. Yo le he dicho que no escriba (que es una opción configurable), por lo cual no debe ni intentar escribir - pero lo hace. Ahora bien, resulta que hay varios procesos spamd que intentan abrir para escritura el mismo fichero - y no son capaces de acceder simultáneamente, no lo han programado para ello (ya he comentado otras veces mis dudas respecto al API de Linux en el acceso simultaneo compartido). Ese es el error, que no han programado el acceso simultaneo de varios procesos. El primero que llega bloquea el fichero, y los demás fallan. Eso se sabe. Deberían darse cuenta de eso y no informar como emergencia, sino como "debug", si acaso. Y programar el acceso arbitrado.
¿Y cómo lo hace "sutilmente"? Bueno, vale podría ser configurable desde un archivo... pero si tanto te molesta, fíltralo en el syslog-ng para que no lo registre >:-P
Si, ya... lo puedo hacer, pero eso no es la filosofía.
La filosofía debe ser "mantén al administrador informado" para que actúe (o no) en consecuencia y si el administrador es también usuario, pues permitirle que configure lo que quiere (o no) registrar.
Ambas premisas se cumplen >:-)
No, no se cumplen. No es correcto atiborrar al administrador de avisos con nivel de emergencia, sin serlo, porque se le pasarán por algo las verdaderas emergencias. Se deben grabar esos avisos, pero con un nivel mucho más bajo. Están ahí para que el administrador los vea, no para asustarle. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpBVg0ACgkQtTMYHG2NR9UDLACgmDa6xQHGGcjzbPpXeCypBzrO JScAn2e1YyNzRa5eHoaIGYsZYtEhQUrb =qPtb -----END PGP SIGNATURE-----