[gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Alan Mackenzie]

Hello, Gentoo.

Right at the moment, I feel a lot of sympathy with Alan Grimes, and need
a lot of restraint in avoiding the use of swear words in describing some
Gentoo developer.

What has happened is that somebody decided to add virtual/mta-1
surreptitiously to the default software set in Gentoo.  This installs
something called nullmailer, which I don't need, didn't ask for, and
fouls up my mail transmission.

nullmailer installs a file /usr/sbin/sendmail.  This masks out the
correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I
installed by hand, not using emerge) because /usr/sbin is before
/usr/bin in $PATH.

It appears that nullmailer was installed on 2018-06-15.

Up until recently, things seemed to work; mutt seems to bind itself to
the sendmail it finds at (mutt's) installation time.  However,
mutt-1.10.1 was released in the last couple of days.  It bound itself to
the imposter sendmail.

So, when I sent mail from mutt, nullmailer simply swallowed it up,
without forwarding it to its destination (nullmailer not being
configured).  There were no signs of this lack of action anywhere to be
seen.

SO, WATCH OUT, FELLOW GENTOOERS!

The temporary solution was to rename /usr/sbin/sendmail, and to
reinstall mutt.  That's how I'm able to send this mail.  This has cost
me ~two hours of time, so far.

But what's the proper method to tell my gentoo system that I don't want
crud like nullmailer installed?  How can I guard myself against such
presumptiousness on the part of the Gentoo devs in the future?

Is this worth a bug report?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Mike Gilbert]

On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hello, Gentoo.
>
> Right at the moment, I feel a lot of sympathy with Alan Grimes, and need
> a lot of restraint in avoiding the use of swear words in describing some
> Gentoo developer.
>
> ...
>
> nullmailer installs a file /usr/sbin/sendmail.  This masks out the
> correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I
> installed by hand, not using emerge) because /usr/sbin is before
> /usr/bin in $PATH.
>
> ...
>
> But what's the proper method to tell my gentoo system that I don't want
> crud like nullmailer installed?  How can I guard myself against such
> presumptiousness on the part of the Gentoo devs in the future?

You must have installed a package that depends on virtual/mta,
presumably because it needs to send emails. Had you installed qmail
using portage, the virtual/mta dep would have been satisfied by it,
and nullmailer would not have been installed in the first place.
However, you didn't do that, and so portage had no idea qmail was
installed.

A possible workaround would be to add mail-mta/netqmail to
package.provided on your system. However, there's still no guarantee
that your custom-built qmail software will work with other packages
provided by Gentoo.

Regarding your accusations: Gentoo developers cannot anticipate every
possible thing you might do on your system, especially when you start
installing custom programs in paths that are traditionally managed by
our package manager. Using portage you can customize your system
extensively, without needing to custom build your own software. If
that's not good enough for you, go build a Linux from Scratch system
and enjoy the lack of any package management or support whatsoever.

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Ralph Seichter]

On 21.07.2018 23:03, Alan Mackenzie wrote:

> But what's the proper method to tell my gentoo system that I don't
> want crud like nullmailer installed?

Install an MTA using emerge, or let Gentoo know that you have installed
qmail manually. When you work around portage, you are responsible to
keep Gentoo happy in terms of dependencies. Gentoo did not "foul up",
you just tried to be a tricksy fellow, unaware of the consequences. ;-)

-Ralph

[gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Grant Edwards]

On 2018-07-21, Alan Mackenzie <acm@muc.de> wrote:

> What has happened is that somebody decided to add virtual/mta-1
> surreptitiously to the default software set in Gentoo.  This
> installs something called nullmailer, which I don't need, didn't ask
> for, and fouls up my mail transmission.
>
> nullmailer installs a file /usr/sbin/sendmail.  This masks out the
> correct /usr/bin/sendmail (which is a symbolic link to s/qmail,
> which I installed by hand, not using emerge) because /usr/sbin is
> before /usr/bin in $PATH.

