Thanks to Dave Powell who noticed that my initial proposal had a weakness.
By having both sendmail instances be "siblings" under the same service, if
an administrator were to disable the sendmail (daemon) instance but leave
the sendmail-client (queue runner) instance enabled, then an add-on service
that had a dependency on the more general smtp service would have that
dependency met, which would probably not be the intent.
Thus I have modified the case by moving the sendmail-client instance over
to its own service (svc:/network/sendmail-client:default). I am attaching
updated diff'd man pages for sendmail(1m) and sendmail(4) and have placed
the full set of old/new/diff'd man pages in the case materials directory.
I have also updated the date in the IAM file to today but left the status
as "closed approved automatic".
-- John
-------------- next part --------------
--- sendmail.4.old Fri Feb 13 09:51:07 2009
+++ sendmail.4.new Fri Feb 13 09:57:59 2009
@@ -114,30 +114,34 @@
Enabling Access to Remote Clients
The sendmail(1M) man page describes how the
config/local_only property can be set to true or false to
disallow or allow, respectively, access to remote clients
for unmodified systems.
- Setting values for the following properties for the service
- instance svc:/network/smtp:sendmail results in automated
- (re)building of configuration files:
+ Setting values for the following property for the service
+ instance svc:/network/smtp:sendmail
path_to_sendmail_mc
+
+ and for the following property for the service
+ svc:/network/sendmail-client:default results in automated
+ (re)building of configuration files:
+
path_to_submit_mc
The values for these properties should be strings which
represent the path name of the .mc files referred to in
steps 2 and 3 of both procedures above. Recommended values
are:
/etc/mail/cf/cf/`hostname`.mc
/etc/mail/cf/cf/submit-`hostname`.mc
Each property, if set, results in the corresponding .mc file
- being used to (re)build the matching .cf file when the ser-
- vice is started.
+ being used to (re)build the matching .cf file when the
+ corresponding instance/service is started.
These properties persist across upgrades and patches. To
prevent a patch or upgrade from clobbering your .cf file, or
renaming it to .cf.old, you can set the desired properties
instead.
-------------- next part --------------
--- sendmail.1m.old Fri Feb 13 09:51:07 2009
+++ sendmail.1m.new Fri Feb 13 15:33:05 2009
@@ -50,20 +50,43 @@
If a message is found to be undeliverable, it is returned to
the sender with diagnostics that indicate the location and
nature of the failure; or, the message is placed in a
dead.letter file in the sender's home directory.
+ Service Management
The sendmail service is managed by the service management
- facility, smf(5), under the service identifier:
+ facility, smf(5), under the service identifiers:
svc:/network/smtp:sendmail
+ svc:/network/sendmail-client:default
- Administrative actions on this service, such as enabling,
+ Administrative actions on these services, such as enabling,
disabling, or requesting restart, can be performed using
- svcadm(1M). The service's status can be queried using the
+ svcadm(1M). The services' status can be queried using the
svcs(1) command.
+ Note that these are separate services rather than instances
+ of the same service so that other services can properly
+ express any dependencies. In particular, here are some
+ guidelines about which service/instance should be depended
+ on for which purposes:
+
+ * For a service that uses sendmail to send mail, an optional
+ dependency on the service svc:/network/sendmail-client
+ might be in order.
+ * For a service that needs to receive mail in general, but
+ does not depend on sendmail being the particular SMTP
+ receiver, a dependency on the service svc:/network/smtp
+ might be in order.
+ * For a service that needs to interact with sendmail in
+ particular, such as a Milter, a depedency on the instance
+ svc:/network/smtp:sendmail might be in order.
+
+ For the last two, note the difference, as the latter has the
+ ":sendmail" instance specification, whereas the former does
+ not, thus representing the more general service.
+
Enabling Access to Remote Clients
On an unmodified system, access to sendmail by remote
clients is enabled and disabled through the service manage-
ment facility (see smf(5)). In particular, remote access is
determined by the value of the local_only SMF property:
