Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.
On Sun, Jul 22, 2018 at 08:53:44AM -0400, Rich Freeman wrote > On Sun, Jul 22, 2018 at 6:57 AM Alan Mackenzie 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@. 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 I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.
On Sun, Jul 22, 2018 at 6:57 AM, Alan Mackenzie 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
Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.
On Sun, Jul 22, 2018 at 6:57 AM Alan Mackenzie 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.
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.
On Sat, Jul 21, 2018 at 18:10:58 -0400, Mike Gilbert wrote: > On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie 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.
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] Heads up: Gentoo fouls up mail transport agent.
Le 22/07/2018 à 00:10, Mike Gilbert a écrit : On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie 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] Heads up: Gentoo fouls up mail transport agent.
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
Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.
On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie 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.
[gentoo-user] Heads up: Gentoo fouls up mail transport agent.
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).