Manually installing things in /usr/bin or /usr/sbin will often cause
problems because Portage assumes that it controls those directories.

So don't do that: you should manually install things in /usr/local.

Or, install qmail using portage, so that the system knows you have an
MTA. If you don't like the default qmail ebuild for some reason, you
can use your own.

Or, tell Portage you have an MTA by adding an appropriate line to
/etc/portage/profie/package.provided.  See portage(5).

Or, don't use Gentoo if you don't want to do things the way Gentoo
does things.

> Is this worth a bug report?

No.  It's not a bug its a user error.  There are a half-dozen
different ways to do the right thing, but you chose the wrong thing.

--
Grant

[gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Ian Zimmerman]

On 2018-07-21 23:04, Grant Edwards wrote:

> Manually installing things in /usr/bin or /usr/sbin will often cause
> problems because Portage assumes that it controls those directories.
> 
> So don't do that: you should manually install things in /usr/local.
> 
> Or, install qmail using portage, so that the system knows you have an
> MTA. If you don't like the default qmail ebuild for some reason, you
> can use your own.
> 
> Or, tell Portage you have an MTA by adding an appropriate line to
> /etc/portage/profie/package.provided.  See portage(5).
> 
> Or, don't use Gentoo if you don't want to do things the way Gentoo
> does things.

I agree than one should not normally install hand-compiled programs in
the normal directories controlled by portage.  I can see how the case of
MTA can tempt someone into violating that rule, though:  unlike most of
all other cases where a program is called by other programs, the path to
/usr/sbin/sendmail is usually hardcoded, and there is no well known
environment variable either (like EDITOR or PAGER). mutt has a runtime
configuration option for the MTA but that's unusual.

In fact, I myself am guilty of the corresponding sin on my Debian
server: I want to run the latest version of my pet MTA, exim, and with
the features I choose, so hand compiling is the only way.  And this week
it backfired on me too:  I carelessly installed some package that
depended on a MTA - and boom, /usr/sbin/sendmail, which had been a
symlink to /opt/exim/bin/exim, was overwritten by something like
nullmailer.

The /usr/sbin/sendmail convention is one of the parts of Unix that,
honestly, sucks.  With repeated and prolonged exposure one can get
irritated enough to turn Poettering :-P

On Gentoo the best way is to make your own package from your favorite
MTA _and_ your own virtual/mta, and make both available in a local repo.
Recently I discovered dma[1] which IMHO is the _best_ lightweight MTA
for client machines, so now I have a Gentoo package for it.

[1]
https://github.com/corecode/dma/

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[François-Xavier CARTON]

Le 22/07/2018 à 00:10, Mike Gilbert a écrit :
> On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie <acm@muc.de> wrote:
>> Hello, Gentoo.
>>
>> Right at the moment, I feel a lot of sympathy with Alan Grimes, and need
>> a lot of restraint in avoiding the use of swear words in describing some
>> Gentoo developer.
>>
>> ...
>>
>> nullmailer installs a file /usr/sbin/sendmail.  This masks out the
>> correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I
>> installed by hand, not using emerge) because /usr/sbin is before
>> /usr/bin in $PATH.
>>
>> ...
>>
>> But what's the proper method to tell my gentoo system that I don't want
>> crud like nullmailer installed?  How can I guard myself against such
>> presumptiousness on the part of the Gentoo devs in the future?
> 
> You must have installed a package that depends on virtual/mta,
> presumably because it needs to send emails. Had you installed qmail
> using portage, the virtual/mta dep would have been satisfied by it,
> and nullmailer would not have been installed in the first place.
> However, you didn't do that, and so portage had no idea qmail was
> installed.
> 
> A possible workaround would be to add mail-mta/netqmail to
> package.provided on your system. However, there's still no guarantee
> that your custom-built qmail software will work with other packages
> provided by Gentoo.
> 
> Regarding your accusations: Gentoo developers cannot anticipate every
> possible thing you might do on your system, especially when you start
> installing custom programs in paths that are traditionally managed by
> our package manager. Using portage you can customize your system
> extensively, without needing to custom build your own software. If
> that's not good enough for you, go build a Linux from Scratch system
> and enjoy the lack of any package management or support whatsoever.
> 
> 

