Re: [gentoo-user] Local mail delivery agent (MDA) wanted

[tastytea]

On 2021-12-13 23:12+0100 Frank Steinmetzger  wrote:

> Am Mon, Dec 13, 2021 at 10:34:08PM +0100 schrieb Frank Steinmetzger:
> 
> > Using strace, I found out that mail from mailx puts those mail into
> > /var/spool/clientmqueue/, one file per mail, but not in a maildir
> > structure.  
> 
> OK, I found out that this is the usual outgoing queue which needs to
> be processed by sendmail, probably through another cronjob or a
> process that itself checks that directory periodically.

Hmm, I'm pretty sure this worked a few years ago. I just tested it on a
system on which I didn't configure mail before. My mails ended up in
/var/spool/nullmailer/queue. :-(

> > In many places I read that system mail—by default—goes into
> > /var/spool/mail/, but until now I’ve yet to observe this
> > behavior.  
> 
> It’s really not easy to find a description of the default setup of
> olden days (or I’m simply using the wrong search terms). Because when
> you search for something like unix local mail setup, most results are
> about setting up an SMTP server. In hindsight—perhaps that is simply
> the way to go. :-/

A lot of packages depend on virtual/mta, including mailx. It seems you
have no choice but to configure one of the MTAs virtual/mta depends on.

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgp5j9YxUaexa.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] Bug in run-crons?

[Wols Lists]

On 13/12/2021 22:03, Frank Steinmetzger wrote:

If they are involved multiple times
with the default options I think any attempt to scrub something that
is already being scrubbed is just a no-op.  Obviously if you don't
want all that IO during the day you'll have to do something more
clever - you can instruct it to pause and resume so you could have a
couple of crontab entries and scripts to do just that.



Or, since I am the only user of that system, I could go back to my previous
way: just run the scrub manually every other month or so before I go to bed.
Because then I know that nothing will interfere with it and it won’t
interfere with anything else.


Yup. I was thinking that. The problem with scrubs et al auto-resuming or 
firing at boot is that disk i/o is then knackered for ages, and 
interferes with whatever it is you're actually trying to do :-)


Cheers,
Wol

Re: [gentoo-user] Local mail delivery agent (MDA) wanted

[Frank Steinmetzger]

Am Mon, Dec 13, 2021 at 10:34:08PM +0100 schrieb Frank Steinmetzger:

> Using strace, I found out that mail from mailx puts those mail into
> /var/spool/clientmqueue/, one file per mail, but not in a maildir structure.

OK, I found out that this is the usual outgoing queue which needs to be
processed by sendmail, probably through another cronjob or a process that
itself checks that directory periodically.

> In many places I read that system mail—by default—goes into
> /var/spool/mail/, but until now I’ve yet to observe this behavior.

It’s really not easy to find a description of the default setup of olden
days (or I’m simply using the wrong search terms). Because when you search
for something like unix local mail setup, most results are about setting up
an SMTP server. In hindsight—perhaps that is simply the way to go. :-/

-- 
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Petrol station attendand to customer:
“Could you turn off that SUV for a mo’, or I’ll never get it full.”


signature.asc
Description: PGP signature

Re: [gentoo-user] Bug in run-crons?

[Frank Steinmetzger]

Am Mon, Dec 13, 2021 at 04:54:30PM -0500 schrieb Rich Freeman:
> On Mon, Dec 13, 2021 at 4:42 PM Michael Orlitzky  wrote:
> >
> > On Mon, 2021-12-13 at 22:38 +0100, Frank Steinmetzger wrote:
> > >
> > > Well I *could* disable run-crons altogether and add entries to fcron’s own
> > > crontab which would run those scripts in /etc/cron.{hourly,daily,...}
> > > instead.
> > >
> > > However, I like predictable times at which those jobs will run. Especially
> > > if one of them is a zfs scrub; the NAS is powered down for weeks, 
> > > sometimes
> > > months. And when I power it up, it’s for a reason. And that reason usually
> > > is not a scrub, which—at the current zfs fill level—takes 10½ hours.
> > >
> >
> > Why choose fcron then? It sounds like you have the same rationale as I
> > do: "no, I don't want to run the 4am backup job in the middle of the
> > business day just because it wasn't run at 4am."

