Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #224583 > unrolled thread

Whats chances of getting libTLSv1.3 for stretch

Back to article view | Back to linux.debian.user

Contents

  Whats chances of getting libTLSv1.3 for stretch Gene Heskett <gheskett@shentel.net> - 2020-07-08 11:20 +0200
    Re: Whats chances of getting libTLSv1.3 for stretch Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-08 14:00 +0200
      Re: Whats chances of getting libTLSv1.3 for stretch Gene Heskett <gheskett@shentel.net> - 2020-07-08 15:40 +0200
        Re: Whats chances of getting libTLSv1.3 for stretch Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-09 10:40 +0200
          Re: Whats chances of getting libTLSv1.3 for stretch Zenaan Harkness <zenaan@freedbms.net> - 2020-07-09 11:50 +0200
            Re: Whats chances of getting libTLSv1.3 for stretch Gene Heskett <gheskett@shentel.net> - 2020-07-09 14:30 +0200
              Re: Whats chances of getting libTLSv1.3 for stretch <tomas@tuxteam.de> - 2020-07-09 15:00 +0200
                Re: Whats chances of getting libTLSv1.3 for stretch Gene Heskett <gheskett@shentel.net> - 2020-07-09 19:20 +0200
                  Re: Whats chances of getting libTLSv1.3 for stretch <tomas@tuxteam.de> - 2020-07-10 10:20 +0200
          Re: Whats chances of getting libTLSv1.3 for stretch Gene Heskett <gheskett@shentel.net> - 2020-07-09 14:10 +0200
            Re: Whats chances of getting libTLSv1.3 for stretch Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-09 18:10 +0200
    Re: Whats chances of getting libTLSv1.3 for stretch Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-09 10:20 +0200
      Re: Whats chances of getting libTLSv1.3 for stretch Gene Heskett <gheskett@shentel.net> - 2020-07-09 13:50 +0200

#224583 — Whats chances of getting libTLSv1.3 for stretch

Greetings all;

2 questions.

As a 2 decade user of fetchmail/procmail combo, I just updated to stretch 
backports, but did not get a TLSv1.3, so when I configure the newest 
fetchmail, I don't get ssl3 support.

So whats chances of getting that in stretch security/backports?

Also, I've not a clue how to generate the systemd-service file that 
systemd seems to be demanding and that so far I have had to rebuild 
fetchmail from src and reinstall everytime cron runs 
~/bin/sa-train-bayes.  Thats not very friendly on systemd's intrusions 
into normal daily operations. I am the only O2 breathing user here, so I 
do eventually get it to work, as me, which is all it has to do, but I 
don't appreciate the PITA the battle is  with systemd to do what s/b 
normal housekeeping. So the 2nd question is how can this be fixed?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [next] | [standalone]

#224586

On Wed, Jul 08, 2020 at 05:12:20AM -0400, Gene Heskett wrote:
> As a 2 decade user of fetchmail/procmail combo, I just updated to stretch 
> backports, but did not get a TLSv1.3, so when I configure the newest 
> fetchmail, I don't get ssl3 support.

Er... what?  This question doesn't make any sense.  I can't figure
out whether you're asking for a *newer* library or an *older* library
than what you have right now.

TLS 1.3 is very new, and is not assumed to be present by most
applications.

SSL 3 is extremely old, and has well-known exploited holes.  My
first Google hit for SSL 3 is a refernce to the POODLE exploit from
2014. <https://blog.qualys.com/ssllabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack>

Are you *really* trying to use SSL 3, because that's what you configured
the other end to use, "2 decades" ago?  If so, it is time to stop
doing that.  Upgrade *both* ends to use currently supported, non-vulnerable
TLS protocols.  At this point, TLS 1.2 is your most likely target.

[toc] | [prev] | [next] | [standalone]

#224593

On Wednesday 08 July 2020 07:54:33 Greg Wooledge wrote:

