upgrading sendmail 8.12.8 to 8.13.7

I’m sure I didn’t do this the way I was supposed to, but here’s what I did. Seems to be working (knock on silicon).

Tried yum, rpm, no dice.
Untarred archive from sendmail.org

service sendmail stop

/$srcpath/sh Build

/$srcpath/sh Build install

(had to make paths for man pages in order to get a clean build)

cd /etc/mail

edit sendmail.mc to add FEATURE(`greet_pause', `1000')

(incidentally, here’s a discussion about the order for whitelisting senders with greetpause)

make -C /etc/mail

make complained about missing $path/sendmail-cf/feature/great_pause.m4

backed up sendmail-cf directory to sendmail-cf.8.12.8, copied new cf from usr/src/sendmail-8.13.7/cf

make -C /etc/mail

make complained about mssing $path/sendmail-cf/hack/popauth.m4

copied that from the sendmail-cf.8.12.8 backup

make -C /etc/mail

is happy

service sendmail restart

confirmed version 8.13.7 via

/usr/sbin/sendmail -d0 < /dev/null | grep -i version

and headers on test emails look good.

4 Responses to “upgrading sendmail 8.12.8 to 8.13.7”

  1. geekgeekgeek Says:

    Did this first on dev, then the exact same process on prod

  2. geekgeekgeek Says:

    While trying to resolve smrsh problem, noticed this:

    [root@vps mail]# newaliases

    Warning: Option: AuthMechanisms requires SASL support (-DSASL)

    Warning: Option: AuthOptions requires SASL support (-DSASL)

    So it looks like I built sendmail without SASL. Figured out I\’m running SASL 2.1.10.
    and found instructions to add
    APPENDDEF(`confENVDEF\\\', `-DSASL=2\\\')
    APPENDDEF(`conf_sendmail_LIBS\\\', `-lsasl2\\\')

    to site.config.m4 (in $sendmailsourcepath/devtools/Site)
    compiled and re-installed sendmail (sh Build, sh Build install), no dice.
    Obtained, built and installed SASL 2.1.22.
    That was easy, but of no help. Of course, it\’s probably not a bad idea to be on the latest stable production release.
    Tore out hair for a couple of hours. Finally saw this in the devtools/Site/README:
    Notice: if any of the above files is changed, the -c flag must be specified with the Build command, otherwise those changes will have no effect.
    Oh, great, now you tell me.

  3. geekgeekgeek Says:

    Everything worked fine on the dev box (naturally) but the mailman installation on the production box complained:

    smrsh: \"mailman\" not available for sendmail programs (stat failed)

    Here\\\’s what happened: the default build for the new sendmail pointed smrsh at /usr/adm/sm.bin vs RedHat 9\\\’s default of /etc/smrsh. I could have recompiled smrsh:

    -DSMRSH_CMDDIR=\\\\\\\"dir\\\\\\\" \\\\\\\"/usr/adm/sm.bin\\\\\\\"

    But I took the easy way out and moved the former contents of /etc/smrsh.

    This was a little harder to figure out than it might have been for three reasons:

    1. Red herring! I got hung up with lookng for setuid problems. Argh!
    2. Red herring! Found some documentation that said in /etc/mail/aliases I should change lines like
      listname: \\\\\\\"|/$pathtomailman/mailman post listname\\\\\\\"
      to
      listname: \\\\\\\"|/$pathtosmrshexecutables post listname\\\\\\\"
      This works (at least for \\\\\\\”post\\\\\\\”) but it\\\\\\\’s not necessary and didn\\\\\\\’t fix my problem.
    3. This instruction was misleading:
      Figure out where smrsh expects symlinks for allowable mail programs. At the very beginning of the following output you will see a full path to some directory, e.g. /var/adm/sm.bin or similar:
      % strings $path_to_smrsh | less
      In point of fact, the relevant output was not easy to parse. What I had to do was

      strings $path_to_smrsh | grep etc

      strings $path_to_smrsh | grep usr

      And so forth to see what was going on.
  4. geekgeekgeek Says:

    Just for the record, I upgraded the sasl daemon, rebuilt sendmail with sasl support, and re-linked files in smrsh’s execute directory on the dev box, too, so the boxes are once again in sync — except for the mail filtering I’m testing on dev.

Leave a Reply