Fair point.
Fcron has a serialisation feature, so that for instance updatedb and mandb
don’t run at the same time. Me kinda liky.

> fcron is perfectly capable of running jobs at either set times or at
> loosely-defined intervals that are compensated for if the machine is
> off.

Indeed, I can say "@monthly * 0 *" to run a monthly job (like the scrub)
only at night. *pondering*

> Systemd timers can also be set that way, and can also have
> limits put on scheduling (daily nominally at 3AM but allowed between
> 11PM and 5AM or whatever).  Obviously the more expressive the crontab
> equivalent is, the more you can tweak it to do what you want it to.

I’ve gotten used to systemd on my Arch-based desktops. But the NAS is still
on good-ol’ openrc. :)

> I'll also note that zfs scrubs checkpoint at shutdown and will
> auto-resume where you leave off.

That’s a nice bit of knowledge.

> If they are involved multiple times
> with the default options I think any attempt to scrub something that
> is already being scrubbed is just a no-op.  Obviously if you don't
> want all that IO during the day you'll have to do something more
> clever - you can instruct it to pause and resume so you could have a
> couple of crontab entries and scripts to do just that.

Or, since I am the only user of that system, I could go back to my previous
way: just run the scrub manually every other month or so before I go to bed.
Because then I know that nothing will interfere with it and it won’t
interfere with anything else.

-- 
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

This message was written using only recycled electrons.


signature.asc
Description: PGP signature

Re: [gentoo-user] Bug in run-crons?

[Rich Freeman]

On Mon, Dec 13, 2021 at 4:42 PM Michael Orlitzky  wrote:
>
> On Mon, 2021-12-13 at 22:38 +0100, Frank Steinmetzger wrote:
> >
> > Well I *could* disable run-crons altogether and add entries to fcron’s own
> > crontab which would run those scripts in /etc/cron.{hourly,daily,...}
> > instead.
> >
> > However, I like predictable times at which those jobs will run. Especially
> > if one of them is a zfs scrub; the NAS is powered down for weeks, sometimes
> > months. And when I power it up, it’s for a reason. And that reason usually
> > is not a scrub, which—at the current zfs fill level—takes 10½ hours.
> >
>
> Why choose fcron then? It sounds like you have the same rationale as I
> do: "no, I don't want to run the 4am backup job in the middle of the
> business day just because it wasn't run at 4am."
>
> If you pick a dumber cron, the crontab entries are run only at the
> specified times.

There really are no one-size-fits all solutions obviously.  You can
either have predictable times and if the machine is down things get
skipped, or you can run opportunistically in which case you lose
predictable times at least until the machine goes back to running
24x7.  The machine has no way to know if you'll leave it on overnight
the NEXT night - only if you did so the one before.

fcron is perfectly capable of running jobs at either set times or at
loosely-defined intervals that are compensated for if the machine is
off.  Systemd timers can also be set that way, and can also have
limits put on scheduling (daily nominally at 3AM but allowed between
11PM and 5AM or whatever).  Obviously the more expressive the crontab
equivalent is, the more you can tweak it to do what you want it to.

The default configs are a one-size-fits all approach that tend to do
the right thing if you leave the machine on 24x7, or if you run it at
random times.  If you want to specify exact behavior just edit the
config files and make it do so.

I'll also note that zfs scrubs checkpoint at shutdown and will
auto-resume where you leave off.  If they are involved multiple times
with the default options I think any attempt to scrub something that
is already being scrubbed is just a no-op.  Obviously if you don't
want all that IO during the day you'll have to do something more
clever - you can instruct it to pause and resume so you could have a
couple of crontab entries and scripts to do just that.