> On Wed, Jul 08, 2020 at 05:12:20AM -0400, Gene Heskett wrote:
> > As a 2 decade user of fetchmail/procmail combo, I just updated to
> > stretch backports, but did not get a TLSv1.3, so when I configure
> > the newest fetchmail, I don't get ssl3 support.
>
> Er... what?  This question doesn't make any sense.  I can't figure
> out whether you're asking for a *newer* library or an *older* library
> than what you have right now.
>
> TLS 1.3 is very new, and is not assumed to be present by most
> applications.
>
> SSL 3 is extremely old, and has well-known exploited holes.  My
> first Google hit for SSL 3 is a refernce to the POODLE exploit from
> 2014.
> <https://blog.qualys.com/ssllabs/2014/10/15/ssl-3-is-dead-killed-by-th
>e-poodle-attack>
>
> Are you *really* trying to use SSL 3, because that's what you
> configured the other end to use, "2 decades" ago?  If so, it is time
> to stop doing that.  Upgrade *both* ends to use currently supported,
> non-vulnerable TLS protocols.  At this point, TLS 1.2 is your most
> likely target.

./configure --with-ssl, make, sudo make install, is whats working right 
now. But I won't know if it all just works again till the middle of the 
night when sa-train-bayes runs again.  But it runs as me, so nothing is 
stopping me from running it right now. And this time it did restart 
fetchmail ok when it was done. 6.4.3 was giving systemd a tummy ache 
after updating from backports, about 150 packages.  That also destroyed 
TDE and it took a reboot to restore it, a startx got me xfce.

But, while fetchmail-6.4.8 seems to be listed by synaptic, its ghosted 
and will not let me install the "approved" version, so I must dl and 
build my own.  Whats with that?

And I note that procmail is being bad-mouthed, but its been doing exactly 
what I want for 2 decades with no hiccups. I would submit that its docs 
might need help, but if you read them carefully, it does exactly what 
you tell it to do, so I've no need/urge to experiment with getmail. 

Thanks Gregg.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#224633

[Multipart message — attachments visible in raw view] — view raw

On Mi, 08 iul 20, 09:36:25, Gene Heskett wrote:
> On Wednesday 08 July 2020 07:54:33 Greg Wooledge wrote:
> 
> > On Wed, Jul 08, 2020 at 05:12:20AM -0400, Gene Heskett wrote:
> > > As a 2 decade user of fetchmail/procmail combo, I just updated to
> > > stretch backports, but did not get a TLSv1.3, so when I configure
> > > the newest fetchmail, I don't get ssl3 support.
> >
> > Er... what?  This question doesn't make any sense.  I can't figure
> > out whether you're asking for a *newer* library or an *older* library
> > than what you have right now.
> >
> > TLS 1.3 is very new, and is not assumed to be present by most
> > applications.
> >
> > SSL 3 is extremely old, and has well-known exploited holes.  My
> > first Google hit for SSL 3 is a refernce to the POODLE exploit from
> > 2014.
> > <https://blog.qualys.com/ssllabs/2014/10/15/ssl-3-is-dead-killed-by-th
> >e-poodle-attack>
> >
> > Are you *really* trying to use SSL 3, because that's what you
> > configured the other end to use, "2 decades" ago?  If so, it is time
> > to stop doing that.  Upgrade *both* ends to use currently supported,
> > non-vulnerable TLS protocols.  At this point, TLS 1.2 is your most
> > likely target.
> 
> ./configure --with-ssl, make, sudo make install, is whats working right 
> now. But I won't know if it all just works again till the middle of the 
> night when sa-train-bayes runs again.  But it runs as me, so nothing is 
> stopping me from running it right now. And this time it did restart 
> fetchmail ok when it was done. 6.4.3 was giving systemd a tummy ache 
> after updating from backports, about 150 packages.  That also destroyed 
> TDE and it took a reboot to restore it, a startx got me xfce.
> 
> But, while fetchmail-6.4.8 seems to be listed by synaptic, its ghosted 
> and will not let me install the "approved" version, so I must dl and 
> build my own.  Whats with that?

Please post the output of 'apt policy fetchmail'.
 
> And I note that procmail is being bad-mouthed, but its been doing 
> exactly what I want for 2 decades with no hiccups.

I remember having a look at its syntax and... well, let's say I used 
maildrop ;)

> I would submit that its docs might need help, but if you read them 
> carefully, it does exactly what you tell it to do, so I've no 
> need/urge to experiment with getmail. 
 
getmail is intended as a replacement for fetchmail...

http://pyropus.ca/software/getmail/faq.html#faq-about-why

As far as I can tell it supports Python 2 only, which is going to be 
removed from Debian.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#224636