I was also surprised to see the installation of a mta in an emerge 
update, so I masked virtual/mta to see why this dependency was pulled. 
It turns out that app-crypt/gnupg depends on virtual/mta since version 
2.2.6.

Now the question is, why does gpg need a mta?

Re: [gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Kai Peter]

On 2018-07-22 04:11, Ian Zimmerman wrote:
> On 2018-07-21 23:04, Grant Edwards wrote:
> 
>> Manually installing things in /usr/bin or /usr/sbin will often cause
>> problems because Portage assumes that it controls those directories.
>> 
>> So don't do that: you should manually install things in /usr/local.
>> 
>> Or, install qmail using portage, so that the system knows you have an
>> MTA. If you don't like the default qand make both available in a local 
>> repo.mail ebuild for some reason, you
>> can use your own.
>> 
>> Or, tell Portage you have an MTA by adding an appropriate line to
>> /etc/portage/profie/package.provided.  See portage(5).
>> 
>> Or, don't use Gentoo if you don't want to do things the way Gentoo
>> does things.
> 
> I agree than one should not normally install hand-compiled programs in
> the normal directories controlled by portage.  I can see how the case 
> of

+1, this should (MUST) be a general rule.

> MTA can tempt someone into violating that rule, though:  unlike most of
> all other cases where a program is called by other programs, the path 
> to
> /usr/sbin/sendmail is usually hardcoded, and there is no well known
> environment variable either (like EDITOR or PAGER). mutt has a runtime
> configuration option for the MTA but that's unusual.

> The /usr/sbin/sendmail convention is one of the parts of Unix that,
> honestly, sucks.  With repeated and prolonged exposure one can get
> irritated enough to turn Poettering :-P

Really true, but it is like it is :(
> 
> On Gentoo the best way is to make your own package from your favorite

The effort for an ebuild of an individual package is usually to high.

> MTA _and_ your own virtual/mta, and make both available in a local 
> repo.
> Recently I discovered dma[1] which IMHO is the _best_ lightweight MTA
> for client machines, so now I have a Gentoo package for it.

A bit more easier is to create an 'empty' virtual ebuild which at least 
does nothing but tells portage the dependency is fulfilled. This can be 
done in general for each unwanted dependency/package. For sure 
self-compiled programs have to be installed outside of portage 
controlled directories.

Alternative one can use in this particular case nail (or mailx) to 
fulfil the virtual/mta dep. It doesn't listen on port(s), provides all 
expected binaries and usually doesn't conflict with an individual mta. 
As a side effect scripts can be written more portable.


-- 
Sent with eQmail-1.11 beta - a fork of the djb's famous qmail

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Alan Mackenzie]

On Sun, Jul 22, 2018 at 07:46:47 +0200, François-Xavier CARTON wrote:

> I was also surprised to see the installation of a mta in an emerge 
> update, so I masked virtual/mta to see why this dependency was pulled. 
> It turns out that app-crypt/gnupg depends on virtual/mta since version 
> 2.2.6.

Yes.  This was indeed the package (well, version 2.2.8) whose
installation in June pulled in virtual/mta.

> Now the question is, why does gpg need a mta?

It surely doesn't.  This is surely a bug.  One can picture a highly
secure environment where encrypted email arrives on one box, and is
transferred to another, disconnected, box for decryption.  Here it is
essential that no MTA exists on the box that uses gnupg.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Ralph Seichter]

On 22.07.2018 09:27, Kai Peter wrote:

> A bit more easier is to create an 'empty' virtual ebuild which at
> least does nothing but tells portage the dependency is fulfilled.

Not a good choice, IMO. Portage has its own mechanism for that:
https://wiki.gentoo.org/wiki//etc/portage/profile/package.provided

-Ralph

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Alan Mackenzie]

On Sat, Jul 21, 2018 at 18:10:58 -0400, Mike Gilbert wrote:
> On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie <acm@muc.de> wrote:
> > Hello, Gentoo.

> > Right at the moment, I feel a lot of sympathy with Alan Grimes, and need
> > a lot of restraint in avoiding the use of swear words in describing some
> > Gentoo developer.

> > ...

> > nullmailer installs a file /usr/sbin/sendmail.  This masks out the
> > correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I
> > installed by hand, not using emerge) because /usr/sbin is before
> > /usr/bin in $PATH.

> > ...

> > But what's the proper method to tell my gentoo system that I don't want
> > crud like nullmailer installed?  How can I guard myself against such
> > presumptiousness on the part of the Gentoo devs in the future?

Apologies to the maintainers and users of nullmailer.  I didn't mean to
say what I said about it, and I'm sure it's a perfectly good package.

> You must have installed a package that depends on virtual/mta,
> presumably because it needs to send emails.

The package was gnupg, which surely doesn't need to send email.

> Had you installed qmail using portage, the virtual/mta dep would have
> been satisfied by it, and nullmailer would not have been installed in
> the first place.  However, you didn't do that, and so portage had no
> idea qmail was installed.

qmail suffered long from a "non-standard" copyright, where modified
versions could not be circulated.  Instead, the original sources
together with (lots of) patches did the rounds.  About a decade ago, the
author of Qmail, Daniel Berstein, put it into the public domain.  Two or
three people, independently, have gathered the fragments into coherent
packages and done things like ading IPv6, one of them being Erwin
Hoffmann's s/qmail, which I use.  None of these packages have Gentoo
ebuilds.

> A possible workaround would be to add mail-mta/netqmail to
> package.provided on your system. However, there's still no guarantee
> that your custom-built qmail software will work with other packages
> provided by Gentoo.

Thanks, I didn't know about package.provided.  It's not quite ideal, but
suffices as a workaround.  What's suboptimal about it is that you can
only specify particular versions of packages, not the package as such.
So, if I put

    virtual/mta-1

into my package.provided, I'm going to suffer again in the same way when
somebody releases virtual/mta-2.  As a workaround, my p.p. looks like
this:

    virtual/mta-0
    virtual/mta-1
    virtual/mta-1.1
    virtual/mta-1.2
    virtual/mta-2
    virtual/mta-2.1
    virtual/mta-2.2
    virtual/mta-3
    virtual/mta-3.1
    virtual/mta-3.2
    virtual/mta-4
    virtual/mta-4.1
    virtual/mta-4.2
    virtual/mta-5
    virtual/mta-5.1
    virtual/mta-5.2
    virtual/mta-6
    virtual/mta-6.1
    virtual/mta-6.2

, which should protect me for quite a few years.

> Regarding your accusations: Gentoo developers cannot anticipate every
> possible thing you might do on your system, especially when you start
> installing custom programs in paths that are traditionally managed by
> our package manager. Using portage you can customize your system
> extensively, without needing to custom build your own software.

Life is not so simple, but I take the point.  s/qmail had no option to
build into /usr/local, and I didn't perceive any particular need to try
to move it by hand.

> If that's not good enough for you, go build a Linux from Scratch
> system and enjoy the lack of any package management or support
> whatsoever.

That's the other extreme.

Thanks for the reply.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Alan Mackenzie]

Hello, Ralph.

On Sun, Jul 22, 2018 at 00:20:02 +0200, Ralph Seichter wrote:
> On 21.07.2018 23:03, Alan Mackenzie wrote:

> Install an MTA using emerge, or let Gentoo know that you have installed
> qmail manually. When you work around portage, you are responsible to
> keep Gentoo happy in terms of dependencies. Gentoo did not "foul up",
> you just tried to be a tricksy fellow, unaware of the consequences. ;-)

Gentoo didn't "foul up" as such, but it did "foul up my MTA" because I
didn't know how to tell it not to.  package.provided is documented on
the portage man page, but this is difficult to find, unless you already
know what you're looking for.  I don't think there's a section entitled
"Including non-portage packages in Gentoo" or the like, in any
documentation page.

> -Ralph

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Rich Freeman]

On Sun, Jul 22, 2018 at 6:57 AM Alan Mackenzie <acm@muc.de> wrote:
>
> On Sat, Jul 21, 2018 at 18:10:58 -0400, Mike Gilbert wrote:
>
> Apologies to the maintainers and users of nullmailer.

Yeah, there is nothing wrong with nullmailer.  It is a minimalist MTA
for systems where you just want to relay mail to another host without
running a full MTA.

> > You must have installed a package that depends on virtual/mta,
> > presumably because it needs to send emails.
>
> The package was gnupg, which surely doesn't need to send email.
>

https://wiki.gnupg.org/WKS
https://bugs.gentoo.org/658164

(The latter ironically has yet another person not using
package.provided - this one should know better...  Plus, you really
don't want to have a system without any MTA - in your case you had
installed one outside of portage, but if you don't have any that is
what nullmailer is for.)

>
> Thanks, I didn't know about package.provided.  It's not quite ideal, but
> suffices as a workaround.  What's suboptimal about it is that you can
> only specify particular versions of packages, not the package as such.
> So, if I put
>
>     virtual/mta-1
>
> into my package.provided, I'm going to suffer again in the same way when
> somebody releases virtual/mta-2.  As a workaround, my p.p. looks like
> this:

So, two things:

First, it is probably better to put one of the qmail variants in your
package.provided and not virtual/mta-1.  I believe that will actually
block stuff that interferes with qmail instead of merely making it
less likely for an MTA to be pulled in.

Nobody should be depending on a specific version of virtual/mta unless
there is something wrong with the packages in the previous versions.
If there is something wrong with those packages, then there is
probably something wrong with your configuration which you would want
to know.  Since you've put qmail in your packages.provided you'll
actually get blockers instead of portage just walking over your stuff.

You should also be installing qmail in /usr/local so that you don't
have files getting overwritten by portage.  You'll still have the path
concerns but in general you shouldn't be writing to /usr without the
package manager.  You get to keep the pieces if it happily overwrites
your stuff from time to time otherwise.

-- 
Rich

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Mike Gilbert]

On Sun, Jul 22, 2018 at 6:57 AM, Alan Mackenzie <acm@muc.de> wrote:
> The package was gnupg, which surely doesn't need to send email.

See bug 658164. It's not quite that straightforward. ;)

https://bugs.gentoo.org/658164

[gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Nikos Chantziaras]

On 22/07/18 00:03, Alan Mackenzie wrote:
> But what's the proper method to tell my gentoo system that I don't want
> crud like nullmailer installed?  How can I guard myself against such
> presumptiousness on the part of the Gentoo devs in the future?

By reading the output of "emerge --ask <...>" next time.

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Walter Dnes]

On Sun, Jul 22, 2018 at 08:53:44AM -0400, Rich Freeman wrote
> On Sun, Jul 22, 2018 at 6:57 AM Alan Mackenzie <acm@muc.de> wrote:
> 
> Yeah, there is nothing wrong with nullmailer.  It is a minimalist MTA
> for systems where you just want to relay mail to another host without
> running a full MTA.

  The problem is brain-dead packages which gratuitously pull in an mta
because they "might" need one in certain edge cases that most people do
not use them for.

