Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc ben delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament i
després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació horària a: /etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més ràpid que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de
registre o, com a últim recurs, que no es generin?

Gràcies.

Narcis Garcia

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc ben delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament i
després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació horària a: /etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més ràpid que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de
registre o, com a últim recurs, que no es generin?

Gràcies.

--
Narcis Garcia

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

OSTRES

És un problema que, si m'equivoco de remitent, la llista de Debian admet igualment el meu correu de remitent no subscrit, i el publica amb
l'adreça i tot a l'hemeroteca.
Com podem estar al segle XX en aquest tema entre les subscripcions i la publicació de dades?


Narcis Garcia

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 8/4/22 a les 14:42, Narcis Garcia ha escrit:

Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc ben delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament i després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació horària a: /etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més ràpid
que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de
registre o, com a últim recurs, que no es generin?

Gràcies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 8/4/22 a les 14:42, Narcis Garcia ha escrit:

Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc ben delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament i després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació horària a: /etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més ràpid que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de
registre o, com a últim recurs, que no es generin?

Gràcies.

Sense entrar a valorar la causa de l'emplenament exagerat dels fitxers
de registre d'activitat (si ho consideres convenient, podries enviar-ne
una petita mostra per si et podem orientar millor), la idea salomònica
de neutralitzar-los seria recreant-los com enllaços simbòlics a /dev/null

Personalment no m'agrada gens la idea de perdre tot registre d'activitat
pel risc que suposa emmascarar errors o il·lícits, així que prioritzaria
per sobre de tot trobar-ne la causa arrel. Així a cegues, per les
bitàcoles afectades diria que hi ha algun procés que està intentant
canviar de permisos o privilegis d'usuari contínuament, probablement
sense èxit.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 8/4/22 a les 15:13, Eloi ha escrit:

El 8/4/22 a les 14:42, Narcis Garcia ha escrit:

Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc ben
delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament i
després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació horària a: >> /etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més
ràpid que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de
registre o, com a últim recurs, que no es generin?

Gràcies.

Sense entrar a valorar la causa de l'emplenament exagerat dels fitxers
de registre d'activitat (si ho consideres convenient, podries enviar-ne
una petita mostra per si et podem orientar millor), la idea salomònica
de neutralitzar-los seria recreant-los com enllaços simbòlics a /dev/null

Personalment no m'agrada gens la idea de perdre tot registre d'activitat
pel risc que suposa emmascarar errors o il·lícits, així que prioritzaria per sobre de tot trobar-ne la causa arrel. Així a cegues, per les
bitàcoles afectades diria que hi ha algun procés que està intentant canviar de permisos o privilegis d'usuari contínuament, probablement
sense èxit.

Tens raó, i porto més d'un mes donant voltes a això. El problema és que
els missatges enregistrats no parlen de cap problema, sinó que sembla la reiteració dels mateixos missatges de Xorg mil vegades, i altre
programari del sistema.
Com que no he pogut aïllar l'aplicació i quan és que fa aquest efecte, tampoc no he pogut analitzar bé les bitàcoles, i quan el problema ha ocorregut la prioritat era esborrar-les per a permetre l'arrencada.

Provaré això del /dev/null si és l'únic fre a les inundacions de text.

Gràcies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 8/4/22 a les 15:30, Eloi ha escrit:

El 8/4/22 a les 15:22, Narcis Garcia ha escrit:

El 8/4/22 a les 15:13, Eloi ha escrit:

El 8/4/22 a les 14:42, Narcis Garcia ha escrit:

Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc ben
delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament
i després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació
horària a:
/etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més >>>> ràpid que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de
registre o, com a últim recurs, que no es generin?

Gràcies.

Sense entrar a valorar la causa de l'emplenament exagerat dels
fitxers de registre d'activitat (si ho consideres convenient, podries
enviar-ne una petita mostra per si et podem orientar millor), la idea
salomònica de neutralitzar-los seria recreant-los com enllaços
simbòlics a /dev/null

Personalment no m'agrada gens la idea de perdre tot registre
d'activitat pel risc que suposa emmascarar errors o il·lícits, així
que prioritzaria per sobre de tot trobar-ne la causa arrel. Així a
cegues, per les bitàcoles afectades diria que hi ha algun procés que
està intentant canviar de permisos o privilegis d'usuari
contínuament, probablement sense èxit.

Tens raó, i porto més d'un mes donant voltes a això. El problema és
que els missatges enregistrats no parlen de cap problema, sinó que
sembla la reiteració dels mateixos missatges de Xorg mil vegades, i
altre programari del sistema.
Com que no he pogut aïllar l'aplicació i quan és que fa aquest efecte,
tampoc no he pogut analitzar bé les bitàcoles, i quan el problema ha
ocorregut la prioritat era esborrar-les per a permetre l'arrencada.

