Thursday Feb 18, 2010

managing sendmail.cf across upgrades

There have been problems in the past caused by sendmail upgrades, where custom configurations have been moved aside and mail started bouncing. This is because long ago there were some sendmail upgrades that included security fixes, and it was deemed that the new default /etc/mail/sendmail.cf should be installed on upgrade, taking precedence over the old customized version of that file, which was instead moved aside to /etc/mail/sendmail.cf.old . Some suggested that the packaging for sendmail.cf should be changed from type renameold to renamenew, but that had down sides as well. So in Nevada build 90 I introduced a solution to this problem:
  • First, you need the .mc file from which your sendmail.cf gets built. This .mc file is typically stored under /etc/mail/cf/cf/ (no, that is not a typo: the first cf is for the configuration hierarchy; the second is where the individual files are stored). You need to know the exact name of your .mc file; we recommend /etc/mail/cf/cf/`hostname`.mc .
  • As root or some other user/role with sufficient privilege, do the following, where X is replaced by the name of the file from above:
      # svccfg -s sendmail
      svc:/network/smtp:sendmail> setprop config/path_to_sendmail_mc=astring: X
      svc:/network/smtp:sendmail> \^D
      # svcadm refresh svc:/network/smtp:sendmail
      # svcadm restart svc:/network/smtp:sendmail
    
  • If you ever do a fresh install, be sure to save the file (X) beforehand and restore it afterward, then repeat the above setprop/refresh/restart dance after you restore the file.
  • On service start, the specified .mc file will be expanded into a .cf file and copied to /etc/mail/sendmail.cf before sendmail is started.
Well, that new feature in build 90 was delivered with sendmail version 8.14.3, which went a very long time before it was superseded, when version 8.14.4 was introduced in build 132. So for the first time in 42 builds (almost two years), this upgrade issue has raised its head again. In particular, doing a pkg image-update from build 131 or earlier to build 132 or later will result in any customizations to sendmail.cf being moved aside as described above, and mail may start bouncing unless you deploy the new service property as noted above.
 
In addition to this generally useful tidbit, there is a particular issue with doing a pkg image-update from build 132 or earlier to build 133 or later:
 
14570 file install logic discommoded by excessive cleverness if preserve=rename\*
 
To work around this problem, do the following, again as root or a user/role with sufficient privilege:
# svcadm disable -t sendmail
# cp /etc/mail/cf/cf/sendmail.cf /etc/mail/sendmail.cf
before the pkg image-update. This will prevent the packaging system from being confused by the customized sendmail.cf and allow the upgrade to proceed smoothly. After rebooting to the new boot environment, sendmail will re-generate its configuration per the above method and mail should continue to be served properly.
About

jbeck

Search

Categories
Archives
« February 2010 »
SunMonTueWedThuFriSat
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
19
20
21
22
23
24
25
26
27
28
      
       
Today