opensuse
[Arriba] [Todas las Listas]

Re: fetchmail Consejo (era Re: [opensuse] Dovecot 2.0)

To: opensuse@xxxxxxxxxxxx
Subject: Re: fetchmail Consejo (era Re: [opensuse] Dovecot 2.0)
From: Anton Aylward <opensuse@xxxxxxxxxxxxxxxx>
Date: Sat, 24 Sep 2011 10:11:58 -0400
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 24 Sep 2011 10:14:05 -0400
Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=antonaylward.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= antonaylward.com; bh=QkO502NvzG2znd/085Vetj5L2Gs=; b=oBwIWBpDUkk u5Ot/6JaQLZmFnz4QzLNsypa1CAE6088eeI3NyWixTONXQ82FZCsCLB178An934/ M5nVG0e82B6IKEYtZPg+e/HpFsRJlEk/B2AZoAQTszRBkXWUWOkw4Yh54xkWZo/y 5Eb07iELOWp3BWjxqlF2l7LTuUshlkpI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=antonaylward.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s= antonaylward.com; b=GtmNpWpvYUvw4mUTPliCsMFeAugOb4MVvAe93YGLVhg6 sIXK02+b9k5r/ia9Gr1enccUy9dMmHt9HRLzlrXpyh9vtIzn7mVUnDWh+NMxA9vk GKnJG6k5yeqetXE6K3dTUqZwwiPnUIJjZMMyThMP3DHJ8QZnDI1DJWAlfN3J/WU=
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <1316869084.27854.3.camel@t43.lan0.a-domani.nl>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
Organization: SI
References: <65941d57-f42e-43af-9478-0e53f17a5088@email.android.com> <4E78D7D8.4090906@antonaylward.com> <4E78E2D8.8020501@rogers.com> <j5bt6h$5gc$1@saturn.local.net> <4E7A35E0.4070402@rogers.com> <j5ddbj$8pk$2@saturn.local.net> <4E7B3D94.2040503@rogers.com> <4E7B4601.6000102@rogers.com> <4E7B7F08.5040701@suddenlinkmail.com> <4E7C5203.7020806@rogers.com> <4E7C7576.1050509@rogers.com> <4E7CD291.4000508@rogers.com> <4E7CE407.3040404@antonaylward.com> <4E7CF056.5000500@rogers.com> <4E7D35AB.60401@antonaylward.com> <1316869084.27854.3.camel@t43.lan0.a-domani.nl>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Firefox/6.0.2 Thunderbird/6.0.2
Hans *Witvliet dijo el siguiendo en 09/24/2011 08:58 AM:
En *Fri, 2011-09-23 en 21:43 -0400, Anton *Aylward escribió:
James *Knott dijo el siguiendo en 09/23/2011 04:47 PM:

 ellos todos tienen que correr su caso propio de *fetchmail?

Sí y no.
Sí hacen y no su hecho *via *crontab.
--
Era en la suposición que uno no tendría que correr *fetchmail de *cron.
Si quieres *fetch lo regularmente, utiliza el "-*d 1500" opción, de modo que
*fetchmail carreras como *deamon.

Uno de los problemas un )podría encontrar, cuándo utilizando *cron, es que tienes el *risc que uno es empezado arriba, antes de que el anterior ha acabado,
mientras esto es evitado por utilizar el *daemon opción de *fetchmail.


No un problema :-)

