On Wed, May 12, 2010 at 5:01 PM, Sebastien Roy <[email protected]> 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 > <addrobj> 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 > <seconds> | 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: > > <?xml version='1.0'?> > <!DOCTYPE service_bundle SYSTEM > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> > <service_bundle type='profile' name='default'> > <service name='network/physical' version='1' type='service'> > <instance name='nwam' enabled='false'/> > </service> Something seems incomplete here. If nwam is enabled, then is the static configuration used or ignored? > <service name='network/install' version='1' type='service'> > <instance name='default' enabled='true'/> > <property_group name='install_ipv4_interface' type='application'> > <propval name='name' type='astring' value='bge0/v4' /> > <propval name='address_type' type='astring' value='static' /> > <propval name='static_address' type='net_address_v4' > 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? > <propval name='default_route' type='net_address_v4' > value='10.4.235.1' /> > </property_group> > <property_group name='install_ipv6_interface' type='application'> > <propval name='name' type='astring' value='bge0/v6' /> > <propval name='address_type' type='astring' value='addrconf' /> > 9 > <propval name='static_address' type='net_address_v6' > value='::0/0' /> > <propval name='interface_id' type='net_address_v6' > value='::abcd/64' /> > <propval name='stateless' type='astring' value='no' /> > <propval name='stateful' type='astring' value='no'/> > <propval name='default_route' type='net_address_v6' > value='::0' /> > </property_group> > </service> > <service name='network/dns/install' version='1' type='service'> > <instance name='default' enabled='true'/> > <property_group name='install_props' type='application'> > <property name='nameserver' type='net_address'> > <net_address_list> > <value_node value='129.145.155.220' /> > <value_node value='129.145.154.118' /> > <value_node value='129.147.9.5' /> > <value_node value='129.147.4.5' /> > </net_address_list> > </property> > <propval name='domain' type='astring' value='sfbay.sun.com' /> > <property name='search' type='astring'> > <astring_list> > <value_node value='sfbay.sun.com' /> > <value_node value='east.sun.com' /> > </astring_list> > </property> > </property_group> > </service> > </service_bundle> 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/ _______________________________________________ opensolaris-arc mailing list [email protected]
