'make delete-old' breaks local mail delivery with sendmail port

noodlefling

noodlefling

I recently rebuilt world after updating to 9.1-RELEASE-p4 from 9.1-RELEASE-p3 and working through the process, I followed the make delete-old step.

This deleted a bunch of Sendmail stuff, which seemed a little scary, but made sense since I'm using a Sendmail port and not the base installation.

I've got this in /etc/rc.conf
Code: 
sendmail_enable="YES"

and this in /etc/make.conf
Code: 
NO_SENDMAIL=TRUE

Immediately after updating, I started to get this error in /var/log/maillog
Code: 
Cannot exec /usr/libexec/mail.local: No such file or directory

That's not totally unexpected given that I just deleted the file, but going to /etc/mail and doing a make did not produce a cf file with the correct location for mail.local. It should be /usr/local/libexec/mail.local but it showed the old location at /usr/libexec/mail.local

I changed the value of Mlocal in /etc/mail/sendmail.cf and all seems well, but it looks like this change will get lost next time I update the Sendmail port.

Any suggestions for the proper way to solve this problem, so I don't accidentally blast it later?
 
I think
Code: 
NO_SENDMAIL=TRUE
is only for port mail/sendmail. In any case, use make.conf for ports and src.conf for world. If you don't want it to be included in your base system installation, you have to read src.conf(5)(). There you can find, that the appropriate way to do it, is merely define a variable WITHOUT_SENDMAIL. It can have any value, merely the definition of the variable will trigger the desired effect, so you can just write
Code: 
WITHOUT_SENDMAIL=yes
in your /etc/src.conf.

You said you're using the sendmail port. So read the contents of /usr/ports/mail/sendmail/pkg-message (you can view it on-line here). There you have clearly described, that you have to define
Code: 
SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf
in your /etc/make.conf and edit your /etc/mailer.conf to contain these lines
Code: 
sendmail         /usr/local/sbin/sendmail
send-mail        /usr/local/sbin/sendmail
mailq            /usr/local/sbin/sendmail
newaliases       /usr/local/sbin/sendmail
hoststat         /usr/local/sbin/sendmail
purgestat        /usr/local/sbin/sendmail

and to use the port's mailer, you shouldn't run # make in /etc, but # make -C /usr/ports/mail/sendmail mailer.conf, and optionally edit a bunch of other files. It's all in the instructions.

It seems you've been using the base system sendmail all along, and now that you've deleted it, you're noticing it.

For further reference, what I like about ports is documentation. If you have to do extra configuration, always search for a pkg-message* file in the port's directory, or, after installing the port, in /usr/local/share/doc. devel/ccache is one such example.
 
jozze said:
I think
Code: 
NO_SENDMAIL=TRUE
is only for port mail/sendmail.
Click to expand...
Hmmm...my comments in make.conf say I put that there so Sendmail won't be remade during a make buildworld, but it does look like they were being recompiled each time. The only reason I can imagine adding that line is because the port told me to do it (via the pkg-message you mention), but that could have been a decade ago. I don't see any references to NO_SENDMAIL in the modern era, so that was probably deprecated a while ago.

Thanks for that clarification. I'll add a src.conf and see what happens in that department.

There you have clearly described, that you have to define
Code: 
SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf
in your /etc/make.conf and edit your /etc/mailer.conf to contain these lines
Code: 
sendmail         /usr/local/sbin/sendmail
send-mail        /usr/local/sbin/sendmail
mailq            /usr/local/sbin/sendmail
newaliases       /usr/local/sbin/sendmail
hoststat         /usr/local/sbin/sendmail
purgestat        /usr/local/sbin/sendmail
Click to expand...

I had those configured properly.

...you shouldn't run # make in /etc, but # make -C /usr/ports/mail/sendmail mailer.conf, and optionally edit a bunch of other files.
Click to expand...

/usr/ports/mail/sendmail feels like a weird and dangerously temporary place to be working on the .cf and .mc files, but I'll experiment.

It seems you've been using the base system sendmail all along, and now that you've deleted it, you're noticing it.
Click to expand...
What was actually happening was that I was using the port for regular mail and the system version for local delivery. That's confirmed in the email headers, which would show weird version numbering such as "(8.14.7/8.14.5)" when mailing myself. The make delete-old has forced some housecleaning, which is a good thing.
 
OK, I think I have answer my original question, although there is still a small mystery and something that should probably be changed with the Sendmail port.