$ *crontab -*l
@*reboot      *fetchmail -*d 300
@*hourly      (*fetchmail -*q; sueño 5; *fetchmail -*d 300) >/*dev/*null 2>&1

Por qué, preguntas?
Nosotros'*ve encontró *fetchmail a veces hace cosas extrañas, es muy sensible a errores en el *rc archivo. Qué lo realmente las necesidades es algo que hace un *SIGUSER1 o mejor, algo que *re-lee el *config archivo bastante que justo retomando el encuestando secuencia. O mejor todavía, detecta que el *rc el archivo ha cambiado y *re-lo lee.

Sí soy consciente que la página de hombre dice
<citar>
Si tocas o cambiar el /.*fetchmailrc Archivo mientras *fetchmail está
corriendo en *daemon modo, esto será detectado al principio del
ciclo de encuesta próximo.  Cuándo un cambiado  /.*fetchmailrc Es detectado, *fetchmail
lo relee y retoma de arañazo (utilizando *exec(2); no la información estatal es retenida en el caso nuevo). Nota que si *fetchmail necesidades a consulta para contraseñas, de que si rompes el /.*fetchmailrc Archivo *syntax, el caso nuevo suavemente y *silently *vanish fuera
en *startup.
</Citar>
Pero leído que otra vez y verás por qué *CRON está siendo utilizado para asegurar robustez.

*Fetchmail También tiene problemas con errores de DNS en *startup.
Esperaría que alguna clase de 'dependencia' mecanismo como '*systemd' finalmente dirigirá esto.

En cuanto a correr *fetchmail como sistema *daemon bastante que un por usuario *daemon, pienso la manera actual de habiendo ALL los guiones en /*etc/*fetchmailrc es mal-encabezado. Pienso que el sistema *daemon tener que *spawn de procesos de niño que leyeron el por usuario /.*fetchmail Archivos y llevarles a cabo. Aquella manera los usuarios individuales pueden añadir y editar su propio .*fetchmail Archivos y no *compromise el sistema.

Sí el *sysadmin todavía les puede editar también.  Nada nuevo allí.

Cómo es este diferente del sistema-nivel *Apache *recognising los usuarios /públicos_*html y *spawning de *sub-procesos para tratarles?

En cuanto a *sysloging; *fetchmail produce mucha nariz pero es a menudo silencioso sobre errores. Cuando la página de hombre dice, él a veces 'suavemente y *silently' *vanishes.

Ningún software es perfecto, a veces necesitamos *wrappers para aumentar robustez.


Por qué?
En esencia no tenemos un '*Sysadmin en llamada'.
Si un usuario experimentado puede cuidar de su o sus problemas propios en su espacio propio les dejamos. Pero intentamos hacer seguro que pueden no tornillo arriba del sistema para todo el mundo más. No somos *paranoid sobre él.
Pensamos que nuestros usuarios son personas responsables.

Naturalmente *YMMD.

--
Si los errores del pasado eran bien bastante para
nuestros antepasados, ellos *re bien bastante para #prpers!
--
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
Puesto que órdenes adicionales, *e-correo: *opensuse+help@xxxxxxxxxxxx


Hans Witvliet said the following on 09/24/2011 08:58 AM:
On Fri, 2011-09-23 at 21:43 -0400, Anton Aylward wrote:
James Knott said the following on 09/23/2011 04:47 PM:

Do they all have to run their own instance of fetchmail?

Yes and no.
Yes they do and no its done via crontab.
--
I was in the assumption that one should not run fetchmail from cron.
If you want to fetch it regularly, use the "-d 1500" option, so that
fetchmail runs as a deamon.

One of the problems one )might_ encounter, when using cron, is that you
have the risc that one is started up, before the previous has finished,
while this is avoided by using the daemon option from fetchmail.


Not a problem :-)

$ crontab -l
@reboot      fetchmail -d 300
@hourly      (fetchmail -q; sleep 5; fetchmail -d 300) >/dev/null 2>&1

Why, you ask?
We've found fetchmail sometimes does strange things, is very sensitive to errors in the rc file. What it really needs is something that does a SIGUSER1 or better, something that re-reads the config file rather than just restarting the polling sequence. Or better still, detects that the rc file has changed and re-reads it.

Yes I am aware that the man page says
<quote>
If you touch or change the ~/.fetchmailrc file while fetchmail is
running in daemon mode, this will be detected at the beginning of the
next poll cycle.  When a changed  ~/.fetchmailrc is detected, fetchmail
rereads it and restarts from scratch (using exec(2); no state information is retained in the new instance). Note that if fetchmail needs to query for passwords, of that if you break the ~/.fetchmailrc file's syntax, the new instance will softly and silently vanish away
on startup.
</quote>
But read that again and you'll see why CRON is being used to ensure robustness.

Fetchmail also has problems with DNS errors at startup.
I'd hope that some kind of 'dependency' mechanism such as 'systemd' will eventually address this.

As for running fetchmail as a system daemon rather than a per user daemon, I think the current way of having ALL the scripts in /etc/fetchmailrc is wrong-headed. I think that the system daemon should spawn off child processes that read the per user ~/.fetchmail files and carry them out. That way the individual users can add and edit their own .fetchmail files and not compromise the system.

Yes the sysadmin can still edit them as well.  Nothing new there.

How is this different from the system-level Apache recognising users ~/public_html and spawning of sub-processes to deal with them?

As for sysloging; fetchmail produces a lot of nose but is often silent about errors. As the man page says, it sometimes 'softly and silently' vanishes.

No software is perfect, sometimes we need wrappers to increase robustness.


Why?
In essence we don't have a 'Sysadmin on call'.
If an experienced user can take care of his or her own problems in their own space we let them. But we try to make sure that they can't screw up the system for everyone else. We're not paranoid about it.
We think our users are responsible people.

Of course YMMD.

--
If the errors of the past were good enough for
our ancestors, they re good enough for us!
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>