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