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*.<intf> 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
_______________________________________________
opensolaris-arc mailing list
[email protected]
