From Sebastien.Roy@Sun.COM Mon Nov 30 14:15:20 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAUMFKcD018223 for ; Mon, 30 Nov 2009 14:15:20 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAUMFKGd007606 for ; Mon, 30 Nov 2009 14:15:20 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAUMFKZ4006975 for ; Mon, 30 Nov 2009 22:15:20 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTX00300ZS6YJ00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 30 Nov 2009 15:15:20 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTY00E2E0HD01A0@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 30 Nov 2009 15:15:14 -0700 (MST) Date: Mon, 30 Nov 2009 17:12:30 -0500 From: Sebastien Roy Subject: VRRP disabled by default [PSARC/2009/653 Self Review] Sender: Sebastien.Roy@Sun.COM To: psarc-ext Cc: Cathy Zhou Message-id: <1259619150.9917.47.camel@strat> Organization: Sun Microsystems Status: RO Content-Length: 1276 I'm filing the following self-reviewed case on behalf of Cathy Zhou. It is marked closed approved automatic. This case modifies 2009/388 which has a Patch release binding and has not yet been included in a Patch release. This case also has Patch release binding to allow the VRRP functionality to be included wholly in any release with this case. Disable VRRP service by default: This case proposes that VRRP service (PSARC/2008/693 and PSARC/2009/388) to be disabled by default when the system boots up. Administrators must explicitly enable the svc:/network/vrrp:default service before they try to use the VRRP functionality, and configure any VRRP routers. This would address the problem that - currently - with VRRP service being enabled by default, in a shared-stack zone (where VRRP service is not supported), the VRRP service goes directly to the maintenance state and prompts annoying warning messages. This is also in-line with how the other non-essential service work in Solaris. Interface Table =============== Interface Classification Comments ================== ============== ======== svc:/network/vrrp:default Committed The VRRP service References ========== [1] vrrpadm(1M) From carlsonj@workingcode.com Tue Dec 1 03:29:15 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB1BTEAb019813 for ; Tue, 1 Dec 2009 03:29:15 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1BTErD014580 for ; Tue, 1 Dec 2009 03:29:14 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB1BKMA3004348 for ; Tue, 1 Dec 2009 11:29:09 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-4681649 for psarc-ext@sac.sfbay.sun.com; Tue, 1 Dec 2009 11:29:05 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-104217568; Tue, 1 Dec 2009 11:29:04 Z Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-16293043; Tue, 1 Dec 2009 11:29:04 Z Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id nB1BT3lu014282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 06:29:03 -0500 (EST) Message-ID: <4B14FDFF.1010203@workingcode.com> Date: Tue, 01 Dec 2009 06:29:03 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) To: Sebastien Roy CC: psarc-ext , Cathy Zhou Subject: Re: VRRP disabled by default [PSARC/2009/653 Self Review] References: <1259619150.9917.47.camel@strat> In-Reply-To: <1259619150.9917.47.camel@strat> X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 663 Sebastien Roy wrote: > This case proposes that VRRP service (PSARC/2008/693 and PSARC/2009/388) > to be disabled by default when the system boots up. Administrators must > explicitly enable the svc:/network/vrrp:default service before they > try to use the VRRP functionality, and configure any VRRP routers. Disabled by default seems like a perfectly reasonable answer, but why does the administrator have to enable it manually when the service is needed? The service seems to be an implementation detail. Shouldn't configuration using the supplied tool be sufficient? -- James Carlson 42.703N 71.076W From Sebastien.Roy@Sun.COM Tue Dec 1 07:05:52 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB1F5qFF023351 for ; Tue, 1 Dec 2009 07:05:52 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1F5pPr028847 for ; Tue, 1 Dec 2009 07:05:52 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB1F5p9m003177 for ; Tue, 1 Dec 2009 15:05:51 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTZ00L00AXD7A00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 01 Dec 2009 08:05:51 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTZ00D9FB9QZB60@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 01 Dec 2009 08:05:50 -0700 (MST) Date: Tue, 01 Dec 2009 10:03:06 -0500 From: Sebastien Roy Subject: Re: VRRP disabled by default [PSARC/2009/653 Self Review] In-reply-to: <4B14FDFF.1010203@workingcode.com> Sender: Sebastien.Roy@Sun.COM To: James Carlson Cc: psarc-ext , Cathy Zhou Message-id: <1259679786.25846.20.camel@strat> Organization: Sun Microsystems References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> Status: RO Content-Length: 784 On Tue, 2009-12-01 at 06:29 -0500, James Carlson wrote: > Sebastien Roy wrote: > > This case proposes that VRRP service (PSARC/2008/693 and PSARC/2009/388) > > to be disabled by default when the system boots up. Administrators must > > explicitly enable the svc:/network/vrrp:default service before they > > try to use the VRRP functionality, and configure any VRRP routers. > > Disabled by default seems like a perfectly reasonable answer, but why > does the administrator have to enable it manually when the service is > needed? The service seems to be an implementation detail. Shouldn't > configuration using the supplied tool be sufficient? That's a valid question, and I've upgraded this to a fast-track with a timer of December 07, 2009, to address it. -Seb From Cathy.Zhou@Sun.COM Tue Dec 1 10:19:48 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB1IJmsK002677 for ; Tue, 1 Dec 2009 10:19:48 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1IJkfi021498 for ; Tue, 1 Dec 2009 10:19:47 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB1IJf9e023129 for ; Tue, 1 Dec 2009 18:19:41 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTZ00M00K0KMP00@mail-apac.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 02 Dec 2009 02:19:40 +0800 (SGT) Received: from [129.146.108.16] ([unknown] [129.146.108.16]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTZ00IDEK8R0W90@mail-apac.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 02 Dec 2009 02:19:40 +0800 (SGT) Date: Tue, 01 Dec 2009 10:16:34 -0800 From: Cathy Zhou Subject: Re: VRRP disabled by default [PSARC/2009/653 Self Review] In-reply-to: <1259679786.25846.20.camel@strat> Sender: Cathy.Zhou@Sun.COM To: Sebastien Roy Cc: James Carlson , psarc-ext Message-id: <4B155D82.7030206@sun.com> References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> <1259679786.25846.20.camel@strat> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 1161 I think it can be implemented either way. But my understanding of the precedent examples, is that, the administrators has to enable the services explicitly in order for the service to work, for example, the ILB service. If we agreed we do not need to follow such precedence, I can change how VRRP works. Thanks - Cathy > On Tue, 2009-12-01 at 06:29 -0500, James Carlson wrote: > >> Sebastien Roy wrote: >> >>> This case proposes that VRRP service (PSARC/2008/693 and PSARC/2009/388) >>> to be disabled by default when the system boots up. Administrators must >>> explicitly enable the svc:/network/vrrp:default service before they >>> try to use the VRRP functionality, and configure any VRRP routers. >>> >> Disabled by default seems like a perfectly reasonable answer, but why >> does the administrator have to enable it manually when the service is >> needed? The service seems to be an implementation detail. Shouldn't >> configuration using the supplied tool be sufficient? >> > > That's a valid question, and I've upgraded this to a fast-track with a > timer of December 07, 2009, to address it. > > -Seb > > > From gdamore@sun.com Tue Dec 1 10:33:01 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB1IX1xn003591 for ; Tue, 1 Dec 2009 10:33:01 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1IX1vO001197 for ; Tue, 1 Dec 2009 10:33:01 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB1IWuQ1002919 for ; Tue, 1 Dec 2009 10:32:56 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTZ00F00ITOHO00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 01 Dec 2009 10:32:56 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTZ00IVQKUVIQA0@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 01 Dec 2009 10:32:55 -0800 (PST) Date: Tue, 01 Dec 2009 10:32:55 -0800 From: "Garrett D'Amore" Subject: Re: VRRP disabled by default [PSARC/2009/653 Self Review] In-reply-to: <4B155D82.7030206@sun.com> Sender: Garrett.Damore@sun.com To: Cathy Zhou Cc: Sebastien Roy , James Carlson , psarc-ext Message-id: <4B156157.2090702@sun.com> References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> <1259679786.25846.20.camel@strat> <4B155D82.7030206@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1722 Cathy Zhou wrote: > I think it can be implemented either way. But my understanding of the > precedent examples, is that, the administrators has to enable the > services explicitly in order for the service to work, for example, the > ILB service. > > If we agreed we do not need to follow such precedence, I can change > how VRRP works. I think there is precedent the other way, though. ypinit -c for example, implicitly enables the related NIS services. I think setting sharenfs=yes on a ZFS filesystem implicitly enables the NFS server services. If the only hook into a service is the SMF facility, then you should use that. If you already have another administrative interface to enable or disable a facility (or configure it), then you should not also require a separate action to enable it in SMF. - Garrett > > Thanks > - Cathy >> On Tue, 2009-12-01 at 06:29 -0500, James Carlson wrote: >> >>> Sebastien Roy wrote: >>> >>>> This case proposes that VRRP service (PSARC/2008/693 and >>>> PSARC/2009/388) >>>> to be disabled by default when the system boots up. >>>> Administrators must >>>> explicitly enable the svc:/network/vrrp:default service before they >>>> try to use the VRRP functionality, and configure any VRRP routers. >>>> >>> Disabled by default seems like a perfectly reasonable answer, but why >>> does the administrator have to enable it manually when the service is >>> needed? The service seems to be an implementation detail. Shouldn't >>> configuration using the supplied tool be sufficient? >>> >> >> That's a valid question, and I've upgraded this to a fast-track with a >> timer of December 07, 2009, to address it. >> >> -Seb >> >> >> > From Sebastien.Roy@Sun.COM Tue Dec 1 10:36:53 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB1Iarkl003616 for ; Tue, 1 Dec 2009 10:36:53 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1IaqCK004053 for ; Tue, 1 Dec 2009 10:36:52 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB1Iaq1s023434 for ; Tue, 1 Dec 2009 18:36:52 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTZ00F00IY2MP00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 01 Dec 2009 11:36:52 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTZ002CZL1C5T70@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 01 Dec 2009 11:36:49 -0700 (MST) Date: Tue, 01 Dec 2009 13:34:04 -0500 From: Sebastien Roy Subject: Re: VRRP disabled by default [PSARC/2009/653 Self Review] In-reply-to: <4B155D82.7030206@sun.com> Sender: Sebastien.Roy@Sun.COM To: Cathy Zhou Cc: James Carlson , psarc-ext Message-id: <1259692444.3909.30.camel@strat> Organization: Sun Microsystems References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> <1259679786.25846.20.camel@strat> <4B155D82.7030206@sun.com> Status: RO Content-Length: 993 On Tue, 2009-12-01 at 10:16 -0800, Cathy Zhou wrote: > I think it can be implemented either way. But my understanding of the > precedent examples, is that, the administrators has to enable the > services explicitly in order for the service to work, for example, the > ILB service. The existing best practice would seem to be that the service is disabled until _some_ explicit administrative opt-in enabling action is performed. Whether that's a "svcadm enable ..." incantation, or something else that implicitly enables the service would both adhere to the best practice (the ypinit command is one example of the latter as it implicitly enables appropriate network/nis/* services). In the latter case, to be symmetrical an implicit disable mechanism should also exist when the feature is disabled or when the software determines that the service is no longer needed by the implementation. > If we agreed we do not need to follow such precedence, I can change how > VRRP works. -Seb From Cathy.Zhou@Sun.COM Tue Dec 1 10:53:09 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB1Ir9Xb003709 for ; Tue, 1 Dec 2009 10:53:09 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1Ir7V6015106 for ; Tue, 1 Dec 2009 10:53:08 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB1Ir23n011147 for ; Tue, 1 Dec 2009 18:53:02 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTZ00G00LQJ3700@mail-apac.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 02 Dec 2009 02:53:02 +0800 (SGT) Received: from [129.146.108.16] ([unknown] [129.146.108.16]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTZ006YHLSCSX70@mail-apac.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 02 Dec 2009 02:53:02 +0800 (SGT) Date: Tue, 01 Dec 2009 10:49:56 -0800 From: Cathy Zhou Subject: Re: VRRP disabled by default [PSARC/2009/653 Self Review] In-reply-to: <1259692444.3909.30.camel@strat> Sender: Cathy.Zhou@Sun.COM To: Sebastien Roy Cc: James Carlson , psarc-ext Message-id: <4B156554.5060400@sun.com> References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> <1259679786.25846.20.camel@strat> <4B155D82.7030206@sun.com> <1259692444.3909.30.camel@strat> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 1159 Sebastien Roy wrote: > On Tue, 2009-12-01 at 10:16 -0800, Cathy Zhou wrote: > >> I think it can be implemented either way. But my understanding of the >> precedent examples, is that, the administrators has to enable the >> services explicitly in order for the service to work, for example, the >> ILB service. >> > > The existing best practice would seem to be that the service is disabled > until _some_ explicit administrative opt-in enabling action is > performed. Whether that's a "svcadm enable ..." incantation, or > something else that implicitly enables the service would both adhere to > the best practice (the ypinit command is one example of the latter as it > implicitly enables appropriate network/nis/* services). In the latter > case, to be symmetrical an implicit disable mechanism should also exist > when the feature is disabled or when the software determines that the > service is no longer needed by the implementation. > Okay then. I will update the case material and let you know. Thanks - Cathy > >> If we agreed we do not need to follow such precedence, I can change how >> VRRP works. >> > > -Seb > > > From Scott.Rotondo@Sun.COM Tue Dec 1 14:11:19 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB1MBJUq011146 for ; Tue, 1 Dec 2009 14:11:19 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1MBIGJ000474 for ; Tue, 1 Dec 2009 14:11:18 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB1MBIKs024346 for ; Tue, 1 Dec 2009 22:11:18 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTZ00I00UTLIP00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 01 Dec 2009 15:11:18 -0700 (MST) Received: from [129.146.108.62] ([unknown] [129.146.108.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTZ00FOMUYHYA80@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 01 Dec 2009 15:11:06 -0700 (MST) Date: Tue, 01 Dec 2009 14:11:05 -0800 From: Scott Rotondo Subject: Re: VRRP disabled by default [PSARC/2009/653 Self Review] In-reply-to: <1259692444.3909.30.camel@strat> Sender: Scott.Rotondo@Sun.COM To: Sebastien Roy Cc: Cathy Zhou , James Carlson , psarc-ext Message-id: <4B159479.3090100@sun.com> References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> <1259679786.25846.20.camel@strat> <4B155D82.7030206@sun.com> <1259692444.3909.30.camel@strat> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1249 Sebastien Roy wrote: > On Tue, 2009-12-01 at 10:16 -0800, Cathy Zhou wrote: >> I think it can be implemented either way. But my understanding of the >> precedent examples, is that, the administrators has to enable the >> services explicitly in order for the service to work, for example, the >> ILB service. > > The existing best practice would seem to be that the service is disabled > until _some_ explicit administrative opt-in enabling action is > performed. Whether that's a "svcadm enable ..." incantation, or > something else that implicitly enables the service would both adhere to > the best practice (the ypinit command is one example of the latter as it > implicitly enables appropriate network/nis/* services). In the latter > case, to be symmetrical an implicit disable mechanism should also exist > when the feature is disabled or when the software determines that the > service is no longer needed by the implementation. Mounting an NFS filesystem is an even more common example of an administrative action that implicitly enables SMF services (for NFS file locking). Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From Sebastien.Roy@Sun.COM Tue Dec 15 11:10:37 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBFJAbYR017747 for ; Tue, 15 Dec 2009 11:10:37 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBFJAaBG018002 for ; Tue, 15 Dec 2009 11:10:36 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBFJAavx001070 for ; Tue, 15 Dec 2009 19:10:36 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUP00C00JB0H800@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 15 Dec 2009 12:10:36 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUP007WLJXND7E0@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 15 Dec 2009 12:10:35 -0700 (MST) Date: Tue, 15 Dec 2009 14:07:45 -0500 From: Sebastien Roy Subject: Re: VRRP disabled by default [PSARC/2009/653 FastTrack timeout 12/22/2009] In-reply-to: <4B156554.5060400@sun.com> Sender: Sebastien.Roy@Sun.COM To: Cathy Zhou Cc: James Carlson , psarc-ext Message-id: <1260904065.16594.57.camel@strat> Organization: Sun Microsystems References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> <1259679786.25846.20.camel@strat> <4B155D82.7030206@sun.com> <1259692444.3909.30.camel@strat> <4B156554.5060400@sun.com> Status: RO Content-Length: 1765 On Tue, 2009-12-01 at 10:49 -0800, Cathy Zhou wrote: > Okay then. I will update the case material and let you know. > Cathy has provided an updated spec that addresses the issue raised that a cleaner architecture would not require the administrator to directly manipulate the state of the VRRP SMF service. I've placed a "spec.txt" file in the case directory, and pasted it in-line here. The timer is reset to expire on December 22nd. Disable VRRP service by default: This case proposes that the VRRP SMF service (PSARC/2008/693 and PSARC/2009/388) be disabled by default when the system boots up. The svc:/network/vrrp:default service will be automatically enabled when the first VRRP router is created by the "vrrpadm create-router" subcommand, and the service will be automatically disabled when the last VRRP router is deleted by the "vrrpadm delete-router" subcommand. A solaris.smf.manage.vrrp authorization will be introduced which is required to enable/disable the VRRP service. This authorization will be assigned to the "Network VRRP" and "Network Management" profile. This would address the problem that - currently - with VRRP service being enabled by default, in a shared-stack zone (where VRRP service is not supported), the VRRP service goes directly to the maintenance state and prompts annoying warning messages. This is also in-line with how other non-essential services work in Solaris. Interface Table =============== Interface Classification Comments ================== ============== ======== solaris.smf.manage.vrrp Committed Authorization required to authorization enable/disable VRRP service From gdamore@sun.com Tue Dec 15 11:18:39 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBFJIctX017894 for ; Tue, 15 Dec 2009 11:18:39 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBFJIcBs023490 for ; Tue, 15 Dec 2009 11:18:38 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBFJIXUX010576 for ; Tue, 15 Dec 2009 11:18:33 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUP00900K3YDE00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 15 Dec 2009 11:18:33 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUP00342KAV4UH0@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 15 Dec 2009 11:18:32 -0800 (PST) Date: Tue, 15 Dec 2009 11:18:31 -0800 From: "Garrett D'Amore" Subject: Re: VRRP disabled by default [PSARC/2009/653 FastTrack timeout 12/22/2009] In-reply-to: <1260904065.16594.57.camel@strat> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: Cathy Zhou , James Carlson , psarc-ext Message-id: <4B27E107.4020801@sun.com> References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> <1259679786.25846.20.camel@strat> <4B155D82.7030206@sun.com> <1259692444.3909.30.camel@strat> <4B156554.5060400@sun.com> <1260904065.16594.57.camel@strat> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1969 This looks much better, thanks Cathy and Seb. +1 on the revised specification. -- Garrett Sebastien Roy wrote: > On Tue, 2009-12-01 at 10:49 -0800, Cathy Zhou wrote: > >> Okay then. I will update the case material and let you know. >> >> > > Cathy has provided an updated spec that addresses the issue raised that > a cleaner architecture would not require the administrator to directly > manipulate the state of the VRRP SMF service. I've placed a "spec.txt" > file in the case directory, and pasted it in-line here. The timer is > reset to expire on December 22nd. > > Disable VRRP service by default: > > This case proposes that the VRRP SMF service (PSARC/2008/693 and PSARC/2009/388) > be disabled by default when the system boots up. The > svc:/network/vrrp:default service will be automatically enabled when > the first VRRP router is created by the "vrrpadm create-router" > subcommand, and the service will be automatically disabled when the > last VRRP router is deleted by the "vrrpadm delete-router" subcommand. > > A solaris.smf.manage.vrrp authorization will be introduced which is > required to enable/disable the VRRP service. This authorization will be > assigned to the "Network VRRP" and "Network Management" profile. > > This would address the problem that - currently - with VRRP service being > enabled by default, in a shared-stack zone (where VRRP service is not > supported), the VRRP service goes directly to the maintenance state and > prompts annoying warning messages. > > This is also in-line with how other non-essential services work in > Solaris. > > Interface Table > =============== > > Interface Classification Comments > ================== ============== ======== > solaris.smf.manage.vrrp Committed Authorization required to > authorization enable/disable VRRP service > > > From carlsonj@workingcode.com Tue Dec 15 14:47:02 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBFMl24I021323 for ; Tue, 15 Dec 2009 14:47:02 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBFMl1Up001497 for ; Tue, 15 Dec 2009 14:47:01 -0800 (PST) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBFMbHlU024269 for ; Tue, 15 Dec 2009 22:47:01 GMT Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-2855002 for psarc-ext@sac.sfbay.sun.com; Tue, 15 Dec 2009 22:47:01 Z Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-6710070 for psarc-ext@sac.sfbay.sun.com; Tue, 15 Dec 2009 22:47:00 Z Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-6586462 for psarc-ext@sac.sfbay.sun.com; Tue, 15 Dec 2009 22:47:00 Z Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id nBFMkwLE006827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Dec 2009 17:46:59 -0500 (EST) Message-ID: <4B2811E1.6000301@workingcode.com> Date: Tue, 15 Dec 2009 17:46:57 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) To: Sebastien Roy CC: Cathy Zhou , psarc-ext Subject: Re: VRRP disabled by default [PSARC/2009/653 FastTrack timeout 12/22/2009] References: <1259619150.9917.47.camel@strat> <4B14FDFF.1010203@workingcode.com> <1259679786.25846.20.camel@strat> <4B155D82.7030206@sun.com> <1259692444.3909.30.camel@strat> <4B156554.5060400@sun.com> <1260904065.16594.57.camel@strat> In-Reply-To: <1260904065.16594.57.camel@strat> X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.137sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 604 Sebastien Roy wrote: > On Tue, 2009-12-01 at 10:49 -0800, Cathy Zhou wrote: >> Okay then. I will update the case material and let you know. >> > > Cathy has provided an updated spec that addresses the issue raised that > a cleaner architecture would not require the administrator to directly > manipulate the state of the VRRP SMF service. I've placed a "spec.txt" > file in the case directory, and pasted it in-line here. The timer is > reset to expire on December 22nd. The update resolves the questions I had. Thanks! -- James Carlson 42.703N 71.076W From Sebastien.Roy@Sun.COM Wed Dec 16 10:19:53 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBGIJrrQ026983 for ; Wed, 16 Dec 2009 10:19:53 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBGIJrZS007175 for ; Wed, 16 Dec 2009 10:19:53 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBGIJrcg012234 for ; Wed, 16 Dec 2009 18:19:53 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUR00000BC3KB00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 16 Dec 2009 11:19:53 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUR00104C90G3G0@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 16 Dec 2009 11:19:49 -0700 (MST) Date: Wed, 16 Dec 2009 13:17:00 -0500 From: Sebastien Roy Subject: Re: VRRP disabled by default [PSARC/2009/653 Self Review] In-reply-to: <1259619150.9917.47.camel@strat> Sender: Sebastien.Roy@Sun.COM To: psarc-ext Cc: Cathy Zhou Message-id: <1260987420.17127.35.camel@strat> Organization: Sun Microsystems References: <1259619150.9917.47.camel@strat> Status: RO Content-Length: 59 This case was approved during today's PSARC meeting. -Seb