Provaré això del /dev/null si és l'únic fre a les inundacions de text. >>
Gràcies.

Una alternativa menys traumàtica, però que tampoc és solució, seria muntar /var/log a un sistema de fitxers diferenciat, preferentment no compartit (evitant un bind contra una altra partició, traslladant el problema). Si no disposes d'espai per reparticionar, sempre pots crear
un fitxer contenidor en una partició ja existent i muntar-la.

Pot tenir problemes de rendiment (especialment si el fitxer és sparse o està fragmentat) i igualment un cop emplenada la partició suposarà la pèrdua de registres, però pot servir per contenir el problema temporalment.

Parlant de registres, un problema que ja m'he trobat és el de ~/.xsession-errors, que aquest per defecte no està sota la mira del logrotate i té tendència a créixer desmesuradament amb el temps.

Solució interessant (veig millor la partició ordinària), tot i que
implica que, en emplenar-se, totes les bitàcoles deixarien d'enregistrar
res.
He pensat ara en no muntar tot el directori /var/log sinó un directori
sense cap relació, i aleshores enllaçar-hi només les 3 bitàcoles problemàtiques:
ln -s /mnt/runa/log/messages /var/log/messages
ln -s /mnt/runalog/syslog /var/log/syslog
ln -s /mnt/runa/log/user.log /var/log/user.log

i buidar els fitxers de la partició a cada arrencada del sistema.

Del què necessito estar segur és que els enllaços no seran reemplaçats
per rsyslog ni per logrotate amb les seves operacions.

Salut.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 8/4/22 a les 15:22, Narcis Garcia ha escrit:

El 8/4/22 a les 15:13, Eloi ha escrit:

El 8/4/22 a les 14:42, Narcis Garcia ha escrit:

Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc ben
delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament
i després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació
horària a:
/etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més
ràpid que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de
registre o, com a últim recurs, que no es generin?

Gràcies.

Sense entrar a valorar la causa de l'emplenament exagerat dels
fitxers de registre d'activitat (si ho consideres convenient, podries
enviar-ne una petita mostra per si et podem orientar millor), la idea
salomònica de neutralitzar-los seria recreant-los com enllaços
simbòlics a /dev/null

Personalment no m'agrada gens la idea de perdre tot registre
d'activitat pel risc que suposa emmascarar errors o il·lícits, així
que prioritzaria per sobre de tot trobar-ne la causa arrel. Així a
cegues, per les bitàcoles afectades diria que hi ha algun procés que
està intentant canviar de permisos o privilegis d'usuari
contínuament, probablement sense èxit.

Tens raó, i porto més d'un mes donant voltes a això. El problema és
que els missatges enregistrats no parlen de cap problema, sinó que
sembla la reiteració dels mateixos missatges de Xorg mil vegades, i
altre programari del sistema.
Com que no he pogut aïllar l'aplicació i quan és que fa aquest efecte, tampoc no he pogut analitzar bé les bitàcoles, i quan el problema ha ocorregut la prioritat era esborrar-les per a permetre l'arrencada.

Provaré això del /dev/null si és l'únic fre a les inundacions de text.

Gràcies.

Una alternativa menys traumàtica, però que tampoc és solució, seria
muntar /var/log a un sistema de fitxers diferenciat, preferentment no
compartit (evitant un bind contra una altra partició, traslladant el problema). Si no disposes d'espai per reparticionar, sempre pots crear
un fitxer contenidor en una partició ja existent i muntar-la.

Pot tenir problemes de rendiment (especialment si el fitxer és sparse o
està fragmentat) i igualment un cop emplenada la partició suposarà la pèrdua de registres, però pot servir per contenir el problema temporalment.

Parlant de registres, un problema que ja m'he trobat és el de ~/.xsession-errors, que aquest per defecte no està sota la mira del
logrotate i té tendència a créixer desmesuradament amb el temps.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 8/4/22 a les 15:37, Narcis Garcia ha escrit:

El 8/4/22 a les 15:30, Eloi ha escrit:

El 8/4/22 a les 15:22, Narcis Garcia ha escrit:

El 8/4/22 a les 15:13, Eloi ha escrit:

El 8/4/22 a les 14:42, Narcis Garcia ha escrit:

Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc
ben delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena
completament i després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació
horària a:
/etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més >>>>> ràpid que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de >>>>> registre o, com a últim recurs, que no es generin?

Gràcies.