On Thu, Jul 09, 2020 at 11:38:14AM +0300, Andrei POPESCU wrote:
> On Mi, 08 iul 20, 09:36:25, Gene Heskett wrote:
> > And I note that procmail is being bad-mouthed, but its been doing 
> > exactly what I want for 2 decades with no hiccups.
> 
> I remember having a look at its syntax and... well, let's say I used 
> maildrop ;)
> 
> > I would submit that its docs might need help, but if you read them 
> > carefully, it does exactly what you tell it to do, so I've no 
> > need/urge to experiment with getmail. 
>  
> getmail is intended as a replacement for fetchmail...
> 
> http://pyropus.ca/software/getmail/faq.html#faq-about-why
> 
> As far as I can tell it supports Python 2 only, which is going to be 
> removed from Debian.

Gene, the biggest benefit to switching off of fetchmail is speed. It is
literally 10 or more times faster.

And a trick to make it about twice as fast or more again (even before
transitioning from procmail to sieve) is to make it 2 steps:

 1. Save all downloading email to a temp email folder/file.

 2. Only after that's finished, sort your email into folders.

Doing it this way means that the sorting program is only launched (and
all the rules read) once, not once for each email.

The final speed boost, and much cleaner rules file (which I suggest not
doing until after getmail is running smoothly for you) is using sieve
for email sorting.

There are 2 sieves: Gnu `sieve` in the `mailutils` package, and
`sieve-filter` from the `dovecot-sieve` package.

dovecot-sieve by default pulls in dovecot-core, the mail server, which I
don't use, and I'm not sure if it is started automatically when
installed, so I just use gnu sieve.

The only thing with gnu sieve though, is that it balks on the occasional
emails containing a lone extra space at the end of the From line (which
is out of spec), which means a trivial perl/sed pass on your "incoming/
recently downloaded email folder" prior to sorting, something like this:

    perl -p -i -e 's/^(From:.*)( +)$/\1/' "$MAIL_INCOMING"

All that said, we won't hold the stone age against ya ;)

[toc] | [prev] | [next] | [standalone]

#224645

On Thursday 09 July 2020 05:47:15 Zenaan Harkness wrote:

> On Thu, Jul 09, 2020 at 11:38:14AM +0300, Andrei POPESCU wrote:
> > On Mi, 08 iul 20, 09:36:25, Gene Heskett wrote:
> > > And I note that procmail is being bad-mouthed, but its been doing
> > > exactly what I want for 2 decades with no hiccups.
> >
> > I remember having a look at its syntax and... well, let's say I used
> > maildrop ;)
> >
> > > I would submit that its docs might need help, but if you read them
> > > carefully, it does exactly what you tell it to do, so I've no
> > > need/urge to experiment with getmail.
> >
> > getmail is intended as a replacement for fetchmail...
> >
> > http://pyropus.ca/software/getmail/faq.html#faq-about-why
> >
> > As far as I can tell it supports Python 2 only, which is going to be
> > removed from Debian.
>
> Gene, the biggest benefit to switching off of fetchmail is speed. It
> is literally 10 or more times faster.
>
> And a trick to make it about twice as fast or more again (even before
> transitioning from procmail to sieve) is to make it 2 steps:
>
>  1. Save all downloading email to a temp email folder/file.

Why? Its designed to use an MTA, so procmail does all that.

>  2. Only after that's finished, sort your email into folders.

Kmail does that. And it occasionally gets a tummy ache when another 
program puts a mail in one of its folders.

> Doing it this way means that the sorting program is only launched (and
> all the rules read) once, not once for each email.
>
> The final speed boost, and much cleaner rules file (which I suggest
> not doing until after getmail is running smoothly for you) is using
> sieve for email sorting.

Looked at it, needless complexity IMO.

> There are 2 sieves: Gnu `sieve` in the `mailutils` package, and
> `sieve-filter` from the `dovecot-sieve` package.
>
> dovecot-sieve by default pulls in dovecot-core, the mail server, which
> I don't use, and I'm not sure if it is started automatically when
> installed, so I just use gnu sieve.
>
> The only thing with gnu sieve though, is that it balks on the
> occasional emails containing a lone extra space at the end of the From
> line (which is out of spec), which means a trivial perl/sed pass on
> your "incoming/ recently downloaded email folder" prior to sorting,
> something like this:
>
>     perl -p -i -e 's/^(From:.*)( +)$/\1/' "$MAIL_INCOMING"
>
> All that said, we won't hold the stone age against ya ;)

