From sacadmin Wed May 6 09:28:27 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46GSRHn021551; Wed, 6 May 2009 09:28:27 -0700 (PDT) Received: (from carlsonj@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n46GSQpV021543; Wed, 6 May 2009 09:28:26 -0700 (PDT) Date: Wed, 6 May 2009 09:28:26 -0700 (PDT) From: James Carlson Message-Id: <200905061628.n46GSQpV021543@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: DHCP Client Updates [PSARC/2009/285 FastTrack timeout 05/13/2009] Status: RO Content-Length: 552 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: DHCP Client Updates 1.2. Name of Document Author/Supplier: Author: James Carlson 1.3 Date of This Document: 06 May, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Wed May 6 13:18:04 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46KI33e029966 for ; Wed, 6 May 2009 13:18:04 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n46KI3KX053390 for ; Wed, 6 May 2009 16:18:03 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n46KHGZm024800 for ; Wed, 6 May 2009 16:17:16 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n46KHGpM024797; Wed, 6 May 2009 16:17:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18945.61516.63585.245655@gargle.gargle.HOWL> Date: Wed, 6 May 2009 16:17:16 -0400 From: James Carlson To: psarc-ext@sac.sfbay.sun.com Subject: PSARC 2009/285 DHCP Client Updates X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 7714 I'm sponsoring this fast-track request for myself. The timer is set to 05/13/2009, the interfaces described are all "Committed", and the release binding is Patch/Micro. This project includes five fairly simple updates for dhcpagent (the DHCP client on OpenSolaris) for the price of one. The changes could reasonably go in a patch, but, for clarity, I have no intention of backporting them at this time. They're intended for OpenSolaris. 1. Waiting for commands other than "start." The ifconfig "dhcp" subcommand allows the insertion of an optional "wait " (where is in seconds) directive between the "dhcp" keyword and the keyword specifying a command. Currently, the only thing that this does is to include a timeout parameter in the command sent (via IPC) to the dhcpagent process, which then uses it as a timer for the "start" operation. In all cases, the client blocks "forever" waiting for the results, and relies on the server for any timers. As described in CR 6823679, this behavior can be harmful if something bad has happened to the DHCP server, and thus to decouple clients from server behavior, we will now take the timeout into account on the client side as well. To make things simple, the client will always wait two seconds longer than the timeout value sent to the server, so the server has a chance to report its own timeout in the "normal" failure case. This will allow clients (such as nwamd) to use: ifconfig dhcp wait drop ifconfig dhcp wait release No man page updates are needed; the new behavior is consistent with the existing documented behavior. 2. dhcpinfo primary The dhcpinfo(1) command will fail if no "-i " option is provided and there's no "primary" DHCP interface. As described in CR 6553194, nwamd intentionally does not set "primary" on any interface, and thus /sbin/dhcpinfo will fail unless given the "-i" option. While use of "-i" is clearly the preferred method in DHCP eventhook scripts, in order to be specific about the information desired, other scripts may invoke this command without knowing which interface is the "right" one. This project will change dhcpinfo behavior such that if "-i" is not specified, and no DHCP-controlled interface is marked primary, then the interface whose name sorts lexically first and that has information from a DHCP server will be treated as the "primary" interface for the requested parameter. This behavior mirrors the historical behavior of the system boot-time automatic "primary" interface selection. If a primary interface is selected, then this new feature has no effect; omitting the "-i" option causes dhcpinfo to return DHCP parameters from only that one interface. This new behavior will be documented on the dhcpinfo(1) man page. 3. Ignore unwanted options As documented in CR 6667011, it's frequently necessary to exercise discretion in the DHCP client's operation by ignoring some parameters provided by the server. For example, one may wish to ignore the "Hostname" parameter to avoid using one assigned by a hostile administrator (such as an ISP), or ignore an untrusted source of "DNSserv" addresses. The existing PARAM_REQUEST_LIST does not do this; it only sets the list of parameters we request from the server and does not constrain the results the server may supply. In order to allow for this discretion, a new "PARAM_IGNORE_LIST" parameter will be added to /etc/default/dhcpagent. This parameter is a string representing the DHCP Standard and Site options that should be ignored, and operates in exactly the same manner as the existing "PARAM_REQUEST_LIST" parameter. If the server supplies one of these parameters, we will behave as though it wasn't supplied. (Note that Vendor options cannot be ignored. They can't be requested, either.) The dhcpagent(1M) man page (which documents this file) will be updated to describe this new parameter. 4. Symbolic parameter names As described in 4783123, it would be easier for administrators to add entries to the PARAM_REQUEST_LIST if they could use the symbolic names from /etc/dhcp/inittab (and /etc/dhcp/inittab6 for v6.PARAM_REQUEST_LIST), in much the same way that symbolic option names are allowed for the dhcpinfo(1) command. This project will update the agent to parse out symbolic Standard and Site options for PARAM_REQUEST_LIST and the new PARAM_IGNORE_LIST. The dhcpagent(1M) man page (which documents this file) will be updated to describe the new behavior. 5. Lease validation refinement Currently, the dhcpagent daemon will "drop" releases on shutdown, which means that the lease is stored in local stable storage (disk) and the DHCP server is not informed that the client is shutting down. It then attempts to get the lease back at start-up. The /etc/default/dhcpagent file has a RELEASE_ON_SIGTERM option that will make the daemon "release" leases at shutdown instead, so that the lease isn't stored on disk, and the server is told that we're finished with the lease. This latter behavior is more desirable for nomadic clients, but as CR 6835298 documents, it sometimes isn't enough. In particular, the daemon will attempt to reverify leases on a link down/up transition and on a SIGTHAW (due to suspend/resume). If the server fails to respond at all (which is quite likely if you've moved your laptop to a new network and the server doesn't recognize you), you'll drive on with your old and now-invalid lease, and RELEASE_ON_SIGTERM won't help. To fix this problem, a new VERIFIED_LEASE_ONLY flag will be introduced. When this flag is set (the flag has the same on/off sense and default as the previous flag), the DHCP client will discard the lease if it's unable to verify rather than continuing with the remaining lease, and will return to a normal lease acquisition attempt, in addition to not caching the lease at shutdown time and releasing it at the server, just like RELEASE_ON_SIGTERM. Due to the way parameters in this file are parsed, the simplest change is to allow RELEASE_ON_SIGTERM to continue to have its old meaning and not affect link-up/SIGTHAW, so that the new parameter is a superset of the old behavior. We will remove RELEASE_ON_SIGTERM from the template /etc/default/dhcpagent file and the man page, and replace with VERIFIED_LEASE_ONLY. RELEASE_ON_SIGTERM becomes "Obsolete Committed." Upgrade notes: On upgrade from a previous release, SysV packaging will edit the existing /etc/default/dhcpagent file to conform with the new features, but only if it contains the old text. In all but one case, this is merely comment changes. If the user has set RELEASE_ON_SIGTERM set and upgrades with SysV packaging, we will convert this to VERIFIED_LEASE_ONLY. The greatest likelihood is that users will need the new behavior and not the old. If this were released as a patch (no plans to do so), we would make the patch scripts leave RELEASE_ON_SIGTERM alone, so that the existing behavior is not changed, and the user must explicitly add the new variable if desired. The implications for IPS are not known at this time. IPS does not have a facility similar to the i.dhcpagent class-action script in SUNWcnetr. However, users will be notified via mailing lists about the new feature. From gdamore@sun.com Wed May 6 14:12: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 n46LCqMH001226 for ; Wed, 6 May 2009 14:12:52 -0700 (PDT) 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.2) with ESMTP id n46LCquQ053595 for ; Wed, 6 May 2009 14:12:52 -0700 (PDT) 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 n46LCl6X008209 for ; Wed, 6 May 2009 14:12:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ800400QLTPU00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 06 May 2009 14:12:47 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ8005R5QWV1L20@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 06 May 2009 14:12:32 -0700 (PDT) Date: Wed, 06 May 2009 14:12:31 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/285 DHCP Client Updates In-reply-to: <18945.61516.63585.245655@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: psarc-ext@sac.sfbay.sun.com Message-id: <4A01FD3F.5080806@sun.com> References: <18945.61516.63585.245655@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 8447 Seems like good stuff to me, especially the fixes for SIGTHAW. +1. Probably somewhere there should be some documentation explaining how dhcpagent works in the face of suspend/resume (i.e. SIGTHAW) -- the implicit "lease expiration" upon resume may catch a few people unawares. (Probably fewer than the old behavior did, but still it should be noted somewhere... I'm just not sure where.) - Garrett James Carlson wrote: > I'm sponsoring this fast-track request for myself. The timer is set > to 05/13/2009, the interfaces described are all "Committed", and the > release binding is Patch/Micro. This project includes five fairly > simple updates for dhcpagent (the DHCP client on OpenSolaris) for the > price of one. > > The changes could reasonably go in a patch, but, for clarity, I have > no intention of backporting them at this time. They're intended for > OpenSolaris. > > 1. Waiting for commands other than "start." > > The ifconfig "dhcp" subcommand allows the insertion of an optional > "wait " (where is in seconds) directive between the "dhcp" > keyword and the keyword specifying a command. > > Currently, the only thing that this does is to include a timeout > parameter in the command sent (via IPC) to the dhcpagent process, > which then uses it as a timer for the "start" operation. In all > cases, the client blocks "forever" waiting for the results, and > relies on the server for any timers. > > As described in CR 6823679, this behavior can be harmful if > something bad has happened to the DHCP server, and thus to > decouple clients from server behavior, we will now take the > timeout into account on the client side as well. To make things > simple, the client will always wait two seconds longer than the > timeout value sent to the server, so the server has a chance to > report its own timeout in the "normal" failure case. > > This will allow clients (such as nwamd) to use: > > ifconfig dhcp wait drop > ifconfig dhcp wait release > > No man page updates are needed; the new behavior is consistent > with the existing documented behavior. > > 2. dhcpinfo primary > > The dhcpinfo(1) command will fail if no "-i " option is > provided and there's no "primary" DHCP interface. > > As described in CR 6553194, nwamd intentionally does not set > "primary" on any interface, and thus /sbin/dhcpinfo will fail > unless given the "-i" option. While use of "-i" is clearly the > preferred method in DHCP eventhook scripts, in order to be > specific about the information desired, other scripts may invoke > this command without knowing which interface is the "right" one. > > This project will change dhcpinfo behavior such that if "-i" is > not specified, and no DHCP-controlled interface is marked primary, > then the interface whose name sorts lexically first and that has > information from a DHCP server will be treated as the "primary" > interface for the requested parameter. This behavior mirrors the > historical behavior of the system boot-time automatic "primary" > interface selection. > > If a primary interface is selected, then this new feature has no > effect; omitting the "-i" option causes dhcpinfo to return DHCP > parameters from only that one interface. > > This new behavior will be documented on the dhcpinfo(1) man page. > > 3. Ignore unwanted options > > As documented in CR 6667011, it's frequently necessary to exercise > discretion in the DHCP client's operation by ignoring some > parameters provided by the server. For example, one may wish to > ignore the "Hostname" parameter to avoid using one assigned by a > hostile administrator (such as an ISP), or ignore an untrusted > source of "DNSserv" addresses. The existing PARAM_REQUEST_LIST > does not do this; it only sets the list of parameters we request > from the server and does not constrain the results the server may > supply. > > In order to allow for this discretion, a new "PARAM_IGNORE_LIST" > parameter will be added to /etc/default/dhcpagent. This parameter > is a string representing the DHCP Standard and Site options that > should be ignored, and operates in exactly the same manner as the > existing "PARAM_REQUEST_LIST" parameter. If the server supplies > one of these parameters, we will behave as though it wasn't > supplied. > > (Note that Vendor options cannot be ignored. They can't be > requested, either.) > > The dhcpagent(1M) man page (which documents this file) will be > updated to describe this new parameter. > > 4. Symbolic parameter names > > As described in 4783123, it would be easier for administrators to > add entries to the PARAM_REQUEST_LIST if they could use the > symbolic names from /etc/dhcp/inittab (and /etc/dhcp/inittab6 for > v6.PARAM_REQUEST_LIST), in much the same way that symbolic option > names are allowed for the dhcpinfo(1) command. > > This project will update the agent to parse out symbolic Standard > and Site options for PARAM_REQUEST_LIST and the new > PARAM_IGNORE_LIST. > > The dhcpagent(1M) man page (which documents this file) will be > updated to describe the new behavior. > > 5. Lease validation refinement > > Currently, the dhcpagent daemon will "drop" releases on shutdown, > which means that the lease is stored in local stable storage > (disk) and the DHCP server is not informed that the client is > shutting down. It then attempts to get the lease back at > start-up. The /etc/default/dhcpagent file has a > RELEASE_ON_SIGTERM option that will make the daemon "release" > leases at shutdown instead, so that the lease isn't stored on > disk, and the server is told that we're finished with the lease. > > This latter behavior is more desirable for nomadic clients, but as > CR 6835298 documents, it sometimes isn't enough. > > In particular, the daemon will attempt to reverify leases on a > link down/up transition and on a SIGTHAW (due to suspend/resume). > If the server fails to respond at all (which is quite likely if > you've moved your laptop to a new network and the server doesn't > recognize you), you'll drive on with your old and now-invalid > lease, and RELEASE_ON_SIGTERM won't help. > > To fix this problem, a new VERIFIED_LEASE_ONLY flag will be > introduced. When this flag is set (the flag has the same on/off > sense and default as the previous flag), the DHCP client will > discard the lease if it's unable to verify rather than continuing > with the remaining lease, and will return to a normal lease > acquisition attempt, in addition to not caching the lease at > shutdown time and releasing it at the server, just like > RELEASE_ON_SIGTERM. > > Due to the way parameters in this file are parsed, the simplest > change is to allow RELEASE_ON_SIGTERM to continue to have its old > meaning and not affect link-up/SIGTHAW, so that the new parameter > is a superset of the old behavior. We will remove > RELEASE_ON_SIGTERM from the template /etc/default/dhcpagent file > and the man page, and replace with VERIFIED_LEASE_ONLY. > RELEASE_ON_SIGTERM becomes "Obsolete Committed." > > Upgrade notes: > > On upgrade from a previous release, SysV packaging will edit the > existing /etc/default/dhcpagent file to conform with the new > features, but only if it contains the old text. In all but one > case, this is merely comment changes. > > If the user has set RELEASE_ON_SIGTERM set and upgrades with SysV > packaging, we will convert this to VERIFIED_LEASE_ONLY. The > greatest likelihood is that users will need the new behavior and > not the old. > > If this were released as a patch (no plans to do so), we would > make the patch scripts leave RELEASE_ON_SIGTERM alone, so that the > existing behavior is not changed, and the user must explicitly add > the new variable if desired. > > The implications for IPS are not known at this time. IPS does not > have a facility similar to the i.dhcpagent class-action script in > SUNWcnetr. However, users will be notified via mailing lists > about the new feature. > From carlsonj@phorcys.east.sun.com Wed May 6 14:18:06 2009 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46LI689001365 for ; Wed, 6 May 2009 14:18:06 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n46LI5dN045159; Wed, 6 May 2009 17:18:05 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n46LHI2h025204; Wed, 6 May 2009 17:17:18 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n46LHIrx025201; Wed, 6 May 2009 17:17:18 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18945.65118.271947.40265@gargle.gargle.HOWL> Date: Wed, 6 May 2009 17:17:18 -0400 From: James Carlson To: "Garrett D'Amore" Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: PSARC 2009/285 DHCP Client Updates In-Reply-To: <4A01FD3F.5080806@sun.com> References: <18945.61516.63585.245655@gargle.gargle.HOWL> <4A01FD3F.5080806@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 792 Garrett D'Amore writes: > Seems like good stuff to me, especially the fixes for SIGTHAW. > > +1. > > Probably somewhere there should be some documentation explaining how > dhcpagent works in the face of suspend/resume (i.e. SIGTHAW) -- the > implicit "lease expiration" upon resume may catch a few people > unawares. (Probably fewer than the old behavior did, but still it > should be noted somewhere... I'm just not sure where.) I can certainly add it to the man page (along with the identical link-up behavior) as part of the new VERIFIED_LEASE_ONLY option. -- 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 gdamore@sun.com Wed May 6 14:32:30 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 n46LWTPw001694 for ; Wed, 6 May 2009 14:32:29 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n46LWTEP062167 for ; Wed, 6 May 2009 14:32:29 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n46LWN18004585 for ; Wed, 6 May 2009 14:32:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ800600RRDDP00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 06 May 2009 14:32:23 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ80052ORTZ1L70@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 06 May 2009 14:32:23 -0700 (PDT) Date: Wed, 06 May 2009 14:32:22 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/285 DHCP Client Updates In-reply-to: <18945.65118.271947.40265@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: psarc-ext@sac.sfbay.sun.com Message-id: <4A0201E6.1050602@sun.com> References: <18945.61516.63585.245655@gargle.gargle.HOWL> <4A01FD3F.5080806@sun.com> <18945.65118.271947.40265@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 661 James Carlson wrote: > Garrett D'Amore writes: > >> Seems like good stuff to me, especially the fixes for SIGTHAW. >> >> +1. >> >> Probably somewhere there should be some documentation explaining how >> dhcpagent works in the face of suspend/resume (i.e. SIGTHAW) -- the >> implicit "lease expiration" upon resume may catch a few people >> unawares. (Probably fewer than the old behavior did, but still it >> should be noted somewhere... I'm just not sure where.) >> > > I can certainly add it to the man page (along with the identical > link-up behavior) as part of the new VERIFIED_LEASE_ONLY option. > Sounds good. Thanks. - Garrett From kais.belgaied@sun.com Wed May 6 14:41:07 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46Lf7cI001792 for ; Wed, 6 May 2009 14:41:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n46LerFM065367; Wed, 6 May 2009 15:41:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ8009ADS8HKF10@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 May 2009 14:41:05 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ800KYCS78EM70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 May 2009 14:40:20 -0700 (PDT) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n46LeKHN488188; Wed, 06 May 2009 14:40:20 -0700 (PDT) Date: Wed, 06 May 2009 14:40:20 -0700 From: Kais Belgaied Subject: Re: PSARC 2009/285 DHCP Client Updates In-reply-to: <18945.61516.63585.245655@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-ext@sun.com Reply-to: kais.belgaied@sun.com Message-id: <4A0203C4.6090804@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18945.61516.63585.245655@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 507 On 05/06/09 13:17, James Carlson wrote: > I'm sponsoring this fast-track request for myself. The timer is set > to 05/13/2009, the interfaces described are all "Committed", and the > release binding is Patch/Micro. This project includes five fairly > simple updates for dhcpagent (the DHCP client on OpenSolaris) for the > price of one. > > The changes could reasonably go in a patch, but, for clarity, I have > no intention of backporting them at this time. They're intended for > OpenSolaris. +1 Kais From bart.smaalders@Sun.COM Wed May 6 17:13:58 2009 Received: from zion.sfbay.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n470DveV004942 for ; Wed, 6 May 2009 17:13:57 -0700 (PDT) Received: from cyber.SFBay.Sun.COM (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id n470Dv4D023836; Thu, 7 May 2009 00:13:57 GMT Message-ID: <4A0227C5.3030700@Sun.COM> Date: Wed, 06 May 2009 17:13:57 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: James Carlson CC: psarc-ext@sac.sfbay.sun.com Subject: Re: PSARC 2009/285 DHCP Client Updates References: <18945.61516.63585.245655@gargle.gargle.HOWL> In-Reply-To: <18945.61516.63585.245655@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1919 James Carlson wrote: > I'm sponsoring this fast-track request for myself. The timer is set > to 05/13/2009, the interfaces described are all "Committed", and the > release binding is Patch/Micro. This project includes five fairly > simple updates for dhcpagent (the DHCP client on OpenSolaris) for the > price of one. > > The changes could reasonably go in a patch, but, for clarity, I have > no intention of backporting them at this time. They're intended for > OpenSolaris. > ... > Upgrade notes: > > On upgrade from a previous release, SysV packaging will edit the > existing /etc/default/dhcpagent file to conform with the new > features, but only if it contains the old text. In all but one > case, this is merely comment changes. > > If the user has set RELEASE_ON_SIGTERM set and upgrades with SysV > packaging, we will convert this to VERIFIED_LEASE_ONLY. The > greatest likelihood is that users will need the new behavior and > not the old. > > If this were released as a patch (no plans to do so), we would > make the patch scripts leave RELEASE_ON_SIGTERM alone, so that the > existing behavior is not changed, and the user must explicitly add > the new variable if desired. > > The implications for IPS are not known at this time. IPS does not > have a facility similar to the i.dhcpagent class-action script in > SUNWcnetr. However, users will be notified via mailing lists > about the new feature. So you're intending this for OpenSolaris, but you're not exploring the affect of your change on those users? If the user has made no changes to this file (assumed editable), he'll get the new version. If he has made changes, he'll keep the old version. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From carlsonj@phorcys.east.sun.com Thu May 7 05:29:49 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n47CTno9009458 for ; Thu, 7 May 2009 05:29:49 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n47CTlOp002460; Thu, 7 May 2009 08:29:47 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n47CT1Ej026418; Thu, 7 May 2009 08:29:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n47CT1d0026415; Thu, 7 May 2009 08:29:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18946.54285.12792.5071@gargle.gargle.HOWL> Date: Thu, 7 May 2009 08:29:01 -0400 From: James Carlson To: Bart Smaalders Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: PSARC 2009/285 DHCP Client Updates In-Reply-To: <4A0227C5.3030700@Sun.COM> References: <18945.61516.63585.245655@gargle.gargle.HOWL> <4A0227C5.3030700@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2015 Bart Smaalders writes: > So you're intending this for OpenSolaris, but you're not exploring the > affect of your change on those users? No ... I just haven't been able to do that yet, and there are no files in ON that control the behavior, and (as far as I know) I have no reasonable way to make my own modified repository. My plan was (a) to ask the local OpenSolaris experts when I next had a chance [likely the start of next week] and (b) to document appropriately whatever the results were well in advance of any possible OpenSolaris availability. However, I have no plan to contribute special code to OpenSolaris to handle the i.dhcpagent logic. That's an existing class-action script that I'm only updating in a fairly minor way. If someone on the OpenSolaris team wants to figure those scripts out, that'd be great, but I don't think it ought to be my responsibility to do so. I'd expect that things will likely get a lot easier to manage once OpenSolaris integrates. > If the user has made no changes to this file (assumed editable), he'll > get the new version. If he has made changes, he'll keep the old version. Great. Either the old or the new version will work fine. As I noted, the changes are essentially comments. The tradition here (in SysV packaging) is to massage the comments on each update. The only non-comment change is the RELEASE_ON_SIGTERM flag, and the file will still be valid and still produce expected results without applying that change. Users who want the new functionality will be forced (due to the lack of class-action script support) to change the variable on their own. Otherwise, if they change nothing, they'll still get the old behavior for that one flag. Essentially, you're saying that it behaves like a patch, and that seems fine. -- 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 carlsonj@phorcys.east.sun.com Thu May 14 09:13:03 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4EGD2Yw004886 for ; Thu, 14 May 2009 09:13:02 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4EGD2Fv019708 for ; Thu, 14 May 2009 12:13:02 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4EGCAZH015214 for ; Thu, 14 May 2009 12:12:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4EGC9l4015211; Thu, 14 May 2009 12:12:09 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18956.17113.964056.397127@gargle.gargle.HOWL> Date: Thu, 14 May 2009 12:12:09 -0400 From: James Carlson To: psarc-ext@sac.sfbay.sun.com Subject: Re: PSARC 2009/285 DHCP Client Updates In-Reply-To: <18945.61516.63585.245655@gargle.gargle.HOWL> References: <18945.61516.63585.245655@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1162 James Carlson writes: > I'm sponsoring this fast-track request for myself. The timer is set > to 05/13/2009, the interfaces described are all "Committed", and the > release binding is Patch/Micro. This project includes five fairly > simple updates for dhcpagent (the DHCP client on OpenSolaris) for the > price of one. The timer has expired, and there are multiple "+1"s on this request. I'm marking this fast-track as "closed approved." The following documentation issues will be handled by the project team: - The dhcpagent documentation will be updated to include information about lease re-verification due to suspend/resume SIGTHAW and driver link up notification. - I've discussed the OpenSolaris upgrade issues with Dave Miner, and he agrees that a suitably-worded release note for the build that includes these changes is the right answer. I will work with David Comay to produce that release note. -- 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