Sense entrar a valorar la causa de l'emplenament exagerat dels
fitxers de registre d'activitat (si ho consideres convenient,
podries enviar-ne una petita mostra per si et podem orientar
millor), la idea salomònica de neutralitzar-los seria recreant-los
com enllaços simbòlics a /dev/null

Personalment no m'agrada gens la idea de perdre tot registre
d'activitat pel risc que suposa emmascarar errors o il·lícits, així >>>> que prioritzaria per sobre de tot trobar-ne la causa arrel. Així a
cegues, per les bitàcoles afectades diria que hi ha algun procés
que està intentant canviar de permisos o privilegis d'usuari
contínuament, probablement sense èxit.

Tens raó, i porto més d'un mes donant voltes a això. El problema és
que els missatges enregistrats no parlen de cap problema, sinó que
sembla la reiteració dels mateixos missatges de Xorg mil vegades, i
altre programari del sistema.
Com que no he pogut aïllar l'aplicació i quan és que fa aquest
efecte, tampoc no he pogut analitzar bé les bitàcoles, i quan el
problema ha ocorregut la prioritat era esborrar-les per a permetre
l'arrencada.

Provaré això del /dev/null si és l'únic fre a les inundacions de text. >>>
Gràcies.

Una alternativa menys traumàtica, però que tampoc és solució, seria
muntar /var/log a un sistema de fitxers diferenciat, preferentment no
compartit (evitant un bind contra una altra partició, traslladant el
problema). Si no disposes d'espai per reparticionar, sempre pots
crear un fitxer contenidor en una partició ja existent i muntar-la.

Pot tenir problemes de rendiment (especialment si el fitxer és sparse
o està fragmentat) i igualment un cop emplenada la partició suposarà
la pèrdua de registres, però pot servir per contenir el problema
temporalment.

Parlant de registres, un problema que ja m'he trobat és el de
~/.xsession-errors, que aquest per defecte no està sota la mira del
logrotate i té tendència a créixer desmesuradament amb el temps.

Solució interessant (veig millor la partició ordinària), tot i que
implica que, en emplenar-se, totes les bitàcoles deixarien
d'enregistrar res.
He pensat ara en no muntar tot el directori /var/log sinó un directori
sense cap relació, i aleshores enllaçar-hi només les 3 bitàcoles problemàtiques:
ln -s /mnt/runa/log/messages /var/log/messages
ln -s /mnt/runalog/syslog /var/log/syslog
ln -s /mnt/runa/log/user.log /var/log/user.log

i buidar els fitxers de la partició a cada arrencada del sistema.

Del què necessito estar segur és que els enllaços no seran reemplaçats per rsyslog ni per logrotate amb les seves operacions.

Salut.

Per això és millor idea la de la partició muntada ex-profeso per a
/var/log que la dels enllaços simbòlics, que de fet en el cas de rotació (reconec que no hi havia caigut) poden invalidar igualment la solució de /dev/null

De totes maneres, és el que deia abans, això no deixen de ser pedaços
per evitar la caiguda general del sistema per l'emplenament de la
partició arrel; el que cal és resoldre'n la causa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hola, Narcís,

En els darrers dies m'he trobat puntualment amb un programa que fa una cosa semblant al que dius... però l'aturo a temps (també puja el temps de processador, per aquest motiu ho vaig detectar).
En el meu cas, la qüestió apareix en els fitxers següents:

kern.log (uns 9 GB de mida)

Mar 30 10:50:16 debian kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: error: failed setting DAI config for HDA0.OUT
Mar 30 10:50:16 debian kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ASoC: error at snd_soc_dai_hw_params on Analog CPU DAI: -19
Mar 30 10:50:16 debian kernel: Analog Playback and Capture: ASoC: __soc_pcm_hw_params() failed (-19)
Mar 30 10:50:16 debian kernel: HDA Analog: ASoC: dpcm_fe_dai_hw_params
failed (-19)

syslog (uns 9 GB de mida)

Mar 30 10:50:16 debian pulseaudio[2414]: Failed to set hardware parameters:
El dispositiu no és vàlid
Mar 30 10:50:16 debian kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: error: failed setting DAI config for HDA0.OUT
Mar 30 10:50:16 debian kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ASoC: error at snd_soc_dai_hw_params on Analog CPU DAI: -19
Mar 30 10:50:16 debian kernel: Analog Playback and Capture: ASoC: __soc_pcm_hw_params() failed (-19)
Mar 30 10:50:16 debian kernel: HDA Analog: ASoC: dpcm_fe_dai_hw_params
failed (-19)


user.log (uns 4 GB de mida)

Mar 30 10:50:16 debian pulseaudio[2414]: Failed to set hardware parameters:
El dispositiu no és vàlid