-- 
Rich

Re: [gentoo-user] Bug in run-crons?

[Michael Orlitzky]

On Mon, 2021-12-13 at 22:38 +0100, Frank Steinmetzger wrote:
> 
> Well I *could* disable run-crons altogether and add entries to fcron’s own
> crontab which would run those scripts in /etc/cron.{hourly,daily,...}
> instead.
> 
> However, I like predictable times at which those jobs will run. Especially
> if one of them is a zfs scrub; the NAS is powered down for weeks, sometimes
> months. And when I power it up, it’s for a reason. And that reason usually
> is not a scrub, which—at the current zfs fill level—takes 10½ hours.
> 

Why choose fcron then? It sounds like you have the same rationale as I
do: "no, I don't want to run the 4am backup job in the middle of the
business day just because it wasn't run at 4am."

If you pick a dumber cron, the crontab entries are run only at the
specified times.

Re: [gentoo-user] Bug in run-crons?

[Frank Steinmetzger]

Am Mon, Dec 13, 2021 at 04:33:32PM -0500 schrieb Michael Orlitzky:
> On Mon, 2021-12-13 at 22:19 +0100, Frank Steinmetzger wrote:
> > 
> > For the record: The checks in run-crons that I referred to earlier are
> > actually more for those cases in which the machine was powered off for a
> > while in order to restore cron completeness as early as possible after boot.
> > 
> 
> The run-crons quackery has been causing problems since 2004:
> 
>   https://bugs.gentoo.org/69777
> 
> One-liners with run-parts (NOT run-crons) are a lot more predictable.

Well I *could* disable run-crons altogether and add entries to fcron’s own
crontab which would run those scripts in /etc/cron.{hourly,daily,...}
instead.

However, I like predictable times at which those jobs will run. Especially
if one of them is a zfs scrub; the NAS is powered down for weeks, sometimes
months. And when I power it up, it’s for a reason. And that reason usually
is not a scrub, which—at the current zfs fill level—takes 10½ hours.

-- 
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

A preposition is something you should never end a sentence with.


signature.asc
Description: PGP signature

Re: [gentoo-user] Local mail delivery agent (MDA) wanted

[Frank Steinmetzger]

Am Mon, Dec 13, 2021 at 08:40:05PM +0100 schrieb tastytea:
> On 2021-12-12 14:25+0100 Frank Steinmetzger  wrote:
> 
> > Hey list,
> > 
> > I am looking for an as-simple-as-possible setup for local mail
> > delivery. What I mean by that is: the mail shall go into
> > /var/spool/mail locally, which is why I deem it overkill to set up
> > and run a complicated smtpd daemon with its own config file language.
> 
> mail-client/mailx provides /usr/bin/mail which can be used for looking
> at mail in /var/spool/mail/ and for sending it to local users. No
> configuration necessary. cron and other software will automatically use
> it.

OK, it looks promising -- very neatly small and tiny. But:

lcars ~ # echo hello | mail root
lcars ~ # mail
No mail for root
lcars ~ #

Using strace, I found out that mail from mailx puts those mail into
/var/spool/clientmqueue/, one file per mail, but not in a maildir structure.
I had similar issues with mailutils’ mda. The ebuild installs no manpage and
the package’s website simply points to debian.org. -_-

In many places I read that system mail—by default—goes into
/var/spool/mail/, but until now I’ve yet to observe this behavior.
It’s becoming a little frustrating by now. This is also not my first attempt
at this; I tried this before in the past years but never reached the goal.

-- 
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

“Hodor.”


signature.asc
Description: PGP signature

Re: [gentoo-user] Bug in run-crons?

[Michael Orlitzky]