> 
> > > You must have installed a package that depends on virtual/mta,
> > > presumably because it needs to send emails.
> >
> > The package was gnupg, which surely doesn't need to send email.
> >
> 
> https://wiki.gnupg.org/WKS
> https://bugs.gentoo.org/658164

######################################################
emerge -pv gnupg

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] app-crypt/gnupg-2.2.8::gentoo  USE="bzip2 readline smartcard ssl -doc -ldap -nls (-selinux) -tofu -tools -usb -wks-server" 0 KiB
######################################################

  On my system, gnupg has the "-wks-server" USE flag, but it is still
hard-coded to depend on mta-1.  procmail also pulls in mta-1, even
though I only use it to filter incoming email.

> Plus, you really don't want to have a system without any MTA -

  That should be my decision.

> in your case you had installed one outside of portage, but if you
> don't have any that is what nullmailer is for.)

  There was already a /usr/sbin/sendmail symlink, as the OP pointed out.
Is there a way to make the presence of that file satisfy mta-1?

  Speaking of "sendmail" symlinks, I do ***NOT*** want them.  My most
embaressing linux moment occured years ago at a more newbie stage, when
a chatty cron job started spewing stuff to root.  ssmtp does one thing;
it forwards emails to my ISP's mta for dispatch.  I was more of a newbie
back the, and din't realise that ssmtp splatters symlinks all over the
place...

/usr/bin/sendmail
/usr/lib64/sendmail (64-bit systems)
/usr/lib/sendmail (32-bit systems)
/usr/sbin/sendmail

  I wasn't aware of filtering outbound email by UID.  Net result;
cronjob spam ended up going to root@<my ISP>.  Not appreciated.  I
eventually figured this out, and took the following safety precaution...

######################################################
#!/bin/bash
rm -rf /usr/bin/sendmail
rm -rf /usr/lib64/sendmail
rm -rf /usr/lib/sendmail
rm -rf /usr/sbin/sendmail

mkdir /usr/bin/sendmail
touch /usr/bin/sendmail/.keep
mkdir /usr/lib64/sendmail
touch /usr/lib64/sendmail/.keep
mkdir /usr/lib/sendmail
touch /usr/lib/sendmail/.keep
mkdir /usr/sbin/sendmail
touch /usr/sbin/sendmail/.keep
######################################################

  This blocked the creation of sendmail symlinks.  I "lived happily ever
after"... until Portage changed policy to fail hard when it couldn't
create the symlinks.  So an @world update dies in the middle.  Now, if a
"-pv" run shows that ssmtp will be updated, I have to...

* "rm -rf" the "sendmail" directories
* emerge -1 ssmtp
* re-run the symlink-killer script
* do the @world update.

  Yes, I do filter emails for low UIDs now, but I like defense-in-depth.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Kai Peter]

On 2018-07-22 12:24, Ralph Seichter wrote:
> On 22.07.2018 09:27, Kai Peter wrote:
> 
>> A bit more easier is to create an 'empty' virtual ebuild which at
>> least does nothing but tells portage the dependency is fulfilled.
> 
> Not a good choice, IMO. Portage has its own mechanism for that:
> https://wiki.gentoo.org/wiki//etc/portage/profile/package.provided
> 
> -Ralph

It was related to Ian's suggestion of an extra ebuild. And 
package.provided have to be configured at each host by hand wich is a 
big effort if you have a lot of boxes.
-- 
Sent with eQmail-1.11 beta - a fork of the djb's famous qmail

Re: [gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Ralph Seichter]

On 23.07.2018 08:56, Kai Peter wrote:

> package.provided have to be configured at each host by hand wich is a
> big effort if you have a lot of boxes.

I call that nonsense. How is that an effort, especially if the proposed
alternative is installing a do-nothing ebuild on "a lot of boxes"?

"He who cannot be bothered to add an entry to a text file should not
administer Linux systems." (Confucius)

-Ralph