El creixement dels fitxers s'atura perquè aturo pulseaudio.

Com podeu veure, es tracta de pulseaudio combinat amb el controlador SOF d'Intel.
Treballo amb nucli compilat expressament per usar aquest controlador ja que altrament no puc fer servir el micròfon del portàtil.

Cordialment,
Josep

On Fri, 8 Apr 2022 at 15:06, Narcis Garcia <narcisgarcia@gilug.org> wrote:

Hola bones,

En un ordinador, sota algunes circumstàncies que encara no tinc ben delimitades, però que semblen tenir a veure amb una aplicació
d'escriptori, hi ha moments en què els fitxers:
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament i després no hi ha manera ni d'arrencar.

He provat a configurar la limitació de fitxers a 20M i rotació horària a: /etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més ràpid
que no pas el temps de reacció.

Algú sap com limitar de forma eficaç el volum d'aquests fitxers de
registre o, com a últim recurs, que no es generin?

Gràcies.

--
Narcis Garcia

--
--
Salutacions...Josep
--

<div dir="ltr"><div dir="ltr"><div>Hola, Narcís,</div><div><br></div><div>En els darrers dies m&#39;he trobat puntualment amb un programa que fa una cosa semblant al que dius... però l&#39;aturo a temps (també puja el temps de processador, per aquest
motiu ho vaig detectar).</div><div></div><div>En el meu cas, la qüestió apareix en els fitxers següents:<br></div></div><div><br></div><div>kern.log (uns 9 GB de mida)<br></div><div><br></div><div>Mar 30 10:50:16 debian kernel: sof-audio-pci-intel-cnl
0000:00:1f.3: error: failed setting DAI config for HDA0.OUT<br>Mar 30 10:50:16 debian kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ASoC: error at snd_soc_dai_hw_params on Analog CPU DAI: -19<br>Mar 30 10:50:16 debian kernel: Analog Playback and Capture:
ASoC: __soc_pcm_hw_params() failed (-19)<br>Mar 30 10:50:16 debian kernel: HDA Analog: ASoC: dpcm_fe_dai_hw_params failed (-19)</div><div><br></div><div>syslog (uns 9 GB de mida)<br></div><div><br></div><div>Mar 30 10:

Hola, Narcis:

És un problema que, si m'equivoco de remitent, la llista de
Debian admet igualment el meu correu de remitent no subscrit,
i el publica amb l'adreça i tot a l'hemeroteca.

El que per tu és un problema per a d'altra gent és un avantatge.

Fa una pila d'anys que la majoria de llistes de debian permeten
enviar-hi correus des de qualsevol adreça per tal de fomentar la participació.

Si creus que la publicació d'aquesta altra adreça justifica que
s'elimini el correu, pots demanar als administradors de les
llistes que ho facin.

Salut,
Alex

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Alex Muntada <alexm@debian.org>
⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org
⠈⠳⣄⠀⠀⠀⠀


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEaUBwKsbetWW2SKTt466XjoNOXn4FAmJUX/YACgkQ466XjoNO Xn4RJA//fbh/8tT2tkS9e/DHYu+/is4IAt9Bud7izq8W+AZt3ahD1BjrO5jxcTqH O5FGPFBKJVzYaoRqvhv653ipdmbqIV0+C1e4GCGkbAKvfk8CQC17q0pDKy6iXCUu hh95EKGE/qPe3EP4Cgr4VTdL/jZOEhCOxP1X2KhhqH2EF9yU4gpemk5qcR9sCk0c QTEo3errftrFO97LeQP6DmSNObwedNo+oru+9lZfz0SS/aNJ4NDTiiRrt7zwgb5p bmqMUznAu93k6mcedI3Ns8A6Yxd3rljGWnB00Sx6QdL51WoEeVJzXYJvldYqMXzn FEbK7K3tS3sA97TehHTwpBtLKSr7BAs7GnUUdtdotn9xsFjt/CE4juSEcUkb+MmK iPfxcY6mzihXPS4mp712v7kRLaEPNdhWysulr1N2C0jmtzyL0BI0XnRiWpZxfK5z kSDspWxw0VPEXR6WaFTQS18Y4ir30elmVwvHRUC+j3GvdKBW7ROlMvquLCZx5E+O q0AqBW7K1OI7F6otMev19ceiin5R4xzMs+G5n3OzOM8Xo4ck35+pEeIh3qb2ow+Q WM7VCIGrlhfhB3e1JVgycoJs6yNUrOxn92LY7OtB1LcecbADiIEAD7hN6NHgNILK Cws59stQBItfDea13Qb05vhpLoCSuPsMSolZ1kl0fYbGemRmqw8=
=WPke
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)