Spamassasin con fetchmail y procmail.
Hola. Tengo sue 9.0 y no soy capaz de poner a funcionar el spamassassin. Me he leído cosas en internet pero no logro que clasifique nada como spam. Mi .fecthmailrc tiene una línea que dice "procmail -d telecopower" ya que el Susefirewall2 no me deja llamar de ninguna manera a localhost, pero el correo baja bien. La cosa viene a que si yo, por ejemplo, me mando un spam con echo '<html><body>unadireccionmala</body></html>' | mail -s 'hablan de instrumentos alargadores' (lo pongo así pq Suse me lo devuelve) telecopower@localhost|spamassassin me sale que no es spam por más que repita la línea. Puede alguein echarme una mano a ver cómo hago? Recibo tantos mails de Suse como de spam!!! Sólo hoy en una cuenta de correo tenía 96 mensajes!!! y de ellos 55 eran de Suse. Gracias.
José Rodríguez S. escribió:
Hola.
Tengo sue 9.0 y no soy capaz de poner a funcionar el spamassassin. Me he leído cosas en internet pero no logro que clasifique nada como spam.
Mi .fecthmailrc tiene una línea que dice "procmail -d telecopower" ya que el Susefirewall2 no me deja llamar de ninguna manera a localhost, pero el correo baja bien.
La cosa viene a que si yo, por ejemplo, me mando un spam con echo '<html><body>unadireccionmala</body></html>' | mail -s 'hablan de instrumentos alargadores' (lo pongo así pq Suse me lo devuelve) telecopower@localhost|spamassassin me sale que no es spam por más que repita la línea.
Puede alguein echarme una mano a ver cómo hago? Recibo tantos mails de Suse como de spam!!!
Sólo hoy en una cuenta de correo tenía 96 mensajes!!! y de ellos 55 eran de Suse.
Gracias.
Yo tengo un problema parecido y uso Mozilla Thunderbird que filtra el spam con una efectividad muy alta. Por si te sirve... Saludos.
El 2004-06-05 a las 16:29 +0200, José Rodríguez S. escribió:
Hola.
Tengo sue 9.0 y no soy capaz de poner a funcionar el spamassassin. Me he leído cosas en internet pero no logro que clasifique nada como spam.
Mi .fecthmailrc tiene una línea que dice "procmail -d telecopower" ya que el Susefirewall2 no me deja llamar de ninguna manera a localhost, pero el correo baja bien.
El Susefirewall2 no afecta en nada a fetchmail. Me parece que tienes montado un buen cacao. El firewall bloquea las conexiones entrantes, no las salientes... y el fetchmail sale.
La cosa viene a que si yo, por ejemplo, me mando un spam con echo '<html><body>unadireccionmala</body></html>' | mail -s 'hablan de instrumentos alargadores' (lo pongo así pq Suse me lo devuelve) telecopower@localhost|spamassassin me sale que no es spam por más que repita la línea.
Es que simplemente por poner esa cabecera no es spam... Y además, no has contado como llamas al spamassassin ni donde. -- Saludos Carlos Robinson
El dom, 06-06-2004 a las 01:57, Carlos E. R. escribió:
El 2004-06-05 a las 16:29 +0200, José Rodríguez S. escribió:
Hola.
Tengo sue 9.0 y no soy capaz de poner a funcionar el spamassassin. Me he leído cosas en internet pero no logro que clasifique nada como spam.
Mi .fecthmailrc tiene una línea que dice "procmail -d telecopower" ya que el Susefirewall2 no me deja llamar de ninguna manera a localhost, pero el correo baja bien.
El Susefirewall2 no afecta en nada a fetchmail. Me parece que tienes montado un buen cacao. El firewall bloquea las conexiones entrantes, no las salientes... y el fetchmail sale.
Ojo, no he dicho que el susefirewall me trastocara el fetchmail, dije que cuando tengo el susefirewall2 levantado no puedo hacer llamadas a localhos, o sea, pones http://localhost en el navegador y se agota el tiempo, un ftp no se conecta, telnet tampoco y aasí unas cuantas cosas. Recuerdas que hace tiempo pregunté por qué el fetchmail podía mirar si había correo con la opción -c pero al decirle que los descargara no lo hacía? no encontraba a localhost para enviarlo. Lo arregle poniendo la línea "procmail -d usuario" en el .fetchmailrc. A eso me refiero, si quito el FW se reconoce localhost.
La cosa viene a que si yo, por ejemplo, me mando un spam con echo '<html><body>unadireccionmala</body></html>' | mail -s 'hablan de instrumentos alargadores' (lo pongo así pq Suse me lo devuelve) telecopower@localhost|spamassassin me sale que no es spam por más que repita la línea.
Es que simplemente por poner esa cabecera no es spam... Y además, no has contado como llamas al spamassassin ni donde.
Pues leí en una guía que eso servía para que filtrara. Al final de la línea sale |sapamassassin y el resultado es el análisis del mismo diciendo que no es spam y que necesito que me lo envíen 5 veces para que lo sea pero por más que me lo envío no lo cataloga. Por otra parte encontré otro sitio que dice cómo llamar a spamassassin desde evolution directamente, aunque mejor es la otra forma, y se llama con /usr/bin/spamc -c y lo que entrega se mueve a la carpeta spam pero no lo hhace, de hecho creo que ni lo mira porque el evolution se queda funcionando igual que antes y no se "toma su tiempo" en analizar el correo (el spamassassin) después de descargarlo. Debería parecer que el evolution se cuelga por unos instantes mientras el spamassassin trabaja pero no. Gracias.
-- Saludos Carlos Robinson
El Domingo, 6 de Junio de 2004 09:59, José Rodríguez S. escribió:
Pues leí en una guía que eso servía para que filtrara.
Al final de la línea sale |sapamassassin y el resultado es el análisis del mismo diciendo que no es spam y que necesito que me lo envíen 5 veces para que lo sea pero por más que me lo envío no lo cataloga.
Por otra parte encontré otro sitio que dice cómo llamar a spamassassin desde evolution directamente, aunque mejor es la otra forma, y se llama con /usr/bin/spamc -c y lo que entrega se mueve a la carpeta spam pero no lo hhace, de hecho creo que ni lo mira porque el evolution se queda funcionando igual que antes y no se "toma su tiempo" en analizar el correo (el spamassassin) después de descargarlo. Debería parecer que el evolution se cuelga por unos instantes mientras el spamassassin trabaja pero no.
A ver, yo uso el kmail para dos cuentas pop3 y la local y el spamassassin funciona 100%. El tema está en que el spamassasin sólo dice si algo es spam o no, en ningún caso te lo va a mover a ningún sitio. Eso lo tiene que hacer el evolution. No suelo trabajar con el evolution, pero para que te hagas a la idea, en kmail para usar el spamassassin se añaden 2 filtros: - El primero es que todo el mail que llegue pase por la tubería spamc. - El segundo comprueba si la cabecera X-Spam-Flag está activada. Es decir, si el spamassassin ha marcado el mensaje como spam. Si está activada, lo mueve a una carpeta llamada spam. No conviene borrarlos, que el spamassassin a veces se "cuela" y marca como spam mails que no lo son. Yo creo que el problema está en cómo haces el filtrado. Si usas "spam -c" el spamassassin no devuelve nada, tan sólo un 1 si es spam, o un 0 si no lo és. Para usar el filtro que te acabo de comentar tienes que usar "spam" a secas. Con eso consigues que el spamassassin marque los mails que son spam. Saludos!
Gracias.
-- Saludos Carlos Robinson
-- " Dios no juega a los dados con el universo " " El mundo no es malo por culpa de quienes hacen cosas malas, sino porque el resto se sientan a observar. " Albert Einstein Pablo Mª Romeu Guallart
Lo de los filtros lo tengo claro, la cosa es que el spamassassin no me marca nada como spam. Por lo que tengo entendido el spamassassin pone un campo a "si" si es spam (no recuerdo el nombre pero es algo como "es spam:") y no lo hace. Ahora estoy probando la solución de Camaleón pero aun no me ha llegado spam, je!. El dom, 06-06-2004 a las 12:00, Pablo Romeu escribió:
El Domingo, 6 de Junio de 2004 09:59, José Rodríguez S. escribió:
Pues leí en una guía que eso servía para que filtrara.
Al final de la línea sale |sapamassassin y el resultado es el análisis del mismo diciendo que no es spam y que necesito que me lo envíen 5 veces para que lo sea pero por más que me lo envío no lo cataloga.
Por otra parte encontré otro sitio que dice cómo llamar a spamassassin desde evolution directamente, aunque mejor es la otra forma, y se llama con /usr/bin/spamc -c y lo que entrega se mueve a la carpeta spam pero no lo hhace, de hecho creo que ni lo mira porque el evolution se queda funcionando igual que antes y no se "toma su tiempo" en analizar el correo (el spamassassin) después de descargarlo. Debería parecer que el evolution se cuelga por unos instantes mientras el spamassassin trabaja pero no.
A ver, yo uso el kmail para dos cuentas pop3 y la local y el spamassassin funciona 100%. El tema está en que el spamassasin sólo dice si algo es spam o no, en ningún caso te lo va a mover a ningún sitio. Eso lo tiene que hacer el evolution.
No suelo trabajar con el evolution, pero para que te hagas a la idea, en kmail para usar el spamassassin se añaden 2 filtros: - El primero es que todo el mail que llegue pase por la tubería spamc. - El segundo comprueba si la cabecera X-Spam-Flag está activada. Es decir, si el spamassassin ha marcado el mensaje como spam. Si está activada, lo mueve a una carpeta llamada spam. No conviene borrarlos, que el spamassassin a veces se "cuela" y marca como spam mails que no lo son.
Yo creo que el problema está en cómo haces el filtrado. Si usas "spam -c" el spamassassin no devuelve nada, tan sólo un 1 si es spam, o un 0 si no lo és. Para usar el filtro que te acabo de comentar tienes que usar "spam" a secas. Con eso consigues que el spamassassin marque los mails que son spam.
Saludos!
Gracias.
-- Saludos Carlos Robinson
El Domingo, 6 de Junio de 2004 12:10, José Rodríguez S. escribió:
Lo de los filtros lo tengo claro, la cosa es que el spamassassin no me marca nada como spam.
Por lo que tengo entendido el spamassassin pone un campo a "si" si es spam (no recuerdo el nombre pero es algo como "es spam:") y no lo hace.
No uses "spamc -c" porque si lo haces no se modifica el mensaje. Usa spamc
Ahora estoy probando la solución de Camaleón pero aun no me ha llegado spam, je!.
El dom, 06-06-2004 a las 12:00, Pablo Romeu escribió:
El Domingo, 6 de Junio de 2004 09:59, José Rodríguez S. escribió:
Pues leí en una guía que eso servía para que filtrara.
Al final de la línea sale |sapamassassin y el resultado es el análisis del mismo diciendo que no es spam y que necesito que me lo envíen 5 veces para que lo sea pero por más que me lo envío no lo cataloga.
Por otra parte encontré otro sitio que dice cómo llamar a spamassassin desde evolution directamente, aunque mejor es la otra forma, y se llama con /usr/bin/spamc -c y lo que entrega se mueve a la carpeta spam pero no lo hhace, de hecho creo que ni lo mira porque el evolution se queda funcionando igual que antes y no se "toma su tiempo" en analizar el correo (el spamassassin) después de descargarlo. Debería parecer que el evolution se cuelga por unos instantes mientras el spamassassin trabaja pero no.
A ver, yo uso el kmail para dos cuentas pop3 y la local y el spamassassin funciona 100%. El tema está en que el spamassasin sólo dice si algo es spam o no, en ningún caso te lo va a mover a ningún sitio. Eso lo tiene que hacer el evolution.
No suelo trabajar con el evolution, pero para que te hagas a la idea, en kmail para usar el spamassassin se añaden 2 filtros: - El primero es que todo el mail que llegue pase por la tubería spamc. - El segundo comprueba si la cabecera X-Spam-Flag está activada. Es decir, si el spamassassin ha marcado el mensaje como spam. Si está activada, lo mueve a una carpeta llamada spam. No conviene borrarlos, que el spamassassin a veces se "cuela" y marca como spam mails que no lo son.
Yo creo que el problema está en cómo haces el filtrado. Si usas "spam -c" el spamassassin no devuelve nada, tan sólo un 1 si es spam, o un 0 si no lo és. Para usar el filtro que te acabo de comentar tienes que usar "spam" a secas. Con eso consigues que el spamassassin marque los mails que son spam.
Saludos!
Gracias.
-- Saludos Carlos Robinson
-- " Dios no juega a los dados con el universo " " El mundo no es malo por culpa de quienes hacen cosas malas, sino porque el resto se sientan a observar. " Albert Einstein Pablo Mª Romeu Guallart
El 2004-06-06 a las 09:59 +0200, José Rodríguez S. escribió:
El Susefirewall2 no afecta en nada a fetchmail. Me parece que tienes montado un buen cacao. El firewall bloquea las conexiones entrantes, no las salientes... y el fetchmail sale.
Ojo, no he dicho que el susefirewall me trastocara el fetchmail, dije que cuando tengo el susefirewall2 levantado no puedo hacer llamadas a localhos, o sea, pones http://localhost en el navegador y se agota el tiempo, un ftp no se conecta, telnet tampoco y aasí unas cuantas cosas.
Recuerdas que hace tiempo pregunté por qué el fetchmail podía mirar si había correo con la opción -c pero al decirle que los descargara no lo hacía? no encontraba a localhost para enviarlo.
Lo arregle poniendo la línea "procmail -d usuario" en el .fetchmailrc.
Vale, pues entonces lo que hay que hacer es mirar que tienes puesto en el firewall para que no permita la conexión, porque eso no es normal. Ese es el problema principal que tienes que corregir. Si no lo haces, tendrás problemas por todas partes.
A eso me refiero, si quito el FW se reconoce localhost.
La cosa viene a que si yo, por ejemplo, me mando un spam con echo '<html><body>unadireccionmala</body></html>' | mail -s 'hablan de instrumentos alargadores' (lo pongo así pq Suse me lo devuelve) telecopower@localhost|spamassassin me sale que no es spam por más que repita la línea.
Es que simplemente por poner esa cabecera no es spam... Y además, no has contado como llamas al spamassassin ni donde.
Pues leí en una guía que eso servía para que filtrara.
Al final de la línea sale |sapamassassin y el resultado es el análisis del mismo diciendo que no es spam y que necesito que me lo envíen 5 veces para que lo sea pero por más que me lo envío no lo cataloga.
Entre los ficheros que trae el spamassassin hay dos: sample-nonspam.txt sample-spam.txt Son esos ficheros los que tienes que usar para generar un correo de prueba. -- Saludos Carlos Robinson
Bueno, de momento ya logré que el spamassassin me añadiera la cabecera aunque de momento todo me lo pone a no. Falta entrenarlo. Lo que hice fue modificar el .fetchmail rc y donde puse mda "procmail -d usuario" puse mda "spamassassin|procmail -d usuario". Ahora esperaré el spam y miraré las cabeceras a ver qué tal. El dom, 06-06-2004 a las 12:53, Carlos E. R. escribió:
El 2004-06-06 a las 09:59 +0200, José Rodríguez S. escribió:
El Susefirewall2 no afecta en nada a fetchmail. Me parece que tienes montado un buen cacao. El firewall bloquea las conexiones entrantes, no las salientes... y el fetchmail sale.
Ojo, no he dicho que el susefirewall me trastocara el fetchmail, dije que cuando tengo el susefirewall2 levantado no puedo hacer llamadas a localhos, o sea, pones http://localhost en el navegador y se agota el tiempo, un ftp no se conecta, telnet tampoco y aasí unas cuantas cosas.
Recuerdas que hace tiempo pregunté por qué el fetchmail podía mirar si había correo con la opción -c pero al decirle que los descargara no lo hacía? no encontraba a localhost para enviarlo.
Lo arregle poniendo la línea "procmail -d usuario" en el .fetchmailrc.
Vale, pues entonces lo que hay que hacer es mirar que tienes puesto en el firewall para que no permita la conexión, porque eso no es normal. Ese es el problema principal que tienes que corregir. Si no lo haces, tendrás problemas por todas partes.
A eso me refiero, si quito el FW se reconoce localhost.
La cosa viene a que si yo, por ejemplo, me mando un spam con echo '<html><body>unadireccionmala</body></html>' | mail -s 'hablan de instrumentos alargadores' (lo pongo así pq Suse me lo devuelve) telecopower@localhost|spamassassin me sale que no es spam por más que repita la línea.
Es que simplemente por poner esa cabecera no es spam... Y además, no has contado como llamas al spamassassin ni donde.
Pues leí en una guía que eso servía para que filtrara.
Al final de la línea sale |sapamassassin y el resultado es el análisis del mismo diciendo que no es spam y que necesito que me lo envíen 5 veces para que lo sea pero por más que me lo envío no lo cataloga.
Entre los ficheros que trae el spamassassin hay dos:
sample-nonspam.txt sample-spam.txt
Son esos ficheros los que tienes que usar para generar un correo de prueba.
-- Saludos Carlos Robinson
El 2004-06-07 a las 13:24 +0200, José Rodríguez S. escribió:
Ahora esperaré el spam y miraré las cabeceras a ver qué tal.
Pero sigues teniendo un problema en el firewall que debes corregir primero de nada. -- Saludos Carlos Robinson
Bueno, lo del firewall sí que sigue pero puedo recibir y spamasesinar. Como conté ya en mails anteriores no sé popr qué no se reconoce localhost como 127.0.0.1 aunque sí está en /etc/hosts. Para que el fetchmail funcionara a pesar de esto un colega me puso en el .fetchmailrc la línea mda "procmai -d usuario" y así podía bajar el correo ok. Yo le incluí mda "spamassassin|procmail -d usuario" al .fetchmailrc y añade las cabeceras al spam. Adicionalmente les digo que acabo de configurar el fecthmail desde el Yast (MTA) y bajan los correos bien pero aun no me ha llegado spam, así que me reenviaré uno de los que tengo. de todas formas añadí al /etc/fetchmailrc set daemos 600 para que baje le correo cada 10 minutos y aun no he comprobado si lo baja pero me parece que no. Claro que he iniciado fetchmail y spamassassin en el editor de niveles de ejecución. Ahora probaré. El lun, 07-06-2004 a las 13:52, Carlos E. R. escribió:
El 2004-06-07 a las 13:24 +0200, José Rodríguez S. escribió:
Ahora esperaré el spam y miraré las cabeceras a ver qué tal.
Pero sigues teniendo un problema en el firewall que debes corregir primero de nada.
-- Saludos Carlos Robinson
El 2004-06-07 a las 17:21 +0200, José Rodríguez S. escribió:
Bueno, lo del firewall sí que sigue pero puedo recibir y spamasesinar.
Como conté ya en mails anteriores no sé popr qué no se reconoce localhost como 127.0.0.1 aunque sí está en /etc/hosts.
¿Porque no nos pones en un hilo nuevo el problema exacto que tienes con el firewall? Mientras eso no se arregle seguirás teniendo problemas raros, y no me voy a devanar los sesos pensando en que puede estar mal por ahí mientras no arregles lo fundamental. -- Saludos Carlos Robinson
Podría ponerlo pero no lo hago porque es algo inherente del FW. Se ve que por razones que desconozco trae esa regla de serie ya que en el portátil, que no lo trasteo como esto, le pasa lo mismo sólo con instalarlo y activarlo, así que suponmgo que a todos les pasa igual. Por otra parte cuando lo pregunté nadie me respondió así que no escribo más sobre lo mismo. El lun, 07-06-2004 a las 20:23, Carlos E. R. escribió:
El 2004-06-07 a las 17:21 +0200, José Rodríguez S. escribió:
Bueno, lo del firewall sí que sigue pero puedo recibir y spamasesinar.
Como conté ya en mails anteriores no sé popr qué no se reconoce localhost como 127.0.0.1 aunque sí está en /etc/hosts.
¿Porque no nos pones en un hilo nuevo el problema exacto que tienes con el firewall? Mientras eso no se arregle seguirás teniendo problemas raros, y no me voy a devanar los sesos pensando en que puede estar mal por ahí mientras no arregles lo fundamental.
-- Saludos Carlos Robinson
El 2004-06-08 a las 12:42 +0200, José Rodríguez S. escribió:
Podría ponerlo pero no lo hago porque es algo inherente del FW. Se ve que por razones que desconozco trae esa regla de serie ya que en el portátil, que no lo trasteo como esto, le pasa lo mismo sólo con instalarlo y activarlo, así que suponmgo que a todos les pasa igual.
No, eso no es normal. Nunca me ha pasado.
Por otra parte cuando lo pregunté nadie me respondió así que no escribo más sobre lo mismo.
¿Te refieres a este hilo?
|Date: Sat, 08 May 2004 17:16:09 +0200
|From: José Rodríguez S.
|To: Suse
Ahí va el /etc/hosts: # # hosts This file describes a number of hostname-to-address # mappings for the TCP/IP subsystem. It is mostly # used at boot time, when no name servers are running. # On small systems, this file can be used instead of a # "named" name server. # Syntax: # # IP-Address Full-Qualified-Hostname Short-Hostname # 127.0.0.1 localhost # special IPv6 addresses ::1 localhost ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters ff02::3 ipv6-allhosts 192.168.0.3 mobile 192.168.0.5 pivenet.no-ip.com pivenet 192.168.0.1 pivenet.no-ip.com # PLIP IPs 192.168.217.2 server.plip 192.168.217.3 client.plip # ves como sí anda definido localhost? Ese fichero sólo lo he tocado para añadir los nombres de ls ip's locales. El mié, 09-06-2004 a las 00:51, Carlos E. R. escribió:
El 2004-06-08 a las 12:42 +0200, José Rodríguez S. escribió:
Podría ponerlo pero no lo hago porque es algo inherente del FW. Se ve que por razones que desconozco trae esa regla de serie ya que en el portátil, que no lo trasteo como esto, le pasa lo mismo sólo con instalarlo y activarlo, así que suponmgo que a todos les pasa igual.
No, eso no es normal. Nunca me ha pasado.
Por otra parte cuando lo pregunté nadie me respondió así que no escribo más sobre lo mismo.
¿Te refieres a este hilo?
|Date: Sat, 08 May 2004 17:16:09 +0200 |From: José Rodríguez S. |To: Suse
Te respondieron, aunque dabas muy poca información (yo no me leo todos los correos, no tengo tiempo - pero ese hilo si lo leí). Y al dia siguiente dices:
| Al poner 127,0,0,1 sí entra con el FW levantado.
Y a eso te respondió jose maria:
| * Pues o tienes mal definido localhost como te dije, o en la | configuracion de
A lo cual no contestaste - o por lo menos no dentro del hilo, lo cual es como no contestar. Y debo coincidir con él: si puedes llegar a 127.0.0.1 el problema no es el firewall. ¿Que contiene tu /etc/hosts?
Y vuelvo a decirlo: mientras no corrijas ese problema que tienes de no poder llegar a localhost, tendrás problemas muy raros por ahí.
Así que ponnos el contenido de:
/etc/hosts /etc/host.conf /etc/resolv.conf
-- Saludos Carlos Robinson
El 2004-06-09 a las 08:31 +0200, José Rodríguez S. escribió:
ves como sí anda definido localhost?
Ese fichero sólo lo he tocado para añadir los nombres de ls ip's locales.
Vale, si. ¿Y los otros dos ficheros?
/etc/host.conf /etc/resolv.conf
Y "/etc/nsswitch.conf", que se me olvidaba. Ese problema hay que solucionarlo, sea como sea que se produzca. No puede ser que no puedas llegar a localhost, eso está relacionado con muchos de los problemas que has puesto en la lista. Y también el firewall, por si las moscas, no te quejes :-) - con este comando: grep -v "^#" /etc/sysconfig/SuSEfirewall2 -- Saludos Carlos Robinson
No me había dado cuenta que decías de más archivos. Aquí van todos y la salida del comando del FW que me dejiste. El mié, 09-06-2004 a las 14:19, Carlos E. R. escribió:
El 2004-06-09 a las 08:31 +0200, José Rodríguez S. escribió:
ves como sí anda definido localhost?
Ese fichero sólo lo he tocado para añadir los nombres de ls ip's locales.
Vale, si. ¿Y los otros dos ficheros?
/etc/host.conf /etc/resolv.conf
Y "/etc/nsswitch.conf", que se me olvidaba.
Ese problema hay que solucionarlo, sea como sea que se produzca. No puede ser que no puedas llegar a localhost, eso está relacionado con muchos de los problemas que has puesto en la lista.
Y también el firewall, por si las moscas, no te quejes :-) - con este comando:
grep -v "^#" /etc/sysconfig/SuSEfirewall2
-- Saludos Carlos Robinson
El 2004-06-09 a las 19:06 +0200, José Rodríguez S. escribió:
No me había dado cuenta que decías de más archivos.
Aquí van todos y la salida del comando del FW que me dejiste.
He tardado un poco, porque no veía el problema y quise comprobarlo yo mismo. He puesto en mi maquina tu host.conf y tu resolv.conf, y en cuanto lo hice, dejó de encontrarme localhost. No convencido, volví a reponer los mios: nimrodel:~ # host localhost localhost.valinor has address 127.0.0.1 Vuelvo a poner los tuyos - y a todo esto, sin decirle al sistema que recargue la red, ni siquiera el firewall. Primero, el hosts.conf: nimrodel:~ # host localhost localhost.valinor has address 127.0.0.1 Luego, el /etc/resolv.conf nimrodel:~ # host localhost ;; connection timed out; no servers could be reached nimrodel:~ # Tiene cierto sentido, porque no estoy conectado todavía a internet en este momento; pero debería haber resuelto el nombre porque está en el /etc/hosts. No debería ocurrir. Como no quiero conectarme, le digo que use mi propio DNS local, editando el resolv.conf: nameserver 192.168.100.2 search medtelecom.net ¡Y sigue fallando igual! nimrodel:~ # host localhost ;; connection timed out; no servers could be reached Ahora bien, observa esta sutil diferencia: nimrodel:~ # host localhost. localhost has address 127.0.0.1 ¡Ese punto! Poniendo el punto funciona. Ahora, cambio el search, a mi propio dominio local (ficticio, pero existente en el DNS) nameserver 192.168.100.2 search valinor Y funciona (con y sin punto): nimrodel:~ # host localhost localhost.valinor has address 127.0.0.1 nimrodel:~ # host localhost. localhost has address 127.0.0.1 Vuelvo a poner tus DNS: nameserver 62.81.16.129 nameserver 62.81.0.33 search valinor Y vuelve a fallar: nimrodel:~ # host localhost ;; connection timed out; no servers could be reached nimrodel:~ # host localhost. ;; connection timed out; no servers could be reached Conclusiones: rascado de cabeza. ¿Porqué busca "localhost" en el DNS teniendolo en el /etc/hosts? Ahora mismo no lo sé - pero ese es precisamente tu problema. El problema - en mi caso - se arregla con un resolv.conf así: nameserver 192.168.100.2 search valinor donde tanto el nameserver como el dominio de busqueda existen. Si a ti no te funciona tal como lo tienes, es que el DNS que tu usas no resuelve "localhost" - lo cual es correcto que no lo resuelva pues es un DNS de internet. El mio si lo resuelve porque es mio. La solución correcta debe ser otra. Y a todo esto, observa que no he jugado para nada con el firewall. De hecho, he hecho una última prueba poniendolo y quitándolo, y sigue fallando o funcionando igual que antes. Otra observación es que el comando "ping localhost" si que funciona aunque "host" no funcione. Es posible que "host" sólo use el dns, y el contenido del fichero "/etc/hosts" lo ignore (salvo la ip del dns). Yo me inclino por esto. A ver si alguien nos dá más luz, porque yo me estoy durmiendo. -- Saludos Carlos Robinson
*This message was transferred with a trial version of CommuniGate(tm) Pro* -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * Ponerle apellido a la interfaz de bucle cerrado, localhost son ganas de buscarse problemas mas pronto que tarde. * /etc/hosts 127.0.0.1 localhost + el resto de direcciones 192.168.0.1 linux.casa linux etc.. * /etc/host.conf order hosts, bind -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAz6jhAXFL65CppEIRAmLGAJ4xja53uV2fZg6SmfxKzkXS1/3O+ACeN551 VWobnU6G2l18phoXHyUmdXE= =AoQI -----END PGP SIGNATURE-----
Es que así es que lo tengo. El mié, 16-06-2004 a las 03:56, jose maria escribió:
*This message was transferred with a trial version of CommuniGate(tm) Pro* -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
* Ponerle apellido a la interfaz de bucle cerrado, localhost son ganas de buscarse problemas mas pronto que tarde.
* /etc/hosts 127.0.0.1 localhost + el resto de direcciones 192.168.0.1 linux.casa linux etc..
* /etc/host.conf order hosts, bind
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFAz6jhAXFL65CppEIRAmLGAJ4xja53uV2fZg6SmfxKzkXS1/3O+ACeN551 VWobnU6G2l18phoXHyUmdXE= =AoQI -----END PGP SIGNATURE-----
*This message was transferred with a trial version of CommuniGate(tm) Pro* -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Miércoles, 16 de Junio de 2004 12:22, José Rodríguez "S." escribió:
Es que así es que lo tengo.
* Entonces el problema esta en otro sitio, siempre y cuando no se tenga un servidor dns propio, donde el fichero localhost.zone debe ser modificado. * Mira la configuracion del servidor de correo, o la integracion de los distintos paquetes, el correo entrante seguramente pasa por amavis, spamassasin, fetchmail y procmail, seguramente en alguno de ellos, no uso spamassasin sino bogofilter pero apostaria por spamassasin, ya que entiendo que fetchmail y procmail deben estar claros, vigila que no tengas algun paquete que redireccione el correo hacia algun puerto alto, para el antivirus amavisd por ejemplo. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA0KveAXFL65CppEIRAjs+AKCLGJy4Iyd3Azru7oh+VS4kvTuppwCePVEQ VuDosZ+ZEiGbel2a1kb2IDw= =ADO6 -----END PGP SIGNATURE-----
El 2004-06-16 a las 22:21 +0200, jose maria escribió:
Es que así es que lo tengo.
Y yo también, y también me pasa.
* Entonces el problema esta en otro sitio, siempre y cuando no se tenga un servidor dns propio, donde el fichero localhost.zone debe ser modificado.
Exacto. Yo el problema lo tengo solucionado con mi servidor de nombres propio, que es quien resuelve esas consultas. Pero cuando el DNS está puesto a uno externo, ambos tenemos el problema de que "host localhost" falla aún estando definido en el /etc/hosts.conf. Y no debería.
* Mira la configuracion del servidor de correo, o la integracion de los distintos paquetes, el correo entrante seguramente pasa por amavis, spamassasin, fetchmail y procmail, seguramente en alguno de ellos, no uso spamassasin sino bogofilter pero apostaria por spamassasin, ya que entiendo que fetchmail y procmail deben estar claros, vigila que no tengas algun paquete que redireccione el correo hacia algun puerto alto, para el antivirus amavisd por ejemplo.
Nonononono. Todo eso es secundario. Los problemas que tiene con el correo y demás provienen precisamente de que "localhost" no se resuelve. Ya lo llevamos mirando desde hace tiempo. -- Saludos Carlos Robinson
Es que el problema venía de que quería instalar spamassassin y no funcionaba bien el fetchmail antes. Podía saber si había mensajes y dejarlos en el servidor pero al bajarlos se colgaba porque no encontraba cómo dárselo a los usuarios y era por el problema de locahost. Esto se solucionó pasándole del fetchmail al procmail directamente con -d. DNS no tengo instalado. El mié, 16-06-2004 a las 22:21, jose maria escribió:
*This message was transferred with a trial version of CommuniGate(tm) Pro* -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Miércoles, 16 de Junio de 2004 12:22, José Rodríguez "S." escribió:
Es que así es que lo tengo.
* Entonces el problema esta en otro sitio, siempre y cuando no se tenga un servidor dns propio, donde el fichero localhost.zone debe ser modificado.
* Mira la configuracion del servidor de correo, o la integracion de los distintos paquetes, el correo entrante seguramente pasa por amavis, spamassasin, fetchmail y procmail, seguramente en alguno de ellos, no uso spamassasin sino bogofilter pero apostaria por spamassasin, ya que entiendo que fetchmail y procmail deben estar claros, vigila que no tengas algun paquete que redireccione el correo hacia algun puerto alto, para el antivirus amavisd por ejemplo.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFA0KveAXFL65CppEIRAjs+AKCLGJy4Iyd3Azru7oh+VS4kvTuppwCePVEQ VuDosZ+ZEiGbel2a1kb2IDw= =ADO6 -----END PGP SIGNATURE-----
*This message was transferred with a trial version of CommuniGate(tm) Pro* -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Jueves, 17 de Junio de 2004 12:42, José Rodríguez "S." escribió:
Es que el problema venía de que quería instalar spamassassin y no funcionaba bien el fetchmail antes. Podía saber si había mensajes y dejarlos en el servidor pero al bajarlos se colgaba porque no encontraba cómo dárselo a los usuarios y era por el problema de locahost.
* 1.- en yast en la configuracion del mta, elige como agente de transporte local procmail, no cambies la configuracion por defecto de main.cf ni master.cf, dejala de origen. * 2.- ¿ estas usando fechmail desde ficheros .fetchmailrc desde los usuarios o andas haciendo otra cosa? si no es asi procura hacerlo asi. * 3.- quita ficheros .procmailrc que hayas creado en el usuario o renombralo, para esto no se necesitan. * 4.- con la configuracion de localhost que te puse si sigue sin entregar el correo en /var/spool/mail/usuario (que debe existir y es un simple fichero de texto, ojo con los permisos y propiedad del mbox) borra main.cf y master.cf de postfix y reinstala el paquete volviendo al punto 1. * 5.- una vez que entregue localmente correctamente sera hora de empezar con el filtrado e integracion con otros paquetes via .procmailrc, porque si fetchmail u otro paquete no funcionaba desde el principio metiendo spamassasin y ficheros de filtrado, no se va a arreglar. * condiciones, NO tienes un servidor dns local, NO tienes instalado amavisd, si tienes una tarjeta de red, la tienes configurada correctamente, ip y con un nombre decente, NADA de localhost.localdomain, algo del tipo 192.168.0.x linux.micasa linux, postfix solo envia no esta haciendo funciones de smtpd, NO estas alojando un dominio. * Hay que aislar el problema de origen asi que si tienes pensado incorporar modificaciones, mejor no perder mas tiempo, por mi parte. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA0gbUAXFL65CppEIRAkUXAJ425gccy8gYyqFMWwl2XYY6w5LLOQCeOFsl LYAkYeoaPQtWKGrpS2Ra0hU= =o9Qs -----END PGP SIGNATURE-----
El 2004-06-16 a las 03:56 +0200, jose maria escribió:
* Ponerle apellido a la interfaz de bucle cerrado, localhost son ganas de buscarse problemas mas pronto que tarde.
* /etc/hosts 127.0.0.1 localhost + el resto de direcciones 192.168.0.1 linux.casa linux etc..
* /etc/host.conf order hosts, bind
Así es como lo tengo (tenemos), y falla. Sólo funciona si resuelvo localhost en el DNS, el contenido de /etc/hosts se ignora por el comando "host" (y otros). Te lo pongo completo: 127.0.0.1 localhost ::1 localhost ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters ff02::3 ipv6-allhosts # PLIP IPs 192.168.217.2 server.plip 192.168.217.3 client.plip 192.168.100.2 nimrodel.valinor nimrodel /etc/resolv.conf: nameserver 192.168.100.2 search valinor En cuanto cambio el DNS en el resolv.conf, falla - y no debería, porque "localhost" está definido en el hosts.conf. :-/ /etc/host.conf: order hosts, bind multi on A mi me ocurre con SuSE 8.2. -- Saludos Carlos Robinson
Hola a tod@s. Habeis cambiado en etc/sysconfig/SuSEfirewall2 FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS" FW_SERVICE_DNS="yes" Ya que cuando pones un servidor DNS y activas SuSEfirewall2 no hace los cambios de forma automática, sino que los tienes que hacer tu. Un Saludo.
El 2004-06-17 a las 10:40 +0200, Cecilia Marquina escribió:
Habeis cambiado en etc/sysconfig/SuSEfirewall2
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS"
FW_SERVICE_DNS="yes"
Ya que cuando pones un servidor DNS y activas SuSEfirewall2 no hace los cambios de forma automática, sino que los tienes que hacer tu.
Eso podría ser su caso (José Rodríguez), que usa un DNS externo (internet), mientras que yo uso uno propio, local, que por tanto no es afectado por el firewall. Eso podría explicar lo que el dice que le funciona con el firewall quitado. Ahora, da la casualidad que yo tengo copia de su fichero de firewall, y puedo mirar como lo tiene: FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS" FW_SERVICE_DNS="yes" Luego no es eso. En cambio, yo (que tengo DNS local) tengo ahora mismo: FW_ALLOW_INCOMING_HIGHPORTS_UDP="" FW_SERVICE_DNS="yes" y sólo me funciona cuando el DNS está funcionando - y el DNS funciona con ese puerto cerrado, por cierto: claro, porque no tengo que actualizar zonas, ni resuelvo consultas externas. Pero por otra parte, el problema fundamental es que cuando no hay servidor DNS, la orden "host localhost" falla. Eso lo raro de este caso, que el comando "host" no sea capaz de ver que en "/etc/hosts" ya está definido "localhost" y que no tiene porqué narices mirar precisamente que IP es localhost en un DNS, y más grave/raro cuando los servidores DNS de internet no tienen porque resolver esa consulta y contestar con 127.0.0.1 En cambio, comandos como "ping" si que funcionan perfectamente. O lo que es lo mismo, decir que "host" unicamente consulta el DNS, e ignora "files". Debe haber un error de concepto garrafal por nuestra parte, o hay un bug considerable por ahí. A mi en esto me patinan las neuronas. El error de concepto puede ser ese, que "host" no consulta "files". Como tampoco lo hace el correo, o no siempre, porque necesita consultar las entradas "MX" del DNS. Pero al parecer, a José tampoco le funciona el navegador (http://localhost) pero a mi si - eso pudiera ser otra problema distinto. -- Saludos Carlos Robinson
Pero por otra parte, el problema fundamental es que cuando no hay servidor DNS, la orden "host localhost" falla. Eso lo raro de este caso, que el comando "host" no sea capaz de ver que en "/etc/hosts" ya está definido "localhost" y que no tiene porqué narices mirar precisamente que IP es localhost en un DNS, y más grave/raro cuando los servidores DNS de internet no tienen porque resolver esa consulta y contestar con 127.0.0.1
Hola a tod@s. Creo que puede estar en alguna pequeña tonteria que se nos está pasando, mira esto. cecilia@Ceci:~> host localhost localhost has address 127.0.0.1 cecilia@Ceci:~> cecilia@Ceci:~> ping -c3 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.068 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.062 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.064 ms --- 127.0.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.062/0.064/0.068/0.009 ms cecilia@Ceci:~> Un Saludo.
Ojo, creo que he descubierto algo: telecopwer@pivenet:~> host localhost localhost.medtelecom.net has address 127.0.0.1 telecopower@pivenet:~> me añade el dominio de mi proveedor. Ahora al poner en mi navegador localhost.medtelecom.net sí sale el Apache. Acabo de mirar en la configuración de la tarjeta de red pero no encuentro una opción que ví una vez que decía "hacer pertenecer al dominio". Por ahí andan los tiros. El jue, 17-06-2004 a las 14:07, Cecilia Marquina escribió:
Pero por otra parte, el problema fundamental es que cuando no hay servidor DNS, la orden "host localhost" falla. Eso lo raro de este caso, que el comando "host" no sea capaz de ver que en "/etc/hosts" ya está definido "localhost" y que no tiene porqué narices mirar precisamente que IP es localhost en un DNS, y más grave/raro cuando los servidores DNS de internet no tienen porque resolver esa consulta y contestar con 127.0.0.1
Hola a tod@s.
Creo que puede estar en alguna pequeña tonteria que se nos está pasando, mira esto.
cecilia@Ceci:~> host localhost localhost has address 127.0.0.1 cecilia@Ceci:~>
cecilia@Ceci:~> ping -c3 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.068 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.062 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.064 ms
--- 127.0.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.062/0.064/0.068/0.009 ms cecilia@Ceci:~>
Un Saludo.
Creo que he encontrado otra cosa: En Yast busqué por DNS y me aparecen instalados bind-utils, perl-Net-DNS y yast2-dns-server aunque uso los DNS de mi proveedor. Aquí se plantea entonces otra cosa: quitarlos o configurar para unsar mis propios DNS. El bind-utils no lo quité porque me dice: pivenet:/home/telecopower # rpm -e bind-utils --test error: Failed dependencies: /usr/bin/host is needed by (installed) yast2-printer-2.8.24-1 /usr/bin/host is needed by (installed) yast2-dns-server-2.8.11-19 pivenet:/home/telecopower # Al intentarlo con el de perl: pivenet:/home/telecopower # rpm -e perl-Net-DNS --test error: Failed dependencies: perl-Net-DNS is needed by (installed) perl-spamassassin-2.55-63 pivenet:/home/telecopower # Y el último no me da error, lo cual quiere decir que lo puedo quitar. Espero consejos. Gracias. El jue, 17-06-2004 a las 14:07, Cecilia Marquina escribió:
Pero por otra parte, el problema fundamental es que cuando no hay servidor DNS, la orden "host localhost" falla. Eso lo raro de este caso, que el comando "host" no sea capaz de ver que en "/etc/hosts" ya está definido "localhost" y que no tiene porqué narices mirar precisamente que IP es localhost en un DNS, y más grave/raro cuando los servidores DNS de internet no tienen porque resolver esa consulta y contestar con 127.0.0.1
Hola a tod@s.
Creo que puede estar en alguna pequeña tonteria que se nos está pasando, mira esto.
cecilia@Ceci:~> host localhost localhost has address 127.0.0.1 cecilia@Ceci:~>
cecilia@Ceci:~> ping -c3 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.068 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.062 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.064 ms
--- 127.0.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.062/0.064/0.068/0.009 ms cecilia@Ceci:~>
Un Saludo.
El 2004-06-17 a las 21:15 +0200, José Rodríguez S. escribió:
Creo que he encontrado otra cosa:
En Yast busqué por DNS y me aparecen instalados bind-utils, perl-Net-DNS y yast2-dns-server aunque uso los DNS de mi proveedor.
El dns propio se instala con el paquete bind8 o bind9 (demonio "named"). Se obtienen ventajas de velocidad de navegación apreciables si tienes una red lenta al usar bind como caché de DNS. A no ser que el Yast de la versión que tengas te lo ponga hecho, no es tan inmediato de configurar: hay que leer docus, unos cuantos. -- Saludos Carlos Robinson
Perdon. No habia desactivado bien el servidor DNS ahora sale esto. cecilia@Ceci:~> host localhost Host localhost not found: 3(NXDOMAIN) cecilia@Ceci:~> Estoy mirando porque sucede.
El Jue 17 Jun 2004 07:26, Cecilia Marquina escribió:
Perdon.
No habia desactivado bien el servidor DNS ahora sale esto.
cecilia@Ceci:~> host localhost Host localhost not found: 3(NXDOMAIN) cecilia@Ceci:~>
Estoy mirando porque sucede.
Hola es la primera vez que participo en la lista, yo tengo un problema similar yo no puedo conectar el Guardian de KDE y si ejecuto el comando host localhost obtengo el mismo resultado alhi@linux:~> host localhost Host localhost not found: 3(NXDOMAIN) he instalado varias maquinas con esta version de suse 9.1 y con ninguna habia tenido este problema, solo con esta y el procedimiento siempre ha sido el mismo. La verdad espero que alguien aporte algo sobre este problema .... gracias.
On Thu, 17 Jun 2004 08:49:33 -0500, Luis Diez wrote:
El Jue 17 Jun 2004 07:26, Cecilia Marquina escribió:
Perdon.
No habia desactivado bien el servidor DNS ahora sale esto.
cecilia@Ceci:~> host localhost Host localhost not found: 3(NXDOMAIN) cecilia@Ceci:~>
Estoy mirando porque sucede.
Hola es la primera vez que participo en la lista, yo tengo un problema similar yo no puedo conectar el Guardian de KDE y si ejecuto el comando host localhost obtengo el mismo resultado alhi@linux:~> host localhost Host localhost not found: 3(NXDOMAIN)
he instalado varias maquinas con esta version de suse 9.1 y con ninguna habia tenido este problema, solo con esta y el procedimiento siempre ha sido el mismo.
Con el bind en marcha en una SuSE 9.1 benjami@itaca:~> host localhost localhost.bitassa.net has address 127.0.0.1 -- Benjamí http://bitassa.com .
El 2004-06-17 a las 08:49 -0500, Luis Diez escribió:
Hola es la primera vez que participo en la lista, yo tengo un problema similar yo no puedo conectar el Guardian de KDE y si ejecuto el comando host localhost obtengo el mismo resultado alhi@linux:~> host localhost Host localhost not found: 3(NXDOMAIN)
he instalado varias maquinas con esta version de suse 9.1 y con ninguna habia tenido este problema, solo con esta y el procedimiento siempre ha sido el mismo.
No, mi suse 8.2 se comporta igual. Al parecer, es que ese es el comportamiento correcto de ese comando. -- Saludos Carlos Robinson
*This message was transferred with a trial version of CommuniGate(tm) Pro* -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Jueves, 17 de Junio de 2004 11:44, Carlos E. R. escribió:
O lo que es lo mismo, decir que "host" unicamente consulta el DNS, e ignora "files".
* host es un comando para interrogar servidores dns, los que esten apuntados en resolv.conf, la consulta a hosts no tiene fundamento, no es accesible desde otra maquina. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA0f7FAXFL65CppEIRAtnYAJ4gzrb13ByvMSbZwESqFsOLvebLaACggXc/ f7eVm3dIYQARa50bg9eilvs= =Wk6Q -----END PGP SIGNATURE-----
El 2004-06-17 a las 22:27 +0200, jose maria escribió:
O lo que es lo mismo, decir que "host" unicamente consulta el DNS, e ignora "files".
* host es un comando para interrogar servidores dns, los que esten apuntados en resolv.conf, la consulta a hosts no tiene fundamento, no es accesible desde otra maquina.
O sea, es así, es una característica. Entonces hay que averiguar porqué otros comandos como navegar a http://localhost a él no le funcionan, ni tampoco algunas cuestiones del correo que tratan de enviar a localhost. -- Saludos Carlos Robinson
On Fri, 18 Jun 2004 02:13:13 +0200 (CEST), Carlos E. R. wrote:
El 2004-06-17 a las 22:27 +0200, jose maria escribió:
O lo que es lo mismo, decir que "host" unicamente consulta el DNS, e ignora "files".
* host es un comando para interrogar servidores dns, los que esten apuntados en resolv.conf, la consulta a hosts no tiene fundamento, no es accesible desde otra maquina.
O sea, es así, es una característica. Entonces hay que averiguar porqué otros comandos como navegar a http://localhost a él no le funcionan, ni tampoco algunas cuestiones del correo que tratan de enviar a localhost.
Dependiendo del programa, la cosa puede cambiar: - Mozilla primero consulta hosts y luego DNS - Konqueror primero consulta DNS y luego hosts -- Benjamí http://bitassa.com .
Hola. Quiero que fetchmail me baje los carreos de forma auromática. Sé que esto se logra con -d tiempo al llamarlo o en el .fetchmailrc con set daemon tiempo. La cuestión es que para esto he de iniciar manualmente el fetchmail cada vez que arranco la máquina. Cómo lo pongo para que el fetchmail funcione al arrancar la máquina? En el editor de niveles de ejecución ya está activado en los niveles 2, 3 y 5. Gracias.
El Lunes, 7 de Junio de 2004 13:50, José Rodríguez S. escribió:
Hola.
Quiero que fetchmail me baje los carreos de forma auromática. Sé que esto se logra con -d tiempo al llamarlo o en el .fetchmailrc con set daemon tiempo. La cuestión es que para esto he de iniciar manualmente el fetchmail cada vez que arranco la máquina.
Cómo lo pongo para que el fetchmail funcione al arrancar la máquina?
En el editor de niveles de ejecución ya está activado en los niveles 2, 3 y 5.
Gracias. Si utilizas suse 9 o 9.1 no hace falta el fetchmailrc. en el yast/servicio en red/MTA/correo entrante/detalles/ pones tus cuentas de correo. Y luego en el yast/sistema/editor de niveles de ejecucion/activa el fetchmail . Sino pones en el Home/usuario/.kde/Autostart/ creas un archivo con #usr/bin fetchmail -d600
si no me equivoco Saludos -- Antonio López Fernádez Cartagena-España http://www.poesia-castellana.com Suse 9.1 Kde 3.2.2 Kernel 2.6.4-545 gnu/linux users register #319373 jabberID icue@myjabber.net
Eso hice pero no me recoge los correos de forma automática, no sé si será ajuste del tiempo o qué. Si pongo el script en autostart sí funciona pero sólo si arranco KDE, sino no. Yo solo uso la máquina y con KDE, así que en principio no hay problema pero quería encontrar una solución más "administrativa" por si algún día he de enfrentarme a algo similar. El lun, 07-06-2004 a las 14:15, Antonio Lopez Fernandez escribió:
El Lunes, 7 de Junio de 2004 13:50, José Rodríguez S. escribió:
Hola.
Quiero que fetchmail me baje los carreos de forma auromática. Sé que esto se logra con -d tiempo al llamarlo o en el .fetchmailrc con set daemon tiempo. La cuestión es que para esto he de iniciar manualmente el fetchmail cada vez que arranco la máquina.
Cómo lo pongo para que el fetchmail funcione al arrancar la máquina?
En el editor de niveles de ejecución ya está activado en los niveles 2, 3 y 5.
Gracias. Si utilizas suse 9 o 9.1 no hace falta el fetchmailrc. en el yast/servicio en red/MTA/correo entrante/detalles/ pones tus cuentas de correo. Y luego en el yast/sistema/editor de niveles de ejecucion/activa el fetchmail . Sino pones en el Home/usuario/.kde/Autostart/ creas un archivo con #usr/bin fetchmail -d600
si no me equivoco Saludos -- Antonio López Fernádez Cartagena-España http://www.poesia-castellana.com Suse 9.1 Kde 3.2.2 Kernel 2.6.4-545 gnu/linux users register #319373 jabberID icue@myjabber.net
El 2004-06-07 a las 13:50 +0200, José Rodríguez S. escribió:
Quiero que fetchmail me baje los carreos de forma auromática. Sé que esto se logra con -d tiempo al llamarlo o en el .fetchmailrc con set daemon tiempo. La cuestión es que para esto he de iniciar manualmente el fetchmail cada vez que arranco la máquina.
Cómo lo pongo para que el fetchmail funcione al arrancar la máquina?
En el editor de niveles de ejecución ya está activado en los niveles 2, 3 y 5.
El servicio "rcfetchmail" usa el fichero de configuración /etc/fetchmailrc, no el /root/.fetchmailrc. Haciéndolo con el yast es ese también el que se resuelve. -- Saludos Carlos Robinson
participants (9)
-
Angel Martín -
Antonio Lopez Fernandez -
Benjamí Villoslada -
Carlos E. R. -
Cecilia Marquina -
jose maria -
José Rodríguez S. -
Luis Diez -
Pablo Romeu