Guilty re the stone age. What I have has been working well for decades. 
I'm 85 now, and have a replacement parts list thats beginning to 
resemble the 6 million dollar man from b&w tv days, the card case is 
full of this and that for the medics. I've out stared the guy with the 
scythe and made him blink first 3 times now but I understand I've heard 
the 10 minute warning buzzer too. I've had quite a ride, but it will 
end, sometime.

Thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#224648

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jul 09, 2020 at 08:21:40AM -0400, Gene Heskett wrote:

[...]

> > All that said, we won't hold the stone age against ya ;)
> 
> Guilty re the stone age. What I have has been working well for decades. 

I think that dismissive, sometimes condescending tone is not
warranted. Fetchmail is a fine piece of software, albeit perhaps
not maintained, and it might have some tricks up its sleeve
the others haven't picked up.

Arrogance is out of place here.

I used the fetchmail/procmail combo in a specific situation
for a while (not the stone age, a couple of years between
2011 and 2016) and didn't find anything which could have
taken up this job:

it was in a corporate environment. The server department was
deeply entrenched in Microsoft, so mail was served by an
Exchange [1] server, and luckily the admins left the IMAP
service up. My workstation was Linux, and mutt (my preferred
mail reader) luckily (again) could cope with the (typically
Microsoft-y) Rube Goldbergian authentification method which
is NTLM.

So I was reading mails fine. Until some day, Corporate
decided that mails were to be archived after a short period
(one week or so). Storage shortage (seriously?).

Since a big chunk of my operative memory is searching in
mail archives this didn't go well for me. And the archive
was behind one of those crude web interfaces... well, I
won't try to describe it to avoid putting unnecessary strain
on the list moderation :-/

So downloading my mailbox from IMAP with NTLM authentication
was it.

No single program besides fetchmail in the huge Debian distro
fit the bill besides fetchmail. And of course, if you say
fetchmail, the other side is procmail [2].

I know that there are other more pleasing alternatives from
a more "theoretical" POV. Imapsync. Sieve -- to just point
at alternatives to both above. When it went down to get
dirty, it was fetchmail/procmail.

So snicker at stone age all you want, but if you haven't
made your homework, you might look silly ;-)

Cheers

[1] Why do I always read that name as an invitation, like in
   "exchange this server, ASAP"?

[2] Yeah. You can also inject into a local Postfix/Exim/whatnot.
    Since I had already Exim for outgoing... but hey. And good
    luck eliminating duplicates (which I had to!) with an MTA
    setup. Procmail has a recipe for that.

-- tomás

[toc] | [prev] | [next] | [standalone]

#224656

On Thursday 09 July 2020 08:51:51 tomas@tuxteam.de wrote:

> On Thu, Jul 09, 2020 at 08:21:40AM -0400, Gene Heskett wrote:
>
> [...]
>
> > > All that said, we won't hold the stone age against ya ;)
> >
> > Guilty re the stone age. What I have has been working well for
> > decades.
>
> I think that dismissive, sometimes condescending tone is not
> warranted. Fetchmail is a fine piece of software, albeit perhaps
> not maintained,

Only can say that if you haven't looked at it. It is in fact well 
maintained.

> and it might have some tricks up its sleeve 
> the others haven't picked up.

That too.

> Arrogance is out of place here.
>
> I used the fetchmail/procmail combo in a specific situation
> for a while (not the stone age, a couple of years between
> 2011 and 2016) and didn't find anything which could have
> taken up this job:
>
> it was in a corporate environment. The server department was
> deeply entrenched in Microsoft, so mail was served by an
> Exchange [1] server, and luckily the admins left the IMAP
> service up. My workstation was Linux, and mutt (my preferred
> mail reader) luckily (again) could cope with the (typically
> Microsoft-y) Rube Goldbergian authentification method which
> is NTLM.

Shudder.

> So I was reading mails fine. Until some day, Corporate
> decided that mails were to be archived after a short period
> (one week or so). Storage shortage (seriously?).
>
> Since a big chunk of my operative memory is searching in
> mail archives this didn't go well for me. And the archive
> was behind one of those crude web interfaces... well, I
> won't try to describe it to avoid putting unnecessary strain
> on the list moderation :-/
>
> So downloading my mailbox from IMAP with NTLM authentication
> was it.
>
> No single program besides fetchmail in the huge Debian distro
> fit the bill besides fetchmail. And of course, if you say
> fetchmail, the other side is procmail [2].

There are other MTA's, but nothing as well developed as procmail, IMO of 
course.

