On Wed, 2006-10-11 at 17:06 -0700, Zhenghui Xie wrote:
> Below is the service list in the default standalone ULP. User can customize
> this list in the default standalone ULP so that they can choose to
> enable/disable services as needed.
> 
> service name                    state in default standalone profile
> -------------------------------------------------------------------
> milestone/single-user:default enabled
> system/identity:node            enabled but revisited* after online.
> system/identity:domain                enabled but revisited* after name 
> service
> * revisited means "refreshed if it changes"
> 
> network/ssh:default             enabled
> network/smtp:sendmail           enabled
> network/inetd:default           enabled
> 
> network/iscsi_initiator:default       disabled
> network/rarp:default            disabled
> network/slp:default                   disabled
> network/shell:kshell                  disabled
> network/shell:default                 disabled
> 
> network/iptunneling           disabled[2]

We're in the process of re-defining what this is in the context of
Clearview, and I don't believe that this default will have meaning after
we're done.  It may be that we simply don't have such a service at all,
as the configuration of tunnel interfaces will be done by whatever
service configures all other interfaces.  It would probably be less
confusing to remove it from your list for now.

> 4. proposal for hostname.<if> interfaces:
> NWAM will try to obsolete hostname.<if> interfaces. Given that these 
> interfaces
> are very well-known and generally used by our customers as write-to, instead 
> of
> read-from, interfaces, we need to support them for backwards compatibility.
> 
> A proposal for these interfaces is that when NWAM starts, it will look at the
> existence of these files and translate the information in them to the SMF
> repository.
> * If no Link-Layer information exists for a given link, NWAM will create a new
>   property group for the link in question, and include information from the
>   hostname.<if> file.

I'm not sure I understand what this entails, but I suppose it doesn't
much matter if the details are still TBD.

> 
> * If a corresponding Link-Layer information exists already, NWAM will check 
> the
>   information and decide if there is a conflict.  If not, nothing needs to be
>   done.  When there is a conflict, which one to honor is an open question, but
>   we have a bias towards simply honoring whatever is in the SMF repository.
> 
> During the lifetime of the NWAM daemon, it does not check for any changes to
> these files: they are only read when the service starts.  At fresh install,
> NWAM will automatically detect the existence of NIC cards and apply some
> default properties on them.

What kinds of properties?  Only after a fresh install?  What happens if
I insert a new card and type "devfsadm" or just reboot?

> 5. Proposal for hostname:
> Currently if the user wants to change the hostname of the system, s/he has to
> either sys-unconfig then configure the system, or update a bunch of files then
> reboot the machine. NWAM can introduce an interface for setting the hostname. 
> A
> proposal to achieve this is:
> * Use system/identity:node to keep track of system's hostname.
> * When the user changes the hostname through the NWAM UI, NWAM will need to
>   update the node name in the kernel, update /etc/nodename and 
> /etc/inet/hosts,
>   and refresh system/identity:node.

What will be changed in /etc/inet/hosts?  Will the nodename always map
to 127.0.0.1, or will there be some logic to determine what (if any) IP
address is associated with the new nodename?

> * All services that use hostname as a rendezvous point, such as autofs and
>   keyserv, should either be reworked to use "localhost" rather than the 
> current
>   hostname.  Or they should build a "restart_on=refresh" dependency with 
>   system/identity:node.  N.B.: the list of such services needs further
>   investigation and may involve discussions with other teams.

Unfortunately, it's more than just SMF services.  Specific Gnome
processes not managed by SMF have weird dependencies on the local
nodename too.  There are probably 3rd party applications that do as
well.  For me, always having the nodename map to 127.0.0.1 (in addition
to whatever other IP addresses I have configured locally, if any) seems
to make most of these applications happy.  I'm not sure if this
generally a good idea, but it works for at least one person's
systems. :-)

-Seb



Reply via email to