Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
When exim is installed with mailwrapper support it overwrites mailq and newalaiiases symbolic links to the exim binary. They should point to /usr/sbin/sendmail instead which is the mailwrapper binary that will point to exim via /etc/mail/mailer.conf. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Mass re-assign, maintainer to whom this bug was assigned seems inactive.
It's the same with postfix too :-(
Same over here, also with postfix.
Over two years later... <snip> dosym ../sbin/exim /usr/bin/mailq dosym ../sbin/exim /usr/bin/newaliases </snip> This must be a bad joke, I guess...
Colin, are you ignoring the bugs on purpose or what? The latest ebuild you've added ~2 weeks ago *still* messes with mailwrapper in this stupid way. :-( This bug has been sitting here for over two years, so I'd at minimum expect that you won't keep bringing on this borkage into more and more versions. If you are not sure how mailwrapper works, ask some other net-mail folk for help.
(In reply to comment #4) > Over two years later... > > <snip> > dosym ../sbin/exim /usr/bin/mailq > dosym ../sbin/exim /usr/bin/newaliases > </snip> > > This must be a bad joke, I guess... > no, just the wrong fix. The correct fix is to rely on mailer.conf to handle the wrappings, which will be available from 4.67-r1, apologies for it not going in sooner.
fix is in the tree, shout if there are any issues. I'll close this bug some time next week if this fix doesn't work.
*** Bug 189660 has been marked as a duplicate of this bug. ***
This ebuild still gets mailwrapper support wrong. <snip> if \[ ! -e /usr/lib/sendmail \]; then dosym /usr/sbin/sendmail /usr/lib/sendmail fi </snip> This should be handled by mailwrapper use flag instead of checking whether the file exists or not (plus why's the escaping there, BTW?)
(In reply to comment #9) > This ebuild still gets mailwrapper support wrong. > > <snip> > if \[ ! -e /usr/lib/sendmail \]; > then > dosym /usr/sbin/sendmail /usr/lib/sendmail > fi > </snip> > > This should be handled by mailwrapper use flag instead of checking whether the > file exists or not arugebly if the file isn't there, then it should be linked to mailwrapper, but if mailwrapper isn't there, it should default to the MTA. > (plus why's the escaping there, BTW?) > I _think_ it came in from a submitted patch for mailwrapper support, it appears to come in with exim 4.40 specifically, https://bugs.gentoo.org/show_bug.cgi?id=28665 although it was a number of years ago.
If the file is there, you are missing a blocker on something.
(In reply to comment #11) > If the file is there, you are missing a blocker on something. > no, if there is a file there, then I agree there is a problem, but that problem is external to exim. exim does correctly block with ssmtp. However, i do not see any problem with not over-writing /usr/lib/sendmail if it does already exist. Afterall, the user may have put that link in for a very explict reason. I will however fix the escaping and add an einfo/ewarn as appropriate
(In reply to comment #12) > no, if there is a file there, then I agree there is a problem, but that problem > is external to exim. exim does correctly block with ssmtp. How's ssmtp relevant here? <snip> !mailwrapper? ( !virtual/mta ) </snip> That USE=mailwrapper is all that matters here, not whether some file exists or not. It shouldn't exist in the first place if you allow users to emerge this, if it does, the above blocker doesn't work and you have a problem somewhere else.
(In reply to comment #13) > (In reply to comment #12) > > no, if there is a file there, then I agree there is a problem, but that problem > > is external to exim. exim does correctly block with ssmtp. > > How's ssmtp relevant here? > ssmtp is the default, I'm assuming, and it appears to be true, that the other major mailers, postfix, qmail, sendmail all appeared to block correctly last time i checked. > <snip> > !mailwrapper? ( !virtual/mta ) > </snip> > > That USE=mailwrapper is all that matters here, not whether some file exists or > not. It shouldn't exist in the first place if you allow users to emerge this, > if it does, the above blocker doesn't work and you have a problem somewhere > else. > there should be a mailwrapper check around the sendmail link as well, the issue inquestion, (one of the reasons you re-opened this bug) was due to a user with out /usr/<foo>/sendmail when mailwrapper wasn't installed.
(In reply to comment #14) > there should be a mailwrapper check around the sendmail link as well, the issue > inquestion, (one of the reasons you re-opened this bug) was due to a user with > out /usr/<foo>/sendmail when mailwrapper wasn't installed. mailwrapper one, yeah absolutely. :) But not if [ ! -e /usr/lib/sendmail ] one, i.e., move this to the else section of if use mailwrapper ; then ...
So, what's going on here peitholm? Can we look forward to havign this fixed soon? :)
yes, at some point
(In reply to comment #17) > yes, at some point > And since this bug has been open for almost 2 years now, can we have an ETA for what "some point" will be?
Probably the next time I make a commit to the tree, which will be with the next release of exim, as you say this has been 'broken' for 2 years, and it's now an edge case afaics.
And this is *still* broken in 4.69-r1... LMAO! $ diff -Nau exim-4.69{,-r1}.ebuild <snip> @@ -245,7 +245,7 @@ fperms 4755 /usr/sbin/exim dodir /usr/bin /usr/sbin /usr/lib - if \[ ! -e /usr/lib/sendmail \]; + if [ ! -e /usr/lib/sendmail ]; then dosym /usr/sbin/sendmail /usr/lib/sendmail fi </snip> 4.69-r1 is masked with the following reason: # Colin Morey <peitolm@gentoo.org> (20 Mar 2008) # Masked for testing, closing lots of little bugs =mail-mta/exim-4.69-r1 Well, beyond the above diff, there's just *one* change, which in turn leaves mbox use flag completely unused, yet still lingering in IUSE. <snip> @@ -55,7 +55,7 @@ epatch "${FILESDIR}"/exim-4.14-tail.patch epatch "${FILESDIR}"/exim-4.43-r2-localscan_dlopen.patch - if ! use mbox; then + if use maildir; then einfo "Patching maildir support into exim.conf" epatch "${FILESDIR}"/exim-4.20-maildir.patch fi </snip> Let me restate for the last time: 1/ *no* other ebuild with mailwrapper support installs /usr/lib/sendmail symlink when USE=mailwrapper is set. If it did, then you'd have huge number of collisions in the tree obviously. 2/ If everyone did what this ebuild does, people with multiple MTAs installed would have /usr/lib/sendmail pointing to $random MTA based on which MTA did they install first, such mess is definitely not something intended. 3/ *no* other ebuild does install the symlink when mailwrapper use flag is disabled based on checking whether /usr/lib/sendmail exists or not, since: - it shouldn't exist in the first place or you'll again get collisions again; - plus you'll get inconsistencies/potential borkage as you have no clue where does the symlink point to (or whether it's pointing to non-existent place even) and what left it there. To conclude: This bug has been open for over three years now. Instead of getting it finally fixed, I'm being told to boil my head in Bug 189660 Comment #10, and getting blamed for peitolm's 'retirement'. Well since he's stated he's going to retire at the end of February - "once (he's) cleared up the outstanding bugs" - on Bug 203843 Comment #5, I guess we can expect that to happen around February 2015 or so. There're 11 exim bugs open, out of which 8 are over one year old - http://tinyurl.com/2qpkjj Have a nice day.
jakub, perhaps you failed to even consider why that ebuild was committed? no, i thought not. that -r1 ebuild is a work-in-progress, that's why it's pmasked. If you even paid attention to the rest of the changes, then perhaps you might have understood, but hey, maybe you can't read beyond what you want to read. (perhaps the Changelog diff isn't something you read? http://sources.gentoo.org/viewcvs.py/gentoo-x86/mail-mta/exim/ChangeLog?r1=1.120&r2=1.121 might just fill you in on that particular commit) and go back and read the rest of the discussion as to your broken argument. I've already agreed that the test would be better move, I just haven't done it yet. and you don't get collision, go and try it. All I've seen from you is attacks and untested suggestions. and yes, you're the reason I'm leaving, I've run out of patience with you. This is one of the bugs I aim to close. I'm assuming you're trying to wind me up, and congratulations you've succeeded. Have a nice day indeed.
I am now watching this bug and discussion for devrel. Jakub, as you see, the version you are commenting on is in package.mask, and Colin calls this a work in progress. Please respect that and refrain from commenting while such is the case. Mark, does this present a problem for you? And for both of you, Colin says he is planning a new release; please take him at his word.
(In reply to comment #22) > Jakub, as you see, the version you are commenting on is in package.mask, and > Colin calls this a work in progress. Please respect that and refrain from > commenting while such is the case. This has been a 'work in progress' for three years; if a developer is unable to fix a trivial obvious issue for three years and instead of fixing bugs keeps complaining to devrel, kicking around, re-assigning bugs to himself to ignore them for another year and doing a similar nonsense, I'd suggest that he should retire or be retired. An amount of contribution done for Gentoo by peitolm doesn't require a developer status at all. http://cia.vc/stats/author/peitolm
(In reply to comment #21) > I've already agreed that the test would be better move, I just haven't done it > yet. It only took 3+ years so far, what are we waiting for? Godot perhaps? > and you don't get collision, go and try it. All I've seen from you is attacks > and untested suggestions. I'd suggest you should re-read Comment #20 so that you respond to real issues and not ones that noone's claimed and noone's suggested in this debate. You have not addressed a single out of the many arguments there which explain why the current behavior is plain broken. > and yes, you're the reason I'm leaving, I've run out of patience with you. > This is one of the bugs I aim to close. So close it... here's the recipe, hasn't changed ever since this bug has been filed - check the USE flag, not the symlink. Exactly like all the rest of MTAs in the tree do. <snip> --- exim/exim-4.69-r1.ebuild 2008-03-20 20:13:06.000000000 +0100 +++ exim-4.69-r1.ebuild 2008-03-24 21:24:16.000000000 +0100 @@ -245,10 +245,6 @@ fperms 4755 /usr/sbin/exim dodir /usr/bin /usr/sbin /usr/lib - if [ ! -e /usr/lib/sendmail ]; - then - dosym /usr/sbin/sendmail /usr/lib/sendmail - fi if use mailwrapper then @@ -256,6 +252,7 @@ doins "${FILESDIR}"/mailer.conf else dosym exim /usr/sbin/sendmail + dosym /usr/sbin/sendmail /usr/lib/sendmail dosym /usr/sbin/exim /usr/bin/mailq dosym /usr/sbin/exim /usr/bin/newaliases einfo "The Exim ebuild will no longer touch /usr/bin/mail, so as not to interfere with mailx/nail." </snip> If you want a /usr/lib/sendmail symlink, it belongs to mailwrapper and nowhere else for numerous reasons stated in Comment #20 and previous ones.
(In reply to comment #24) > (In reply to comment #21) > > and you don't get collision, go and try it. All I've seen from you is attacks > > and untested suggestions. > > I'd suggest you should re-read Comment #20 so that you respond to real issues > and not ones that noone's claimed and noone's suggested in this debate. You > have not addressed a single out of the many arguments there which explain why > the current behavior is plain broken. o.k. then, so let's go through them as I disagree that I have not addressed any of your arguements (In reply to comment #20) > And this is *still* broken in 4.69-r1... LMAO! > I never claimed to have fixed in the commit for 4.69-r1, but that has already been dealt with in comments #21 and #22. And exim-4.69-r1 is a work-in-progress ebuild, i'm fixing a lot of things with it as I've said before. > 1/ *no* other ebuild with mailwrapper support installs /usr/lib/sendmail > symlink when USE=mailwrapper is set. If it did, then you'd have huge number of > collisions in the tree obviously. I have tested this, and I don't get collisions, so unless you can provide me with a full test case to replicate these collisions you believe will happen, then I don't accept that they will happen. > > 2/ If everyone did what this ebuild does, people with multiple MTAs installed > would have /usr/lib/sendmail pointing to $random MTA based on which MTA did > they install first, such mess is definitely not something intended. > Not true, if the symlink exists, then the ebuild would _not_ modify it, (which causes #189660), so, if _every_ MTA did the check, they would all respect the symlink put in place by first MTA (or the user). Without the check, then the _last_ MTA to be installed would be modifying the symlink. I believe people with multiple MTA usually a) know what they are doing b) use mailwrapper. A valid case would be a server which runs exim on some public interfaces and qmail on others, with exim chosen for local handling as well. > 3/ *no* other ebuild does install the symlink when mailwrapper use flag is > disabled based on checking whether /usr/lib/sendmail exists or not, since: > - it shouldn't exist in the first place or you'll again get collisions again; I can think of two situations where it will exist, both of which need to be handled. 1) A User migrates from non-mailwrapper to mailwrapper. 2) A User installs the symlink themselves. > - plus you'll get inconsistencies/potential borkage as you have no clue where > does the symlink point to (or whether it's pointing to non-existent place even) > and what left it there. As in the two cases above 1) An upgrade, the symlink should point to a sane place 2) The user should know. > To conclude: > > This bug has been open for over three years now. Instead of getting it finally > fixed, I'm being told to boil my head in Bug 189660 Comment #10, Yes, because it feels like every time I commit to the tree, I get abuse from you. I Considered the original bug "exim with mailwrapper support overwrites mailq/newaliases symlinks" closeable on 2007-05-31 23:09:39 0000, And then at 2007-08-21 06:11:31 0000 You marked 189660 a duplicate of this bug, and changed the title to "mail-mta/exim needs proper mailwrapper support" with the comment "This ebuild still gets mailwrapper support wrong. " Which isn't what the duplicate bug was about. So, yes, _this_ bug has been opened for nearly 3 years, however it has changed to a different bug in that time, after being marked ready for closure. I believe it should be considered 2 different bugs. >and getting blamed for peitolm's 'retirement'. Well since he's stated he's going to retire > at the end of February - "once (he's) cleared up the outstanding bugs" - on Bug > 203843 Comment #5, I guess we can expect that to happen around February 2015 or > so. I Consider that a particularly harsh statement. I will re-iterate this again. I accept that the symlink test is in the wrong place, (#14, and you agree in #15). I make no claim to have moved it, and will not until I am satisfied that the fix is correct for #189660 as well.
Is it true that this is _still_ an issue? How long is mailwrapper in the tree? my recent exim upgrade again missed to create the symlinks...
(In reply to comment #26) > Is it true that this is _still_ an issue? How long is mailwrapper in the tree? > my recent exim upgrade again missed to create the symlinks... > Hi Christian, What version(s) are you trying to use? and what do you have in your USE variables? You state you did an upgrade of exim,.. are you experiencing the same symptoms as http://bugs.gentoo.org/show_bug.cgi?id=189660 ? if so, please check comments 7 and 8 in that bug. Cheers, Colin Morey
[ebuild R ] mail-mta/exim-4.69 USE="exiscan-acl ipv6 ldap mailwrapper pam perl ssl tcpd -X -dnsdb -domainkeys -dovecot-sasl -exiscan -gnutls -lmtp -mbox -mbx -mysql -nis -postgres -radius -sasl -spf -sqlite -srs -syslog" 0 kB What I experience is that exim does not create any symlink to the mailwrapper binary.
(In reply to comment #28) > What I experience is that exim does not create any symlink to the mailwrapper > binary. with mailwrapper in USE, all symlinks should be handled by the mailwrapper tool, not by the MTA At some point I think you may have had mailwrapper installed, then emerge'd an MTA without Mailwrapper support, then removed that MTA (either by upgrade or whatever). (for example ssmtp) Can you confirm you have mailwrapper installed?, (and which version it is) also, what's the output of 'grep exim /etc/mail/mailer.conf'
[ebuild R ] net-mail/mailwrapper-0.2.1 0 kB % equery f mailwrapper [ Searching for packages matching mailwrapper... ] * Contents of net-mail/mailwrapper-0.2.1: /etc /etc/mail /etc/mail/mailer.conf /usr /usr/sbin /usr/sbin/sendmail /usr/share /usr/share/man /usr/share/man/man5 /usr/share/man/man5/mailer.conf.5.bz2 /usr/share/man/man8 /usr/share/man/man8/mailwrapper.8.bz2 % equery b /etc/mail/mailer.conf [ Searching for file(s) /etc/mail/mailer.conf in *... ] mail-mta/exim-4.69 (/etc/mail/mailer.conf) net-mail/mailwrapper-0.2.1 (/etc/mail/mailer.conf) % cat /etc/mail/mailer.conf # Execute the "real" sendmail program from exim, # named /usr/sbin/exim # sendmail /usr/sbin/exim mailq /usr/sbin/exim newaliases /usr/sbin/exim rmail /usr/sbin/exim send-mail /usr/sbin/exim rsmtp /usr/sbin/exim mail /usr/sbin/exim
(In reply to comment #30) > [ebuild R ] net-mail/mailwrapper-0.2.1 0 kB > o.k. try net-mail/mailwrapper-0.2.1-r1 it should be putting the rest of the symlinks in. == src_install() { dodir /usr/sbin /usr/bin /usr/lib newsbin mailwrapper sendmail || die "mailwrapper binary not installed" dohard /usr/sbin/sendmail /usr/bin/newaliases dohard /usr/sbin/sendmail /usr/bin/mailq dohard /usr/sbin/sendmail /usr/bin/rmail dosym /usr/sbin/sendmail /usr/lib/sendmail dosym /usr/sbin/sendmail /usr/bin/sendmail doman mailer.conf.5 mailwrapper.8 } == although it's packaged masked, so you may have to unmask it, or create the symlinks yourself, either way, those symlinks are under the control of mailwrapper, if you want the exim ebuild to deal with them, remove mailwrapper from USE.