On Mon, 2021-12-13 at 22:19 +0100, Frank Steinmetzger wrote:
> 
> For the record: The checks in run-crons that I referred to earlier are
> actually more for those cases in which the machine was powered off for a
> while in order to restore cron completeness as early as possible after boot.
> 

The run-crons quackery has been causing problems since 2004:

  https://bugs.gentoo.org/69777

One-liners with run-parts (NOT run-crons) are a lot more predictable.

Re: [gentoo-user] Bug in run-crons?

[Frank Steinmetzger]

Am Mon, Dec 13, 2021 at 03:18:44PM -0500 schrieb Rich Freeman:
> On Sun, Dec 12, 2021 at 2:07 PM Frank Steinmetzger  wrote:
> >
> > Am Sun, Dec 12, 2021 at 01:41:33PM -0500 schrieb Rich Freeman:
> > > On Sun, Dec 12, 2021 at 1:21 PM Frank Steinmetzger  wrote:
> > > >
> > >
> > > I don't use this, but I believe there should be an hourly crontab
> > > entry that deletes the cron.hourly file, which would mean it gets run
> > > on the next 10min cycle (or maybe sooner - I'm not sure if those jobs
> > > are run in parallel or serial).
> >
> > The check that I mentioned above is actually the deletion which you mention:
> > run-crons looks for the state file for the given interval and - if it is old
> > enough - deletes it.
> 
> The check I'm talking about isn't in run-crons at all.  It is in
> /etc/crontab.  It doesn't look at the age of the file and
> unconditionally deletes it every hour:
> 59  *  * * *rm -f /var/spool/cron/lastrun/cron.hourly

I had a look at files and docs on the net again. Thus I found exactly those
rm entries in /etc/crontab, which by itself is not used by fcron. But after
I understood all the logic behind it, I added them to fcron to be run
serially before run-crons. Now everything is as I wanted it.

For the record: The checks in run-crons that I referred to earlier are
actually more for those cases in which the machine was powered off for a
while in order to restore cron completeness as early as possible after boot.

-- 
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

“Selfies are electronic masturbation.” — Karl Lagerfeld


signature.asc
Description: PGP signature

Re: [gentoo-user] Bug in run-crons?

[Rich Freeman]

On Sun, Dec 12, 2021 at 2:07 PM Frank Steinmetzger  wrote:
>
> Am Sun, Dec 12, 2021 at 01:41:33PM -0500 schrieb Rich Freeman:
> > On Sun, Dec 12, 2021 at 1:21 PM Frank Steinmetzger  wrote:
> > >
> >
> > I don't use this, but I believe there should be an hourly crontab
> > entry that deletes the cron.hourly file, which would mean it gets run
> > on the next 10min cycle (or maybe sooner - I'm not sure if those jobs
> > are run in parallel or serial).
>
> The check that I mentioned above is actually the deletion which you mention:
> run-crons looks for the state file for the given interval and - if it is old
> enough - deletes it.

The check I'm talking about isn't in run-crons at all.  It is in
/etc/crontab.  It doesn't look at the age of the file and
unconditionally deletes it every hour:
59  *  * * *rm -f /var/spool/cron/lastrun/cron.hourly

-- 
Rich

Re: [gentoo-user] Local mail delivery agent (MDA) wanted

[Grant Taylor]

On 12/13/21 12:40 PM, tastytea wrote:
mail-client/mailx provides /usr/bin/mail which can be used for looking 
at mail in/var/spool/mail/  and for sending it to local users. No 
configuration necessary. cron and other software will automatically 
use it.


For some reason I thought that mailx (and / or nail) relied on a local 
MTA+LDA.  Even if it's only listening on 127.1.  --  I guess I'm wrong.




--
Grant. . . .
unix || die

Re: [gentoo-user] Local mail delivery agent (MDA) wanted

[tastytea]

On 2021-12-12 14:25+0100 Frank Steinmetzger  wrote:

> Hey list,
> 
> I am looking for an as-simple-as-possible setup for local mail
> delivery. What I mean by that is: the mail shall go into
> /var/spool/mail locally, which is why I deem it overkill to set up
> and run a complicated smtpd daemon with its own config file language.

mail-client/mailx provides /usr/bin/mail which can be used for looking
at mail in /var/spool/mail/ and for sending it to local users. No
configuration necessary. cron and other software will automatically use
it.

Kind regards, tastytea

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpLDDiu5qCL4.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-user] Re: "Broken soname dependencies found" after portage upgrade

[Nikos Chantziaras]

On 12/12/2021 18:41, Neil Bothwick wrote:

On Sun, 12 Dec 2021 18:11:53 +0200, Nikos Chantziaras wrote:


After upgrading from portage 3.0.28 to 3.0.30, I get this when doing
emerge --depclean:

Calculating dependencies... done!
   * Broken soname dependencies found:
   *
   *   x86_64: libexpat.so required by:
   * app-emulation/vmware-workstation-16.2.1.18811642-r1
[...]


Revdep-rebuild won't work because vmware-workstation is a binary package.
You may need to add a file to /etc/revdep-rebuild that adds the vmware
path (somewhere in /opt?) to SEARCH_DIRS_MASK.


This is already the case:

  SEARCH_DIRS_MASK="/opt/vmware"

As I said, revdep-rebuild does not find anything to rebuild and prints 
nothing. It's "emerge --depclean" that shows these messages.

[gentoo-user] Re: "Broken soname dependencies found" after portage upgrade

[Nikos Chantziaras]

On 12/12/2021 18:57, tastytea wrote:

On 2021-12-12 18:11+0200 Nikos Chantziaras  wrote:


After upgrading from portage 3.0.28 to 3.0.30, I get this when doing
emerge --depclean:

Calculating dependencies... done!
   * Broken soname dependencies found:
   *   x86_64: libexpat.so required by:
   * app-emulation/vmware-workstation-16.2.1.18811642-r1
[...]
   *   x86_64: liblttng-ust.so.0 required by:
   * dev-dotnet/dotnet-sdk-bin-6.0.100
[...]


It means the binary wants to load some libraries (like libexpat.so)
portage can't find.


(And before anyone asks, the software works just fine, and neither
revdep-rebuild nor revdep-rebuild.sh find anything wrong.)


But vmware (or rather, the linker) seems to find them. Maybe they are in
the same directory as the binary and portage doesn't search there? You
can check which libraries exactly the binary wants to load with ldd.


Example:

$ ldd 
/opt/vmware/lib/vmware-installer/3.0.0/python/lib/lib-dynload/readline.cpython-39-x86_64-linux-gnu.so
ldd: warning: you do not have execution permission for 
`/opt/vmware/lib/vmware-installer/3.0.0/python/lib/lib-dynload/readline.cpython-39-x86_64-linux-gnu.so'

linux-vdso.so.1 (0x7ffde924c000)
libreadline.so.6 => not found

It seems the new portage version does these checks now. Is there a way 
to opt-out of those checks?

Re: [gentoo-user] Local mail delivery agent (MDA) wanted

[William Kenworthy]

True - missed that!

BillK


On 13/12/21 17:36, Peter Humphrey wrote:

On Sunday, 12 December 2021 23:36:33 GMT William Kenworthy wrote:

I thought the gentoo default mail program is nullmailer? Changed from
smtpd(? or something named similar) some time back.  Simple, reasonably
versatile and has easy configuration.

That's a sending program, not receiving.

Re: [gentoo-user] Local mail delivery agent (MDA) wanted

[Peter Humphrey]

On Sunday, 12 December 2021 23:36:33 GMT William Kenworthy wrote:
> I thought the gentoo default mail program is nullmailer? Changed from
> smtpd(? or something named similar) some time back.  Simple, reasonably
> versatile and has easy configuration.

That's a sending program, not receiving.

-- 
Regards,
Peter.