> I know that there are other more pleasing alternatives from
> a more "theoretical" POV. Imapsync. Sieve -- to just point
> at alternatives to both above. When it went down to get
> dirty, it was fetchmail/procmail.
>
> So snicker at stone age all you want, but if you haven't
> made your homework, you might look silly ;-)

I personally think other methods are still crude and ungainly. Or are 
loaded with bloatware.  That of course is my opinion. YMMV.

Cheers
>
> [1] Why do I always read that name as an invitation, like in
>    "exchange this server, ASAP"?
>
> [2] Yeah. You can also inject into a local Postfix/Exim/whatnot.
>     Since I had already Exim for outgoing... but hey. And good
>     luck eliminating duplicates (which I had to!) with an MTA
>     setup. Procmail has a recipe for that.
>
> -- tomás

I like the old kmail, which is what TDE gives me.  And kmail is quite 
capable of going after its own incoming mail, but while its doing that, 
the user interface is locked up tight. fetchmail/procmail to the rescue 
and to synchronize it all, inotifywait, which when procmail has 
delivered the incoming messages to /var/spool/mail/user, sends kmail a 
get mail command over dbus, which it can do in milliseconds. The kmail 
editor freezes for those same milliseconds, but loses no keystrokes. All 
that fetching has become a background process I don't see. Computers are 
supposed to do work FOR you, so my method results in far fewer mouse 
clicks, one to answer the currently displayed message or go on to the 
net unread.  Answering of course involves some typing, but one click 
sends that message when I've said my piece.

There may be folks who can tie me for the minimum mouse clicks to handle 
their email, but I don't believe anyone here can beat me. But all are 
perfectly welcome to try, I don't mind a bit.

Cheers Tomas, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#224674

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jul 09, 2020 at 01:12:00PM -0400, Gene Heskett wrote:

[...]

> I like the old kmail, which is what TDE gives me [...]

> There may be folks who can tie me for the minimum mouse clicks to handle 
> their email [...]

That would be mutt users. Or Gnus. Or RMAIL ;-D

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#224643

On Thursday 09 July 2020 04:38:14 Andrei POPESCU wrote:

> On Mi, 08 iul 20, 09:36:25, Gene Heskett wrote:
> > On Wednesday 08 July 2020 07:54:33 Greg Wooledge wrote:
> > > On Wed, Jul 08, 2020 at 05:12:20AM -0400, Gene Heskett wrote:
> > > > As a 2 decade user of fetchmail/procmail combo, I just updated
> > > > to stretch backports, but did not get a TLSv1.3, so when I
> > > > configure the newest fetchmail, I don't get ssl3 support.
> > >
> > > Er... what?  This question doesn't make any sense.  I can't figure
> > > out whether you're asking for a *newer* library or an *older*
> > > library than what you have right now.
> > >
> > > TLS 1.3 is very new, and is not assumed to be present by most
> > > applications.
> > >
> > > SSL 3 is extremely old, and has well-known exploited holes.  My
> > > first Google hit for SSL 3 is a refernce to the POODLE exploit
> > > from 2014.
> > > <https://blog.qualys.com/ssllabs/2014/10/15/ssl-3-is-dead-killed-b
> > >y-th e-poodle-attack>
> > >
> > > Are you *really* trying to use SSL 3, because that's what you
> > > configured the other end to use, "2 decades" ago?  If so, it is
> > > time to stop doing that.  Upgrade *both* ends to use currently
> > > supported, non-vulnerable TLS protocols.  At this point, TLS 1.2
> > > is your most likely target.
> >
> > ./configure --with-ssl, make, sudo make install, is whats working
> > right now. But I won't know if it all just works again till the
> > middle of the night when sa-train-bayes runs again.  But it runs as
> > me, so nothing is stopping me from running it right now. And this
> > time it did restart fetchmail ok when it was done. 6.4.3 was giving
> > systemd a tummy ache after updating from backports, about 150
> > packages.  That also destroyed TDE and it took a reboot to restore
> > it, a startx got me xfce.
> >
> > But, while fetchmail-6.4.8 seems to be listed by synaptic, its
> > ghosted and will not let me install the "approved" version, so I
> > must dl and build my own.  Whats with that?
>
> Please post the output of 'apt policy fetchmail'.

fetchmail:
  Installed: (none)
  Candidate: (none)
  Version table:
     6.3.26-3 -1
        100 /var/lib/dpkg/status