Mystery first, if NO_SENDMAIL doesn't do anything, then why did make delete-old decide to delete /usr/libexec/mail.local in the first place?

Let's say it's clever enough to see I've got the Sendmail port installed. If that's the case, then the port should not try to use /usr/libexec/mail.local. Because the default understanding would be that if the port exists, then /usr/libexec/mail.local does not.

However, in /usr/local/share/sendmail/cf/README, I found this:
Code: 
local_lmtp      Use an LMTP capable local mailer.  The argument to this
                feature is the pathname of an LMTP capable mailer.  By
                default, mail.local is used.  This is expected to be the
                mail.local which came with the 8.9 distribution which is
                LMTP capable.  The path to mail.local is set by the
                confEBINDIR m4 variable -- making the default
                LOCAL_MAILER_PATH /usr/libexec/mail.local.
                ...

This did give me the answer to my original question, however, of how do I make it look in the right place and not forget about it the next time Sendmail is updated?

I added the following to /etc/mail/<hostname>.mc and did a make:
Code: 
define(`confEBINDIR', `/usr/local/libexec')dnl

This created an appropriate /etc/mail/<hostname>.cf which I manually copied to /etc/mail/sendmail.cf, then restarted Sendmail.

I've got an answer to my question, but should I point this out to the Sendmail port maintainer?
 
noodlefling said:
Mystery first, if NO_SENDMAIL doesn't do anything, then why did make delete-old decide to delete /usr/libexec/mail.local in the first place?

Let's say it's clever enough to see I've got the Sendmail port installed. If that's the case, then the port should not try to use /usr/libexec/mail.local. Because the default understanding would be that if the port exists, then /usr/libexec/mail.local does not.
Click to expand...
Maybe the variable was removed in a sloppy fashion, since the # make buildworld reads both make.conf and src.conf.
noodlefling said:
I've got an answer to my question, but should I point this out to the Sendmail port maintainer?
Click to expand...
Perhaps you could mail him on dinoex@FreeBSD.org.
 
Further investigation revealed that I did in fact have the following line in my /etc/mail/<hostname>.mc already!
Code: 
define(`confEBINDIR', `/usr/local/libexec')dnl

I must have done this in the past, based on the pkg-message instructions. However, it was towards the end of the .mc file and therefore did not work. It needs to be towards the top, probably above the following line:
Code: 
FEATURE(local_lmtp)

So, it turns out I had done things mostly right, but did not notice anything was broken in the past because the old mail.local was being used.

I've since rebuilt world without NO_SENDMAIL in /etc/make.conf and with WITHOUT_SENDMAIL in /etc/src.conf. mail.local was not rebuilt, but there is a fresh /usr/sbin/sendmail (which which sendmail finds first). I suppose this is fine, but somewhat unexpected.

So, the upshot of all of my noodling around might be simply that a note about placing the line in the .mc in the appropriate place might be a good idea. I've contacted the port manager and said as much.

Thanks for helping me work through all this.
 
Well, I checked what this /usr/sbin/sendmail actually is. As I suspected, command $ file /usr/sbin/sendmail reveals it's a soft link to a non-existing /usr/sbin/mailwrapper, so I'm pretty sure you can delete it. It should be removed with # yes | make delete-old, but I guess the developers overlooked it. Perhaps you could notify them and file a PR.
 
It seems that I have a /usr/sbin/mailwrapper but I notice that there's a WITHOUT_MAILWRAPPER option.

Looks like it's time to rebuild world again to test.
 
Well, first check your /etc/make.conf for a typo. Secondly, I have WITHOUT_MAIL enabled, and according to src.conf(5)() this option means both WITHOUT_MAILWRAPPER and WITHOUT_SENDMAIL are set. Since you won't be using the base system sendmail either, you can try perhaps with this option, and maybe you won't have /usr/sbin/mailwrapper file either.

If you are building your world often, consider installing devel/ccache and following this how-to to speed up the process.
 
It looks like rebuilding world is not necessary. make delete-old seems to function independently of the build process, so:
Code: 
# make check-old
>>> Checking for old files
/etc/mail/mailer.conf
/usr/sbin/mailwrapper
/usr/share/man/man8/mailwrapper.8.gz
/bin/rmail
The only change made to make the above happen was adding the WITHOUT_MAILWRAPPER to /etc/src.conf.

So that explains how it figured out what to delete. It must have been processing the original NO_SENDMAIL in /etc/make.conf, which is what started this issue in the first place.

Deleting /etc/mail/mailer.conf does seem a little scary, since it's one of those things I'm just used to seeing around, but if which can find the correct version, I should be OK.

Note that the /usr/sbin/sendmail symlink is not deleted. I wonder if rebuilding the world will result in that link being redirected. You'd think it would just disappear. I guess I'll have to find out.
 
Since you don't have any programs that require /usr/sbin/sendmail anymore, you should be fine with both keeping and deleting that symlink. I have decided to keep it anyway, and not fiddle too much with the system. And no, rebuilding world doesn't delete that symlink. I have it for months, and I rebuild world quite often (at least twice a week).

As for deleting /etc/mail/mailer.conf, it's okay if it's deleted, since anything that comes from ports uses the /usr/local prefix (at least by default) so "world" and "ports" don't mix. You should have a similar file in /usr/local/etc/mail directory. If it is indeed there, it's safe to delete the one present in /etc/mail (unless it's a symbolic link to /usr/local/etc/mail/mailer.conf which I think is unlikely, since FreeBSD is much stricter than Linux when it comes to obeying system hierarchy.
 
Right now, Sendmail just magically starts, because I have
Code: 
sendmail_enable="YES"
in /etc/rc.conf

How will the system know to use the port if /etc/mailer.conf is missing and there's actually something at /usr/sbin/sendmail which is just a symlink pointing to a missing file?

I don't have a /usr/local/etc/mail directory. It's not created by the port. I still do all my mail-related making in /etc/mail
 
Sorry to double-post, but the port maintainer responded and cleared up all my questions and misconceptions.

I'll summarize it all here so people who google this thread in the future will see the complete resolution.
  1. The original make delete-old mystery was how it knew to delete /usr/libexec/mail.local. The answer is that it checks /etc/make.conf and /etc/src.conf
  2. The proper method to prevent the base Sendmail from recompiling when you do a make buildworld is to add WITHOUT_SENDMAIL to /etc/src.conf.

    You should not use the WITHOUT_MAILWRAPPER flag, because this will cause /etc/mailer.conf to be deleted when you do a make delete-old and that is bad.

    The result of using only WITHOUT_SENDMAIL is that /usr/sbin/sendmail will continue to exist, but only as a symlink to /usr/sbin/mailwrapper. From man mailwrapper:
    Code: 
         The mailwrapper utility is designed to replace /usr/sbin/sendmail and to
     invoke an appropriate MTA instead of sendmail(8) based on configuration
     information placed in /etc/mail/mailer.conf.

    So, a) the symlink is correct and should continue to exist, and b) /etc/mailer.conf must exist or things will break. This is the magic that makes the Sendmail port work instead of the base Sendmail.

    Note that you don't actually have to do any of this to make the Sendmail port work. If you've followed all of the pkg-message instructions carefully, the Sendmail port will work properly and simply ignore the base version of Sendmail, even though parts of it will continue to exist in the base installation.
  3. The only reason I ran into this problem is because, even though I had followed the instructions in /usr/ports/mail/sendmail/pkg-message (which is displayed when you complete an installation of the port), I had put a necessary line in the wrong place in my config file. The port maintainer has updated the pkg-message instructions to clarify what you must do:
    Code: 
    To use the binaries supplied by the port you should add the following lines
to your sendmail.mc file before any mailer or feature definition:

define(`confEBINDIR', `%%PREFIX%%/libexec')dnl
define(`UUCP_MAILER_PATH', `%%LOCALBASE%%/bin/uux')dnl
    Note the "before any mailer or feature definition" clarification.
  4. After you carefully follow all of the instructions in pkg-message, you configure the Sendmail port in the same way you configure base installations of Sendmail -- by modifying configuration files (*.mc) in /etc/mail and then running make to produce appropriate *.cf files.

    That part is complicated, but if you knew how to do it with the base installation, configuring the port will be no different.
Whew.

Did I miss anything?
 
I think the reason we started using the port is that it was easier to update when there were security issues discovered with Sendmail. Now that I'm not so intimidated by rebuilding the world, maybe it doesn't make so much sense.

Hmmm...oh, you know, maybe it's because the base install doesn't do encryption and/or authentication? That sounds familiar. Maybe that's why.

Although the real answer is that I keep using it because we've done so for years. We wouldn't have started mucking around with the port for no reason, but I'm not sure if that reason still applies.
 
You must log in or register to reply here.
Back
Top