On 05/12/10 02:32 PM, Peter Tribble wrote:
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?
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
<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?
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
<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.)
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:
<?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?
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.
<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?
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.
<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?
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.
_______________________________________________
opensolaris-arc mailing list
[email protected]
