From jbeck@eng.sun.com Wed Jan 14 15:45:31 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0ENjVlG005485 for ; Wed, 14 Jan 2009 15:45:31 -0800 (PST) Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0ENjV6P011692; Wed, 14 Jan 2009 15:45:31 -0800 (PST) Received: from opal.eng.sun.com (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.4.Alpha0+Sun/8.14.3) with ESMTP id n0ENjVqQ026517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 15:45:31 -0800 (PST) Received: (from jbeck@localhost) by opal.eng.sun.com (8.14.4.Alpha0+Sun/8.14.3/Submit) id n0ENjVbh026513; Wed, 14 Jan 2009 15:45:31 -0800 (PST) Date: Wed, 14 Jan 2009 15:45:31 -0800 (PST) Message-Id: <200901142345.n0ENjVbh026513@opal.eng.sun.com> From: jbeck@eng.sun.com (John Beck) To: PSARC-ext@sun.com Cc: John.Beck@sun.com Subject: sendmail split-instance [PSARC/2009/027 Self Review] Status: RO Content-Length: 2574 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: sendmail split-instance 1.2. Name of Document Author/Supplier: Author: John Beck 1.3 Date of This Document: 14 January, 2009 4. Technical Description I am self-sponsoring this case, which I believe is sufficiently obvious to qualify for automatic approval; if anyone objects, I will upgrade it to a fast-track. The interfaces are Committed and the release binding is Patch. * Previous related cases * PSARC 2001/812 sendmail 8.12 * PSARC 2002/547 Greenline * PSARC 2008/042 automated building of sendmail configuration files * Problem Since version 8.12 (introduced in Solaris 9), sendmail has had two long- running processes: the traditional daemon, and a client queue runner. Since sendmail comes from outside Sun, it is not contract-aware, which has led to occasional problems of the daemon dumping core and SMF not restarting. This is because the client queue runner was still going and thus the contract was not empty, so SMF would not know to restart it. * Solution Split the sendmail instance of the svc:/network/smtp service into two, leaving the existing sendmail instance for the daemon, and adding a new sendmail-client instance for the client queue runner. Man pages for sendmail(1m) and sendmail(4) (old, new and diff'd) are available in the case materials directory. * Issues * SBD The sendmail instance will continued to be governed by its property config/local_only as to whether it accepts connections only on loopback addresses or from any IP address. As the sendmail-client instance does not result in any open ports, and its process is enabled by default currently, it will also be enabled by default. * RBAC The sendmail-client instance will use the same authorization value (solaris.smf.manage.sendmail) as the sendmail instance. * Automated config-file building PSARC 2008/042 introduced the property config/path_to_submit_mc for the sendmail instance. This property will now migrate to the sendmail-client instance with the same semantics. Note that this feature, though it has Patch release binding, has not yet been back- ported, so this migration does not present any compatibility issues. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Wed Jan 14 17:19:53 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0F1JqE0026431 for ; Wed, 14 Jan 2009 17:19:52 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0F1JjWK000549; Thu, 15 Jan 2009 09:19:49 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDH00103NOZ4S00@brm-avmta-1.central.sun.com>; Wed, 14 Jan 2009 18:19:47 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDH00L0INOYQ310@brm-avmta-1.central.sun.com>; Wed, 14 Jan 2009 18:19:46 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0F1Jjek007024; Wed, 14 Jan 2009 20:19:45 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0F1Jjld007021; Wed, 14 Jan 2009 20:19:45 -0500 (EST) Date: Wed, 14 Jan 2009 20:19:45 -0500 From: James Carlson Subject: Re: sendmail split-instance [PSARC/2009/027 Self Review] In-reply-to: <200901142345.n0ENjVbh026513@opal.eng.sun.com> To: jbeck@eng.sun.com (John Beck) Cc: PSARC-ext@sun.com, John.Beck@sun.com Message-id: <18798.36657.341332.15156@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901142345.n0ENjVbh026513@opal.eng.sun.com> Status: RO Content-Length: 477 John Beck writes: > I am self-sponsoring this case, which I believe is sufficiently obvious to > qualify for automatic approval; if anyone objects, I will upgrade it to a > fast-track. The interfaces are Committed and the release binding is Patch. +1 -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From jbeck@eng.sun.com Fri Feb 13 15:59:17 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1DNxHVW005185 for ; Fri, 13 Feb 2009 15:59:17 -0800 (PST) Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1DNxGMS015670 for ; Fri, 13 Feb 2009 15:59:16 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.4.Alpha0+Sun/8.14.3) with ESMTP id n1DNxGPs006899; Fri, 13 Feb 2009 15:59:16 -0800 (PST) Message-Id: <200902132359.n1DNxGPs006899@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: PSARC-ext@sun.com Cc: John Beck Subject: Re: sendmail split-instance [PSARC/2009/027 Self Review] X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Wed, 14 Jan 2009 15:45:31 PST." <200901142345.n0ENjVbh026513@opal.eng.sun.com> References: <200901142345.n0ENjVbh026513@opal.eng.sun.com> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1234569445_29090" Date: Fri, 13 Feb 2009 15:59:16 -0800 From: John Beck Status: RO Content-Length: 5257 This is a multipart MIME message. --==_Exmh_1234569445_29090 Content-Type: text/plain; charset=us-ascii 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 --==_Exmh_1234569445_29090 Content-Type: text/plain ; name="s4.attach"; charset=us-ascii Content-Description: diff -u of sendmail(4) --- 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. --==_Exmh_1234569445_29090 Content-Type: text/plain ; name="s1m.attach"; charset=us-ascii Content-Description: diff -u of sendmail(1m) --- 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: --==_Exmh_1234569445_29090--