By jbeck on Feb 18, 2010
/etc/mail/sendmail.cfshould 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.cfshould be changed from type
renamenew, but that had down sides as well. So in Nevada build 90 I introduced a solution to this problem:
- First, you need the
.mcfile from which your
sendmail.cfgets built. This
.mcfile 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
.mcfile; we recommend
- 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
.mcfile will be expanded into a
.cffile and copied to
/etc/mail/sendmail.cfbefore sendmail is started.
pkg image-updatefrom build 131 or earlier to build 132 or later will result in any customizations to
sendmail.cfbeing 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-updatefrom 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.cfbefore the
pkg image-update. This will prevent the packaging system from being confused by the customized
sendmail.cfand 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.