From sebastien.roy@oracle.com Wed May 12 09:01:51 2010 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 o4CG1pIT007468 for ; Wed, 12 May 2010 09:01:51 -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.4) with ESMTP id o4CG1oZm033188 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 10:01:51 -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 <0L2B00E0HDV2ST00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:01:50 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B006G5DV0V590@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:01:48 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CG1lqi022487 for ; Wed, 12 May 2010 16:01:48 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CEvgZm022990 for ; Wed, 12 May 2010 16:01:45 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 258923141273680084; Wed, 12 May 2010 09:01:24 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 09:01:23 -0700 Date: Wed, 12 May 2010 12:01:22 -0400 From: Sebastien Roy Subject: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] To: PSARC-ext Cc: Mark Haywood Message-id: <4BEAD0D2.7020705@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0207.4BEAD0EB.0121:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 12357 I'm submitting this fast-track for Mark Haywood. The release binding is Minor. Note that this case has a dependency on PSARC 2010/157. Background ========== The Solaris Next installers intend to use SMF properties, and install derived, SMF profiles to customize system configurations. This is driving the requirement that Solaris provide public interfaces, in the form of of SMF properties, which, when consumed, will provide an initial physical network interface configuration and an initial DNS client configuration for the installed system. This case proposes a set of SMF properties that will satisfy the following requirements: 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a physical interface. 2 - the ability to assign a default route to an IPv4 and/or IPv6 physical interface. 3 - the ability to configure a DNS client with a nameserver list, a search list and a domain. A subsequent ARC case will explain how the installers intend to consume the interfaces during install. Proposal ======== Two new SMF services will be created, svc:/network/install and svc:/network/dns/install. Each of these services will contain properties that will be used by the services to configure an initial physical network interface and/or an initial DNS client configuration. The services will initially be disabled with property values that will not result in any system configuration. As part of install, an SMF profile, enabling the services and containing the appropriate configuration property values for the services, will be applied to the system. On the first reboot following the install, the service start methods will check the properties to see if property values have been assigned. If so, then the services will use these property values to configure the system. The service start methods will terminate after deleting their service properties and disabling the services themselves. The svc:/network/install service will support configuring one IPv4 interface and/or one IPv6 interface and, optionally, a default route reachable by these interfaces. The service will define two property groups, one for an IPv4 interface and one for an IPv6 interface. The service will use its properties and ipadm(1M) to configure the network interfaces. And similarly, the service will use its properties and route(1M) to define a default route. The install_ipv4_interface property group will contain the following properties: name a required property of the property group and will contain the value that will be used as the value of when adding an IPv4 interface address. It has an SMF property type of 'astring'. address_type a required property and will contain the value that will be used to construct the -T option for the ipadm(1M) create-addr sub-command. Therefore, the valid values are “static” or “dhcp”. It has an SMF property type of 'astring'. static_address only required with an 'address_type' of “static” and will be used to construct the “local” address for the ipadm(1M) create-addr sub-command. It has an SMF property type of 'net_address_v4'. dhcp_wait optional property that only applies with an 'address_type' of “dhcp”. If defined, then the property value will be used to construct the “-w | forever” portion of the ipadm(1M) create-addr sub-command. It has an SMF property type of 'astring'. default_route an optional property whose value will be used to define a default route using route(1M). In other words, “/usr/sbin/route -p add default default-route -ifp ifname” (where ifname is the interface name portion of the 'name' property). It has an SMF property type of 'net_address_v4'. The install_ipv6_interface property group will contain the following properties: name a required property of the property group and will contain the value that will be used as the value of when adding an IPv6 interface address. It has an SMF property type of 'astring'. address_type a required property and will contain the value that will be used to construct the -T option for the ipadm(1M) create-addr sub-command. Therefore, the valid values are “static” or “addrconf”. It has an SMF property type of 'astring'. static_address only required with an 'address_type' of “static” and will be used to construct the “local” address for the ipadm(1M) create-addr sub-command. It has an SMF property type of 'net_address_v6'. interface_id an optional property that only applies with an 'address_type' of “addrconf”. If defined, then the property value will be used to construct the “-i interface_id” portion of the ipadm(1M) create-addr sub-command. It has an SMF property type of 'net_address_v6'. stateless an optional property that only applies with an 'address_type' of “addrconf”. If defined, then the property value will be used to construct the “-p stateless=yes|no” portion of the ipadm(1M) create-addr sub-command. It has an SMF property type of 'astring'. stateful an optional property that only applies with an 'address_type' of “addrconf”. If defined, then the property value will be used to construct the “-p stateful=yes|no” portion of the ipadm(1M) create-addr sub-command. It has an SMF property type of 'astring'. default_route an optional property whose value will be used to define a default route using route(1M). In other words, “/usr/sbin/route -p add default default-route -ifp ifname” (where ifname is the interface name portion of the 'name' property). It has an SMF property type of 'net_address_v6'. The svc:/network/dns/install service will support the configuration of a DNS client. The service will define one property group, install_props. The service will use its properties to construct a DNS resolv.conf(4) file. The install_props property group will contain the following properties: domain an optional property of the property group and, if defined, will contain the value of the local domain name. Its value will be used to construct the “domain” directive in resolv.conf(4). It has an SMF property type of 'astring'. nameserver a required property whose value will be used to construct the “nameserver” directives in resolv.conf(4). It has an SMF property type of 'net_address', but should contain an 'net_address_list' of IPv4 and/or IPv6 addresses. search an optional property that if defined, it will contain a value for the search order host name lookup. Its value will be used to construct the “search” directive in resolv.conf(4). It has an SMF property type of 'astring', but should contain an 'astring_list' of domain values. An example SMF profile configuring both IPv4 and IPv6 interfaces and a DNS client follows: 9 This case has a dependency on the new SMF property type, SCF_TYPE_NET_ADDR, described in PSARC/2010/157. The exported interfaces below are intended for Solaris Next (Minor binding) only. Interface Table Exported Interfaces Name Commitment Comments --------------------------------------------------------------------------- svc:/network/install Committed Network interface install service install_ipv4_interface Committed IPv4 network interface SMF property group install_ipv4_interface.name install_ipv4_interface.address_type install_ipv4_interface.static_address install_ipv4_interface.dhcp_wait install_ipv4_interface.default_route install_ipv6_interface Committed IPv6 network interface SMF property group install_ipv6_interface.name install_ipv6_interface.address_type install_ipv6_interface.static_address install_ipv6_interface.interface_id install_ipv6_interface.stateless install_ipv6_interface.stateful install_ipv6_interface.default_route svc:/network/dns/install Committed DNS client install svc install_props Committed DNS client configuration property group install_props.domain install_props.nameserver install_props.search Imported Interfaces Name Commitment Comments --------------------------------------------------------------------------- ipadm(1M) Committed Configure network interfaces route(1M) Committed Configure default routes resolv.conf(4) Committed DNS client configuration From Darren.Moffat@oracle.com Wed May 12 09:13:51 2010 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 o4CGDoIT007876 for ; Wed, 12 May 2010 09:13:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4CGDoG8040741 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 10:13:50 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2B00L0DEF2YO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:13:50 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00HIEEF1VEA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:13:49 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CGDnFY009452 for ; Wed, 12 May 2010 16:13:49 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CDoVjM011991 for ; Wed, 12 May 2010 16:13:48 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 258967491273680827; Wed, 12 May 2010 09:13:47 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 09:13:43 -0700 Date: Wed, 12 May 2010 17:13:40 +0100 From: Darren J Moffat Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD0D2.7020705@oracle.com> To: Sebastien Roy Cc: PSARC-ext , Mark Haywood Message-id: <4BEAD3B4.7050000@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BEAD3BC.019E:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 928 On 12/05/2010 17:01, Sebastien Roy wrote: > The svc:/network/install service will support configuring one IPv4 > interface and/or one IPv6 interface and, optionally, a default route > reachable by these interfaces. The service will define two property > groups, one for an IPv4 interface and one for an IPv6 interface. The > service will use its properties and ipadm(1M) to configure the network > interfaces. And similarly, the service will use its properties and > route(1M) to define a default route. Why is this limited to a single address for v4 and v6 ? Can multiple instances of network/install be created in a profile and be activated by the installer to create hosts with multiple IP addresses ? As is I believe possible today with jumpstart ? For the DNS configuration why are the resolv.conf "options", "sortlist" directives not supported for configuration in svc:/network/dns/install ? -- Darren J Moffat From carlsonj@workingcode.com Wed May 12 09:26:17 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CGQGhD008249 for ; Wed, 12 May 2010 09:26:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CGQGbi012136 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 09:26:16 -0700 (PDT) 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 <0L2B00C07EZSMH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 10:26:16 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00788EZR9S50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 10:26:15 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4CGHeES008059 for ; Wed, 12 May 2010 16:26:15 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-706132 for PSARC-ext@sun.com; Wed, 12 May 2010 16:26:08 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-147213603 for PSARC-ext@sun.com; Wed, 12 May 2010 16:26:06 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-5519682 for PSARC-ext@sun.com; Wed, 12 May 2010 16:26:05 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4CGPu27002309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 12:25:57 -0400 (EDT) Date: Wed, 12 May 2010 12:25:56 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD3B4.7050000@Oracle.COM> To: Darren J Moffat Cc: Sebastien Roy , Mark Haywood , PSARC-ext Message-id: <4BEAD694.5020106@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-URT-Metrics: carlson; whitelist X-Antispam: No, score=-0.7/5.0, scanned in 0.320sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BEAD0D2.7020705@oracle.com> <4BEAD3B4.7050000@Oracle.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1838 Darren J Moffat wrote: > On 12/05/2010 17:01, Sebastien Roy wrote: >> The svc:/network/install service will support configuring one IPv4 >> interface and/or one IPv6 interface and, optionally, a default route >> reachable by these interfaces. The service will define two property >> groups, one for an IPv4 interface and one for an IPv6 interface. The >> service will use its properties and ipadm(1M) to configure the network >> interfaces. And similarly, the service will use its properties and >> route(1M) to define a default route. > > Why is this limited to a single address for v4 and v6 ? > > Can multiple instances of network/install be created in a profile and be > activated by the installer to create hosts with multiple IP addresses ? > As is I believe possible today with jumpstart ? > > > For the DNS configuration why are the resolv.conf "options", "sortlist" > directives not supported for configuration in svc:/network/dns/install ? There seem to be quite a few issues in the same area: - Where are NIS and LDAP? Or are they not needed by this part of the installation process? - How does routing configuration work? Are "default routes" the only thing that's ever needed? - What about datalink configuration? - What about systems that need to have IPMP or other IP-level bits such as tunnels or IPsec? I think what might be missing here are the boundaries of this case. I'm a little queasy with the idea of assuming that the only interfaces that matter are available-at-boot Ethernet drivers with simple IP configuration and not much else, but perhaps it makes sense in some particular (limited?) context. Is there some case that describes what the "Solaris Next" installer can and can't do over a network? -- James Carlson 42.703N 71.076W From Milan.Jurik@sun.com Wed May 12 09:33:46 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CGXkOp008538 for ; Wed, 12 May 2010 09:33:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CGXjqN015950 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 09:33:46 -0700 (PDT) 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 <0L2B00D0DFC98500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 10:33:45 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B007TOFC89S50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 10:33:45 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4CGXiQO025352 for ; Wed, 12 May 2010 16:33:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2B00M00F15DA00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 17:33:24 +0100 (BST) Received: from [129.157.20.30] ([unknown] [129.157.20.30]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2B008XBFBOWNF0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 17:33:24 +0100 (BST) Date: Wed, 12 May 2010 18:33:21 +0200 From: Milan Jurik Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD0D2.7020705@oracle.com> Sender: Milan.Jurik@sun.com To: Sebastien Roy Cc: PSARC-ext , Mark Haywood Message-id: <1273682001.19291.31.camel@xylabone> Organization: Sun Microsystems - Prague Czech Republic MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4BEAD0D2.7020705@oracle.com> Status: RO Content-Length: 13151 Hi, why is it DNS-centric solution only? What about NIS-only environments? And why only hosts and ipnodes config? Best regards, Milan Sebastien Roy píše v st 12. 05. 2010 v 12:01 -0400: > I'm submitting this fast-track for Mark Haywood. The release binding > is Minor. Note that this case has a dependency on PSARC 2010/157. > > Background > ========== > The Solaris Next installers intend to use SMF properties, and install > derived, SMF profiles to customize system configurations. This is > driving the requirement that Solaris provide public interfaces, in the > form of of SMF properties, which, when consumed, will provide an > initial physical network interface configuration and an initial DNS > client configuration for the installed system. This case proposes a > set of SMF properties that will satisfy the following requirements: > > 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a > physical interface. > > 2 - the ability to assign a default route to an IPv4 and/or IPv6 > physical interface. > > 3 - the ability to configure a DNS client with a nameserver list, a > search list and a domain. > > A subsequent ARC case will explain how the installers intend to > consume the interfaces during install. > > Proposal > ======== > Two new SMF services will be created, svc:/network/install and > svc:/network/dns/install. Each of these services will contain > properties that will be used by the services to configure an initial > physical network interface and/or an initial DNS client > configuration. The services will initially be disabled with property > values that will not result in any system configuration. As part of > install, an SMF profile, enabling the services and containing the > appropriate configuration property values for the services, will be > applied to the system. On the first reboot following the install, the > service start methods will check the properties to see if property > values have been assigned. If so, then the services will use these > property values to configure the system. The service start methods > will terminate after deleting their service properties and disabling > the services themselves. > > The svc:/network/install service will support configuring one IPv4 > interface and/or one IPv6 interface and, optionally, a default route > reachable by these interfaces. The service will define two property > groups, one for an IPv4 interface and one for an IPv6 interface. The > service will use its properties and ipadm(1M) to configure the network > interfaces. And similarly, the service will use its properties and > route(1M) to define a default route. > > The install_ipv4_interface property group will contain the following > properties: > > name a required property of the property group and will > contain the value that will be used as the value of > when adding an IPv4 interface address. It > has an SMF property type of 'astring'. > > address_type a required property and will contain the value that > will be used to construct the -T option for the > ipadm(1M) create-addr sub-command. Therefore, the > valid values are “static” or “dhcp”. It has an SMF > property type of 'astring'. > > static_address only required with an 'address_type' of “static” and > will be used to construct the “local” address for > the ipadm(1M) create-addr sub-command. It has an SMF > property type of 'net_address_v4'. > > dhcp_wait optional property that only applies with an > 'address_type' of “dhcp”. If defined, then the > property value will be used to construct the “-w > | forever” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > default_route an optional property whose value will be used to > define a default route using route(1M). In other > words, “/usr/sbin/route -p add default default-route > -ifp ifname” (where ifname is the interface name > portion of the 'name' property). It has an SMF > property type of 'net_address_v4'. > > The install_ipv6_interface property group will contain the following > properties: > > name a required property of the property group and will > contain the value that will be used as the value of > when adding an IPv6 interface address. It > has an SMF property type of 'astring'. > > address_type a required property and will contain the value that > will be used to construct the -T option for the > ipadm(1M) create-addr sub-command. Therefore, the > valid values are “static” or “addrconf”. It has an > SMF property type of 'astring'. > > static_address only required with an 'address_type' of “static” and > will be used to construct the “local” address for > the ipadm(1M) create-addr sub-command. It has an SMF > property type of 'net_address_v6'. > > interface_id an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-i > interface_id” portion of the ipadm(1M) create-addr > sub-command. It has an SMF property type of > 'net_address_v6'. > > stateless an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-p > stateless=yes|no” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > stateful an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-p > stateful=yes|no” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > default_route an optional property whose value will be used to > define a default route using route(1M). In other > words, “/usr/sbin/route -p add default default-route > -ifp ifname” (where ifname is the interface name > portion of the 'name' property). It has an SMF > property type of 'net_address_v6'. > > The svc:/network/dns/install service will support the configuration of > a DNS client. The service will define one property group, > install_props. The service will use its properties to construct a DNS > resolv.conf(4) file. > > The install_props property group will contain the following > properties: > > domain an optional property of the property group and, if > defined, will contain the value of the local domain > name. Its value will be used to construct the > “domain” directive in resolv.conf(4). It has an SMF > property type of 'astring'. > > nameserver a required property whose value will be used to > construct the “nameserver” directives in > resolv.conf(4). It has an SMF property type of > 'net_address', but should contain an > 'net_address_list' of IPv4 and/or IPv6 addresses. > > search an optional property that if defined, it will > contain a value for the search order host name > lookup. Its value will be used to construct the > “search” directive in resolv.conf(4). It has an SMF > property type of 'astring', but should contain an > 'astring_list' of domain values. > > An example SMF profile configuring both IPv4 and IPv6 interfaces and a > DNS client follows: > > > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> > > > > > > > > > > value='10.4.235.146/24' /> > value='10.4.235.1' /> > > > > > 9 > value='::0/0' /> > value='::abcd/64' /> > > > value='::0' /> > > > > > > > > > > > > > > > > > > > > > > > > > This case has a dependency on the new SMF property type, > SCF_TYPE_NET_ADDR, described in PSARC/2010/157. > > The exported interfaces below are intended for Solaris Next (Minor > binding) only. > > Interface Table > > Exported Interfaces > > Name Commitment Comments > --------------------------------------------------------------------------- > svc:/network/install Committed Network interface install > service > install_ipv4_interface Committed IPv4 network interface > SMF property group > install_ipv4_interface.name > install_ipv4_interface.address_type > install_ipv4_interface.static_address > install_ipv4_interface.dhcp_wait > install_ipv4_interface.default_route > > install_ipv6_interface Committed IPv6 network interface > SMF property group > install_ipv6_interface.name > install_ipv6_interface.address_type > install_ipv6_interface.static_address > install_ipv6_interface.interface_id > install_ipv6_interface.stateless > install_ipv6_interface.stateful > install_ipv6_interface.default_route > > svc:/network/dns/install Committed DNS client install svc > install_props Committed DNS client configuration > property group > install_props.domain > install_props.nameserver > install_props.search > > Imported Interfaces > Name Commitment Comments > --------------------------------------------------------------------------- > ipadm(1M) Committed Configure network interfaces > route(1M) Committed Configure default routes > resolv.conf(4) Committed DNS client configuration From ro@CeBiTec.Uni-Bielefeld.DE Wed May 12 09:37:04 2010 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 o4CGb3nT008555 for ; Wed, 12 May 2010 09:37:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CGb383017428 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 09:37:03 -0700 (PDT) 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 <0L2B00M23FHRPR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:37:03 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00KUQFHP6A00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:37:02 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CGVNe8020169 for ; Wed, 12 May 2010 16:37:01 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-417331 for PSARC-ext@sun.com; Wed, 12 May 2010 16:37:01 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-148886245 for PSARC-ext@sun.com; Wed, 12 May 2010 16:37:00 +0000 (Z) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([129.70.160.84] [129.70.160.84]) by relay4i.sun.com with ESMTP id BT-MMP-55239811 for PSARC-ext@sun.com; Wed, 12 May 2010 16:36:59 +0000 (Z) Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 5149729E; Wed, 12 May 2010 18:36:59 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 91moy+ePsaKH; Wed, 12 May 2010 18:36:57 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id C8C4729D; Wed, 12 May 2010 18:36:57 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.3+Sun/8.14.3/Submit) id o4CGavVT018848; Wed, 12 May 2010 18:36:57 +0200 (MEST) Date: Wed, 12 May 2010 18:36:57 +0200 From: Rainer Orth Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD0D2.7020705@oracle.com> To: Sebastien Roy Cc: PSARC-ext , Mark Haywood Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: amavisd-new at cebitec.uni-bielefeld.de X-Antispam: No, score=0.0/5.0, scanned in 0.742sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BEAD0D2.7020705@oracle.com> X-Authentication-warning: manam.CeBiTec.Uni-Bielefeld.DE: ro set sender to ro@CeBiTec.Uni-Bielefeld.DE using -f User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) Status: RO Content-Length: 1189 Sebastien Roy writes: > Proposal > ======== > Two new SMF services will be created, svc:/network/install and > svc:/network/dns/install. Each of these services will contain Is this really restricted to install time? I would think sys-unconfig could make use of those services as well. I'd prefer svc:/network/config and svc:/network/dns/config instead. > The install_ipv4_interface property group will contain the following > properties: Nit: why the install_ prefix here? Since this is a property group of network/install (or network/config), just drop the prefix. > The install_ipv6_interface property group will contain the following > properties: Same here ... > The svc:/network/dns/install service will support the configuration of > a DNS client. The service will define one property group, > install_props. The service will use its properties to construct a DNS > resolv.conf(4) file. > > The install_props property group will contain the following > properties: ... and here: simply props? Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From mark.haywood@oracle.com Wed May 12 11:00:26 2010 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 o4CI0Q78011361 for ; Wed, 12 May 2010 11:00:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CI0Q9D020831 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 11:00:26 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2B00305JCQX000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 11:00:26 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B000DQJCPZP30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 11:00:25 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CI0P99016843 for ; Wed, 12 May 2010 18:00:25 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CHxxUD016659 for ; Wed, 12 May 2010 18:00:24 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 259320161273687214; Wed, 12 May 2010 11:00:14 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 11:00:13 -0700 Date: Wed, 12 May 2010 14:01:28 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD3B4.7050000@Oracle.COM> To: Darren J Moffat Cc: Sebastien Roy , PSARC-ext Message-id: <4BEAECF8.9010705@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BEAECB8.01AD:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <4BEAD3B4.7050000@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 1428 On 05/12/10 12:13 PM, Darren J Moffat wrote: > On 12/05/2010 17:01, Sebastien Roy wrote: >> The svc:/network/install service will support configuring one IPv4 >> interface and/or one IPv6 interface and, optionally, a default route >> reachable by these interfaces. The service will define two property >> groups, one for an IPv4 interface and one for an IPv6 interface. The >> service will use its properties and ipadm(1M) to configure the network >> interfaces. And similarly, the service will use its properties and >> route(1M) to define a default route. > > Why is this limited to a single address for v4 and v6 ? Because at the moment, that's all that the Install team knows that they need. > > Can multiple instances of network/install be created in a profile and > be activated by the installer to create hosts with multiple IP > addresses ? As is I believe possible today with jumpstart ? The Install team has not yet indicated a need to support multiple IP addresses. However, this proposal was made taking into account that this request might come later. There is nothing about this proposal that will prevent support for multiple IP addresses in the future. > > > For the DNS configuration why are the resolv.conf "options", > "sortlist" directives not supported for configuration in > svc:/network/dns/install ? Again, no need yet identified. But nothing prevents supporting it if the need arises. From mark.haywood@oracle.com Wed May 12 11:17:41 2010 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 o4CIHfl8011631 for ; Wed, 12 May 2010 11:17:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CIHeFP027783 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 11:17:41 -0700 (PDT) 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 <0L2B00M07K5GB500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 12:17:40 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B007Y7K5F9TA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 12:17:39 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4CIHcSM001620 for ; Wed, 12 May 2010 18:17:39 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CCeN4N001682; Wed, 12 May 2010 18:17:27 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 259380061273688199; Wed, 12 May 2010 11:16:39 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 11:16:38 -0700 Date: Wed, 12 May 2010 14:17:51 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD694.5020106@workingcode.com> To: James Carlson Cc: Darren J Moffat , Sebastien Roy , PSARC-ext Message-id: <4BEAF0CF.6090805@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BEAF0B7.00A7:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <4BEAD3B4.7050000@Oracle.COM> <4BEAD694.5020106@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 3397 On 05/12/10 12:25 PM, James Carlson wrote: > Darren J Moffat wrote: > >> On 12/05/2010 17:01, Sebastien Roy wrote: >> >>> The svc:/network/install service will support configuring one IPv4 >>> interface and/or one IPv6 interface and, optionally, a default route >>> reachable by these interfaces. The service will define two property >>> groups, one for an IPv4 interface and one for an IPv6 interface. The >>> service will use its properties and ipadm(1M) to configure the network >>> interfaces. And similarly, the service will use its properties and >>> route(1M) to define a default route. >>> >> Why is this limited to a single address for v4 and v6 ? >> >> Can multiple instances of network/install be created in a profile and be >> activated by the installer to create hosts with multiple IP addresses ? >> As is I believe possible today with jumpstart ? >> >> >> For the DNS configuration why are the resolv.conf "options", "sortlist" >> directives not supported for configuration in svc:/network/dns/install ? >> > There seem to be quite a few issues in the same area: > > - Where are NIS and LDAP? Or are they not needed by this part of > the installation process? > They are missing. But as of yet there has been no requirement for their support. Nothing about this proposal prevents the addition of interfaces to support them in the future. > - How does routing configuration work? Are "default routes" the only > thing that's ever needed? > At the moment, the only requirement is that we can configure a default route. > - What about datalink configuration? > What about it? This proposal isn't trying to solve every possible network configuration possibility. If we need to support datalink configuration, then we'll ARC interfaces when the need arises. > - What about systems that need to have IPMP or other IP-level bits > such as tunnels or IPsec? > Again, we're not trying to support all networking configuration possibilities with this proposal. We're trying to provide the Install team with the interfaces that they need to fulfill their requirements of being able to configure one IP interface, a default router for that interface and a DNS client. This proposal is trying to satisfy those requirements without limiting future requirements. If future requirements require a change to the interfaces proposed here, then the interfaces can be adjusted at that time. > I think what might be missing here are the boundaries of this case. I'm > a little queasy with the idea of assuming that the only interfaces that > matter are available-at-boot Ethernet drivers with simple IP > configuration and not much else, but perhaps it makes sense in some > particular (limited?) context. > It makes sense in the context I mentioned above. We'd be very surprised if more requirements don't appear before the Solaris Next release. The interfaces proposed here may have to change as a result. But at the moment, the Install team has identified the requirements already described above. And this proposal is intended to meet those requirements. > Is there some case that describes what the "Solaris Next" installer can > and can't do over a network? > > I don't think there is one yet. As I mentioned in the proposal, I expect the Install team to ARC a case for AI at some point. From mark.haywood@oracle.com Wed May 12 11:26:38 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CIQcpn011667 for ; Wed, 12 May 2010 11:26:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CIQaN7010409; Wed, 12 May 2010 13:26:36 -0500 (CDT) 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 <0L2B00N03KKC3100@brm-avmta-1.central.sun.com>; Wed, 12 May 2010 12:26:36 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B007N4KKC9XB0@brm-avmta-1.central.sun.com>; Wed, 12 May 2010 12:26:36 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4CIQaQ8011202; Wed, 12 May 2010 18:26:36 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CFmsJW020625; Wed, 12 May 2010 18:26:34 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 259412791273688758; Wed, 12 May 2010 11:25:58 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 11:25:57 -0700 Date: Wed, 12 May 2010 14:27:10 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <1273682001.19291.31.camel@xylabone> To: Milan Jurik Cc: Sebastien Roy , PSARC-ext Message-id: <4BEAF2FE.3030907@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BEAF2DB.0089:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <1273682001.19291.31.camel@xylabone> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 13827 On 05/12/10 12:33 PM, Milan Jurik wrote: > Hi, > > why is it DNS-centric solution only? What about NIS-only environments? > And why only hosts and ipnodes config? > Nothing about this proposal excludes future support for NIS or LDAP. I don't believe that whether or not they are supported by install is not an architectural issue. However, if there is an architectural concern, we should address that concern. > Best regards, > > Milan > > Sebastien Roy píše v st 12. 05. 2010 v 12:01 -0400: > >> I'm submitting this fast-track for Mark Haywood. The release binding >> is Minor. Note that this case has a dependency on PSARC 2010/157. >> >> Background >> ========== >> The Solaris Next installers intend to use SMF properties, and install >> derived, SMF profiles to customize system configurations. This is >> driving the requirement that Solaris provide public interfaces, in the >> form of of SMF properties, which, when consumed, will provide an >> initial physical network interface configuration and an initial DNS >> client configuration for the installed system. This case proposes a >> set of SMF properties that will satisfy the following requirements: >> >> 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a >> physical interface. >> >> 2 - the ability to assign a default route to an IPv4 and/or IPv6 >> physical interface. >> >> 3 - the ability to configure a DNS client with a nameserver list, a >> search list and a domain. >> >> A subsequent ARC case will explain how the installers intend to >> consume the interfaces during install. >> >> Proposal >> ======== >> Two new SMF services will be created, svc:/network/install and >> svc:/network/dns/install. Each of these services will contain >> properties that will be used by the services to configure an initial >> physical network interface and/or an initial DNS client >> configuration. The services will initially be disabled with property >> values that will not result in any system configuration. As part of >> install, an SMF profile, enabling the services and containing the >> appropriate configuration property values for the services, will be >> applied to the system. On the first reboot following the install, the >> service start methods will check the properties to see if property >> values have been assigned. If so, then the services will use these >> property values to configure the system. The service start methods >> will terminate after deleting their service properties and disabling >> the services themselves. >> >> The svc:/network/install service will support configuring one IPv4 >> interface and/or one IPv6 interface and, optionally, a default route >> reachable by these interfaces. The service will define two property >> groups, one for an IPv4 interface and one for an IPv6 interface. The >> service will use its properties and ipadm(1M) to configure the network >> interfaces. And similarly, the service will use its properties and >> route(1M) to define a default route. >> >> The install_ipv4_interface property group will contain the following >> properties: >> >> name a required property of the property group and will >> contain the value that will be used as the value of >> when adding an IPv4 interface address. It >> has an SMF property type of 'astring'. >> >> address_type a required property and will contain the value that >> will be used to construct the -T option for the >> ipadm(1M) create-addr sub-command. Therefore, the >> valid values are “static” or “dhcp”. It has an SMF >> property type of 'astring'. >> >> static_address only required with an 'address_type' of “static” and >> will be used to construct the “local” address for >> the ipadm(1M) create-addr sub-command. It has an SMF >> property type of 'net_address_v4'. >> >> dhcp_wait optional property that only applies with an >> 'address_type' of “dhcp”. If defined, then the >> property value will be used to construct the “-w >> | forever” portion of the ipadm(1M) >> create-addr sub-command. It has an SMF property type >> of 'astring'. >> >> default_route an optional property whose value will be used to >> define a default route using route(1M). In other >> words, “/usr/sbin/route -p add default default-route >> -ifp ifname” (where ifname is the interface name >> portion of the 'name' property). It has an SMF >> property type of 'net_address_v4'. >> >> The install_ipv6_interface property group will contain the following >> properties: >> >> name a required property of the property group and will >> contain the value that will be used as the value of >> when adding an IPv6 interface address. It >> has an SMF property type of 'astring'. >> >> address_type a required property and will contain the value that >> will be used to construct the -T option for the >> ipadm(1M) create-addr sub-command. Therefore, the >> valid values are “static” or “addrconf”. It has an >> SMF property type of 'astring'. >> >> static_address only required with an 'address_type' of “static” and >> will be used to construct the “local” address for >> the ipadm(1M) create-addr sub-command. It has an SMF >> property type of 'net_address_v6'. >> >> interface_id an optional property that only applies with an >> 'address_type' of “addrconf”. If defined, then the >> property value will be used to construct the “-i >> interface_id” portion of the ipadm(1M) create-addr >> sub-command. It has an SMF property type of >> 'net_address_v6'. >> >> stateless an optional property that only applies with an >> 'address_type' of “addrconf”. If defined, then the >> property value will be used to construct the “-p >> stateless=yes|no” portion of the ipadm(1M) >> create-addr sub-command. It has an SMF property type >> of 'astring'. >> >> stateful an optional property that only applies with an >> 'address_type' of “addrconf”. If defined, then the >> property value will be used to construct the “-p >> stateful=yes|no” portion of the ipadm(1M) >> create-addr sub-command. It has an SMF property type >> of 'astring'. >> >> default_route an optional property whose value will be used to >> define a default route using route(1M). In other >> words, “/usr/sbin/route -p add default default-route >> -ifp ifname” (where ifname is the interface name >> portion of the 'name' property). It has an SMF >> property type of 'net_address_v6'. >> >> The svc:/network/dns/install service will support the configuration of >> a DNS client. The service will define one property group, >> install_props. The service will use its properties to construct a DNS >> resolv.conf(4) file. >> >> The install_props property group will contain the following >> properties: >> >> domain an optional property of the property group and, if >> defined, will contain the value of the local domain >> name. Its value will be used to construct the >> “domain” directive in resolv.conf(4). It has an SMF >> property type of 'astring'. >> >> nameserver a required property whose value will be used to >> construct the “nameserver” directives in >> resolv.conf(4). It has an SMF property type of >> 'net_address', but should contain an >> 'net_address_list' of IPv4 and/or IPv6 addresses. >> >> search an optional property that if defined, it will >> contain a value for the search order host name >> lookup. Its value will be used to construct the >> “search” directive in resolv.conf(4). It has an SMF >> property type of 'astring', but should contain an >> 'astring_list' of domain values. >> >> An example SMF profile configuring both IPv4 and IPv6 interfaces and a >> DNS client follows: >> >> >> > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> >> >> >> >> >> >> >> >> >> >> > value='10.4.235.146/24' /> >> > value='10.4.235.1' /> >> >> >> >> >> 9 >> > value='::0/0' /> >> > value='::abcd/64' /> >> >> >> > value='::0' /> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> This case has a dependency on the new SMF property type, >> SCF_TYPE_NET_ADDR, described in PSARC/2010/157. >> >> The exported interfaces below are intended for Solaris Next (Minor >> binding) only. >> >> Interface Table >> >> Exported Interfaces >> >> Name Commitment Comments >> --------------------------------------------------------------------------- >> svc:/network/install Committed Network interface install >> service >> install_ipv4_interface Committed IPv4 network interface >> SMF property group >> install_ipv4_interface.name >> install_ipv4_interface.address_type >> install_ipv4_interface.static_address >> install_ipv4_interface.dhcp_wait >> install_ipv4_interface.default_route >> >> install_ipv6_interface Committed IPv6 network interface >> SMF property group >> install_ipv6_interface.name >> install_ipv6_interface.address_type >> install_ipv6_interface.static_address >> install_ipv6_interface.interface_id >> install_ipv6_interface.stateless >> install_ipv6_interface.stateful >> install_ipv6_interface.default_route >> >> svc:/network/dns/install Committed DNS client install svc >> install_props Committed DNS client configuration >> property group >> install_props.domain >> install_props.nameserver >> install_props.search >> >> Imported Interfaces >> Name Commitment Comments >> --------------------------------------------------------------------------- >> ipadm(1M) Committed Configure network interfaces >> route(1M) Committed Configure default routes >> resolv.conf(4) Committed DNS client configuration >> > > From peter.tribble@gmail.com Wed May 12 11:35:01 2010 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 o4CIZ1Rt011798 for ; Wed, 12 May 2010 11:35:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CIZ1Qe003798 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 11:35:01 -0700 (PDT) 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 <0L2B00501KYC7H00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 11:35:01 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00K6HKYC6970@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 11:35:00 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CIVT3N018996 for ; Wed, 12 May 2010 18:35:00 +0000 (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-3318182 for PSARC-ext@sun.com; Wed, 12 May 2010 18:32:59 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-202151575 for PSARC-ext@sun.com; Wed, 12 May 2010 18:32:59 +0000 (Z) Received: from mail-fx0-f49.google.com ([209.85.161.49] [209.85.161.49]) by relay1i.sun.com with ESMTP id BT-MMP-59988041 for PSARC-ext@sun.com; Wed, 12 May 2010 18:32:58 +0000 (Z) Received: by fxm17 with SMTP id 17so409683fxm.8 for ; Wed, 12 May 2010 11:32:47 -0700 (PDT) Received: by 10.204.3.137 with SMTP id 9mr959962bkn.6.1273689166908; Wed, 12 May 2010 11:32:46 -0700 (PDT) Received: by 10.204.121.209 with HTTP; Wed, 12 May 2010 11:32:46 -0700 (PDT) Date: Wed, 12 May 2010 19:32:46 +0100 From: Peter Tribble Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD0D2.7020705@oracle.com> To: Sebastien Roy Cc: PSARC-ext , Mark Haywood Message-id: MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aKB//14KufLeZdpe3/bITt08R0SN4aynA+9iQppoIQU=; b=IuEJIPiVe7R83s0OBoj6uegwaURJ1/4fo7n4nVmuFi0aVfT1adxAXaaGADWQB/onde qeofbSRfelVgV1MVnkublY0x9JRPgC9t90hDiV6AcBoTffLHqJcLj4qm6YH+ggIv04m5 1prRHbB0nS72/36azE/+zLMhDx5BTNiqFkM2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P7Rc0M1h0dTaWPiTI5QV3lW5SvwCCNqjW5Hnvjt+3Axxb28MaUndojb5965iiVCF14 Y8WJYDxCRHrcRHrpnGvucEwUcJfx7PrP+xynE7BKmOCKVg7PuiCkKk0roTqpSMMWY6xF HTYthfGbNdNPES0Z6Q1xKMRCJnJQhFpNhBARA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.483sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BEAD0D2.7020705@oracle.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o4CIZ1Rt011798 Status: RO Content-Length: 8575 On Wed, May 12, 2010 at 5:01 PM, Sebastien Roy wrote: > I'm submitting this fast-track for Mark Haywood.  The release binding > is Minor.  Note that this case has a dependency on PSARC 2010/157. > > Background > ========== > The Solaris Next installers intend to use SMF properties, and install > derived, SMF profiles to customize system configurations. This is > driving the requirement that Solaris provide public interfaces, in the > form of of SMF properties, which, when consumed, will provide an > initial physical network interface configuration and an initial DNS > client configuration for the installed system. This case proposes a > set of SMF properties that will satisfy the following requirements: > > 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a >    physical interface. Only one interface, or can multiple interfaces be configured? How do you assign multiple addresses (and VLANs) to an interface? More complicated objects? > 2 - the ability to assign a default route to an IPv4 and/or IPv6 >    physical interface. Hm. Multiple default routes? Non-default routes? > 3 - the ability to configure a DNS client with a nameserver list, a >    search list and a domain. Doing this using SMF profiles is just plain broken. As an administrator, the requirement is to supply a fully correct /etc/resolv.conf file and for the installer to simply copy it to the installed system. Going through the hoops of an SMF profile (worse, expecting administrators to mangle the XML in such) that supports a non-extensible set of options in the hope that it will produce the right output. Well, yurk. > The install_ipv4_interface property group will contain the following > properties: > > name              a required property of the property group and will >                  contain the value that will be used as the value of >                   when adding an IPv4 interface address. It >                  has an SMF property type of 'astring'. What does this mean? Is this the interface name eg bge0? How do you deal with the common case we use in sysidcfg of the PRIMARY interface? > address_type      a required property and will contain the value that >                  will be used to construct the -T option for the >                  ipadm(1M) create-addr sub-command. Therefore, the >                  valid values are “static” or “dhcp”. It has an SMF >                  property type of 'astring'. There's a dependency between this value and the dns service, in that if dhcp then resolv.conf comes from dhcp. (Or does it?) > static_address    only required with an 'address_type' of “static” and >                  will be used to construct the “local” address for >                  the ipadm(1M) create-addr sub-command. It has an SMF >                  property type of 'net_address_v4'. So this has to be an address, right? (As opposed to the relatively common practice of supplying the name and relying on /etc/inet/hosts having the mapping from name to address.) > dhcp_wait         optional property that only applies with an >                  'address_type' of “dhcp”. If defined, then the >                  property value will be used to construct the “-w >                   | forever” portion of the ipadm(1M) >                  create-addr sub-command. It has an SMF property type >                  of 'astring'. > > default_route     an optional property whose value will be used to >                  define a default route using route(1M). In other >                  words, “/usr/sbin/route -p add default default-route >                  -ifp ifname” (where ifname is the interface name >                  portion of the 'name' property). It has an SMF >                  property type of 'net_address_v4'. > The svc:/network/dns/install service will support the configuration of > a DNS client. Does it ensure that nsswitch.conf includes dns? (Or is dns included by default - which it should be.) > The service will define one property group, > install_props. The service will use its properties to construct a DNS > resolv.conf(4) file. > > The install_props property group will contain the following > properties: > > domain            an optional property of the property group and, if >                  defined, will contain the value of the local domain >                  name. Its value will be used to construct the >                  “domain” directive in resolv.conf(4). It has an SMF >                  property type of 'astring'. > > nameserver        a required property whose value will be used to >                  construct the “nameserver” directives in >                  resolv.conf(4). It has an SMF property type of >                  'net_address', but should contain an >                  'net_address_list' of IPv4 and/or IPv6 addresses. > > search            an optional property that if defined, it will >                  contain a value for the search order host name >                  lookup. Its value will be used to construct the >                  “search” directive in resolv.conf(4). It has an SMF >                  property type of 'astring', but should contain an >                  'astring_list' of domain values. What about sortlist and options? What if resolv.conf is extended to support additional directives in the future? > An example SMF profile configuring both IPv4 and IPv6 interfaces and a > DNS client follows: > > > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> > >     >         >     Something seems incomplete here. If nwam is enabled, then is the static configuration used or ignored? >     >         >         >             >             >                            value='10.4.235.146/24' /> Do I have to specify the type='net_address_v4' bit, or can the be left out and inferred? Looking at the /24 makes me ask: how are broadcast addresses and the netmask defined? >                            value='10.4.235.1' /> >         >         >             >             >                                                  9 >                            value='::0/0' /> >                            value='::abcd/64' /> >             >             >                            value='::0' /> >         >     >     >         >         >             >                 >                     >                     >                     >                     >                 >             >             >             >                 >                     >                     >                 >             >         >     > The above example contains both domain and search, which is setting a bad example. But if both are supplied, what is the ordering? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From Milan.Jurik@Sun.COM Wed May 12 11:47:34 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CIlYq0012030 for ; Wed, 12 May 2010 11:47:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CIlXa1020195 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 13:47:33 -0500 (CDT) 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 <0L2B00101LJ9U000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 12:47:33 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B0073VLJ89WB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 12:47:33 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4CIlVFQ018626 for ; Wed, 12 May 2010 18:47:32 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2B00400LENWR00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 19:47:26 +0100 (BST) Received: from [192.168.1.100] ([unknown] [86.49.42.98]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2B0026XLJ1XZ10@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 19:47:26 +0100 (BST) Date: Wed, 12 May 2010 20:47:24 +0200 From: Milan Jurik Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAF2FE.3030907@oracle.com> Sender: Milan.Jurik@Sun.COM To: Mark Haywood Cc: Sebastien Roy , PSARC-ext Message-id: <1273690044.3216.11.camel@xylabtecra> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4BEAD0D2.7020705@oracle.com> <1273682001.19291.31.camel@xylabone> <4BEAF2FE.3030907@oracle.com> Status: RO Content-Length: 14733 Hi Mark, Mark Haywood píše v st 12. 05. 2010 v 14:27 -0400: > On 05/12/10 12:33 PM, Milan Jurik wrote: > > Hi, > > > > why is it DNS-centric solution only? What about NIS-only environments? > > And why only hosts and ipnodes config? > > > > > Nothing about this proposal excludes future support for NIS or LDAP. I > don't believe that whether or not they are supported by install is not > an architectural issue. However, if there is an architectural concern, > we should address that concern. > I agree it is not necessary to implement all possibilities at once and by your "I-team" and it is concern about consumers of this interface because they remain DNS-centric. I would like to have confirmed it will not stay as the only one option forever. Best regards, Milan > > > Best regards, > > > > Milan > > > > Sebastien Roy píše v st 12. 05. 2010 v 12:01 -0400: > > > >> I'm submitting this fast-track for Mark Haywood. The release binding > >> is Minor. Note that this case has a dependency on PSARC 2010/157. > >> > >> Background > >> ========== > >> The Solaris Next installers intend to use SMF properties, and install > >> derived, SMF profiles to customize system configurations. This is > >> driving the requirement that Solaris provide public interfaces, in the > >> form of of SMF properties, which, when consumed, will provide an > >> initial physical network interface configuration and an initial DNS > >> client configuration for the installed system. This case proposes a > >> set of SMF properties that will satisfy the following requirements: > >> > >> 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a > >> physical interface. > >> > >> 2 - the ability to assign a default route to an IPv4 and/or IPv6 > >> physical interface. > >> > >> 3 - the ability to configure a DNS client with a nameserver list, a > >> search list and a domain. > >> > >> A subsequent ARC case will explain how the installers intend to > >> consume the interfaces during install. > >> > >> Proposal > >> ======== > >> Two new SMF services will be created, svc:/network/install and > >> svc:/network/dns/install. Each of these services will contain > >> properties that will be used by the services to configure an initial > >> physical network interface and/or an initial DNS client > >> configuration. The services will initially be disabled with property > >> values that will not result in any system configuration. As part of > >> install, an SMF profile, enabling the services and containing the > >> appropriate configuration property values for the services, will be > >> applied to the system. On the first reboot following the install, the > >> service start methods will check the properties to see if property > >> values have been assigned. If so, then the services will use these > >> property values to configure the system. The service start methods > >> will terminate after deleting their service properties and disabling > >> the services themselves. > >> > >> The svc:/network/install service will support configuring one IPv4 > >> interface and/or one IPv6 interface and, optionally, a default route > >> reachable by these interfaces. The service will define two property > >> groups, one for an IPv4 interface and one for an IPv6 interface. The > >> service will use its properties and ipadm(1M) to configure the network > >> interfaces. And similarly, the service will use its properties and > >> route(1M) to define a default route. > >> > >> The install_ipv4_interface property group will contain the following > >> properties: > >> > >> name a required property of the property group and will > >> contain the value that will be used as the value of > >> when adding an IPv4 interface address. It > >> has an SMF property type of 'astring'. > >> > >> address_type a required property and will contain the value that > >> will be used to construct the -T option for the > >> ipadm(1M) create-addr sub-command. Therefore, the > >> valid values are “static” or “dhcp”. It has an SMF > >> property type of 'astring'. > >> > >> static_address only required with an 'address_type' of “static” and > >> will be used to construct the “local” address for > >> the ipadm(1M) create-addr sub-command. It has an SMF > >> property type of 'net_address_v4'. > >> > >> dhcp_wait optional property that only applies with an > >> 'address_type' of “dhcp”. If defined, then the > >> property value will be used to construct the “-w > >> | forever” portion of the ipadm(1M) > >> create-addr sub-command. It has an SMF property type > >> of 'astring'. > >> > >> default_route an optional property whose value will be used to > >> define a default route using route(1M). In other > >> words, “/usr/sbin/route -p add default default-route > >> -ifp ifname” (where ifname is the interface name > >> portion of the 'name' property). It has an SMF > >> property type of 'net_address_v4'. > >> > >> The install_ipv6_interface property group will contain the following > >> properties: > >> > >> name a required property of the property group and will > >> contain the value that will be used as the value of > >> when adding an IPv6 interface address. It > >> has an SMF property type of 'astring'. > >> > >> address_type a required property and will contain the value that > >> will be used to construct the -T option for the > >> ipadm(1M) create-addr sub-command. Therefore, the > >> valid values are “static” or “addrconf”. It has an > >> SMF property type of 'astring'. > >> > >> static_address only required with an 'address_type' of “static” and > >> will be used to construct the “local” address for > >> the ipadm(1M) create-addr sub-command. It has an SMF > >> property type of 'net_address_v6'. > >> > >> interface_id an optional property that only applies with an > >> 'address_type' of “addrconf”. If defined, then the > >> property value will be used to construct the “-i > >> interface_id” portion of the ipadm(1M) create-addr > >> sub-command. It has an SMF property type of > >> 'net_address_v6'. > >> > >> stateless an optional property that only applies with an > >> 'address_type' of “addrconf”. If defined, then the > >> property value will be used to construct the “-p > >> stateless=yes|no” portion of the ipadm(1M) > >> create-addr sub-command. It has an SMF property type > >> of 'astring'. > >> > >> stateful an optional property that only applies with an > >> 'address_type' of “addrconf”. If defined, then the > >> property value will be used to construct the “-p > >> stateful=yes|no” portion of the ipadm(1M) > >> create-addr sub-command. It has an SMF property type > >> of 'astring'. > >> > >> default_route an optional property whose value will be used to > >> define a default route using route(1M). In other > >> words, “/usr/sbin/route -p add default default-route > >> -ifp ifname” (where ifname is the interface name > >> portion of the 'name' property). It has an SMF > >> property type of 'net_address_v6'. > >> > >> The svc:/network/dns/install service will support the configuration of > >> a DNS client. The service will define one property group, > >> install_props. The service will use its properties to construct a DNS > >> resolv.conf(4) file. > >> > >> The install_props property group will contain the following > >> properties: > >> > >> domain an optional property of the property group and, if > >> defined, will contain the value of the local domain > >> name. Its value will be used to construct the > >> “domain” directive in resolv.conf(4). It has an SMF > >> property type of 'astring'. > >> > >> nameserver a required property whose value will be used to > >> construct the “nameserver” directives in > >> resolv.conf(4). It has an SMF property type of > >> 'net_address', but should contain an > >> 'net_address_list' of IPv4 and/or IPv6 addresses. > >> > >> search an optional property that if defined, it will > >> contain a value for the search order host name > >> lookup. Its value will be used to construct the > >> “search” directive in resolv.conf(4). It has an SMF > >> property type of 'astring', but should contain an > >> 'astring_list' of domain values. > >> > >> An example SMF profile configuring both IPv4 and IPv6 interfaces and a > >> DNS client follows: > >> > >> > >> >> '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> value='10.4.235.146/24' /> > >> >> value='10.4.235.1' /> > >> > >> > >> > >> > >> 9 > >> >> value='::0/0' /> > >> >> value='::abcd/64' /> > >> > >> > >> >> value='::0' /> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> This case has a dependency on the new SMF property type, > >> SCF_TYPE_NET_ADDR, described in PSARC/2010/157. > >> > >> The exported interfaces below are intended for Solaris Next (Minor > >> binding) only. > >> > >> Interface Table > >> > >> Exported Interfaces > >> > >> Name Commitment Comments > >> --------------------------------------------------------------------------- > >> svc:/network/install Committed Network interface install > >> service > >> install_ipv4_interface Committed IPv4 network interface > >> SMF property group > >> install_ipv4_interface.name > >> install_ipv4_interface.address_type > >> install_ipv4_interface.static_address > >> install_ipv4_interface.dhcp_wait > >> install_ipv4_interface.default_route > >> > >> install_ipv6_interface Committed IPv6 network interface > >> SMF property group > >> install_ipv6_interface.name > >> install_ipv6_interface.address_type > >> install_ipv6_interface.static_address > >> install_ipv6_interface.interface_id > >> install_ipv6_interface.stateless > >> install_ipv6_interface.stateful > >> install_ipv6_interface.default_route > >> > >> svc:/network/dns/install Committed DNS client install svc > >> install_props Committed DNS client configuration > >> property group > >> install_props.domain > >> install_props.nameserver > >> install_props.search > >> > >> Imported Interfaces > >> Name Commitment Comments > >> --------------------------------------------------------------------------- > >> ipadm(1M) Committed Configure network interfaces > >> route(1M) Committed Configure default routes > >> resolv.conf(4) Committed DNS client configuration > >> > > > > > From neal.pollack@oracle.com Wed May 12 11:49:46 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CInkDj012044 for ; Wed, 12 May 2010 11:49:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CInjX2021138 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 13:49:45 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2B00601LMXC500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 11:49:45 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B000JMLMXZR60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 11:49:45 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CInimm006327 for ; Wed, 12 May 2010 18:49:44 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CEX0BL026058; Wed, 12 May 2010 18:49:36 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 236033201273690106; Wed, 12 May 2010 11:48:26 -0700 Received: from [10.1.48.81] (/10.1.48.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 11:48:26 -0700 Date: Wed, 12 May 2010 11:48:20 -0700 From: Neal Pollack Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAF0CF.6090805@oracle.com> To: Mark Haywood Cc: James Carlson , Darren J Moffat , Sebastien Roy , PSARC-ext Message-id: <4BEAF7F4.5090001@oracle.com> Organization: Oracle Corporation MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_LMIyAX0sHOAyfiKfPvCWoQ)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BEAF840.018B:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <4BEAD3B4.7050000@Oracle.COM> <4BEAD694.5020106@workingcode.com> <4BEAF0CF.6090805@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) Status: RO Content-Length: 2567 This is a multi-part message in MIME format. --Boundary_(ID_LMIyAX0sHOAyfiKfPvCWoQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT On 5/12/2010 11:17 AM, Mark Haywood wrote: >> >> - Where are NIS and LDAP? Or are they not needed by this part of >> the installation process? > > They are missing. But as of yet there has been no requirement for > their support. I am puzzled about that. An installer for consumer laptops might only need dns. But an installer for 1300 Solaris engineers and many large corp I.T. customers most certainly needs a way to set up NIS and/or LDAP during install. Perhaps I am biased, but it all seems rather obvious, like one of the first top ten requirements? Where have requirements been collected from for the installer features, or what is the target audience for the installer if no requirements were collected? --Boundary_(ID_LMIyAX0sHOAyfiKfPvCWoQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
On 5/12/2010 11:17 AM, Mark Haywood wrote:

   - Where are NIS and LDAP?  Or are they not needed by this part of
     the installation process?  

They are missing. But as of yet there has been no requirement for their support.

I am puzzled about that.  An installer for consumer laptops might only need dns.
But an installer for 1300 Solaris engineers and many large corp I.T. customers
most certainly needs a way to set up NIS and/or LDAP during install.
Perhaps I am biased, but it all seems rather obvious, like one of the first top ten
requirements?

Where have requirements been collected from for the installer features,
or what is the target audience for the installer if no requirements were collected?
--Boundary_(ID_LMIyAX0sHOAyfiKfPvCWoQ)-- From mark.haywood@oracle.com Wed May 12 12:05:53 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CJ5rPH012608 for ; Wed, 12 May 2010 12:05:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CJ5oNd029541 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 14:05:52 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2B00701MDS4H00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 12:05:52 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B000NFMDRZL70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 12:05:51 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CJ5p3x029535 for ; Wed, 12 May 2010 19:05:51 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CIx9xL006439; Wed, 12 May 2010 19:05:46 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 259545721273691117; Wed, 12 May 2010 12:05:17 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 12:05:13 -0700 Date: Wed, 12 May 2010 15:06:27 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAF7F4.5090001@oracle.com> To: Neal Pollack Cc: James Carlson , Darren J Moffat , Sebastien Roy , PSARC-ext Message-id: <4BEAFC33.30400@oracle.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_pvKopbbFbuTdts1JlJyFnQ)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BEAFC0B.0060:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <4BEAD3B4.7050000@Oracle.COM> <4BEAD694.5020106@workingcode.com> <4BEAF0CF.6090805@oracle.com> <4BEAF7F4.5090001@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 3336 This is a multi-part message in MIME format. --Boundary_(ID_pvKopbbFbuTdts1JlJyFnQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT On 05/12/10 02:48 PM, Neal Pollack wrote: > > On 5/12/2010 11:17 AM, Mark Haywood wrote: >>> >>> - Where are NIS and LDAP? Or are they not needed by this part of >>> the installation process? >> >> They are missing. But as of yet there has been no requirement for >> their support. > > I am puzzled about that. An installer for consumer laptops might only > need dns. > But an installer for 1300 Solaris engineers and many large corp I.T. > customers > most certainly needs a way to set up NIS and/or LDAP during install. > Perhaps I am biased, but it all seems rather obvious, like one of the > first top ten > requirements? > > Where have requirements been collected from for the installer features, > or what is the target audience for the installer if no requirements > were collected? > Don't be puzzled. Simply talk to the Install team and tell them that you'd like to see NIS and LDAP support. In the meantime, this proposal does not prevent that support. > > > --Boundary_(ID_pvKopbbFbuTdts1JlJyFnQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 05/12/10 02:48 PM, Neal Pollack wrote:

On 5/12/2010 11:17 AM, Mark Haywood wrote:

   - Where are NIS and LDAP?  Or are they not needed by this part of
     the installation process?  

They are missing. But as of yet there has been no requirement for their support.

I am puzzled about that.  An installer for consumer laptops might only need dns.
But an installer for 1300 Solaris engineers and many large corp I.T. customers
most certainly needs a way to set up NIS and/or LDAP during install.
Perhaps I am biased, but it all seems rather obvious, like one of the first top ten
requirements?

Where have requirements been collected from for the installer features,
or what is the target audience for the installer if no requirements were collected?


Don't be puzzled. Simply talk to the Install team and tell them that you'd like to see NIS and LDAP support. In the meantime, this proposal does not prevent that support.

--Boundary_(ID_pvKopbbFbuTdts1JlJyFnQ)-- From edward.pilatowicz@oracle.com Wed May 12 12:51:51 2010 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 o4CJppbX013233 for ; Wed, 12 May 2010 12:51:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CJppYl004077 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 12 May 2010 12:51:51 -0700 (PDT) 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 <0L2B0011FOIEFF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 12 May 2010 12:51:50 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00KACOID5UB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 12 May 2010 12:51:49 -0700 (PDT) Received: from jurassic.Eng.Sun.COM (localhost [127.0.0.1]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o4CJpniO200736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 12:51:49 -0700 (PDT) Received: (from edp@localhost) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o4CJpnMj200735; Wed, 12 May 2010 12:51:49 -0700 (PDT) Date: Wed, 12 May 2010 12:51:49 -0700 From: Edward Pilatowicz Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD0D2.7020705@oracle.com> To: Sebastien Roy Cc: PSARC-ext , Mark Haywood Message-id: <20100512195149.GH176566@jurassic.Eng.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Content-transfer-encoding: 8BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BEAD0D2.7020705@oracle.com> X-Authentication-warning: jurassic.Eng.Sun.COM: edp set sender to edward.pilatowicz@oracle.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 13639 some quick questions. how does this functionality interact with different network management services, specifically network/physical:nwam and network/physical:default? is network configuration only supported for one of these methods? if so, what happens if that method is disabled and another one is in use? does enabling the svc:/network/dns/install have any interactions with nsswitch.conf(4)? for example, is it an error to enable svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). will the svc:/network/install service reconfigure interfaces that already have an existing configuration? will the svc:/network/install service ever unconfigure interfaces? for example, if no install_ipv4_interface and install_ipv6_interface values are specified, and the svc:/network/install service is brought online, will it do anything? ed On Wed, May 12, 2010 at 09:01:22AM -0700, Sebastien Roy wrote: > I'm submitting this fast-track for Mark Haywood. The release binding > is Minor. Note that this case has a dependency on PSARC 2010/157. > > Background > ========== > The Solaris Next installers intend to use SMF properties, and install > derived, SMF profiles to customize system configurations. This is > driving the requirement that Solaris provide public interfaces, in the > form of of SMF properties, which, when consumed, will provide an > initial physical network interface configuration and an initial DNS > client configuration for the installed system. This case proposes a > set of SMF properties that will satisfy the following requirements: > > 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a > physical interface. > > 2 - the ability to assign a default route to an IPv4 and/or IPv6 > physical interface. > > 3 - the ability to configure a DNS client with a nameserver list, a > search list and a domain. > > A subsequent ARC case will explain how the installers intend to > consume the interfaces during install. > > Proposal > ======== > Two new SMF services will be created, svc:/network/install and > svc:/network/dns/install. Each of these services will contain > properties that will be used by the services to configure an initial > physical network interface and/or an initial DNS client > configuration. The services will initially be disabled with property > values that will not result in any system configuration. As part of > install, an SMF profile, enabling the services and containing the > appropriate configuration property values for the services, will be > applied to the system. On the first reboot following the install, the > service start methods will check the properties to see if property > values have been assigned. If so, then the services will use these > property values to configure the system. The service start methods > will terminate after deleting their service properties and disabling > the services themselves. > > The svc:/network/install service will support configuring one IPv4 > interface and/or one IPv6 interface and, optionally, a default route > reachable by these interfaces. The service will define two property > groups, one for an IPv4 interface and one for an IPv6 interface. The > service will use its properties and ipadm(1M) to configure the network > interfaces. And similarly, the service will use its properties and > route(1M) to define a default route. > > The install_ipv4_interface property group will contain the following > properties: > > name a required property of the property group and will > contain the value that will be used as the value of > when adding an IPv4 interface address. It > has an SMF property type of 'astring'. > > address_type a required property and will contain the value that > will be used to construct the -T option for the > ipadm(1M) create-addr sub-command. Therefore, the > valid values are “static” or “dhcp”. It has an SMF > property type of 'astring'. > > static_address only required with an 'address_type' of “static” and > will be used to construct the “local” address for > the ipadm(1M) create-addr sub-command. It has an SMF > property type of 'net_address_v4'. > > dhcp_wait optional property that only applies with an > 'address_type' of “dhcp”. If defined, then the > property value will be used to construct the “-w > | forever” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > default_route an optional property whose value will be used to > define a default route using route(1M). In other > words, “/usr/sbin/route -p add default default-route > -ifp ifname” (where ifname is the interface name > portion of the 'name' property). It has an SMF > property type of 'net_address_v4'. > > The install_ipv6_interface property group will contain the following > properties: > > name a required property of the property group and will > contain the value that will be used as the value of > when adding an IPv6 interface address. It > has an SMF property type of 'astring'. > > address_type a required property and will contain the value that > will be used to construct the -T option for the > ipadm(1M) create-addr sub-command. Therefore, the > valid values are “static” or “addrconf”. It has an > SMF property type of 'astring'. > > static_address only required with an 'address_type' of “static” and > will be used to construct the “local” address for > the ipadm(1M) create-addr sub-command. It has an SMF > property type of 'net_address_v6'. > > interface_id an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-i > interface_id” portion of the ipadm(1M) create-addr > sub-command. It has an SMF property type of > 'net_address_v6'. > > stateless an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-p > stateless=yes|no” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > stateful an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-p > stateful=yes|no” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > default_route an optional property whose value will be used to > define a default route using route(1M). In other > words, “/usr/sbin/route -p add default default-route > -ifp ifname” (where ifname is the interface name > portion of the 'name' property). It has an SMF > property type of 'net_address_v6'. > > The svc:/network/dns/install service will support the configuration of > a DNS client. The service will define one property group, > install_props. The service will use its properties to construct a DNS > resolv.conf(4) file. > > The install_props property group will contain the following > properties: > > domain an optional property of the property group and, if > defined, will contain the value of the local domain > name. Its value will be used to construct the > “domain” directive in resolv.conf(4). It has an SMF > property type of 'astring'. > > nameserver a required property whose value will be used to > construct the “nameserver” directives in > resolv.conf(4). It has an SMF property type of > 'net_address', but should contain an > 'net_address_list' of IPv4 and/or IPv6 addresses. > > search an optional property that if defined, it will > contain a value for the search order host name > lookup. Its value will be used to construct the > “search” directive in resolv.conf(4). It has an SMF > property type of 'astring', but should contain an > 'astring_list' of domain values. > > An example SMF profile configuring both IPv4 and IPv6 interfaces and a > DNS client follows: > > > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> > > > > > > > > > > value='10.4.235.146/24' /> > value='10.4.235.1' /> > > > > > 9 > value='::0/0' /> > value='::abcd/64' /> > > > value='::0' /> > > > > > > > > > > > > > > > > > > > > > > > > > This case has a dependency on the new SMF property type, > SCF_TYPE_NET_ADDR, described in PSARC/2010/157. > > The exported interfaces below are intended for Solaris Next (Minor > binding) only. > > Interface Table > > Exported Interfaces > > Name Commitment Comments > --------------------------------------------------------------------------- > svc:/network/install Committed Network interface install > service > install_ipv4_interface Committed IPv4 network interface > SMF property group > install_ipv4_interface.name > install_ipv4_interface.address_type > install_ipv4_interface.static_address > install_ipv4_interface.dhcp_wait > install_ipv4_interface.default_route > > install_ipv6_interface Committed IPv6 network interface > SMF property group > install_ipv6_interface.name > install_ipv6_interface.address_type > install_ipv6_interface.static_address > install_ipv6_interface.interface_id > install_ipv6_interface.stateless > install_ipv6_interface.stateful > install_ipv6_interface.default_route > > svc:/network/dns/install Committed DNS client install svc > install_props Committed DNS client configuration > property group > install_props.domain > install_props.nameserver > install_props.search > > Imported Interfaces > Name Commitment Comments > --------------------------------------------------------------------------- > ipadm(1M) Committed Configure network interfaces > route(1M) Committed Configure default routes > resolv.conf(4) Committed DNS client configuration From mark.haywood@oracle.com Wed May 12 12:58:26 2010 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 o4CJwQS2013844 for ; Wed, 12 May 2010 12:58:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4CJwQeM039839 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 13:58:26 -0600 (MDT) 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 <0L2B00805OTE1N00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 13:58:26 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00651OTD1H80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 13:58:25 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CJwP4X028897 for ; Wed, 12 May 2010 19:58:25 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C64RU9017911; Wed, 12 May 2010 19:58:21 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 259674721273694274; Wed, 12 May 2010 12:57:54 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 12:57:53 -0700 Date: Wed, 12 May 2010 15:59:08 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: To: Peter Tribble Cc: Sebastien Roy , PSARC-ext Message-id: <4BEB088C.2080208@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BEB085E.005A:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 10597 On 05/12/10 02:32 PM, Peter Tribble wrote: > On Wed, May 12, 2010 at 5:01 PM, Sebastien Roy wrote: > >> I'm submitting this fast-track for Mark Haywood. The release binding >> is Minor. Note that this case has a dependency on PSARC 2010/157. >> >> Background >> ========== >> The Solaris Next installers intend to use SMF properties, and install >> derived, SMF profiles to customize system configurations. This is >> driving the requirement that Solaris provide public interfaces, in the >> form of of SMF properties, which, when consumed, will provide an >> initial physical network interface configuration and an initial DNS >> client configuration for the installed system. This case proposes a >> set of SMF properties that will satisfy the following requirements: >> >> 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a >> physical interface. >> > Only one interface, or can multiple interfaces be configured? > > How do you assign multiple addresses (and VLANs) to an > interface? More complicated objects? > I think I've sufficiently responded to this comment with my previous responses. > >> 2 - the ability to assign a default route to an IPv4 and/or IPv6 >> physical interface. >> > Hm. Multiple default routes? Non-default routes? > Same here. > >> 3 - the ability to configure a DNS client with a nameserver list, a >> search list and a domain. >> > Doing this using SMF profiles is just plain broken. > > As an administrator, the requirement is to supply a fully correct > /etc/resolv.conf file and for the installer to simply copy it to the > installed system. Going through the hoops of an SMF profile > (worse, expecting administrators to mangle the XML in such) > that supports a non-extensible set of options in the hope that it > will produce the right output. Well, yurk. > This seems to be more of an issue with the direction that the Install team is taking. Possibly they can respond to your concerns if any of them are on the alias. > >> The install_ipv4_interface property group will contain the following >> properties: >> >> name a required property of the property group and will >> contain the value that will be used as the value of >> when adding an IPv4 interface address. It >> has an SMF property type of 'astring'. >> > What does this mean? Is this the interface name eg bge0? > See ipadm(1M) for the definition of an address object. Or refer to the PSARC 2009/306 > How do you deal with the common case we use in sysidcfg of the > PRIMARY interface? > Good question. We don't yet. Currently, we are hoping that by the time Solaris 11 ships, we will have enabled vanity naming of network links by default. This means that the PRIMARY interface is likely to be something like "net0". But that is yet to be determined. > >> address_type a required property and will contain the value that >> will be used to construct the -T option for the >> ipadm(1M) create-addr sub-command. Therefore, the >> valid values are “static” or “dhcp”. It has an SMF >> property type of 'astring'. >> > There's a dependency between this value and the dns service, in that if > dhcp then resolv.conf comes from dhcp. (Or does it?) > It may come from the DHCP server. If not, then the administrator will likely want to define the DNS client properties using the dns-install service. > >> static_address only required with an 'address_type' of “static” and >> will be used to construct the “local” address for >> the ipadm(1M) create-addr sub-command. It has an SMF >> property type of 'net_address_v4'. >> > So this has to be an address, right? (As opposed to the relatively common > practice of supplying the name and relying on /etc/inet/hosts having > the mapping from name to address.) > Interesting. In the past I always thought Install (in the static case) populated /etc/inet/hosts by prompting the user for the IP address? > >> dhcp_wait optional property that only applies with an >> 'address_type' of “dhcp”. If defined, then the >> property value will be used to construct the “-w >> | forever” portion of the ipadm(1M) >> create-addr sub-command. It has an SMF property type >> of 'astring'. >> >> default_route an optional property whose value will be used to >> define a default route using route(1M). In other >> words, “/usr/sbin/route -p add default default-route >> -ifp ifname” (where ifname is the interface name >> portion of the 'name' property). It has an SMF >> property type of 'net_address_v4'. >> > >> The svc:/network/dns/install service will support the configuration of >> a DNS client. >> > Does it ensure that nsswitch.conf includes dns? (Or is dns included > by default - which it should be.) > Yes, it does. > >> The service will define one property group, >> install_props. The service will use its properties to construct a DNS >> resolv.conf(4) file. >> >> The install_props property group will contain the following >> properties: >> >> domain an optional property of the property group and, if >> defined, will contain the value of the local domain >> name. Its value will be used to construct the >> “domain” directive in resolv.conf(4). It has an SMF >> property type of 'astring'. >> >> nameserver a required property whose value will be used to >> construct the “nameserver” directives in >> resolv.conf(4). It has an SMF property type of >> 'net_address', but should contain an >> 'net_address_list' of IPv4 and/or IPv6 addresses. >> >> search an optional property that if defined, it will >> contain a value for the search order host name >> lookup. Its value will be used to construct the >> “search” directive in resolv.conf(4). It has an SMF >> property type of 'astring', but should contain an >> 'astring_list' of domain values. >> > What about sortlist and options? What if resolv.conf is extended to > support additional directives in the future? > They'll be added as the need arises. > >> An example SMF profile configuring both IPv4 and IPv6 interfaces and a >> DNS client follows: >> >> >> > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> >> >> >> >> >> > Something seems incomplete here. If nwam is enabled, then is > the static configuration used or ignored? > If nwam is enabled, then nwam is likely to change the static configuration that the administrator has defined in the profile. In other words, if using NWAM then there is probably no reason to define the profile. > >> >> >> >> >> >> > value='10.4.235.146/24' /> >> > Do I have to specify the type='net_address_v4' bit, or > can the be left out and inferred? > An RFE has been filed against SMF so that defining the type should not be necessary. > Looking at the /24 makes me ask: how are broadcast addresses and > the netmask defined? > I'm not sure I understand your question? The netmask will be 255.255.255.0. > >> > value='10.4.235.1' /> >> >> >> >> >> 9 >> > value='::0/0' /> >> > value='::abcd/64' /> >> >> >> > value='::0' /> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > The above example contains both domain and search, which is setting a > bad example. But if both are supplied, what is the ordering? > > The bad example was already set by resolv.conf? Just because the properties exist, does not mean an administrator has to set them. In any case, domain then search. From liane.praza@oracle.com Wed May 12 13:19:47 2010 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 o4CKJkql014132 for ; Wed, 12 May 2010 13:19:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4CKJkeh050909 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 14:19:46 -0600 (MDT) 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 <0L2B00903PSYTV00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 14:19:46 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B009VSPSYKK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 14:19:46 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CKJjRR010407 for ; Wed, 12 May 2010 20:19:45 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CKJhdf028211 for ; Wed, 12 May 2010 20:19:43 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 259734841273695542; Wed, 12 May 2010 13:19:02 -0700 Received: from [129.146.228.161] (/129.146.228.161) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 13:19:01 -0700 Date: Wed, 12 May 2010 13:19:00 -0700 From: Liane Praza Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <20100512195149.GH176566@jurassic.Eng.Sun.COM> To: Edward Pilatowicz Cc: Sebastien Roy , PSARC-ext , Mark Haywood Message-id: <4BEB0D34.8010408@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BEB0D61.00E0:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1556 On 05/12/10 12:51 PM, Edward Pilatowicz wrote: > some quick questions. > > how does this functionality interact with different network management > services, specifically network/physical:nwam and > network/physical:default? is network configuration only supported for > one of these methods? if so, what happens if that method is disabled > and another one is in use? > > does enabling the svc:/network/dns/install have any interactions with > nsswitch.conf(4)? for example, is it an error to enable > svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). > > will the svc:/network/install service reconfigure interfaces that > already have an existing configuration? > > will the svc:/network/install service ever unconfigure interfaces? for > example, if no install_ipv4_interface and install_ipv6_interface values > are specified, and the svc:/network/install service is brought online, > will it do anything? I echo Ed's sentiments and generally have a concern about install-only interfaces. (And services named as such.) It'd be better to consider the direction that the interfaces are likely to evolve in long-term and put the properties on the appropriate services. It wouldn't have to change the implementation a great deal for now, but leaves an interface that has a much better chance of evolving. It also allows the opportunity for configuration switching of the style that ipfilter uses now: either the properties or the files are authoritative, and that's switchable and predictable rather than inferred. liane From darren.reed@oracle.com Wed May 12 14:18:18 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CLII0O015319 for ; Wed, 12 May 2010 14:18:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CLIC4G029958 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 16:18:17 -0500 (CDT) 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 <0L2B00027SIHZK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 14:18:17 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00KS2SIGE040@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 14:18:16 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CLIGJ7028992 for ; Wed, 12 May 2010 21:18:16 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CLIEv9024455 for ; Wed, 12 May 2010 21:18:14 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 236406901273699025; Wed, 12 May 2010 14:17:05 -0700 Received: from mintslice.sfbay.sun.com (/129.146.106.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 14:17:03 -0700 Date: Wed, 12 May 2010 14:17:19 -0700 From: Darren Reed Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD0D2.7020705@oracle.com> To: Sebastien Roy Cc: PSARC-ext , Mark Haywood Message-id: <4BEB1ADF.90200@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BEB1B17.01CC:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 12525 Seb, There seems to be a lot of questions about the details on this case, as one of the few remaining PSARC members, does this really fall into the "obvious" category that is usually for fast tracks? To me this would seem meaty enough to be a full case... Darren On 12/05/10 09:01 AM, Sebastien Roy wrote: > I'm submitting this fast-track for Mark Haywood. The release binding > is Minor. Note that this case has a dependency on PSARC 2010/157. > > Background > ========== > The Solaris Next installers intend to use SMF properties, and install > derived, SMF profiles to customize system configurations. This is > driving the requirement that Solaris provide public interfaces, in the > form of of SMF properties, which, when consumed, will provide an > initial physical network interface configuration and an initial DNS > client configuration for the installed system. This case proposes a > set of SMF properties that will satisfy the following requirements: > > 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a > physical interface. > > 2 - the ability to assign a default route to an IPv4 and/or IPv6 > physical interface. > > 3 - the ability to configure a DNS client with a nameserver list, a > search list and a domain. > > A subsequent ARC case will explain how the installers intend to > consume the interfaces during install. > > Proposal > ======== > Two new SMF services will be created, svc:/network/install and > svc:/network/dns/install. Each of these services will contain > properties that will be used by the services to configure an initial > physical network interface and/or an initial DNS client > configuration. The services will initially be disabled with property > values that will not result in any system configuration. As part of > install, an SMF profile, enabling the services and containing the > appropriate configuration property values for the services, will be > applied to the system. On the first reboot following the install, the > service start methods will check the properties to see if property > values have been assigned. If so, then the services will use these > property values to configure the system. The service start methods > will terminate after deleting their service properties and disabling > the services themselves. > > The svc:/network/install service will support configuring one IPv4 > interface and/or one IPv6 interface and, optionally, a default route > reachable by these interfaces. The service will define two property > groups, one for an IPv4 interface and one for an IPv6 interface. The > service will use its properties and ipadm(1M) to configure the network > interfaces. And similarly, the service will use its properties and > route(1M) to define a default route. > > The install_ipv4_interface property group will contain the following > properties: > > name a required property of the property group and will > contain the value that will be used as the value of > when adding an IPv4 interface address. It > has an SMF property type of 'astring'. > > address_type a required property and will contain the value that > will be used to construct the -T option for the > ipadm(1M) create-addr sub-command. Therefore, the > valid values are “static” or “dhcp”. It has an SMF > property type of 'astring'. > > static_address only required with an 'address_type' of “static” and > will be used to construct the “local” address for > the ipadm(1M) create-addr sub-command. It has an SMF > property type of 'net_address_v4'. > > dhcp_wait optional property that only applies with an > 'address_type' of “dhcp”. If defined, then the > property value will be used to construct the “-w > | forever” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > default_route an optional property whose value will be used to > define a default route using route(1M). In other > words, “/usr/sbin/route -p add default default-route > -ifp ifname” (where ifname is the interface name > portion of the 'name' property). It has an SMF > property type of 'net_address_v4'. > > The install_ipv6_interface property group will contain the following > properties: > > name a required property of the property group and will > contain the value that will be used as the value of > when adding an IPv6 interface address. It > has an SMF property type of 'astring'. > > address_type a required property and will contain the value that > will be used to construct the -T option for the > ipadm(1M) create-addr sub-command. Therefore, the > valid values are “static” or “addrconf”. It has an > SMF property type of 'astring'. > > static_address only required with an 'address_type' of “static” and > will be used to construct the “local” address for > the ipadm(1M) create-addr sub-command. It has an SMF > property type of 'net_address_v6'. > > interface_id an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-i > interface_id” portion of the ipadm(1M) create-addr > sub-command. It has an SMF property type of > 'net_address_v6'. > > stateless an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-p > stateless=yes|no” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > stateful an optional property that only applies with an > 'address_type' of “addrconf”. If defined, then the > property value will be used to construct the “-p > stateful=yes|no” portion of the ipadm(1M) > create-addr sub-command. It has an SMF property type > of 'astring'. > > default_route an optional property whose value will be used to > define a default route using route(1M). In other > words, “/usr/sbin/route -p add default default-route > -ifp ifname” (where ifname is the interface name > portion of the 'name' property). It has an SMF > property type of 'net_address_v6'. > > The svc:/network/dns/install service will support the configuration of > a DNS client. The service will define one property group, > install_props. The service will use its properties to construct a DNS > resolv.conf(4) file. > > The install_props property group will contain the following > properties: > > domain an optional property of the property group and, if > defined, will contain the value of the local domain > name. Its value will be used to construct the > “domain” directive in resolv.conf(4). It has an SMF > property type of 'astring'. > > nameserver a required property whose value will be used to > construct the “nameserver” directives in > resolv.conf(4). It has an SMF property type of > 'net_address', but should contain an > 'net_address_list' of IPv4 and/or IPv6 addresses. > > search an optional property that if defined, it will > contain a value for the search order host name > lookup. Its value will be used to construct the > “search” directive in resolv.conf(4). It has an SMF > property type of 'astring', but should contain an > 'astring_list' of domain values. > > An example SMF profile configuring both IPv4 and IPv6 interfaces and a > DNS client follows: > > > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> > > > > > > > > > > value='10.4.235.146/24' /> > value='10.4.235.1' /> > > > > > 9 > value='::0/0' /> > value='::abcd/64' /> > > > value='::0' /> > > > > > > > > > > > > > > > > > > > > > > > > > This case has a dependency on the new SMF property type, > SCF_TYPE_NET_ADDR, described in PSARC/2010/157. > > The exported interfaces below are intended for Solaris Next (Minor > binding) only. > > Interface Table > > Exported Interfaces > > Name Commitment Comments > --------------------------------------------------------------------------- > > svc:/network/install Committed Network interface install > service > install_ipv4_interface Committed IPv4 network interface > SMF property group > install_ipv4_interface.name > install_ipv4_interface.address_type > install_ipv4_interface.static_address > install_ipv4_interface.dhcp_wait > install_ipv4_interface.default_route > > install_ipv6_interface Committed IPv6 network interface > SMF property group > install_ipv6_interface.name > install_ipv6_interface.address_type > install_ipv6_interface.static_address > install_ipv6_interface.interface_id > install_ipv6_interface.stateless > install_ipv6_interface.stateful > install_ipv6_interface.default_route > > svc:/network/dns/install Committed DNS client install svc > install_props Committed DNS client configuration > property group > install_props.domain > install_props.nameserver > install_props.search > > Imported Interfaces > Name Commitment Comments > --------------------------------------------------------------------------- > > ipadm(1M) Committed Configure network > interfaces > route(1M) Committed Configure default routes > resolv.conf(4) Committed DNS client configuration From carlsonj@workingcode.com Wed May 12 14:31:16 2010 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 o4CLVFE8015403 for ; Wed, 12 May 2010 14:31:15 -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.4) with ESMTP id o4CLVElY019981 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 15:31:15 -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 <0L2B0040JT42M000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 14:31:14 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00KINT41E090@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 14:31:14 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CLVCLq006692 for ; Wed, 12 May 2010 21:31:13 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-3326484 for PSARC-ext@sun.com; Wed, 12 May 2010 21:31:12 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-38223 for PSARC-ext@sun.com; Wed, 12 May 2010 21:31:11 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-60351058 for PSARC-ext@sun.com; Wed, 12 May 2010 21:31:10 +0000 (Z) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4CLUvv9010884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 17:30:58 -0400 (EDT) Date: Wed, 12 May 2010 17:30:56 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAF7F4.5090001@oracle.com> To: Neal Pollack Cc: Mark Haywood , Darren J Moffat , Sebastien Roy , PSARC-ext Message-id: <4BEB1E10.9000501@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-SIHOPE-DCC-3-Metrics: carlson; whitelist X-Antispam: No, score=-0.7/5.0, scanned in 0.563sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BEAD0D2.7020705@oracle.com> <4BEAD3B4.7050000@Oracle.COM> <4BEAD694.5020106@workingcode.com> <4BEAF0CF.6090805@oracle.com> <4BEAF7F4.5090001@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2250 On 05/12/10 14:48, Neal Pollack wrote: > > On 5/12/2010 11:17 AM, Mark Haywood wrote: >>> >>> - Where are NIS and LDAP? Or are they not needed by this part of >>> the installation process? >> >> They are missing. But as of yet there has been no requirement for >> their support. > > I am puzzled about that. An installer for consumer laptops might only > need dns. > But an installer for 1300 Solaris engineers and many large corp I.T. > customers > most certainly needs a way to set up NIS and/or LDAP during install. > Perhaps I am biased, but it all seems rather obvious, like one of the > first top ten > requirements? It wouldn't surprise me that the environment described is "enough" for basic installation, even in an environment that uses NIS/LDAP. It looks like the parameters being set are _just_ for the install process itself, and a different configuration will be used on the installed system. (Much as it is with classic Solaris; the network install environment is quite a bit different from the actual run-time environment.) But it's hard to tell. And my main concern is that a very narrow focus here will result in great future pain. We've seen that before with things like /etc/hostname.*. It's all too easy to focus on hard-wired Ethernet interfaces (designing for "le0" and not much else), and end up with something that's just impossible to extend meaningfully. I also share the concerns of the other posters (Rich, maybe?), who rightly noted that it's odd to have "special" configuration for one mode, and "other" configuration otherwise -- e.g., using /etc/resolv.conf in most cases, but using special SMF parameters to configure DNS in other cases. There really ought to be just one way to express things, because the split will just cause confusion and bugs in the future. That split (or duplication of interfaces), I think, is architectural. > Where have requirements been collected from for the installer features, > or what is the target audience for the installer if no requirements were > collected? At least as much as it affects the intended architecture, I think this is needed as reference material for this case. -- James Carlson 42.703N 71.076W From mark.haywood@oracle.com Wed May 12 16:25:30 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CNPT7W018410 for ; Wed, 12 May 2010 16:25:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CNPShW023076 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 18:25:29 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2B00K0NYEHIK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 16:25:29 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00H2NYEGHW20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 16:25:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CNPSvo020709 for ; Wed, 12 May 2010 23:25:28 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CMrtLH001020 for ; Wed, 12 May 2010 23:25:27 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 236686091273706655; Wed, 12 May 2010 16:24:15 -0700 Received: from new-host-2.home (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 16:24:15 -0700 Date: Wed, 12 May 2010 19:24:07 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <20100512195149.GH176566@jurassic.Eng.Sun.COM> To: Edward Pilatowicz Cc: Sebastien Roy , PSARC-ext Message-id: <4BEB3897.8020000@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BEB38E7.0123:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 14791 Edward Pilatowicz wrote: > some quick questions. > > how does this functionality interact with different network management > services, specifically network/physical:nwam and > network/physical:default? is network configuration only supported for > one of these methods? if so, what happens if that method is disabled > and another one is in use? > The new SMF services being proposed would run before network/physical and would setup persistent configuration before network/physical:nwam and network/physical:default run. So, this functionality basically provides the system with an initial configuration at first boot. network/physical:nwam and network/physical:default should continue to function exactly like they do today on *any* boot. That is, network/physical:default continues to use the system persistent configuration and NWAM uses its profiles to determine what to do. > does enabling the svc:/network/dns/install have any interactions with > nsswitch.conf(4)? for example, is it an error to enable > svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). > svc:/network/dns/install copies nsswitch.dns to nsswitch.conf. > will the svc:/network/install service reconfigure interfaces that > already have an existing configuration? > They can't have existing configurations. This service only runs on the first boot after the initial install. > will the svc:/network/install service ever unconfigure interfaces? for > example, if no install_ipv4_interface and install_ipv6_interface values > are specified, and the svc:/network/install service is brought online, > will it do anything? > No. No profile means nothing is done. The new services are disabled by default. > ed > > On Wed, May 12, 2010 at 09:01:22AM -0700, Sebastien Roy wrote: > >> I'm submitting this fast-track for Mark Haywood. The release binding >> is Minor. Note that this case has a dependency on PSARC 2010/157. >> >> Background >> ========== >> The Solaris Next installers intend to use SMF properties, and install >> derived, SMF profiles to customize system configurations. This is >> driving the requirement that Solaris provide public interfaces, in the >> form of of SMF properties, which, when consumed, will provide an >> initial physical network interface configuration and an initial DNS >> client configuration for the installed system. This case proposes a >> set of SMF properties that will satisfy the following requirements: >> >> 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a >> physical interface. >> >> 2 - the ability to assign a default route to an IPv4 and/or IPv6 >> physical interface. >> >> 3 - the ability to configure a DNS client with a nameserver list, a >> search list and a domain. >> >> A subsequent ARC case will explain how the installers intend to >> consume the interfaces during install. >> >> Proposal >> ======== >> Two new SMF services will be created, svc:/network/install and >> svc:/network/dns/install. Each of these services will contain >> properties that will be used by the services to configure an initial >> physical network interface and/or an initial DNS client >> configuration. The services will initially be disabled with property >> values that will not result in any system configuration. As part of >> install, an SMF profile, enabling the services and containing the >> appropriate configuration property values for the services, will be >> applied to the system. On the first reboot following the install, the >> service start methods will check the properties to see if property >> values have been assigned. If so, then the services will use these >> property values to configure the system. The service start methods >> will terminate after deleting their service properties and disabling >> the services themselves. >> >> The svc:/network/install service will support configuring one IPv4 >> interface and/or one IPv6 interface and, optionally, a default route >> reachable by these interfaces. The service will define two property >> groups, one for an IPv4 interface and one for an IPv6 interface. The >> service will use its properties and ipadm(1M) to configure the network >> interfaces. And similarly, the service will use its properties and >> route(1M) to define a default route. >> >> The install_ipv4_interface property group will contain the following >> properties: >> >> name a required property of the property group and will >> contain the value that will be used as the value of >> when adding an IPv4 interface address. It >> has an SMF property type of 'astring'. >> >> address_type a required property and will contain the value that >> will be used to construct the -T option for the >> ipadm(1M) create-addr sub-command. Therefore, the >> valid values are ?static? or ?dhcp?. It has an SMF >> property type of 'astring'. >> >> static_address only required with an 'address_type' of ?static? and >> will be used to construct the ?local? address for >> the ipadm(1M) create-addr sub-command. It has an SMF >> property type of 'net_address_v4'. >> >> dhcp_wait optional property that only applies with an >> 'address_type' of ?dhcp?. If defined, then the >> property value will be used to construct the ?-w >> | forever? portion of the ipadm(1M) >> create-addr sub-command. It has an SMF property type >> of 'astring'. >> >> default_route an optional property whose value will be used to >> define a default route using route(1M). In other >> words, ?/usr/sbin/route -p add default default-route >> -ifp ifname? (where ifname is the interface name >> portion of the 'name' property). It has an SMF >> property type of 'net_address_v4'. >> >> The install_ipv6_interface property group will contain the following >> properties: >> >> name a required property of the property group and will >> contain the value that will be used as the value of >> when adding an IPv6 interface address. It >> has an SMF property type of 'astring'. >> >> address_type a required property and will contain the value that >> will be used to construct the -T option for the >> ipadm(1M) create-addr sub-command. Therefore, the >> valid values are ?static? or ?addrconf?. It has an >> SMF property type of 'astring'. >> >> static_address only required with an 'address_type' of ?static? and >> will be used to construct the ?local? address for >> the ipadm(1M) create-addr sub-command. It has an SMF >> property type of 'net_address_v6'. >> >> interface_id an optional property that only applies with an >> 'address_type' of ?addrconf?. If defined, then the >> property value will be used to construct the ?-i >> interface_id? portion of the ipadm(1M) create-addr >> sub-command. It has an SMF property type of >> 'net_address_v6'. >> >> stateless an optional property that only applies with an >> 'address_type' of ?addrconf?. If defined, then the >> property value will be used to construct the ?-p >> stateless=yes|no? portion of the ipadm(1M) >> create-addr sub-command. It has an SMF property type >> of 'astring'. >> >> stateful an optional property that only applies with an >> 'address_type' of ?addrconf?. If defined, then the >> property value will be used to construct the ?-p >> stateful=yes|no? portion of the ipadm(1M) >> create-addr sub-command. It has an SMF property type >> of 'astring'. >> >> default_route an optional property whose value will be used to >> define a default route using route(1M). In other >> words, ?/usr/sbin/route -p add default default-route >> -ifp ifname? (where ifname is the interface name >> portion of the 'name' property). It has an SMF >> property type of 'net_address_v6'. >> >> The svc:/network/dns/install service will support the configuration of >> a DNS client. The service will define one property group, >> install_props. The service will use its properties to construct a DNS >> resolv.conf(4) file. >> >> The install_props property group will contain the following >> properties: >> >> domain an optional property of the property group and, if >> defined, will contain the value of the local domain >> name. Its value will be used to construct the >> ?domain? directive in resolv.conf(4). It has an SMF >> property type of 'astring'. >> >> nameserver a required property whose value will be used to >> construct the ?nameserver? directives in >> resolv.conf(4). It has an SMF property type of >> 'net_address', but should contain an >> 'net_address_list' of IPv4 and/or IPv6 addresses. >> >> search an optional property that if defined, it will >> contain a value for the search order host name >> lookup. Its value will be used to construct the >> ?search? directive in resolv.conf(4). It has an SMF >> property type of 'astring', but should contain an >> 'astring_list' of domain values. >> >> An example SMF profile configuring both IPv4 and IPv6 interfaces and a >> DNS client follows: >> >> >> > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> >> >> >> >> >> >> >> >> >> >> > value='10.4.235.146/24' /> >> > value='10.4.235.1' /> >> >> >> >> >> 9 >> > value='::0/0' /> >> > value='::abcd/64' /> >> >> >> > value='::0' /> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> This case has a dependency on the new SMF property type, >> SCF_TYPE_NET_ADDR, described in PSARC/2010/157. >> >> The exported interfaces below are intended for Solaris Next (Minor >> binding) only. >> >> Interface Table >> >> Exported Interfaces >> >> Name Commitment Comments >> --------------------------------------------------------------------------- >> svc:/network/install Committed Network interface install >> service >> install_ipv4_interface Committed IPv4 network interface >> SMF property group >> install_ipv4_interface.name >> install_ipv4_interface.address_type >> install_ipv4_interface.static_address >> install_ipv4_interface.dhcp_wait >> install_ipv4_interface.default_route >> >> install_ipv6_interface Committed IPv6 network interface >> SMF property group >> install_ipv6_interface.name >> install_ipv6_interface.address_type >> install_ipv6_interface.static_address >> install_ipv6_interface.interface_id >> install_ipv6_interface.stateless >> install_ipv6_interface.stateful >> install_ipv6_interface.default_route >> >> svc:/network/dns/install Committed DNS client install svc >> install_props Committed DNS client configuration >> property group >> install_props.domain >> install_props.nameserver >> install_props.search >> >> Imported Interfaces >> Name Commitment Comments >> --------------------------------------------------------------------------- >> ipadm(1M) Committed Configure network interfaces >> route(1M) Committed Configure default routes >> resolv.conf(4) Committed DNS client configuration >> From mark.haywood@oracle.com Wed May 12 16:37:57 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CNbueA018628 for ; Wed, 12 May 2010 16:37:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CNbuLS028107 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 18:37:56 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2B00L07YZ87500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 16:37:56 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00HA1YZ7HD20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 16:37:56 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4CNbtdM015781 for ; Wed, 12 May 2010 23:37:55 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CGABxC010163 for ; Wed, 12 May 2010 23:37:54 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 236711001273707460; Wed, 12 May 2010 16:37:40 -0700 Received: from new-host-2.home (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 16:37:40 -0700 Date: Wed, 12 May 2010 19:37:37 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB0D34.8010408@oracle.com> To: Liane Praza Cc: Edward Pilatowicz , Sebastien Roy , PSARC-ext Message-id: <4BEB3BC1.6040002@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BEB3BD3.003A:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB0D34.8010408@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 2314 Liane Praza wrote: > On 05/12/10 12:51 PM, Edward Pilatowicz wrote: >> some quick questions. >> >> how does this functionality interact with different network management >> services, specifically network/physical:nwam and >> network/physical:default? is network configuration only supported for >> one of these methods? if so, what happens if that method is disabled >> and another one is in use? >> >> does enabling the svc:/network/dns/install have any interactions with >> nsswitch.conf(4)? for example, is it an error to enable >> svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). >> >> will the svc:/network/install service reconfigure interfaces that >> already have an existing configuration? >> >> will the svc:/network/install service ever unconfigure interfaces? for >> example, if no install_ipv4_interface and install_ipv6_interface values >> are specified, and the svc:/network/install service is brought online, >> will it do anything? > > I echo Ed's sentiments and generally have a concern about install-only > interfaces. (And services named as such.) > > It'd be better to consider the direction that the interfaces are > likely to evolve in long-term and put the properties on the > appropriate services. It wouldn't have to change the implementation a > great deal for now, but leaves an interface that has a much better > chance of evolving. It also allows the opportunity for configuration > switching of the style that ipfilter uses now: either the properties > or the files are authoritative, and that's switchable and predictable > rather than inferred. I understand your concern. If network interfaces were currently modeled in SMF, then this case probably wouldn't be necessary. Modeling the network interfaces in SMF is not currently a committed project but is under investigation. However, given the uncertainty in its implementation we are trying to provide Install with interfaces that meet their needs in the near-term. If an SMF implementation of network interfaces comes into existence before Solaris Next, then the proposed interfaces will be changed. It such an implementation comes into existence after Solaris Next ships, then the proposed services and their properties can be used to initialize the new implementations. > > liane From edward.pilatowicz@oracle.com Wed May 12 17:20:16 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4D0KGEq019384 for ; Wed, 12 May 2010 17:20:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4D0KFxO016060 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 12 May 2010 19:20:15 -0500 (CDT) 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 <0L2C0080B0XRYH00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 12 May 2010 18:20:15 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00GB20XQNH90@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 12 May 2010 18:20:15 -0600 (MDT) Received: from jurassic.Eng.Sun.COM (localhost [127.0.0.1]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o4D0KEM5226601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 17:20:14 -0700 (PDT) Received: (from edp@localhost) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o4D0KE8E226600; Wed, 12 May 2010 17:20:14 -0700 (PDT) Date: Wed, 12 May 2010 17:20:14 -0700 From: Edward Pilatowicz Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB3897.8020000@oracle.com> To: Mark Haywood Cc: Sebastien Roy , PSARC-ext Message-id: <20100513002014.GI176566@jurassic.Eng.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> X-Authentication-warning: jurassic.Eng.Sun.COM: edp set sender to edward.pilatowicz@oracle.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 2917 On Wed, May 12, 2010 at 04:24:07PM -0700, Mark Haywood wrote: > Edward Pilatowicz wrote: > >some quick questions. > > > >how does this functionality interact with different network management > >services, specifically network/physical:nwam and > >network/physical:default? is network configuration only supported for > >one of these methods? if so, what happens if that method is disabled > >and another one is in use? > > The new SMF services being proposed would run before > network/physical and would setup persistent configuration before > network/physical:nwam and network/physical:default run. So, this > functionality basically provides the system with an initial > configuration at first boot. network/physical:nwam and > network/physical:default should continue to function exactly like > they do today on *any* boot. That is, network/physical:default > continues to use the system persistent configuration and NWAM uses > its profiles to determine what to do. so it sounds like this new service will essentially configure the system to work with either network/physical:nwam or network/physical:default? ie, the new network/install service will create/modify /etc/hostname file(s) so that if network/physical:default is enabled the system boots with the requested configuration, and, the new network/install service will also create and enable a static nwam profile so that if network/physical:nwam is enabled we'll get the same requested configuration applied? > >does enabling the svc:/network/dns/install have any interactions with > >nsswitch.conf(4)? for example, is it an error to enable > >svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). > > > svc:/network/dns/install copies nsswitch.dns to nsswitch.conf. > > >will the svc:/network/install service reconfigure interfaces that > >already have an existing configuration? > > > They can't have existing configurations. This service only runs on > the first boot after the initial install. > but these new services always exist on the system and are committed interfaces, so anyone could create these property groups and re-enable the service at any time. what happens then? > >will the svc:/network/install service ever unconfigure interfaces? for > >example, if no install_ipv4_interface and install_ipv6_interface values > >are specified, and the svc:/network/install service is brought online, > >will it do anything? > > No. No profile means nothing is done. The new services are disabled > by default. > let me re-phrase my question. say install_ipv4_interface is defined for e1000g0 and install_ipv6_interface is not defined. also say e1000g0 already has an ipv4 and ipv6 address configured. presumably, enabling this service will change the e1000g0 ipv6 configuration, but will it also unconfigure the ipv6 address on e1000g0? another question. will these services exist and be supported within zones? ed From tony.q.nguyen@oracle.com Wed May 12 17:28:14 2010 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 o4D0SDZ1019418 for ; Wed, 12 May 2010 17:28:13 -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.4) with ESMTP id o4D0SCR6036635 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 18:28:13 -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 <0L2C006011B1MD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 17:28:13 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C008BH1B0KJB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 17:28:13 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4D0SChm010009 for ; Thu, 13 May 2010 00:28:12 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CLoMR1010974 for ; Thu, 13 May 2010 00:28:11 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 236793531273710471; Wed, 12 May 2010 17:27:51 -0700 Received: from [129.146.226.122] (/129.146.226.122) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 17:27:51 -0700 Date: Wed, 12 May 2010 17:27:50 -0700 From: Tony Nguyen Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB3897.8020000@oracle.com> To: Mark Haywood Cc: PSARC-ext Message-id: <4BEB4786.7060005@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BEB479C.004F:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2135 On 05/12/10 04:24 PM, Mark Haywood wrote: > Edward Pilatowicz wrote: >> some quick questions. >> >> how does this functionality interact with different network management >> services, specifically network/physical:nwam and >> network/physical:default? is network configuration only supported for >> one of these methods? if so, what happens if that method is disabled >> and another one is in use? > > The new SMF services being proposed would run before network/physical > and would setup persistent configuration before network/physical:nwam > and network/physical:default run. So, this functionality basically > provides the system with an initial configuration at first boot. > network/physical:nwam and network/physical:default should continue to > function exactly like they do today on *any* boot. That is, > network/physical:default continues to use the system persistent > configuration and NWAM uses its profiles to determine what to do. >> does enabling the svc:/network/dns/install have any interactions with >> nsswitch.conf(4)? for example, is it an error to enable >> svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). > > > svc:/network/dns/install copies nsswitch.dns to nsswitch.conf. > >> will the svc:/network/install service reconfigure interfaces that >> already have an existing configuration? > > > They can't have existing configurations. This service only runs on the > first boot after the initial install. > >> will the svc:/network/install service ever unconfigure interfaces? for >> example, if no install_ipv4_interface and install_ipv6_interface values >> are specified, and the svc:/network/install service is brought online, >> will it do anything? > > No. No profile means nothing is done. The new services are disabled by > default. Sorry but it's still not clear to me. It sounds like there should be some interaction between physical:nwam and these new services, e.g. these services sets up an NWAM profile that is activated by physical:nwam. If this is the case, it seems long-winded as the networking configuration can just be in physical:nwam instance. -tn From mark.haywood@oracle.com Wed May 12 17:41:54 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4D0frsQ019452 for ; Wed, 12 May 2010 17:41:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4D0frEm024035 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 19:41:53 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2C001051XTO500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 17:41:53 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00HRS1XSHX40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 17:41:52 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4D0fqlN017155 for ; Thu, 13 May 2010 00:41:52 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C66I8a003734 for ; Thu, 13 May 2010 00:41:51 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 236816551273711290; Wed, 12 May 2010 17:41:30 -0700 Received: from Mark-Haywoods-MacBook-Pro.local (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 17:41:29 -0700 Date: Wed, 12 May 2010 20:41:26 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <20100513002014.GI176566@jurassic.Eng.Sun.COM> To: Edward Pilatowicz Cc: Sebastien Roy , PSARC-ext Message-id: <4BEB4AB6.6080107@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BEB4AD0.0007:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 4404 Edward Pilatowicz wrote: > On Wed, May 12, 2010 at 04:24:07PM -0700, Mark Haywood wrote: > >> Edward Pilatowicz wrote: >> >>> some quick questions. >>> >>> how does this functionality interact with different network management >>> services, specifically network/physical:nwam and >>> network/physical:default? is network configuration only supported for >>> one of these methods? if so, what happens if that method is disabled >>> and another one is in use? >>> >> The new SMF services being proposed would run before >> network/physical and would setup persistent configuration before >> network/physical:nwam and network/physical:default run. So, this >> functionality basically provides the system with an initial >> configuration at first boot. network/physical:nwam and >> network/physical:default should continue to function exactly like >> they do today on *any* boot. That is, network/physical:default >> continues to use the system persistent configuration and NWAM uses >> its profiles to determine what to do. >> > > so it sounds like this new service will essentially configure the system > to work with either network/physical:nwam or network/physical:default > ? > Basically yes. This new service will not do anything to the NWAM. It functions as it always has regardless of what the new service does. As for network/physical:default, it will use the persistent configuration provided by this network/install service at first boot. > ie, the new network/install service will create/modify /etc/hostname > file(s) so that if network/physical:default is enabled the system boots > with the requested configuration, and, the new network/install service > will also create and enable a static nwam profile so that if > network/physical:nwam is enabled we'll get the same requested > configuration applied? > No. The new service runs ipadm to create a persistent configuration (no /etc/hostname*. files in the future). This will be consumed by network/physcial:default. NWAM ignores the ipadm configurations and operates the way it always has. > >>> does enabling the svc:/network/dns/install have any interactions with >>> nsswitch.conf(4)? for example, is it an error to enable >>> svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). >>> >> svc:/network/dns/install copies nsswitch.dns to nsswitch.conf. >> >> >>> will the svc:/network/install service reconfigure interfaces that >>> already have an existing configuration? >>> >> They can't have existing configurations. This service only runs on >> the first boot after the initial install. >> >> > > but these new services always exist on the system and are committed > interfaces, so anyone could create these property groups and re-enable > the service at any time. what happens then? > Well actually, the services delete the properties after processing them on first reboot. That said, there is nothing that prevents a user from recreating the properties and reenabling the service using an SMF profile. The behavior would depend upon how the user defined the profile. Basically, it would try to install the configuration defined. Depending on the configuration, that might work, but not recommended. > >>> will the svc:/network/install service ever unconfigure interfaces? for >>> example, if no install_ipv4_interface and install_ipv6_interface values >>> are specified, and the svc:/network/install service is brought online, >>> will it do anything? >>> >> No. No profile means nothing is done. The new services are disabled >> by default. >> >> > > let me re-phrase my question. say install_ipv4_interface is defined for > e1000g0 and install_ipv6_interface is not defined. also say e1000g0 > already has an ipv4 and ipv6 address configured. presumably, enabling > this service will change the e1000g0 ipv6 configuration, but will it > also unconfigure the ipv6 address on e1000g0? > Again, this service should not be rerun after the first reboot. If necessary a property could be introduced to the service to prevent it. So, no preexisting configuration exists. > another question. will these services exist and be supported within > zones? > The network/install service is supported only in the exclusive IP zone. The dns/install service is supported in exclusive and share IP zones. > ed > From mark.haywood@oracle.com Wed May 12 17:43:59 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4D0hxI3019484 for ; Wed, 12 May 2010 17:43:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4D0hx3Q024731 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 19:43:59 -0500 (CDT) 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 <0L2C00B0321B3V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 17:43:59 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C0086W21AKRB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 17:43:58 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4D0hvkR016162 for ; Thu, 13 May 2010 00:43:58 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4D0hv2B024287 for ; Thu, 13 May 2010 00:43:57 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 236820861273711393; Wed, 12 May 2010 17:43:13 -0700 Received: from Mark-Haywoods-MacBook-Pro.local (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 17:43:13 -0700 Date: Wed, 12 May 2010 20:43:10 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB4786.7060005@oracle.com> To: Tony Nguyen Cc: PSARC-ext Message-id: <4BEB4B1E.6080907@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BEB4B4D.0117:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <4BEB4786.7060005@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 2260 Tony Nguyen wrote: > On 05/12/10 04:24 PM, Mark Haywood wrote: >> Edward Pilatowicz wrote: >>> some quick questions. >>> >>> how does this functionality interact with different network management >>> services, specifically network/physical:nwam and >>> network/physical:default? is network configuration only supported for >>> one of these methods? if so, what happens if that method is disabled >>> and another one is in use? >> >> The new SMF services being proposed would run before network/physical >> and would setup persistent configuration before network/physical:nwam >> and network/physical:default run. So, this functionality basically >> provides the system with an initial configuration at first boot. >> network/physical:nwam and network/physical:default should continue to >> function exactly like they do today on *any* boot. That is, >> network/physical:default continues to use the system persistent >> configuration and NWAM uses its profiles to determine what to do. >>> does enabling the svc:/network/dns/install have any interactions with >>> nsswitch.conf(4)? for example, is it an error to enable >>> svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). >> >> >> svc:/network/dns/install copies nsswitch.dns to nsswitch.conf. >> >>> will the svc:/network/install service reconfigure interfaces that >>> already have an existing configuration? >> >> >> They can't have existing configurations. This service only runs on >> the first boot after the initial install. >> >>> will the svc:/network/install service ever unconfigure interfaces? for >>> example, if no install_ipv4_interface and install_ipv6_interface values >>> are specified, and the svc:/network/install service is brought online, >>> will it do anything? >> >> No. No profile means nothing is done. The new services are disabled >> by default. > > Sorry but it's still not clear to me. It sounds like there should be > some interaction between physical:nwam and these new services, e.g. > these services sets up an NWAM profile that is activated by > physical:nwam. If this is the case, it seems long-winded as the > networking configuration can just be in physical:nwam instance. No. These services do not set up an NWAM profile. > > -tn From carlsonj@workingcode.com Wed May 12 17:47:45 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4D0ljis019509 for ; Wed, 12 May 2010 17:47:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4D0li7E026793 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 19:47:45 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2C0020327K0O00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 12 May 2010 17:47:44 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00HVL27KHT40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 12 May 2010 17:47:44 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4D0lhW9017438 for ; Thu, 13 May 2010 00:47:43 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-439191 for PSARC-ext@Sun.COM; Thu, 13 May 2010 00:45:43 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-148006740 for PSARC-ext@Sun.COM; Thu, 13 May 2010 00:45:42 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-5679421 for PSARC-ext@Sun.COM; Thu, 13 May 2010 00:45:41 +0000 (Z) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4D0jQ2G005446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 20:45:26 -0400 (EDT) Date: Wed, 12 May 2010 20:45:25 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAF0CF.6090805@oracle.com> To: Mark Haywood Cc: Darren J Moffat , Sebastien Roy , PSARC-ext Message-id: <4BEB4BA5.7070608@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=-0.2/5.0, scanned in 0.399sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BEAD0D2.7020705@oracle.com> <4BEAD3B4.7050000@Oracle.COM> <4BEAD694.5020106@workingcode.com> <4BEAF0CF.6090805@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1677 On 05/12/10 14:17, Mark Haywood wrote: > On 05/12/10 12:25 PM, James Carlson wrote: >> - What about systems that need to have IPMP or other IP-level bits >> such as tunnels or IPsec? >> > > Again, we're not trying to support all networking configuration > possibilities with this proposal. We're trying to provide the Install > team with the interfaces that they need to fulfill their requirements of > being able to configure one IP interface, a default router for that > interface and a DNS client. This proposal is trying to satisfy those > requirements without limiting future requirements. If future > requirements require a change to the interfaces proposed here, then the > interfaces can be adjusted at that time. I guess that makes the question I'm asking rather simple: how is the ARC supposed to review the architectural aspects of this project if the larger context into which it's designed to fit isn't something that is readily available to the ARC members? Your answers to the specific questions seem fine, and I have no reason to doubt that there's some larger project that this all fits into and that it satisfies all the requirements of that larger project. But one of the important functions of the ARC is exactly that: recording and reviewing precisely how distinct projects fit together. It doesn't seem like that function can be satisfied here. > I don't think there is one yet. As I mentioned in the proposal, I expect > the Install team to ARC a case for AI at some point. No longer an ARC member, but if I were, I think I'd ask to see that project first. -- James Carlson 42.703N 71.076W From edward.pilatowicz@oracle.com Wed May 12 18:25:22 2010 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 o4D1PLr1020054 for ; Wed, 12 May 2010 18:25:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4D1PLg8005160 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 12 May 2010 18:25:21 -0700 (PDT) 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 <0L2C00F013Y96S00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 12 May 2010 19:25:21 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00GST3Y8NHC0@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 12 May 2010 19:25:21 -0600 (MDT) Received: from jurassic.Eng.Sun.COM (localhost [127.0.0.1]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o4D1PKFT232613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 18:25:20 -0700 (PDT) Received: (from edp@localhost) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o4D1PK5h232612; Wed, 12 May 2010 18:25:20 -0700 (PDT) Date: Wed, 12 May 2010 18:25:20 -0700 From: Edward Pilatowicz Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB4AB6.6080107@oracle.com> To: Mark Haywood Cc: Sebastien Roy , PSARC-ext Message-id: <20100513012518.GA231274@jurassic.Eng.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> X-Authentication-warning: jurassic.Eng.Sun.COM: edp set sender to edward.pilatowicz@oracle.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 2615 On Wed, May 12, 2010 at 05:41:26PM -0700, Mark Haywood wrote: > Edward Pilatowicz wrote: > >On Wed, May 12, 2010 at 04:24:07PM -0700, Mark Haywood wrote: > >>Edward Pilatowicz wrote: > >>>some quick questions. > >>> > >>>how does this functionality interact with different network management > >>>services, specifically network/physical:nwam and > >>>network/physical:default? is network configuration only supported for > >>>one of these methods? if so, what happens if that method is disabled > >>>and another one is in use? > >>The new SMF services being proposed would run before > >>network/physical and would setup persistent configuration before > >>network/physical:nwam and network/physical:default run. So, this > >>functionality basically provides the system with an initial > >>configuration at first boot. network/physical:nwam and > >>network/physical:default should continue to function exactly like > >>they do today on *any* boot. That is, network/physical:default > >>continues to use the system persistent configuration and NWAM uses > >>its profiles to determine what to do. > > > >so it sounds like this new service will essentially configure the system > >to work with either network/physical:nwam or network/physical:default > >? > > Basically yes. This new service will not do anything to the NWAM. It > functions as it always has regardless of what the new service does. > As for network/physical:default, it will use the persistent > configuration provided by this network/install service at first > boot. > > >ie, the new network/install service will create/modify /etc/hostname > >file(s) so that if network/physical:default is enabled the system boots > >with the requested configuration, and, the new network/install service > >will also create and enable a static nwam profile so that if > >network/physical:nwam is enabled we'll get the same requested > >configuration applied? > > No. The new service runs ipadm to create a persistent configuration > (no /etc/hostname*. files in the future). This will be > consumed by network/physcial:default. NWAM ignores the ipadm > configurations and operates the way it always has. > so it sounds like this new network/install service won't support systems using nwam. (since if nwam is enabled the system will not boot with the requested configuration.) so it seems like an error to have this service enabled and to also have NWAM enabled at the same time. also, i have the same question as tony. if nwam already supports profiles why is this case even needed? why doesn't install just apply a nwam profile to the system? ed From mark.haywood@oracle.com Wed May 12 18:33:58 2010 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 o4D1XwPa020144 for ; Wed, 12 May 2010 18:33:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4D1Xwl5008024 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 18:33:58 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2C004054CMMY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 18:33:58 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00HPY4CMHZ60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 18:33:58 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4D1XwUn017545 for ; Thu, 13 May 2010 01:33:58 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4D0cJGm017531 for ; Thu, 13 May 2010 01:33:57 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 260370791273714414; Wed, 12 May 2010 18:33:34 -0700 Received: from Mark-Haywoods-MacBook-Pro.local (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 18:33:33 -0700 Date: Wed, 12 May 2010 21:33:29 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <20100513012518.GA231274@jurassic.Eng.Sun.COM> To: Edward Pilatowicz Cc: Sebastien Roy , PSARC-ext Message-id: <4BEB56E9.3050407@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0206.4BEB5705.0135:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 3293 Edward Pilatowicz wrote: > On Wed, May 12, 2010 at 05:41:26PM -0700, Mark Haywood wrote: > >> Edward Pilatowicz wrote: >> >>> On Wed, May 12, 2010 at 04:24:07PM -0700, Mark Haywood wrote: >>> >>>> Edward Pilatowicz wrote: >>>> >>>>> some quick questions. >>>>> >>>>> how does this functionality interact with different network management >>>>> services, specifically network/physical:nwam and >>>>> network/physical:default? is network configuration only supported for >>>>> one of these methods? if so, what happens if that method is disabled >>>>> and another one is in use? >>>>> >>>> The new SMF services being proposed would run before >>>> network/physical and would setup persistent configuration before >>>> network/physical:nwam and network/physical:default run. So, this >>>> functionality basically provides the system with an initial >>>> configuration at first boot. network/physical:nwam and >>>> network/physical:default should continue to function exactly like >>>> they do today on *any* boot. That is, network/physical:default >>>> continues to use the system persistent configuration and NWAM uses >>>> its profiles to determine what to do. >>>> >>> so it sounds like this new service will essentially configure the system >>> to work with either network/physical:nwam or network/physical:default >>> ? >>> >> Basically yes. This new service will not do anything to the NWAM. It >> functions as it always has regardless of what the new service does. >> As for network/physical:default, it will use the persistent >> configuration provided by this network/install service at first >> boot. >> >> >>> ie, the new network/install service will create/modify /etc/hostname >>> file(s) so that if network/physical:default is enabled the system boots >>> with the requested configuration, and, the new network/install service >>> will also create and enable a static nwam profile so that if >>> network/physical:nwam is enabled we'll get the same requested >>> configuration applied? >>> >> No. The new service runs ipadm to create a persistent configuration >> (no /etc/hostname*. files in the future). This will be >> consumed by network/physcial:default. NWAM ignores the ipadm >> configurations and operates the way it always has. >> >> > > so it sounds like this new network/install service won't support systems > using nwam. (since if nwam is enabled the system will not boot with the > requested configuration.) so it seems like an error to have this > service enabled and to also have NWAM enabled at the same time.\ > No. I don't consider it an error. It is true that this service will install a network configuration that will likely be ignored if NWAM is enabled or enabled at some later point. But it would still serve as the original conifguration that would be restored by NWAM if NWAM was subsequently disabled. > also, i have the same question as tony. if nwam already supports > profiles why is this case even needed? why doesn't install just apply a > nwam profile to the system? > Support for configuring NWAM via SMF properties doesn't exist. And the Install team would prefer to not have to understand the details of an NWAM profile to create one themselves. From Darren.Kenny@Oracle.COM Thu May 13 00:03:05 2010 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 o4D735qw019817 for ; Thu, 13 May 2010 00:03:05 -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.4) with ESMTP id o4D734l7017986 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 01:03:04 -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 <0L2C00M05JL4B300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 00:03:04 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00FKPJL3US80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 00:03:03 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4D732aj016137 for ; Thu, 13 May 2010 07:03:02 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CKPmLL011812 for ; Thu, 13 May 2010 07:03:00 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 237407071273734109; Thu, 13 May 2010 00:01:49 -0700 Received: from [129.156.226.114] (/129.156.226.114) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 00:01:48 -0700 Date: Thu, 13 May 2010 08:01:45 +0100 From: Darren Kenny Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB56E9.3050407@oracle.com> To: Mark Haywood Cc: Edward Pilatowicz , Sebastien Roy , PSARC-ext Message-id: <4BEBA3D9.6070306@Oracle.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BEBA426.002E:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BEB56E9.3050407@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.5pre) Gecko/20100504 Lightning/1.0b2pre OracleBeehiveExtension/1.0.0.0pre6 Lanikai/3.1b2 Status: RO Content-Length: 1023 On 05/13/10 02:33 AM, Mark Haywood wrote: ... > No. I don't consider it an error. It is true that this service will > install a network configuration that will likely be ignored if NWAM is > enabled or enabled at some later point. But it would still serve as the > original conifguration that would be restored by NWAM if NWAM was > subsequently disabled. > IIRC, since this would be the first run of nwam (on boot, post install) then if using NWAM Phase 1, it *will* attempt to import the existing non-nwam configuration - especially if that current configuration configures static IPs, and NIS or LDAP - this was something that was specifically targeted at internal consumers of NWAM upgrading with static IPs. So, if this service sets up a network/physical:default configuration before network/physical:nwam would be run, things should upgrade to NWAM - at least part of the way - exactly how much I'm not 100% sure of. I really would suggest getting input from the NWAM engineers on this part. Thanks, Darren. From Darren.Moffat@Oracle.COM Thu May 13 01:28:47 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4D8Sl9o016903 for ; Thu, 13 May 2010 01:28:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4D8SkEI002254 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 03:28:47 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2C0040JNJYB300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 01:28:46 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C002N7NJYZQ10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 01:28:46 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4D8Skh2022226 for ; Thu, 13 May 2010 08:28:46 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4D8Jbb7020161 for ; Thu, 13 May 2010 08:28:45 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 261082331273739256; Thu, 13 May 2010 01:27:36 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 01:27:35 -0700 Date: Thu, 13 May 2010 09:27:27 +0100 From: Darren J Moffat Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB56E9.3050407@oracle.com> To: Mark Haywood Cc: Edward Pilatowicz , PSARC-ext Message-id: <4BEBB7EF.5030708@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BEBB83D.0182:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BEB56E9.3050407@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 837 > > Support for configuring NWAM via SMF properties doesn't exist. And the > Install team would prefer to not have to understand the details of an > NWAM profile to create one themselves. Sorry but that comment alone is grounds for derailing the case. There is an existing "profile" based architecture that already deals with all of the things this case can do and much more. Please put this case in waiting-need-spec and have the spec updated with detailed information on why using an NWAM profile with a static rather than DHCP based configuration won't work. When that information is available the case can be re-railed if it is still even necessary. There has been a very significant amount of engineering work put into NWAM profiles and the case of static configuration was an important part of it. -- Darren J Moffat From mark.haywood@oracle.com Thu May 13 04:16:10 2010 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 o4DBGABW021058 for ; Thu, 13 May 2010 04:16:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DBG5ID005879 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 04:16:10 -0700 (PDT) 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 <0L2C00029VAXMO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 05:16:09 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00C55VAWQT60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 05:16:08 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DBG8Bt005548 for ; Thu, 13 May 2010 11:16:08 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DBFwel001481 for ; Thu, 13 May 2010 11:16:07 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 261458981273749272; Thu, 13 May 2010 04:14:32 -0700 Received: from Mark-Haywoods-MacBook-Pro.local (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 04:14:31 -0700 Date: Thu, 13 May 2010 07:14:29 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEBB7EF.5030708@Oracle.COM> To: Darren J Moffat Cc: Edward Pilatowicz , PSARC-ext Message-id: <4BEBDF15.6030604@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BEBDF77.01C3:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BEB56E9.3050407@oracle.com> <4BEBB7EF.5030708@Oracle.COM> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 1303 Darren J Moffat wrote: >> >> Support for configuring NWAM via SMF properties doesn't exist. And the >> Install team would prefer to not have to understand the details of an >> NWAM profile to create one themselves. > > Sorry but that comment alone is grounds for derailing the case. There > is an existing "profile" based architecture that already deals with > all of the things this case can do and much more. All blackbirds are black. Not all black birds atre blackbirds. > > Please put this case in waiting-need-spec and have the spec updated > with detailed information on why using an NWAM profile with a static > rather than DHCP based configuration won't work. When that > information is available the case can be re-railed if it is still even > necessary. Yes, a case will be necessary, because as was explained in the first sentence of this case, Install intends to use SMF profiles to configure system resources. No SMF profile exists that will create an NWAM profile any more than one exists to create an ipadm-based configuration. But I agree that a PSARC case for Install might be a prerequisite to this case. > > There has been a very significant amount of engineering work put into > NWAM profiles and the case of static configuration was an important > part of it. > From mark.haywood@oracle.com Thu May 13 04:18:42 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4DBIgS8021135 for ; Thu, 13 May 2010 04:18:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DBIfwV017495 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 04:18:42 -0700 (PDT) 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 <0L2C0000JVF6TF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 05:18:42 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00CA7VF5QT60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 05:18:41 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DBIfNq019631 for ; Thu, 13 May 2010 11:18:41 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DAKMHY029520 for ; Thu, 13 May 2010 11:18:40 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 237916281273749519; Thu, 13 May 2010 04:18:39 -0700 Received: from Mark-Haywoods-MacBook-Pro.local (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 04:18:39 -0700 Date: Thu, 13 May 2010 07:18:37 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEBA3D9.6070306@Oracle.COM> To: Darren Kenny Cc: Edward Pilatowicz , Sebastien Roy , PSARC-ext Message-id: <4BEBE00D.5090304@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BEBE010.0148:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BEB56E9.3050407@oracle.com> <4BEBA3D9.6070306@Oracle.COM> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 1250 Darren Kenny wrote: > On 05/13/10 02:33 AM, Mark Haywood wrote: > ... > >> No. I don't consider it an error. It is true that this service will >> install a network configuration that will likely be ignored if NWAM is >> enabled or enabled at some later point. But it would still serve as the >> original conifguration that would be restored by NWAM if NWAM was >> subsequently disabled. >> >> > > IIRC, since this would be the first run of nwam (on boot, post install) then if > using NWAM Phase 1, it *will* attempt to import the existing non-nwam > configuration - especially if that current configuration configures static IPs, > and NIS or LDAP - this was something that was specifically targeted at internal > consumers of NWAM upgrading with static IPs. > Yes, and this was exactly the point I was trying to make. This service is installing an initial configuration. NWAM already handles this case. > So, if this service sets up a network/physical:default configuration before > network/physical:nwam would be run, things should upgrade to NWAM - at least > part of the way - exactly how much I'm not 100% sure of. I really would suggest > getting input from the NWAM engineers on this part. > > Thanks, > > Darren. > From mark.haywood@oracle.com Thu May 13 04:58:34 2010 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 o4DBwYDq022248 for ; Thu, 13 May 2010 04:58:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DBwXNE022688 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 04:58:34 -0700 (PDT) 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 <0L2C0061JX9MYZ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 04:58:34 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00KDGX9JPX70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 04:58:31 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DBwUFH009943 for ; Thu, 13 May 2010 11:58:30 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DAJWEn010097 for ; Thu, 13 May 2010 11:58:29 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 261557821273751908; Thu, 13 May 2010 04:58:28 -0700 Received: from Mark-Haywoods-MacBook-Pro.local (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 04:58:27 -0700 Date: Thu, 13 May 2010 07:58:25 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEBB7EF.5030708@Oracle.COM> To: Darren J Moffat Cc: Edward Pilatowicz , PSARC-ext Message-id: <4BEBE961.5030503@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BEBE965.01A8:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BEB56E9.3050407@oracle.com> <4BEBB7EF.5030708@Oracle.COM> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 1956 Darren J Moffat wrote: >> >> Support for configuring NWAM via SMF properties doesn't exist. And the >> Install team would prefer to not have to understand the details of an >> NWAM profile to create one themselves. > > Sorry but that comment alone is grounds for derailing the case. There > is an existing "profile" based architecture that already deals with > all of the things this case can do and much more. > > Please put this case in waiting-need-spec and have the spec updated > with detailed information on why using an NWAM profile with a static > rather than DHCP based configuration won't work. When that > information is available the case can be re-railed if it is still even > necessary. > > There has been a very significant amount of engineering work put into > NWAM profiles and the case of static configuration was an important > part of it. > Just to be clear (since I've been informed that I wasn't). What I meant was that the Install team wants configuration to be agnostic to them. They don't want the install mechanism to understand the format of an NWAM profile (unless it is an SMF-based profile ... which it isn't). Install does not even want to rely on the existence of an ipadm(1M) command to configure an IP interface. Install is asking for committed SMF properties that can be used to configure a system. No such thing exists today for configuring IP interfaces. True we (Solaris Networking) could be proposing to provide an SMF profile and SMF service that configured an NWAM profile. However, AI install is seen to be geared more towards Enterprise users. And it is believed that those users would not be interested in having NWAM enabled by default by install. Sorry if that wasn't clear when I said that the "Install team would prefer not to understand the details of an NWAM profile". What I meant was that the Install team does not believe that the install mechanism should have that knowlege. From Darren.Moffat@oracle.com Thu May 13 05:17:37 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4DCHaOU022558 for ; Thu, 13 May 2010 05:17:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DCHaxG017179 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 07:17:36 -0500 (CDT) 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 <0L2C0050OY5CX500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 06:17:36 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2C00C6OY5CQYA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 06:17:36 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DCHZoi018719 for ; Thu, 13 May 2010 12:17:36 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DABsO0024475 for ; Thu, 13 May 2010 12:17:34 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 238035471273753012; Thu, 13 May 2010 05:16:52 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 05:16:52 -0700 Date: Thu, 13 May 2010 13:16:49 +0100 From: Darren J Moffat Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEBE961.5030503@oracle.com> To: Mark Haywood Cc: Edward Pilatowicz , PSARC-ext Message-id: <4BEBEDB1.8040607@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BEBEDDF.00F1:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BEB56E9.3050407@oracle.com> <4BEBB7EF.5030708@Oracle.COM> <4BEBE961.5030503@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 383 With Mark's clarification I'm comfortable with this continuing as a fast-track for now. I share the concern about NIS and LDAP not being covered but I don't see that the architecture of this case precludes equivalent services for those being added (if anything it sets precedence for how to do it), for the SMF issues I'm happy to defer to the SMF experts. -- Darren J Moffat From liane.praza@oracle.com Thu May 13 06:16:50 2010 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 o4DDGo85023077 for ; Thu, 13 May 2010 06:16:50 -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.4) with ESMTP id o4DDGn0B016357 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 07:16:49 -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 <0L2D002190W1JQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 06:16:49 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2D00FD60VZSI40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 06:16:47 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DDGkCA023307 for ; Thu, 13 May 2010 13:16:47 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DCjEkr013122 for ; Thu, 13 May 2010 13:16:46 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 238179791273756585; Thu, 13 May 2010 06:16:25 -0700 Received: from [10.7.251.216] (/10.7.251.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 06:16:24 -0700 Date: Thu, 13 May 2010 06:16:23 -0700 From: Liane Praza Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB3BC1.6040002@oracle.com> To: Mark Haywood Cc: Edward Pilatowicz , Sebastien Roy , PSARC-ext , "POWELL,DAVID" Message-id: <4BEBFBA7.5000005@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BEBFBBE.00F3:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB0D34.8010408@oracle.com> <4BEB3BC1.6040002@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 3048 On 05/12/10 16:37, Mark Haywood wrote: > Liane Praza wrote: >> On 05/12/10 12:51 PM, Edward Pilatowicz wrote: >>> some quick questions. >>> >>> how does this functionality interact with different network management >>> services, specifically network/physical:nwam and >>> network/physical:default? is network configuration only supported for >>> one of these methods? if so, what happens if that method is disabled >>> and another one is in use? >>> >>> does enabling the svc:/network/dns/install have any interactions with >>> nsswitch.conf(4)? for example, is it an error to enable >>> svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). >>> >>> will the svc:/network/install service reconfigure interfaces that >>> already have an existing configuration? >>> >>> will the svc:/network/install service ever unconfigure interfaces? for >>> example, if no install_ipv4_interface and install_ipv6_interface values >>> are specified, and the svc:/network/install service is brought online, >>> will it do anything? >> >> I echo Ed's sentiments and generally have a concern about install-only >> interfaces. (And services named as such.) >> >> It'd be better to consider the direction that the interfaces are >> likely to evolve in long-term and put the properties on the >> appropriate services. It wouldn't have to change the implementation a >> great deal for now, but leaves an interface that has a much better >> chance of evolving. It also allows the opportunity for configuration >> switching of the style that ipfilter uses now: either the properties >> or the files are authoritative, and that's switchable and predictable >> rather than inferred. > > I understand your concern. If network interfaces were currently modeled > in SMF, then this case probably wouldn't be necessary. Modeling the > network interfaces in SMF is not currently a committed project but is > under investigation. However, given the uncertainty in its > implementation we are trying to provide Install with interfaces that > meet their needs in the near-term. If an SMF implementation of network > interfaces comes into existence before Solaris Next, then the proposed > interfaces will be changed. It such an implementation comes into > existence after Solaris Next ships, then the proposed services and their > properties can be used to initialize the new implementations. Does the segregation of the properties to an "install" service help with the forward compatibility goals? I don't see that it does, but maybe I'm missing something. (I believe that with the modifications I suggested, this project could currently be useful at more points in time than just install, which would seem valuable, including for layered administration tools like Visual Panels. The set of configuration parameters deemed necessary for serialization at install time are likely to significantly overlap with the most common configurations, so I believe there's value in allowing the properties you're introducing to be persistently authoritative.) liane From mark.haywood@oracle.com Thu May 13 06:46:15 2010 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 o4DDkFUR023238 for ; Thu, 13 May 2010 06:46:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4DDkBDL031863 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 07:46:14 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2D00J0L292QF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 06:46:14 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2D00FI3291CC70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 06:46:13 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DDkDcB013133 for ; Thu, 13 May 2010 13:46:13 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DDkB4t010371 for ; Thu, 13 May 2010 13:46:11 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 261838211273758300; Thu, 13 May 2010 06:45:00 -0700 Received: from Mark-Haywoods-MacBook-Pro.local (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 06:44:59 -0700 Date: Thu, 13 May 2010 09:44:44 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEBFBA7.5000005@oracle.com> To: Liane Praza Cc: Edward Pilatowicz , Sebastien Roy , PSARC-ext , "POWELL,DAVID" Message-id: <4BEC024C.3000804@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BEC02A4.0185:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB0D34.8010408@oracle.com> <4BEB3BC1.6040002@oracle.com> <4BEBFBA7.5000005@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 3808 Liane Praza wrote: > On 05/12/10 16:37, Mark Haywood wrote: >> Liane Praza wrote: >>> On 05/12/10 12:51 PM, Edward Pilatowicz wrote: >>>> some quick questions. >>>> >>>> how does this functionality interact with different network management >>>> services, specifically network/physical:nwam and >>>> network/physical:default? is network configuration only supported for >>>> one of these methods? if so, what happens if that method is disabled >>>> and another one is in use? >>>> >>>> does enabling the svc:/network/dns/install have any interactions with >>>> nsswitch.conf(4)? for example, is it an error to enable >>>> svc:/network/dns/install if dns is not enabled via nsswitch.conf(4). >>>> >>>> will the svc:/network/install service reconfigure interfaces that >>>> already have an existing configuration? >>>> >>>> will the svc:/network/install service ever unconfigure interfaces? for >>>> example, if no install_ipv4_interface and install_ipv6_interface >>>> values >>>> are specified, and the svc:/network/install service is brought online, >>>> will it do anything? >>> >>> I echo Ed's sentiments and generally have a concern about install-only >>> interfaces. (And services named as such.) >>> >>> It'd be better to consider the direction that the interfaces are >>> likely to evolve in long-term and put the properties on the >>> appropriate services. It wouldn't have to change the implementation a >>> great deal for now, but leaves an interface that has a much better >>> chance of evolving. It also allows the opportunity for configuration >>> switching of the style that ipfilter uses now: either the properties >>> or the files are authoritative, and that's switchable and predictable >>> rather than inferred. >> >> I understand your concern. If network interfaces were currently modeled >> in SMF, then this case probably wouldn't be necessary. Modeling the >> network interfaces in SMF is not currently a committed project but is >> under investigation. However, given the uncertainty in its >> implementation we are trying to provide Install with interfaces that >> meet their needs in the near-term. If an SMF implementation of network >> interfaces comes into existence before Solaris Next, then the proposed >> interfaces will be changed. It such an implementation comes into >> existence after Solaris Next ships, then the proposed services and their >> properties can be used to initialize the new implementations. > > Does the segregation of the properties to an "install" service help > with the forward compatibility goals? I don't see that it does, but > maybe I'm missing something. If there was a better place to hang these properties, I'd propose hanging them there. OK, maybe the DNS properties could be located in the dns/client service. However, I don't believe libresolv is ever going to use SMF properties directly for its configuration. And placing properties there seems to be misleading to me. > > (I believe that with the modifications I suggested, this project could > currently be useful at more points in time than just install, which > would seem valuable, including for layered administration tools like > Visual Panels. The set of configuration parameters deemed necessary > for serialization at install time are likely to significantly overlap > with the most common configurations, so I believe there's value in > allowing the properties you're introducing to be persistently > authoritative.) And I don't believe that I argued your point at all. What I said was that until we get there, this proposal will allow the install team to move forward. I don't believe modeling network configuration will be trivial. If the Install team has to wait for us to do that, then I think we might be impact the Solaris Next schedule. > > liane From sebastien.roy@oracle.com Thu May 13 07:48:20 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4DEmKk0024529 for ; Thu, 13 May 2010 07:48:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DEmKqc021054 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 07:48:20 -0700 (PDT) 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 <0L2D00I0H54KE400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 08:48:20 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2D00CW454J8C40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 08:48:19 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DEmJZX004958 for ; Thu, 13 May 2010 14:48:19 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4D8lgBq028391 for ; Thu, 13 May 2010 14:48:18 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 238442571273762096; Thu, 13 May 2010 07:48:16 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 07:48:15 -0700 Date: Thu, 13 May 2010 10:48:14 -0400 From: Sebastien Roy Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEB1ADF.90200@oracle.com> To: Darren Reed Cc: PSARC-ext , Mark Haywood Message-id: <4BEC112E.2070101@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BEC1132.01C0:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <4BEB1ADF.90200@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 744 On 05/12/10 05:17 PM, Darren Reed wrote: > There seems to be a lot of questions about the details on this case, > as one of the few remaining PSARC members, There are fifteen PSARC members, twelve of which are currently active (meaning not on sabbatical), but that's beside the point. > does this really fall > into the "obvious" category that is usually for fast tracks? To me > this would seem meaty enough to be a full case... I viewed it as a fast-track when I filed it and still feel that way, but I think there is missing install context. There is also some discussion that needs to occur offline between a few of the interested parties before we can move forward with this case. I'll send a separate note to that effect. -Seb From sebastien.roy@oracle.com Thu May 13 08:02:58 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4DF2w1D025069 for ; Thu, 13 May 2010 08:02:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DF2u93027604 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 08:02:58 -0700 (PDT) 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 <0L2D00J0Z5SXNM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 09:02:57 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2D00CCG5SW8760@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 09:02:56 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DF2uJt013337 for ; Thu, 13 May 2010 15:02:56 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CN8hWV010645 for ; Thu, 13 May 2010 15:02:55 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt354.oracle.com with ESMTP id 238480341273762882; Thu, 13 May 2010 08:01:22 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 08:01:22 -0700 Date: Thu, 13 May 2010 11:01:16 -0400 From: Sebastien Roy Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD0D2.7020705@oracle.com> To: PSARC-ext Cc: Mark Haywood Message-id: <4BEC143C.7010608@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BEC14A0.0032:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 468 I'm changing the status of this case to "waiting need spec" while the project team and other interested parties hold offline discussions on the specifics of this case and its greater context. Thanks to those who reviewed this case and provided constructive input. Please hold further comments until an updated spec is provided, or in the meantime, send your feedback directly to Mark or the install team at caiman-discuss@opensolaris.org (Cc me please). -Seb From erik.nordmark@oracle.com Mon May 17 14:42:54 2010 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 o4HLgsKE010932 for ; Mon, 17 May 2010 14:42:54 -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.4) with ESMTP id o4HLgrO1027045 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 17 May 2010 15:42:54 -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 <0L2L00I072ZH0000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 May 2010 14:42:53 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2L00GRT2ZHIY10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 May 2010 14:42:53 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4HLgqC8016831 for ; Mon, 17 May 2010 21:42:53 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HJLhWG011659 for ; Mon, 17 May 2010 21:42:51 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt354.oracle.com with ESMTP id 272211011274132564; Mon, 17 May 2010 14:42:44 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 14:42:43 -0700 Date: Mon, 17 May 2010 14:42:39 -0700 From: Erik Nordmark Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <20100513012518.GA231274@jurassic.Eng.Sun.COM> To: Edward Pilatowicz Cc: Mark Haywood , Sebastien Roy , PSARC-ext Message-id: <4BF1B84F.5090406@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BF1B85C.00E1:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1386 On 05/12/10 06:25 PM, Edward Pilatowicz wrote: > also, i have the same question as tony. if nwam already supports > profiles why is this case even needed? why doesn't install just apply a > nwam profile to the system? > On 05/13/10 01:27 AM, Darren J Moffat wrote: > There has been a very significant amount of engineering work put into > NWAM profiles and the case of static configuration was an important part > of it. The reason NWAM can't be used is that NWAM has a different notion of static addresses than what we provide for enterprise servers using network/physical:default. NWAM's notion of static is reactive in the sense that the static configuration is not applied if the link isn't up (cable plugged in), whereas the network/physical:default applies the configuration whether or not the link is up. Thus replacing network/physical:default with a static NWAM profile would introduce a new failure mode; if the cable is unplugged the server can no longer talk it itself, and server applications that bind to the local IP addresses of the system would fail - since the addresses wouldn't be configured when the link is down. Hence we can't use NWAM for this right now. One of the many projects underway in this area is to consolidate NWAM and physical:default. The NWAM engineers are involved in this and other network configuration projects. Erik From erik.nordmark@oracle.com Mon May 17 14:55:38 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4HLtcTv011227 for ; Mon, 17 May 2010 14:55:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4HLtbMT029772 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 May 2010 16:55:38 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2L004093KPER00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 May 2010 14:55:37 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2L000TG3KPM550@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 May 2010 14:55:37 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4HLtabl017134 for ; Mon, 17 May 2010 21:55:36 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HLl6Tv013742 for ; Mon, 17 May 2010 21:55:35 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 272238351274133333; Mon, 17 May 2010 14:55:33 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 14:55:33 -0700 Date: Mon, 17 May 2010 14:55:28 -0700 From: Erik Nordmark Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEBFBA7.5000005@oracle.com> To: Liane Praza Cc: Mark Haywood , Edward Pilatowicz , Sebastien Roy , PSARC-ext , "POWELL,DAVID" Message-id: <4BF1BB50.7040100@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BF1BB57.0160:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB0D34.8010408@oracle.com> <4BEB3BC1.6040002@oracle.com> <4BEBFBA7.5000005@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2067 On 05/13/10 06:16 AM, Liane Praza wrote: > Does the segregation of the properties to an "install" service help with > the forward compatibility goals? I don't see that it does, but maybe I'm > missing something. > > (I believe that with the modifications I suggested, this project could > currently be useful at more points in time than just install, which > would seem valuable, including for layered administration tools like > Visual Panels. The set of configuration parameters deemed necessary for > serialization at install time are likely to significantly overlap with > the most common configurations, so I believe there's value in allowing > the properties you're introducing to be persistently authoritative.) With the limitations on configuring one network interface, I don't see the IP configuration parts of this having a very long lifetime. We need to figure out how to fit multiple interfaces and IPMP into a configuration manifest sooner rather than later. But there are a few enabling projects that need to happen first. Removing the "install" from the name of this property groups doesn't help AFAICT. I haven't explored all the possibilities for the DNS part. Fundamentally we are talking about distributing the resolv.conf file content as part of the configuration that happens at the first boot after install, but there isn't any planned mechanism in autoinstall to allow such file distribution. But as resolv.conf currently works, the only SMF profile that is possible is one that seeds the resolv.conf on the just installed system and is not used after that step. Otherwise we'd end up with multiple authoritative sources of DNS configuration; one being the /etc/resolv.conf file on the system which the admin might have modified, and the other being the property groups. Thus I think the use of "install" for those property groups is appropriate. If we in some future decide to break with Unix and Linux and no longer have a writable /etc/resolv.conf config file, then we reconsider the DNS property group names. Erik From Darren.Moffat@oracle.com Tue May 18 01:20:05 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4I8K51H010988 for ; Tue, 18 May 2010 01:20:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4I8K4PY006695 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 May 2010 03:20:05 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2L00F1HWHGNO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 May 2010 01:20:04 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2L00BWCWHFX140@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 May 2010 01:20:04 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4I8K3eW027061 for ; Tue, 18 May 2010 08:20:03 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4I5dWwL007661 for ; Tue, 18 May 2010 08:19:59 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 274026861274170781; Tue, 18 May 2010 01:19:41 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 May 2010 01:19:41 -0700 Date: Tue, 18 May 2010 09:19:29 +0100 From: Darren J Moffat Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BF1B84F.5090406@oracle.com> To: Erik Nordmark Cc: Edward Pilatowicz , Mark Haywood , PSARC-ext Message-id: <4BF24D91.9000509@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BF24DB3.0050:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BF1B84F.5090406@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 1686 On 17/05/2010 22:42, Erik Nordmark wrote: > On 05/12/10 06:25 PM, Edward Pilatowicz wrote: >> also, i have the same question as tony. if nwam already supports >> profiles why is this case even needed? why doesn't install just apply a >> nwam profile to the system? >> > > On 05/13/10 01:27 AM, Darren J Moffat wrote: > > There has been a very significant amount of engineering work put into > > NWAM profiles and the case of static configuration was an important part > > of it. > > The reason NWAM can't be used is that NWAM has a different notion of > static addresses than what we provide for enterprise servers using > network/physical:default. > > NWAM's notion of static is reactive in the sense that the static > configuration is not applied if the link isn't up (cable plugged in), > whereas the network/physical:default applies the configuration whether > or not the link is up. > > Thus replacing network/physical:default with a static NWAM profile would > introduce a new failure mode; if the cable is unplugged the server can > no longer talk it itself, and server applications that bind to the local > IP addresses of the system would fail - since the addresses wouldn't be > configured when the link is down. > > Hence we can't use NWAM for this right now. Thanks for that explanation, that makes a lot more sense as the reason why NWAM can't be used than wither or not the NWAM configuration of a static profile is in an SMF xml fragment or not. > One of the many projects underway in this area is to consolidate NWAM > and physical:default. The NWAM engineers are involved in this and other > network configuration projects. That helps too. -- Darren J Moffat From carlsonj@workingcode.com Tue May 18 04:52:12 2010 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 o4IBqC3J014537 for ; Tue, 18 May 2010 04:52:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4IBqBFw005337 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 May 2010 04:52:12 -0700 (PDT) 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 <0L2M00F216AZ3J00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 May 2010 05:52:11 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2M00EUL6AY1C00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 May 2010 05:52:10 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4IBq90W021664 for ; Tue, 18 May 2010 11:52:10 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-753188 for PSARC-ext@sun.com; Tue, 18 May 2010 11:52:08 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-213187850 for PSARC-ext@sun.com; Tue, 18 May 2010 11:52:07 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-26415091 for PSARC-ext@sun.com; Tue, 18 May 2010 11:52:07 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4IBq1vr013588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 07:52:02 -0400 (EDT) Date: Tue, 18 May 2010 07:52:01 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BF24D91.9000509@Oracle.COM> To: Darren J Moffat Cc: Erik Nordmark , Mark Haywood , PSARC-ext Message-id: <4BF27F61.5000901@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=-2.6/5.0, scanned in 0.144sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BF1B84F.5090406@oracle.com> <4BF24D91.9000509@Oracle.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2358 Darren J Moffat wrote: > On 17/05/2010 22:42, Erik Nordmark wrote: >> Thus replacing network/physical:default with a static NWAM profile would >> introduce a new failure mode; if the cable is unplugged the server can >> no longer talk it itself, and server applications that bind to the local >> IP addresses of the system would fail - since the addresses wouldn't be >> configured when the link is down. >> >> Hence we can't use NWAM for this right now. > > Thanks for that explanation, that makes a lot more sense as the reason > why NWAM can't be used than wither or not the NWAM configuration of a > static profile is in an SMF xml fragment or not. It does make more sense, but how is it relevant for system install? Surely you don't want to have (and can't have) your network interfaces stuck "down" while attempting to do a network-based install, right? Erik's description of this problem would be a reason why the current NWAM would be unsuitable for _installed_ server systems (and is perhaps a bug), but I don't think it addresses this _installer_ project directly. I think that one of the underlying arguments in favor of this project is that since this is a one-shot deal (used only during install time, not in any subsequent post-install ordinary operation), it doesn't have to look like anything else, nor include options for all of the current networking features, nor follow any of the rest of the design in this area. It's an exception. Even given that situation, I still think the project is misguided. A better approach would be to help the NWAM project do what's needed rather than building a bypass out of bailing wire. It seems a shame to miss the opportunity to have these groups working together rather than at cross-purposes. This feels a lot like one of those nasty corners of the system (like sysid) that are eventually forgotten and left in disrepair. The result we've seen in the past is bugs and user frustration when subtle differences between the "install only" and the "real" configuration environment lead to systems that either can't be installed when everyone else on the wire is working fine, or to systems that install perfectly but then fail to connect to the net after reboot. It'd sure be nice if install weren't a special case. -- James Carlson 42.703N 71.076W From erik.nordmark@oracle.com Wed May 19 03:06:22 2010 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 o4JA6MOW029093 for ; Wed, 19 May 2010 03:06:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4JA6LVk061281 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 May 2010 04:06:21 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2N00N05W2L5700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 May 2010 03:06:21 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2N00KPFW2KYR30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 May 2010 03:06:21 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4JA6Ktc018151 for ; Wed, 19 May 2010 10:06:20 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4JA6CaS015387; Wed, 19 May 2010 10:06:12 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 249978491274263566; Wed, 19 May 2010 03:06:06 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 May 2010 03:06:05 -0700 Date: Wed, 19 May 2010 03:06:01 -0700 From: Erik Nordmark Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BF27F61.5000901@workingcode.com> To: James Carlson Cc: Darren J Moffat , Mark Haywood , PSARC-ext Message-id: <4BF3B809.5060603@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BF3B815.0076:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BF1B84F.5090406@oracle.com> <4BF24D91.9000509@Oracle.COM> <4BF27F61.5000901@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2788 On 05/18/10 04:52 AM, James Carlson wrote: > Darren J Moffat wrote: >> On 17/05/2010 22:42, Erik Nordmark wrote: >>> Thus replacing network/physical:default with a static NWAM profile would >>> introduce a new failure mode; if the cable is unplugged the server can >>> no longer talk it itself, and server applications that bind to the local >>> IP addresses of the system would fail - since the addresses wouldn't be >>> configured when the link is down. >>> >>> Hence we can't use NWAM for this right now. >> >> Thanks for that explanation, that makes a lot more sense as the reason >> why NWAM can't be used than wither or not the NWAM configuration of a >> static profile is in an SMF xml fragment or not. > > It does make more sense, but how is it relevant for system install? > Surely you don't want to have (and can't have) your network interfaces > stuck "down" while attempting to do a network-based install, right? > > Erik's description of this problem would be a reason why the current > NWAM would be unsuitable for _installed_ server systems (and is perhaps > a bug), but I don't think it addresses this _installer_ project directly. > > I think that one of the underlying arguments in favor of this project is > that since this is a one-shot deal (used only during install time, not > in any subsequent post-install ordinary operation), it doesn't have to > look like anything else, nor include options for all of the current > networking features, nor follow any of the rest of the design in this > area. It's an exception. The plan is for this project to handle the initial requirements from the install team, and be useful as a stepping stone as we 1) make the configuration post install more feature-rich and 2) move the network configuration into the SMF. I realize the ARC can't review that, because it isn't done. Hence it is hard for the ARC to add value in this case. > Even given that situation, I still think the project is misguided. A > better approach would be to help the NWAM project do what's needed > rather than building a bypass out of bailing wire. It seems a shame to > miss the opportunity to have these groups working together rather than > at cross-purposes. I don't understand how speculating on the organizational structure at Oracle is part of the ARC process. FWIW There is one organization working on network configuration. That includes folks that have previously worked on NWAM. There is a plan with a set of projects to incrementally improve the network configuration. I hope we can get those done as soon as possible, but there is significant work to be done as we complete the transition to ipadm, move away from /etc/hostname files and towards SMF, and integrate (NWAM) profiles into the base of the system. Erik From carlsonj@workingcode.com Wed May 19 04:38:31 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4JBcV6V000296 for ; Wed, 19 May 2010 04:38:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4JBcU7O027547 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 May 2010 04:38:31 -0700 (PDT) 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 <0L2O0020J0C6EY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 May 2010 05:38:30 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2O00F560C6CK60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 May 2010 05:38:30 -0600 (MDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4JBTAgW014643 for ; Wed, 19 May 2010 11:38:30 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-2193535 for PSARC-ext@sun.com; Wed, 19 May 2010 11:38:29 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-215647009 for PSARC-ext@sun.com; Wed, 19 May 2010 11:38:29 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-41182654 for PSARC-ext@sun.com; Wed, 19 May 2010 11:38:28 +0000 (Z) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4JBbvE0018968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 07:37:58 -0400 (EDT) Date: Wed, 19 May 2010 07:37:57 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BF3B809.5060603@oracle.com> To: Erik Nordmark Cc: Darren J Moffat , Mark Haywood , PSARC-ext Message-id: <4BF3CD95.5060101@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=-0.7/5.0, scanned in 0.182sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BF1B84F.5090406@oracle.com> <4BF24D91.9000509@Oracle.COM> <4BF27F61.5000901@workingcode.com> <4BF3B809.5060603@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2822 On 05/19/10 06:06, Erik Nordmark wrote: > On 05/18/10 04:52 AM, James Carlson wrote: >> I think that one of the underlying arguments in favor of this project is >> that since this is a one-shot deal (used only during install time, not >> in any subsequent post-install ordinary operation), it doesn't have to >> look like anything else, nor include options for all of the current >> networking features, nor follow any of the rest of the design in this >> area. It's an exception. > > The plan is for this project to handle the initial requirements from the > install team, and be useful as a stepping stone as we 1) make the > configuration post install more feature-rich and 2) move the network > configuration into the SMF. > > I realize the ARC can't review that, because it isn't done. Hence it is > hard for the ARC to add value in this case. It'd be nice if some of those broader plans were included somewhere for review or at least for reference. It is indeed hard for ARC members and other participants to make any sense out of the materials submitted for review if there are crucial parts that are not included. The quality of the review and the eventual product both suffer. >> Even given that situation, I still think the project is misguided. A >> better approach would be to help the NWAM project do what's needed >> rather than building a bypass out of bailing wire. It seems a shame to >> miss the opportunity to have these groups working together rather than >> at cross-purposes. > > I don't understand how speculating on the organizational structure at > Oracle is part of the ARC process. I'm talking about the projects and the relationships between them, which are the items under review by the ARC. I neither know nor care about Oracle's internal structure. One of the important jobs of the ARC is to make sure that (as much as as possible) projects are working together in a common direction. The fact that there were clear statements in this thread from project team members saying that they didn't want to have to understand NWAM profiles certainly makes it appear that project alignment is one of the problems. http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00616.html http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00626.html http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00605.html > FWIW There is one organization working on network configuration. That > includes folks that have previously worked on NWAM. Then let's cut to the chase: have these install configuration bits been discussed on nwam-discuss? As the 20q document would ask: are the folks who are working in the NWAM area aware of what this project is doing, and do they agree with it? -- James Carlson 42.703N 71.076W From erik.nordmark@oracle.com Wed May 19 06:10:14 2010 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 o4JDAE07001730 for ; Wed, 19 May 2010 06:10:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4JDAD8N027927 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 May 2010 07:10:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2O009034L11S00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 May 2010 06:10:13 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2O00KWB4L0YLD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 May 2010 06:10:13 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4JDACtC006308 for ; Wed, 19 May 2010 13:10:12 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4J78bjM020305; Wed, 19 May 2010 13:10:01 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 280779101274274534; Wed, 19 May 2010 06:08:54 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 May 2010 06:08:53 -0700 Date: Wed, 19 May 2010 06:08:49 -0700 From: Erik Nordmark Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BF3CD95.5060101@workingcode.com> To: James Carlson Cc: Darren J Moffat , Mark Haywood , PSARC-ext Message-id: <4BF3E2E1.2080305@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BF3E32B.0094:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BF1B84F.5090406@oracle.com> <4BF24D91.9000509@Oracle.COM> <4BF27F61.5000901@workingcode.com> <4BF3B809.5060603@oracle.com> <4BF3CD95.5060101@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 3727 On 05/19/10 04:37 AM, James Carlson wrote: > It'd be nice if some of those broader plans were included somewhere for > review or at least for reference. It is indeed hard for ARC members and > other participants to make any sense out of the materials submitted for > review if there are crucial parts that are not included. The first order issue is that AI, which has been underway for years, isn't available for review yet. The network configuration roadmap and its projects are still seeing significant change. If AI had been presented to the ARC, I could put together an overview/umbrella presentation of the network configuration projects that we are discussing. But I don't know if that is useful given that there isn't similar material for AI available to the ARC. > The quality of the review and the eventual product both suffer. The ARC isn't the only place where things get reviewed, hence I'm not too concerned about the product quality in the space of network configuration. >>> Even given that situation, I still think the project is misguided. A >>> better approach would be to help the NWAM project do what's needed >>> rather than building a bypass out of bailing wire. It seems a shame to >>> miss the opportunity to have these groups working together rather than >>> at cross-purposes. >> >> I don't understand how speculating on the organizational structure at >> Oracle is part of the ARC process. > > I'm talking about the projects and the relationships between them, which > are the items under review by the ARC. I neither know nor care about > Oracle's internal structure. Sorry, but you were referring to there being separate groups (and such groups consists of people AFAIK) not working together, when in fact that doesn't match the current organization. > One of the important jobs of the ARC is to make sure that (as much as as > possible) projects are working together in a common direction. Had your comment been "have you coordinated with the XYZ project" it would have been different. However, the NWAM project is done apart from any followup bug fixing, hence it isn't useful to coordinate with that project. Moving forward we have a set of work in the area of networking configuration that spans the range from how servers are typically configured to the problems NWAM set out to solve. The reason to structure things that way is exactly to avoid the problems you are concerned about. > The fact > that there were clear statements in this thread from project team > members saying that they didn't want to have to understand NWAM profiles > certainly makes it appear that project alignment is one of the problems. > > http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00616.html > http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00626.html > http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00605.html I don't see anything on those emails where Mark says or implies that he doesn't want to have to understand NWAM profiles. Hence I think you owe Mark an apology. > >> FWIW There is one organization working on network configuration. That >> includes folks that have previously worked on NWAM. > > Then let's cut to the chase: have these install configuration bits been > discussed on nwam-discuss? Not AFAIK. But the NWAM project is done apart from bug fixing hence it might not be that relevant. > As the 20q document would ask: are the folks > who are working in the NWAM area aware of what this project is doing, > and do they agree with it? In a previous email I said: > The NWAM engineers are involved in this and other network configuration projects. Perhaps that wasn't sufficiently clear. Erik From carlsonj@workingcode.com Wed May 19 10:52:44 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4JHqhRN009679 for ; Wed, 19 May 2010 10:52:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4JHqgxr023015 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 May 2010 12:52:43 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2O00K0FHNUW900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 May 2010 10:52:42 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2O00KLCHNTFJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 May 2010 10:52:41 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4JHqdqU024986 for ; Wed, 19 May 2010 17:52:40 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-3686789 for PSARC-ext@sun.com; Wed, 19 May 2010 17:52:39 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-218654222 for PSARC-ext@sun.com; Wed, 19 May 2010 17:52:38 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-5500555 for PSARC-ext@sun.com; Wed, 19 May 2010 17:52:37 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4JHpq9K006809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 13:51:57 -0400 (EDT) Date: Wed, 19 May 2010 13:51:50 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BF3E2E1.2080305@oracle.com> To: Erik Nordmark Cc: Darren J Moffat , Mark Haywood , PSARC-ext Message-id: <4BF42536.4050705@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=-0.7/5.0, scanned in 0.248sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BF1B84F.5090406@oracle.com> <4BF24D91.9000509@Oracle.COM> <4BF27F61.5000901@workingcode.com> <4BF3B809.5060603@oracle.com> <4BF3CD95.5060101@workingcode.com> <4BF3E2E1.2080305@oracle.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 6033 Erik Nordmark wrote: > On 05/19/10 04:37 AM, James Carlson wrote: > >> It'd be nice if some of those broader plans were included somewhere for >> review or at least for reference. It is indeed hard for ARC members and >> other participants to make any sense out of the materials submitted for >> review if there are crucial parts that are not included. > > The first order issue is that AI, which has been underway for years, > isn't available for review yet. The network configuration roadmap and > its projects are still seeing significant change. > > If AI had been presented to the ARC, I could put together an > overview/umbrella presentation of the network configuration projects > that we are discussing. > > But I don't know if that is useful given that there isn't similar > material for AI available to the ARC. I see. >> The quality of the review and the eventual product both suffer. > > The ARC isn't the only place where things get reviewed, hence I'm not > too concerned about the product quality in the space of network > configuration. The ARC is where the architecture of projects for OpenSolaris is supposed to be reviewed. If changes and plans are also reviewed elsewhere, that's great, but I don't think such reviews are in any way a substitute ... as long as the ARC still exists and serves some useful function. On the other hand, I completely agree that without the background information, it's not possible for the ARC to "add value." >>> I don't understand how speculating on the organizational structure at >>> Oracle is part of the ARC process. >> >> I'm talking about the projects and the relationships between them, which >> are the items under review by the ARC. I neither know nor care about >> Oracle's internal structure. > > Sorry, but you were referring to there being separate groups (and such > groups consists of people AFAIK) not working together, when in fact that > doesn't match the current organization. If it helps, I'm happy running s/group/project team/g on any of the previous statements I made. Again, I neither know nor care about Oracle's internal structure. >> One of the important jobs of the ARC is to make sure that (as much as as >> possible) projects are working together in a common direction. > > Had your comment been "have you coordinated with the XYZ project" it > would have been different. However, the NWAM project is done apart from > any followup bug fixing, hence it isn't useful to coordinate with that > project. > > Moving forward we have a set of work in the area of networking > configuration that spans the range from how servers are typically > configured to the problems NWAM set out to solve. The reason to > structure things that way is exactly to avoid the problems you are > concerned about. When NWAM first came for review (and then again when it came for review of Phase 1), PSARC members asked the project team why physical:default was still present, and why NWAM was just an "option," and indeed _not_ even the default one at that. The answer was that NWAM would eventually be the only way to configure the system, and that the project team recognized that it was less good to have two separate mechanisms, but that this would persist for some time. At least until NWAM (in Phase 2) eventually grew the features necessary for enterprise-scale operation. Then, in the Phase 1 review, the NWAM project team introduced "profiles" as a key concept in the NWAM architecture which (still, at that time) was intended to be the future way for configuring interfaces, and which the ARC members were told was consistent with the SMF goals. If I'm reading what you've written above correctly, it seems that you're saying that the future architecture won't necessarily be what was originally reviewed -- that there is no "Phase 2" and NWAM won't be the sole mechanism -- and that some higher level work is being done. But that there's no ARC material available at the moment that describes this. The hard part for the folks on the ARC list, though, is to figure out how the proposal here eventually morphs into that future architecture. I know I don't see it. As described in the last opinion, we are (or were) waiting for future NWAM phases (that I now assume are no longer happening): http://arc.opensolaris.org/caselog/PSARC/2008/532/opinion.txt >> The fact >> that there were clear statements in this thread from project team >> members saying that they didn't want to have to understand NWAM profiles >> certainly makes it appear that project alignment is one of the problems. >> >> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00616.html >> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00626.html >> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00605.html > > I don't see anything on those emails where Mark says or implies that he > doesn't want to have to understand NWAM profiles. Hence I think you owe > Mark an apology. Here's what he wrote in that very first message I cited: "And the Install team would prefer to not have to understand the details of an NWAM profile to create one themselves. " I don't believe I've written anything that requires that I give an apology to Mark. But if he is indeed offended, I hope that he'll speak up about it, at least privately, and I'll be happy to reply. Certainly no offense of any sort was intended. My interpretation of that statement was that even if profiles are a core concept in NWAM, dependence on them would be unwise for another project. The implication is that either they're too complex for the task at hand, or too unstable, or perhaps that NWAM itself will be supplanted. All of those seem possible, I don't know which is the case, but there's at least a lack of clarity on how these things align. Thus, I think the earlier questions from Darren and others asking why NWAM isn't part of this answer are right on the mark. -- James Carlson 42.703N 71.076W From erik.nordmark@oracle.com Fri May 21 06:47:15 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LDlF5K005098 for ; Fri, 21 May 2010 06:47:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LDl6iQ010586 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 06:47:14 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00G1DVMKSB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 06:47:08 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00329VMKKZD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 06:47:08 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4LDl7lZ022165 for ; Fri, 21 May 2010 13:47:07 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4LDkswc025611; Fri, 21 May 2010 13:46:55 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 287932851274449608; Fri, 21 May 2010 06:46:48 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 06:46:45 -0700 Date: Fri, 21 May 2010 06:46:15 -0700 From: Erik Nordmark Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BF42536.4050705@workingcode.com> To: James Carlson Cc: Darren J Moffat , Mark Haywood , PSARC-ext Message-id: <4BF68EA7.8060801@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BF68ED8.0186:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BF1B84F.5090406@oracle.com> <4BF24D91.9000509@Oracle.COM> <4BF27F61.5000901@workingcode.com> <4BF3B809.5060603@oracle.com> <4BF3CD95.5060101@workingcode.com> <4BF3E2E1.2080305@oracle.com> <4BF42536.4050705@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 3785 On 05/19/10 10:51 AM, James Carlson wrote: >> Moving forward we have a set of work in the area of networking >> configuration that spans the range from how servers are typically >> configured to the problems NWAM set out to solve. The reason to >> structure things that way is exactly to avoid the problems you are >> concerned about. > > When NWAM first came for review (and then again when it came for review > of Phase 1), PSARC members asked the project team why physical:default > was still present, and why NWAM was just an "option," and indeed _not_ > even the default one at that. > > The answer was that NWAM would eventually be the only way to configure > the system, and that the project team recognized that it was less good > to have two separate mechanisms, but that this would persist for some > time. At least until NWAM (in Phase 2) eventually grew the features > necessary for enterprise-scale operation. > > Then, in the Phase 1 review, the NWAM project team introduced "profiles" > as a key concept in the NWAM architecture which (still, at that time) > was intended to be the future way for configuring interfaces, and which > the ARC members were told was consistent with the SMF goals. > > If I'm reading what you've written above correctly, it seems that you're > saying that the future architecture won't necessarily be what was > originally reviewed -- that there is no "Phase 2" and NWAM won't be the > sole mechanism -- and that some higher level work is being done. But > that there's no ARC material available at the moment that describes this. I don't know what I said above that made you come to that conclusion. The project named NWAM is done, and we are continuing to work in the area of network configuration (to solve the problems NWAM set out to solve). > The hard part for the folks on the ARC list, though, is to figure out > how the proposal here eventually morphs into that future architecture. > I know I don't see it. As described in the last opinion, we are (or > were) waiting for future NWAM phases (that I now assume are no longer > happening): I think you are confusing the name of the project NWAM with the capabilities of the system going forward. As I said, we are working on network configuration that spans the range from how servers are typically configured to the problems NWAM set out to solve. >>> The fact >>> that there were clear statements in this thread from project team >>> members saying that they didn't want to have to understand NWAM profiles >>> certainly makes it appear that project alignment is one of the problems. >>> >>> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00616.html >>> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00626.html >>> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00605.html >> >> I don't see anything on those emails where Mark says or implies that he >> doesn't want to have to understand NWAM profiles. Hence I think you owe >> Mark an apology. > > Here's what he wrote in that very first message I cited: > > "And the Install team would prefer to not have to understand the > details of an NWAM profile to create one themselves. " > > I don't believe I've written anything that requires that I give an > apology to Mark. But if he is indeed offended, I hope that he'll speak > up about it, at least privately, and I'll be happy to reply. Certainly > no offense of any sort was intended. Mark clealy referred to "the Install team". You replaced that by "project team members". Those are completely separate. None from the Install team have commented on this email thread. Mark later clarified why the Install team want to decouple themselves from everything which doesn't look like an SMF profile. Erik From mark.haywood@oracle.com Mon May 24 09:36:27 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4OGaR54002857 for ; Mon, 24 May 2010 09:36:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4OGaRYl011859 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 24 May 2010 09:36:27 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2X00G05NGR2700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 24 May 2010 09:36:27 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2X00E32NGPBS20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 24 May 2010 09:36:26 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4OGaPCM004312 for ; Mon, 24 May 2010 16:36:25 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4OGHq54015980; Mon, 24 May 2010 16:36:22 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 293491541274718885; Mon, 24 May 2010 09:34:45 -0700 Received: from Mark-Haywoods-MacBook-Pro.local (/10.7.250.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 May 2010 09:34:45 -0700 Date: Mon, 24 May 2010 12:34:42 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BF42536.4050705@workingcode.com> To: James Carlson Cc: Erik Nordmark , Darren J Moffat , PSARC-ext Message-id: <4BFAAAA2.3050004@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0202.4BFAAB07.0097:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> <20100512195149.GH176566@jurassic.Eng.Sun.COM> <4BEB3897.8020000@oracle.com> <20100513002014.GI176566@jurassic.Eng.Sun.COM> <4BEB4AB6.6080107@oracle.com> <20100513012518.GA231274@jurassic.Eng.Sun.COM> <4BF1B84F.5090406@oracle.com> <4BF24D91.9000509@Oracle.COM> <4BF27F61.5000901@workingcode.com> <4BF3B809.5060603@oracle.com> <4BF3CD95.5060101@workingcode.com> <4BF3E2E1.2080305@oracle.com> <4BF42536.4050705@workingcode.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 3656 James Carlson wrote: > Erik Nordmark wrote: > >> On 05/19/10 04:37 AM, James Carlson wrote: >> >> >>> The fact >>> that there were clear statements in this thread from project team >>> members saying that they didn't want to have to understand NWAM profiles >>> certainly makes it appear that project alignment is one of the problems. >>> >>> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00616.html >>> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00626.html >>> http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00605.html >>> >> I don't see anything on those emails where Mark says or implies that he >> doesn't want to have to understand NWAM profiles. Hence I think you owe >> Mark an apology. >> > > Here's what he wrote in that very first message I cited: > > "And the Install team would prefer to not have to understand the > details of an NWAM profile to create one themselves. " > > I don't believe I've written anything that requires that I give an > apology to Mark. But if he is indeed offended, I hope that he'll speak > up about it, at least privately, and I'll be happy to reply. Certainly > no offense of any sort was intended. > Sorry. I was on vacation last week and was unable to demand an apology. This week I don't feel like I need one. > My interpretation of that statement was that even if profiles are a core > concept in NWAM, dependence on them would be unwise for another project. > The implication is that either they're too complex for the task at > hand, or too unstable, or perhaps that NWAM itself will be supplanted. > > All of those seem possible, I don't know which is the case, but there's > at least a lack of clarity on how these things align. > I thought that my prior explanation: "Just to be clear (since I've been informed that I wasn't). What I meant was that the Install team wants configuration to be agnostic to them. They don't want the install mechanism to understand the format of an NWAM profile (unless it is an SMF-based profile ... which it isn't). Install does not even want to rely on the existence of an ipadm(1M) command to configure an IP interface. Install is asking for committed SMF properties that can be used to configure a system. No such thing exists today for configuring IP interfaces. True we (Solaris Networking) could be proposing to provide an SMF profile and SMF service that configured an NWAM profile. However, AI install is seen to be geared more towards Enterprise users. And it is believed that those users would not be interested in having NWAM enabled by default by install. Sorry if that wasn't clear when I said that the "Install team would prefer not to understand the details of an NWAM profile". What I meant was that the Install team does not believe that the install mechanism should have that knowlege." made it pretty clear that none of what you suggest was the intent of my comment? > Thus, I think the earlier questions from Darren and others asking why > NWAM isn't part of this answer are right on the mark. > I and the folks working on install don't believe that NWAM is yet functionally complete enough to be the default service for our Enterprise customers. And therefore, we chose to provide install with a mechanism for configuring an initial physical:default configuration. Does this mean that we (Solaris Networking) aren't working on doing away with the separation between physical:default and physical:nwam? No. That work is being planned. When completed, I believe that the interfaces proposed by this case will be changed appropriately. From dave.miner@oracle.com Wed Jun 2 07:33:02 2010 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 o52EX2bW001002 for ; Wed, 2 Jun 2010 07:33:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o52EWxf6012987; Wed, 2 Jun 2010 08:33:00 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3E0020Z5R03H00@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Jun 2010 07:33:00 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E00H0Y5QZ99A0@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Jun 2010 07:32:59 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o52EWwpI006695; Wed, 02 Jun 2010 14:32:59 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o52EWsgW012255; Wed, 02 Jun 2010 14:32:54 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 316266181275489078; Wed, 02 Jun 2010 07:31:18 -0700 Received: from krissy.2greys.com (/129.150.80.69) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jun 2010 07:31:18 -0700 Date: Wed, 02 Jun 2010 10:31:16 -0400 From: Dave Miner Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <4BFC277E.6050401@oracle.com> To: PSARC-ext@sun.com Cc: Mark Haywood , Jan Damborsky , Ethan Quach Message-id: <4C066B34.1080604@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C066B9A.0132:SCFMA4539814,ss=1,fgs=0 References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre6 Thunderbird/3.0.4 Status: RO Content-Length: 4535 To help get this case back on track, I've been asked to respond to some of the concerns regarding its relationship to the installation architecture raised in the discussion so far. Mark and Erik have responded to questions on the networking-specific aspects of the architecture (relationship to NWAM, etc.) already and I won't repeat those points. As Seb noted in some off-line discussion, it would be helpful to place this in context with the original Caiman umbrella case (PSARC/2007/039), as that would seem to most directly cover the questions that have been raised, and I agree, it's well past time we offered an update. I'll schedule that in the near future. However, I think this case can and should proceed in advance of that discussion. First, I hope that the use of SMF profiles as a replacement for the sysidcfg(4) mechanism is neither surprising nor controversial, as it's been the plan of record since the inception of the new installer four years ago and is something I've talked about in every presentation on the program. Indeed, it's a significant driver for enhancements delivered by PSARC/2009/371 and PSARC/2010/157, and conversion of existing miscellaneous configuration data to SMF is the subject of other existing (PSARC/2010/183) and forthcoming cases. The interfaces provided by this case will be leveraged in the installation architecture in two ways. First, we require a way to transfer configuration information gathered by the interactive installers (GUI and Text) to the installed system. Second, we require a way for administrators to express the desired configuration of the installed system to an Automated Install (AI). Install will be using this case's interfaces to satisfy both of those requirements. Interactive installers will generate SMF profiles that are applied at first boot, while AI users will, at least for now pending any future work on AI tooling, supply SMF profiles directly. I note that, contrary to speculation offered in some of the comments, the mechanism proposed here is explicitly not used to configure the installation environment itself; the networking environment used in executing a network-based installation such as Automated Install is necessarily derived from DHCP (x86 or SPARC) or the OBP properties (SPARC only, not yet working in AI but planned). Other comments offered related to the set of parameters: - Why not more interfaces, routes, datalinks, etc.? The interactive installers are at present only configuring a single interface; additional networking configuration is expected to be the province of more complete management tools used post-installation. Thus, we provided those basic requirements to networking as a starting point for discussion, leading to this proposal. We would welcome having the capability to provide more complex network configuration as part of AI, though, and indeed think it is a requirement long-term; Erik and Mark have already discussed the issues there. - Why not LDAP or NIS? They're not part of this case for two reasons. First, the networking organization doesn't own either one of those technologies, so it's out of Mark's scope, and second, we just aren't ready to handle them yet in the installers. Both are candidates for inclusion in the overall configuration plan once we get farther along; LDAP, at least, is a certainty in my view. - Why not just pass over a resolv.conf for DNS? We believe that providing a basic, initial DNS configuration via SMF properties is reasonable in order to provide AI users with a relatively straightforward configuration mechanism using one file, which was one of the good points of sysidcfg(4). This does not preclude the use of other mechanisms, such as configuration management tools like cfengine that replicate configuration files directly, and we are considering ways that the installers can integrate well with those long-term. The approach taken by the networking team (and others) in producing serialized, complex configurations might also demand similar capabilities, and we'll be continuing that discussion over the coming months. Finally, for more background on the system configuration work for installation, I'll note the project page on opensolaris.org[1]. It's not ready for ARC review at this time, but input via caiman-discuss@opensolaris.org or to me or Jan Damborsky directly would be welcome. Dave [1]http://hub.opensolaris.org/bin/view/Project+caiman/System+Configuration+Project From carlsonj@workingcode.com Wed Jun 2 10:33:48 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o52HXmxq010077 for ; Wed, 2 Jun 2010 10:33:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o52HV6ZH029082 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 10:33:46 -0700 (PDT) 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 <0L3E00L09E42FC00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 11:33:38 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E00A2EE415PB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 11:33:37 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o52HNbRV012192 for ; Wed, 02 Jun 2010 17:33:37 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-2377478 for PSARC-ext@sun.com; Wed, 02 Jun 2010 17:33:37 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-250580173 for PSARC-ext@sun.com; Wed, 02 Jun 2010 17:33:36 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-21840546 for PSARC-ext@sun.com; Wed, 02 Jun 2010 17:33:36 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o52HXVjW008735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 02 Jun 2010 13:33:31 -0400 (EDT) Date: Wed, 02 Jun 2010 13:33:31 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <4C066B34.1080604@oracle.com> To: Dave Miner Cc: PSARC-ext@sun.com, Mark Haywood , Ethan Quach Message-id: <4C0695EB.40503@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-sonic.net-Metrics: carlson; whitelist X-Antispam: No, score=-2.6/5.0, scanned in 0.132sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2611 Dave Miner wrote: > First, I hope that the use of SMF profiles as a replacement for the > sysidcfg(4) mechanism is neither surprising nor controversial, as it's > been the plan of record since the inception of the new installer four > years ago and is something I've talked about in every presentation on > the program. Indeed, it's a significant driver for enhancements > delivered by PSARC/2009/371 and PSARC/2010/157, and conversion of > existing miscellaneous configuration data to SMF is the subject of other > existing (PSARC/2010/183) and forthcoming cases. That's certainly not surprising to me. > The interfaces provided by this case will be leveraged in the > installation architecture in two ways. First, we require a way to > transfer configuration information gathered by the interactive > installers (GUI and Text) to the installed system. Second, we require a > way for administrators to express the desired configuration of the > installed system to an Automated Install (AI). Install will be using > this case's interfaces to satisfy both of those requirements. > Interactive installers will generate SMF profiles that are applied at > first boot, while AI users will, at least for now pending any future > work on AI tooling, supply SMF profiles directly. The remaining doubt I have about the project revolves around the network/physical instances. Currently, when OpenSolaris is installed from a CD, unlike legacy Solaris, it enables NWAM by default. Given the way this project is translating SMF properties into /etc/* information, though, it seems that install profiles based on this project might be required to disable physical:nwam and enable physical:default instead. Otherwise, NWAM will just walk all over the configuration bits. (That might be what someone wants, but then that same someone likely wouldn't want any of the unused static configuration bits from this project.) Is that a reasonable understanding? That installing OpenSolaris from fixed media will result in NWAM being enabled, but that automated installs will result in NWAM (at least usually) being disabled? If so, then what's the longer-term plan? Will we want to keep the nwam/default fork as it proves useful here? Or might there be a future NWAM that knows how to read these SMF properties? Or are we perhaps going a different direction altogether? That's the part that still confuses me. I'd expected that, just as installation was "based on" NWAM in OpenSolaris, this would be the pattern for the future as well. -- James Carlson 42.703N 71.076W From carlsonj@workingcode.com Wed Jun 2 10:43:21 2010 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 o52HhLVH010728 for ; Wed, 2 Jun 2010 10:43:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o52HhKbk004280 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 10:43:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3E00B0HEK80Y00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 10:43:20 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E009BFEK8QV30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 10:43:20 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o52HcWCZ013499 for ; Wed, 02 Jun 2010 17:43:19 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-62452 for PSARC-ext@sun.com; Wed, 02 Jun 2010 17:43:19 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-188686762 for PSARC-ext@sun.com; Wed, 02 Jun 2010 17:43:19 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-501755 for PSARC-ext@sun.com; Wed, 02 Jun 2010 17:43:19 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o52HhFYf010483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 02 Jun 2010 13:43:15 -0400 (EDT) Date: Wed, 02 Jun 2010 13:43:15 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <4C0695EB.40503@workingcode.com> To: Dave Miner Cc: Mark Haywood , PSARC-ext@sun.com, Ethan Quach Message-id: <4C069833.3080108@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-sonic.net-Metrics: carlson; whitelist X-Antispam: No, score=-0.2/5.0, scanned in 0.064sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1104 James Carlson wrote: > That's the part that still confuses me. I'd expected that, just as > installation was "based on" NWAM in OpenSolaris, this would be the > pattern for the future as well. And, now, I understand Mark's last reply, where he said: I and the folks working on install don't believe that NWAM is yet functionally complete enough to be the default service for our Enterprise customers. And therefore, we chose to provide install with a mechanism for configuring an initial physical:default configuration. OK; that's the missing bit. It *is* intentionally physical:default, not just for install, but also (potentially) for the running system. The original proposal provided that hint in the XML-encoded profile, but never came out and said it directly. It was a long drive to figure out that this was intentional and not a "bug." Could something to the effect of "for AI, and for the time being, we're expecting to disable NWAM and use physical:default on the installed system" be added to the spec? -- James Carlson 42.703N 71.076W From mark.haywood@oracle.com Wed Jun 2 12:01:52 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o52J1qfc014870 for ; Wed, 2 Jun 2010 12:01:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o52J1lxl006522 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 12:01:52 -0700 (PDT) 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 <0L3E0071FI6YNQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 12:01:46 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E007P8I6X00E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 12:01:45 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o52J1jPU008037 for ; Wed, 02 Jun 2010 19:01:45 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o52J1epQ019841; Wed, 02 Jun 2010 19:01:40 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 317069871275505236; Wed, 02 Jun 2010 12:00:36 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jun 2010 12:00:36 -0700 Date: Wed, 02 Jun 2010 15:01:57 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <4C069833.3080108@workingcode.com> To: James Carlson Cc: Dave Miner , PSARC-ext@sun.com, Ethan Quach Message-id: <4C06AAA5.6030400@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C06AA95.016B:SCFMA4539814,ss=1,fgs=0 References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 1835 On 06/ 2/10 01:43 PM, James Carlson wrote: > James Carlson wrote: > >> That's the part that still confuses me. I'd expected that, just as >> installation was "based on" NWAM in OpenSolaris, this would be the >> pattern for the future as well. >> > And, now, I understand Mark's last reply, where he said: > > I and the folks working on install don't believe that NWAM is yet > functionally complete enough to be the default service for our > Enterprise customers. And therefore, we chose to provide install with a > mechanism for configuring an initial physical:default configuration. > > OK; that's the missing bit. It *is* intentionally physical:default, not > just for install, but also (potentially) for the running system. The > original proposal provided that hint in the XML-encoded profile, but > never came out and said it directly. > > It was a long drive to figure out that this was intentional and not a > "bug." Could something to the effect of "for AI, and for the time > being, we're expecting to disable NWAM and use physical:default on the > installed system" be added to the spec? > It is intentional that the interfaces provided by this case will only have significance for physical:default. And I think that it is also correct to say that for AI, more often than not, we expect NWAM to be disabled. However, an administrator can do whatever she likes in an SMF profile. If she wishes to enable NWAM *and* define the static configuration, then we can't prevent that. We can, however, display a message that indicates that she just did something that was probably nonsensical. We can also document the network/install service to make it clear that the properties are used to configure static configurations for physical:default only. The spec can be updated to make this clear. From dave.miner@oracle.com Wed Jun 2 12:58:27 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o52JwRIM016376 for ; Wed, 2 Jun 2010 12:58:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o52JwRo7029187 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 12:58:27 -0700 (PDT) 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 <0L3E00A0BKTFK200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 13:58:27 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E001GKKTFSH40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 13:58:27 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o52JwRRh009080 for ; Wed, 02 Jun 2010 19:58:27 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o52JYml2014926; Wed, 02 Jun 2010 19:58:19 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 291404321275508636; Wed, 02 Jun 2010 12:57:16 -0700 Received: from krissy.2greys.com (/129.150.80.69) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jun 2010 12:57:15 -0700 Date: Wed, 02 Jun 2010 15:57:14 -0400 From: Dave Miner Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <4C0695EB.40503@workingcode.com> To: James Carlson Cc: PSARC-ext@sun.com, Mark Haywood , Ethan Quach Message-id: <4C06B79A.2090601@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C06B7DD.0192:SCFMA4539814,ss=1,fgs=0 References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre6 Thunderbird/3.0.4 Status: RO Content-Length: 2978 I see that you maybe answered your primary question yourself, but to hopefully provide more clarity on a couple of points: On 06/ 2/10 01:33 PM, James Carlson wrote: > Dave Miner wrote: >> First, I hope that the use of SMF profiles as a replacement for the >> sysidcfg(4) mechanism is neither surprising nor controversial, as it's >> been the plan of record since the inception of the new installer four >> years ago and is something I've talked about in every presentation on >> the program. Indeed, it's a significant driver for enhancements >> delivered by PSARC/2009/371 and PSARC/2010/157, and conversion of >> existing miscellaneous configuration data to SMF is the subject of other >> existing (PSARC/2010/183) and forthcoming cases. > > That's certainly not surprising to me. > >> The interfaces provided by this case will be leveraged in the >> installation architecture in two ways. First, we require a way to >> transfer configuration information gathered by the interactive >> installers (GUI and Text) to the installed system. Second, we require a >> way for administrators to express the desired configuration of the >> installed system to an Automated Install (AI). Install will be using >> this case's interfaces to satisfy both of those requirements. >> Interactive installers will generate SMF profiles that are applied at >> first boot, while AI users will, at least for now pending any future >> work on AI tooling, supply SMF profiles directly. > > The remaining doubt I have about the project revolves around the > network/physical instances. > > Currently, when OpenSolaris is installed from a CD, unlike legacy > Solaris, it enables NWAM by default. Given the way this project is > translating SMF properties into /etc/* information, though, it seems > that install profiles based on this project might be required to disable > physical:nwam and enable physical:default instead. Otherwise, NWAM will > just walk all over the configuration bits. (That might be what someone > wants, but then that same someone likely wouldn't want any of the unused > static configuration bits from this project.) > > Is that a reasonable understanding? That installing OpenSolaris from > fixed media will result in NWAM being enabled, but that automated > installs will result in NWAM (at least usually) being disabled? > I wouldn't use "fixed media" as the dividing principle here, because that's not how I expect it'll be long term, even if it sort of works that way right now. Yes, we expect that in many, if not most, cases, the users of Automated Install will choose non-NWAM configurations for the installed system, at least in NWAM's current form. Interactive installers may or may not offer a choice between the two; we'll be explicit about the behavior of each interactive installer in its case. The GUI is currently explicit about only supporting NWAM. The text installer case (2010/165) is coming for review in a couple of weeks. Dave From garrett@damore.org Wed Jun 2 16:02:25 2010 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 o52N2Ob8022277 for ; Wed, 2 Jun 2010 16:02:24 -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.4) with ESMTP id o52N2NJY021934 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 17:02:23 -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 <0L3E0020HTBZ3X00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 16:02:23 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E008JNTBYUY40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 16:02:22 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o52N0BwJ026622 for ; Wed, 02 Jun 2010 23:02:22 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-24492 for PSARC-ext@sun.com; Wed, 02 Jun 2010 23:02:21 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-187534454 for PSARC-ext@sun.com; Wed, 02 Jun 2010 23:02:20 +0000 (Z) Received: from oproxy3-pub.bluehost.com ([69.89.21.8] [69.89.21.8]) by relay4i.sun.com id BT-MMP-1110949 for PSARC-ext@sun.com; Wed, 02 Jun 2010 23:02:20 +0000 (Z) Received: (qmail 28729 invoked by uid 0); Wed, 02 Jun 2010 23:02:20 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy3.bluehost.com with SMTP; Wed, 02 Jun 2010 23:02:20 +0000 Received: from [216.129.112.21] (helo=[10.1.1.200]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OJwx1-0003YF-Nj; Wed, 02 Jun 2010 17:02:19 -0600 Date: Wed, 02 Jun 2010 14:01:51 -0700 From: "Garrett D'Amore" Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <4C06AAA5.6030400@oracle.com> To: Mark Haywood Cc: James Carlson , PSARC-ext@sun.com, Dave Miner , Ethan Quach Message-id: <1275512511.21541.11.camel@velocity> MIME-version: 1.0 X-Mailer: Evolution 2.28.3 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=HLxblbcH0fuD23zF0o1dDZoG/CfJiuf3ReZ1xF33v32laoDRWwBZ4XvODISatktMC+j3lca4q8+UNPzbfyOeV3qWxJLurV9CFdU1EC0jiM7CEaxlt6hatnHE71+lZJv+; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 216.129.112.21 authed with garrett+damore.org} X-Antispam: No, score=-0.7/5.0, scanned in 0.087sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> <4C06AAA5.6030400@oracle.com> Status: RO Content-Length: 2744 On Wed, 2010-06-02 at 15:01 -0400, Mark Haywood wrote: > On 06/ 2/10 01:43 PM, James Carlson wrote: > > James Carlson wrote: > > > >> That's the part that still confuses me. I'd expected that, just as > >> installation was "based on" NWAM in OpenSolaris, this would be the > >> pattern for the future as well. > >> > > And, now, I understand Mark's last reply, where he said: > > > > I and the folks working on install don't believe that NWAM is yet > > functionally complete enough to be the default service for our > > Enterprise customers. And therefore, we chose to provide install with a > > mechanism for configuring an initial physical:default configuration. > > > > OK; that's the missing bit. It *is* intentionally physical:default, not > > just for install, but also (potentially) for the running system. The > > original proposal provided that hint in the XML-encoded profile, but > > never came out and said it directly. > > > > It was a long drive to figure out that this was intentional and not a > > "bug." Could something to the effect of "for AI, and for the time > > being, we're expecting to disable NWAM and use physical:default on the > > installed system" be added to the spec? > > > > It is intentional that the interfaces provided by this case will only > have significance for physical:default. And I think that it is also > correct to say that for AI, more often than not, we expect NWAM to be > disabled. However, an administrator can do whatever she likes in an SMF > profile. If she wishes to enable NWAM *and* define the static > configuration, then we can't prevent that. We can, however, display a > message that indicates that she just did something that was probably > nonsensical. We can also document the network/install service to make it > clear that the properties are used to configure static configurations > for physical:default only. I think the idea that NWAM is typically *not* enabled by default with AI is unfortunate. Many sites may choose to deploy AI in environments where the network infrastructure (dhcp) provides correct and reasonable configuration even for systems that have more or less "fixed" IP configuration. As such, NWAM offers an easier configuration for end-users. I view network/physical:default as an unfortunate artifact, representing a deficiency in nwam, that I had hoped would one day be corrected. Having two totally different and totally incompatible network configuration schemes is a recipe for much end-user confusion and many service calls. - Garrett > > The spec can be updated to make this clear. > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From bart.smaalders@oracle.com Wed Jun 2 16:31:28 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o52NVS13023371 for ; Wed, 2 Jun 2010 16:31:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o52NVSJL025075 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 16:31:28 -0700 (PDT) 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 <0L3E00601UOGFJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 17:31:28 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E001XXUOFSQC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 17:31:27 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o52NVQXf690204; Wed, 02 Jun 2010 16:31:26 -0700 (PDT) Date: Wed, 02 Jun 2010 16:29:17 -0700 From: Bart Smaalders Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <1275512511.21541.11.camel@velocity> To: "Garrett D'Amore" Cc: Mark Haywood , James Carlson , PSARC-ext@sun.com, Dave Miner , Ethan Quach Message-id: <4C06E94D.4090605@oracle.com> Organization: Oracle MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> <4C06AAA5.6030400@oracle.com> <1275512511.21541.11.camel@velocity> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 530 On 06/02/10 14:01, Garrett D'Amore wrote: > I view network/physical:default as an unfortunate artifact, representing > a deficiency in nwam, that I had hoped would one day be corrected. > > Having two totally different and totally incompatible network > configuration schemes is a recipe for much end-user confusion and many > service calls. Hear hear! - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaalders@oracle.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From mark.haywood@Oracle.COM Wed Jun 2 17:20:46 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o530Kklm024521 for ; Wed, 2 Jun 2010 17:20:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o530KkGG009780 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 19:20:46 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3E00707WYLJ200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 17:20:45 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E003IOWYK8Z60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 17:20:44 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o530KiDq017689 for ; Thu, 03 Jun 2010 00:20:44 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o53088fF017751; Thu, 03 Jun 2010 00:20:40 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt354.oracle.com with ESMTP id 292006561275524439; Wed, 02 Jun 2010 17:20:39 -0700 Received: from [129.148.19.14] (/129.148.19.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jun 2010 17:20:39 -0700 Date: Wed, 02 Jun 2010 20:20:38 -0400 From: Mark Haywood Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <1275512511.21541.11.camel@velocity> To: "Garrett D'Amore" Cc: James Carlson , PSARC-ext@sun.com, Dave Miner , Ethan Quach Message-id: <4C06F556.4050409@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C06F559.016C:SCFMA4539814,ss=1,fgs=0 References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> <4C06AAA5.6030400@oracle.com> <1275512511.21541.11.camel@velocity> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 3415 Garrett D'Amore wrote: > On Wed, 2010-06-02 at 15:01 -0400, Mark Haywood wrote: > >> On 06/ 2/10 01:43 PM, James Carlson wrote: >> >>> James Carlson wrote: >>> >>> >>>> That's the part that still confuses me. I'd expected that, just as >>>> installation was "based on" NWAM in OpenSolaris, this would be the >>>> pattern for the future as well. >>>> >>>> >>> And, now, I understand Mark's last reply, where he said: >>> >>> I and the folks working on install don't believe that NWAM is yet >>> functionally complete enough to be the default service for our >>> Enterprise customers. And therefore, we chose to provide install with a >>> mechanism for configuring an initial physical:default configuration. >>> >>> OK; that's the missing bit. It *is* intentionally physical:default, not >>> just for install, but also (potentially) for the running system. The >>> original proposal provided that hint in the XML-encoded profile, but >>> never came out and said it directly. >>> >>> It was a long drive to figure out that this was intentional and not a >>> "bug." Could something to the effect of "for AI, and for the time >>> being, we're expecting to disable NWAM and use physical:default on the >>> installed system" be added to the spec? >>> >>> >> It is intentional that the interfaces provided by this case will only >> have significance for physical:default. And I think that it is also >> correct to say that for AI, more often than not, we expect NWAM to be >> disabled. However, an administrator can do whatever she likes in an SMF >> profile. If she wishes to enable NWAM *and* define the static >> configuration, then we can't prevent that. We can, however, display a >> message that indicates that she just did something that was probably >> nonsensical. We can also document the network/install service to make it >> clear that the properties are used to configure static configurations >> for physical:default only. >> > > I think the idea that NWAM is typically *not* enabled by default with AI > is unfortunate. Many sites may choose to deploy AI in environments > where the network infrastructure (dhcp) provides correct and reasonable > configuration even for systems that have more or less "fixed" IP > configuration. As such, NWAM offers an easier configuration for > end-users. > NWAM isn't a requirement for using DHCP to gather configuration information. This proposal supports DHCP as a source for network configuration via the network/physical:default service. > I view network/physical:default as an unfortunate artifact, representing > a deficiency in nwam, that I had hoped would one day be corrected. > > Having two totally different and totally incompatible network > configuration schemes is a recipe for much end-user confusion and many > service calls. > And from one of my earlier responses on this thread: "Does this mean that we (Solaris Networking) aren't working on doing away with the separation between physical:default and physical:nwam? No. That work is being planned. When completed, I believe that the interfaces proposed by this case will be changed appropriately. " Mark > - Garrett > > >> The spec can be updated to make this clear. >> >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> > > > From garrett@damore.org Wed Jun 2 18:38:19 2010 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 o531cJ5b025518 for ; Wed, 2 Jun 2010 18:38:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o531cID5028521 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 18:38:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3F00B030JUWC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Jun 2010 18:38:18 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3F003B90JU94B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Jun 2010 18:38:18 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o531WFfh009252 for ; Thu, 03 Jun 2010 01:38:17 +0000 (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-295510 for PSARC-ext@Sun.COM; Thu, 03 Jun 2010 01:38:17 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-188100766 for PSARC-ext@Sun.COM; Thu, 03 Jun 2010 01:38:17 +0000 (Z) Received: from oproxy3-pub.bluehost.com ([69.89.21.8] [69.89.21.8]) by relay4i.sun.com id BT-MMP-6169659 for PSARC-ext@Sun.COM; Thu, 03 Jun 2010 01:38:16 +0000 (Z) Received: (qmail 6857 invoked by uid 0); Thu, 03 Jun 2010 01:38:16 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy3.bluehost.com with SMTP; Thu, 03 Jun 2010 01:38:15 +0000 Received: from [216.129.112.21] (helo=[10.1.1.200]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OJzNu-0004PO-Hh; Wed, 02 Jun 2010 19:38:15 -0600 Date: Wed, 02 Jun 2010 18:38:13 -0700 From: "Garrett D'Amore" Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <4C06F556.4050409@oracle.com> To: Mark Haywood Cc: James Carlson , PSARC-ext@sun.com, Dave Miner , Ethan Quach Message-id: <1275529093.21541.159.camel@velocity> MIME-version: 1.0 X-Mailer: Evolution 2.28.3 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=DAKd7+NckTPLCEG/k5tyR3xL8KGyVLos17+1b+cWWWZMqmG4+7U1ycWhYaEDh9x31sTHrHjkhj3QUt9kDP/SY/qUtbl6eRwIqJTnMF7N0RAwNygxtEgbb54ldjDOb0CB; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 216.129.112.21 authed with garrett+damore.org} X-Antispam: No, score=-2.6/5.0, scanned in 0.267sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> <4C06AAA5.6030400@oracle.com> <1275512511.21541.11.camel@velocity> <4C06F556.4050409@oracle.com> Status: RO Content-Length: 3704 On Wed, 2010-06-02 at 20:20 -0400, Mark Haywood wrote: > Garrett D'Amore wrote: > > On Wed, 2010-06-02 at 15:01 -0400, Mark Haywood wrote: > > > >> On 06/ 2/10 01:43 PM, James Carlson wrote: > >> > >>> James Carlson wrote: > >>> > >>> > >>>> That's the part that still confuses me. I'd expected that, just as > >>>> installation was "based on" NWAM in OpenSolaris, this would be the > >>>> pattern for the future as well. > >>>> > >>>> > >>> And, now, I understand Mark's last reply, where he said: > >>> > >>> I and the folks working on install don't believe that NWAM is yet > >>> functionally complete enough to be the default service for our > >>> Enterprise customers. And therefore, we chose to provide install with a > >>> mechanism for configuring an initial physical:default configuration. > >>> > >>> OK; that's the missing bit. It *is* intentionally physical:default, not > >>> just for install, but also (potentially) for the running system. The > >>> original proposal provided that hint in the XML-encoded profile, but > >>> never came out and said it directly. > >>> > >>> It was a long drive to figure out that this was intentional and not a > >>> "bug." Could something to the effect of "for AI, and for the time > >>> being, we're expecting to disable NWAM and use physical:default on the > >>> installed system" be added to the spec? > >>> > >>> > >> It is intentional that the interfaces provided by this case will only > >> have significance for physical:default. And I think that it is also > >> correct to say that for AI, more often than not, we expect NWAM to be > >> disabled. However, an administrator can do whatever she likes in an SMF > >> profile. If she wishes to enable NWAM *and* define the static > >> configuration, then we can't prevent that. We can, however, display a > >> message that indicates that she just did something that was probably > >> nonsensical. We can also document the network/install service to make it > >> clear that the properties are used to configure static configurations > >> for physical:default only. > >> > > > > I think the idea that NWAM is typically *not* enabled by default with AI > > is unfortunate. Many sites may choose to deploy AI in environments > > where the network infrastructure (dhcp) provides correct and reasonable > > configuration even for systems that have more or less "fixed" IP > > configuration. As such, NWAM offers an easier configuration for > > end-users. > > > > > NWAM isn't a requirement for using DHCP to gather configuration > information. This proposal supports DHCP as a source for network > configuration via the network/physical:default service. > > > > I view network/physical:default as an unfortunate artifact, representing > > a deficiency in nwam, that I had hoped would one day be corrected. > > > > Having two totally different and totally incompatible network > > configuration schemes is a recipe for much end-user confusion and many > > service calls. > > > > > And from one of my earlier responses on this thread: > > "Does this mean that we (Solaris Networking) aren't working on doing > away with the separation between physical:default and physical:nwam? No. > That work is being planned. When completed, I believe that the > interfaces proposed by this case will be changed appropriately. " Ok, sorry for not reading the entire thread.... As long as we all agree that this situation is basically a "bug" that will be rectified by future work to eliminate physical:default, I'm ok with it. However, I've not read enough of the case to feel comfortable giving it a +1 at this time. - Garrett From sebastien.roy@oracle.com Fri Jun 4 06:46:45 2010 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 o54Dkj0p015344 for ; Fri, 4 Jun 2010 06:46:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o54DkhW9012427 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 4 Jun 2010 07:46:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3H0072RSXVNZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Jun 2010 06:46:43 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3H00247SXU4B70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Jun 2010 06:46:42 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o54DkgL7010038 for ; Fri, 04 Jun 2010 13:46:42 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o54CmjcN021892; Fri, 04 Jun 2010 13:46:37 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 297210941275659092; Fri, 04 Jun 2010 06:44:52 -0700 Received: from [192.168.1.4] (/173.76.19.159) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Jun 2010 06:44:51 -0700 Date: Fri, 04 Jun 2010 09:44:48 -0400 From: Sebastien Roy Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010] In-reply-to: <4C069833.3080108@workingcode.com> To: James Carlson Cc: Dave Miner , Mark Haywood , PSARC-ext@sun.com, Ethan Quach Message-id: <4C090350.8050907@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C0903BE.00D6:SCFMA4539814,ss=1,fgs=0 References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1553 On 06/ 2/10 01:43 PM, James Carlson wrote: > James Carlson wrote: >> That's the part that still confuses me. I'd expected that, just as >> installation was "based on" NWAM in OpenSolaris, this would be the >> pattern for the future as well. > > And, now, I understand Mark's last reply, where he said: > > I and the folks working on install don't believe that NWAM is yet > functionally complete enough to be the default service for our > Enterprise customers. And therefore, we chose to provide install with a > mechanism for configuring an initial physical:default configuration. > > OK; that's the missing bit. It *is* intentionally physical:default, not > just for install, but also (potentially) for the running system. The > original proposal provided that hint in the XML-encoded profile, but > never came out and said it directly. > > It was a long drive to figure out that this was intentional and not a > "bug." Could something to the effect of "for AI, and for the time > being, we're expecting to disable NWAM and use physical:default on the > installed system" be added to the spec? Yes, I think it would be informative to add this to the spec in order to better understand how these interfaces will be effectively used, along with a note that the upcoming cases that define the specific installers' architectures will be the authoritative reference for how users will directly or indirectly interact with this functionality in the context of solaris install. I'll send a note once we have an updated spec. Thanks, -Seb From sebastien.roy@oracle.com Mon Jun 7 07:14:55 2010 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 o57EEsUV016333 for ; Mon, 7 Jun 2010 07:14:55 -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.4) with ESMTP id o57EErEd051792; Mon, 7 Jun 2010 08:14:53 -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 <0L3N0090PE8TP100@nwk-avmta-1.sfbay.Sun.COM>; Mon, 07 Jun 2010 07:14:53 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3N004D0E8RD2B0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 07 Jun 2010 07:14:51 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o57EEpdV013457; Mon, 07 Jun 2010 14:14:51 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5710UU3024353; Mon, 07 Jun 2010 14:14:40 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 326883491275919978; Mon, 07 Jun 2010 07:12:58 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Jun 2010 07:12:57 -0700 Date: Mon, 07 Jun 2010 10:12:56 -0400 From: Sebastien Roy Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 06/14/2010] In-reply-to: <4C090350.8050907@oracle.com> To: James Carlson Cc: Mark Haywood , PSARC-ext@sun.com, Dave Miner , Ethan Quach , jan.damborsky@sun.com Message-id: <4C0CFE68.4040500@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C0CFED4.0153:SCFMA4539814,ss=1,fgs=0 References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> <4C090350.8050907@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 327 On 06/ 4/10 09:44 AM, Sebastien Roy wrote: > I'll send a note once we have an updated spec. > An updated spec (with '+' change marks in the left column) has been placed in the materials directory. Note that the materials update constitutes clarifications and not a change in the architecture as originally proposed. -Seb From carlsonj@workingcode.com Mon Jun 7 07:23:16 2010 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 o57ENG5T016543 for ; Mon, 7 Jun 2010 07:23:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o57ENEIt016613; Mon, 7 Jun 2010 07:23:14 -0700 (PDT) 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 <0L3N0020BEMQ6900@brm-avmta-1.central.sun.com>; Mon, 07 Jun 2010 08:23:14 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3N00M9NEMPBIE0@brm-avmta-1.central.sun.com>; Mon, 07 Jun 2010 08:23:13 -0600 (MDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o57EE5uj016807; Mon, 07 Jun 2010 14:23:13 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-3216357; Mon, 07 Jun 2010 14:23:12 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-659065; Mon, 07 Jun 2010 14:23:12 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-35440558; Mon, 07 Jun 2010 14:23:12 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o57EN1iG009972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 07 Jun 2010 10:23:01 -0400 (EDT) Date: Mon, 07 Jun 2010 10:23:01 -0400 From: James Carlson Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 06/14/2010] In-reply-to: <4C0CFE68.4040500@oracle.com> To: Sebastien Roy Cc: Mark Haywood , PSARC-ext@sun.com, Dave Miner , Ethan Quach , jan.damborsky@sun.com Message-id: <4C0D00C5.4080900@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.213sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> <4C090350.8050907@oracle.com> <4C0CFE68.4040500@oracle.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 596 Sebastien Roy wrote: > On 06/ 4/10 09:44 AM, Sebastien Roy wrote: >> I'll send a note once we have an updated spec. >> > > An updated spec (with '+' change marks in the left column) has been > placed in the materials directory. Note that the materials update > constitutes clarifications and not a change in the architecture as > originally proposed. It looks quite a bit clearer, though I do wonder now about the rationale for making these interfaces Committed given the exceptions carved out for future projects. -- James Carlson 42.703N 71.076W From sebastien.roy@oracle.com Mon Jun 7 07:35:55 2010 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 o57EZt83016895 for ; Mon, 7 Jun 2010 07:35:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o57EZrPe064620; Mon, 7 Jun 2010 08:35:53 -0600 (MDT) 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 <0L3N00301F7T8K00@brm-avmta-1.central.sun.com>; Mon, 07 Jun 2010 08:35:53 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3N00MCUF7TBAF0@brm-avmta-1.central.sun.com>; Mon, 07 Jun 2010 08:35:53 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o57EZqTp025519; Mon, 07 Jun 2010 14:35:52 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5732RXt022353; Mon, 07 Jun 2010 14:35:38 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 326941651275921316; Mon, 07 Jun 2010 07:35:16 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Jun 2010 07:35:10 -0700 Date: Mon, 07 Jun 2010 10:35:08 -0400 From: Sebastien Roy Subject: Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 06/14/2010] In-reply-to: <4C0D00C5.4080900@workingcode.com> To: James Carlson Cc: Mark Haywood , PSARC-ext@sun.com, Dave Miner , Ethan Quach , jan.damborsky@sun.com Message-id: <4C0D039C.2010904@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C0D03BB.002C:SCFMA4539814,ss=1,fgs=0 References: <4BFC0C00.6010300@oracle.com> <4BFC1856.7030905@oracle.com> <4BFC277E.6050401@oracle.com> <4C066B34.1080604@oracle.com> <4C0695EB.40503@workingcode.com> <4C069833.3080108@workingcode.com> <4C090350.8050907@oracle.com> <4C0CFE68.4040500@oracle.com> <4C0D00C5.4080900@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1348 On 06/ 7/10 10:23 AM, James Carlson wrote: > Sebastien Roy wrote: >> On 06/ 4/10 09:44 AM, Sebastien Roy wrote: >>> I'll send a note once we have an updated spec. >>> >> >> An updated spec (with '+' change marks in the left column) has been >> placed in the materials directory. Note that the materials update >> constitutes clarifications and not a change in the architecture as >> originally proposed. > > It looks quite a bit clearer, though I do wonder now about the rationale > for making these interfaces Committed given the exceptions carved out > for future projects. It's a good question, and Mark and I hmm'ed and haa'ed about this a bit prior to submission. As you know, the long term expectation is that parts of this configuration can be supplied using a profile that applies directly to a networking service, and not an intermediary install-specific service. The idea would then be that the installer software (and customers who write profiles directly) would transition away from supplying properties to this install service. At the same time, being that this is currently the only proposed way for administrators to supply such networking configuration, the service and its properties have to be Public and relatively stable. Perhaps Uncommitted would more accurately reflect the project team's intentions.(?) -Seb From sebastien.roy@oracle.com Tue Jun 22 12:43:42 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5MJhgwE003894 for ; Tue, 22 Jun 2010 12:43:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5MJhgb8015908 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Jun 2010 12:43:42 -0700 (PDT) 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 <0L4F00005LGUTK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Jun 2010 13:43:42 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4F00JHLLGTJ830@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Jun 2010 13:43:41 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5MJhefN006787 for ; Tue, 22 Jun 2010 19:43:40 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5MH0K0B006886 for ; Tue, 22 Jun 2010 19:43:38 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 348010551277235782; Tue, 22 Jun 2010 12:43:02 -0700 Received: from [129.148.19.4] (/129.148.19.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jun 2010 12:43:02 -0700 Date: Tue, 22 Jun 2010 15:43:00 -0400 From: Sebastien Roy Subject: Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010] In-reply-to: <4BEAD0D2.7020705@oracle.com> To: PSARC-ext Message-id: <4C211244.5090509@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C21126C.00C5:SCFMA4539814,ss=1,fgs=0 References: <4BEAD0D2.7020705@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100524 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 426 On 05/12/10 12:01 PM, Sebastien Roy wrote: > I'm submitting this fast-track for Mark Haywood. The release binding > is Minor. Note that this case has a dependency on PSARC 2010/157. This case was approved at last week's PSARC meeting. Note that the install-specific SMF services and their properties are Uncommitted (spec.txt in the materials directory has been updated), and not Committed as originally proposed. -Seb