But debians refusal to update fetchmail when it needs it has caused most 
of its users to download the tarball and build/install it 
to /usr/local/bin.  So I'm useing 6.4.8 and understandably apt is giving 
us a worthless WAG.

> > And I note that procmail is being bad-mouthed, but its been doing
> > exactly what I want for 2 decades with no hiccups.
>
> I remember having a look at its syntax and... well, let's say I used
> maildrop ;)

I've looked at maildrop, and its a whole new syntax. procmail still works 
well, running the incoming mail thru clamd, then Spamd, and quite a few 
kill this turkey recipes.

> > I would submit that its docs might need help, but if you read them
> > carefully, it does exactly what you tell it to do, so I've no
> > need/urge to experiment with getmail.
>
> getmail is intended as a replacement for fetchmail...
>
> http://pyropus.ca/software/getmail/faq.html#faq-about-why
>
> As far as I can tell it supports Python 2 only, which is going to be
> removed from Debian.

At which point it (I assume procmail) will be replaced or fixed.

> Kind regards,
> Andrei


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#224653

[Multipart message — attachments visible in raw view] — view raw

On Jo, 09 iul 20, 08:01:43, Gene Heskett wrote:
> On Thursday 09 July 2020 04:38:14 Andrei POPESCU wrote:
> >
> > Please post the output of 'apt policy fetchmail'.
> 
> fetchmail:
>   Installed: (none)
>   Candidate: (none)
>   Version table:
>      6.3.26-3 -1
>         100 /var/lib/dpkg/status
> 
> But debians refusal to update fetchmail when it needs it has caused most 
> of its users to download the tarball and build/install it 
> to /usr/local/bin.  So I'm useing 6.4.8 and understandably apt is giving 
> us a worthless WAG.

Well, according to the above, you don't have any repository configured 
that provides fetchmail. You might want to check your 
/etc/apt/sources.list and files under /etc/apt/sources.list.d/ or 
better, attach them to the list.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#224632

[Multipart message — attachments visible in raw view] — view raw

On Mi, 08 iul 20, 05:12:20, Gene Heskett wrote:
> 
> Also, I've not a clue how to generate the systemd-service file that 
> systemd seems to be demanding and that so far I have had to rebuild 
> fetchmail from src and reinstall everytime cron runs 
> ~/bin/sa-train-bayes.  Thats not very friendly on systemd's intrusions 
> into normal daily operations. I am the only O2 breathing user here, so I 
> do eventually get it to work, as me, which is all it has to do, but I 
> don't appreciate the PITA the battle is  with systemd to do what s/b 
> normal housekeeping. So the 2nd question is how can this be fixed?

It's not clear to me how is systemd interfering here, since it won't 
touch your cron jobs.

Are you maybe running fetchmail as a daemon?

Why do you think you need to generate a service file and for what part 
of the process?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#224640

On Thursday 09 July 2020 04:14:14 Andrei POPESCU wrote:

> On Mi, 08 iul 20, 05:12:20, Gene Heskett wrote:
> > Also, I've not a clue how to generate the systemd-service file that
> > systemd seems to be demanding and that so far I have had to rebuild
> > fetchmail from src and reinstall everytime cron runs
> > ~/bin/sa-train-bayes.  Thats not very friendly on systemd's
> > intrusions into normal daily operations. I am the only O2 breathing
> > user here, so I do eventually get it to work, as me, which is all it
> > has to do, but I don't appreciate the PITA the battle is  with
> > systemd to do what s/b normal housekeeping. So the 2nd question is
> > how can this be fixed?
>
> It's not clear to me how is systemd interfering here, since it won't
> touch your cron jobs.
>
> Are you maybe running fetchmail as a daemon?

Yes, and it runs as me.
>
> Why do you think you need to generate a service file and for what part
> of the process?
>
It appeared that from the error messages, that systemd was denying a 
restart.  However it also seems the error message is completely bogus as 
it was complaining about ~/.fetchmailrc being un-available when it 
clearly was.

An edit to the ~/bin/sa-train-bayes script seems to have fixed it. I had 
to add full paths to everything the script used as it seems that script, 
run from _my_ crontab, no longer inherits my $PATH after the updates 
from backports. After the edit, it has since run normally 3 times so I 
assume it is now fixed.
.
But. I still don't understand the failure's cause. It had been running 
nightly since Spamassassin became available, what, 20 years back up the 
log?

> Kind regards,
> Andrei


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web