Quoth Zhenghui Xie on Wed, Sep 20, 2006 at 04:08:13PM -0700: > I. Brief description: > NWAM will deliver a default standalone Upper Layer Profile (ULP) and several > network ULPs. > > The standalone profile will contain configuration that should apply to the > system when it is standalone, that is, no network is attached. The system > will boot up with the standalone profile, and information it contains will > be applied after the NWAM daemon plumbs and configures the loopback network > interfaces. NWAM will keep detecting outside networks and trying to connect > to networks based on certain policies. (Details about policies will be > discussed in a seperate thread)
There may not be a compelling reason for this, but it seems possible that someone will want his service to run only when no network is available, but only start once NWAM has determined that. I think we could support that by separating a boot profile from the standalone profile. The boot profile would always be active at boot, and would presumably only enable enough services to bring NWAM up, and then NWAM would look for networks, and if it didn't find any, it would switch to the standalone profile. It's probably not worth setting the system up by default this way, but it seems that this setup should work if the administrator desires it. > II. Current services to obsolete: > Given the above model, we do not need to keep network/loopback, > network/physical or network/service post-NWAM, because the transient tasks > these services do will be done by the NWAM daemon. And perhaps more importantly, network profiles are a more appropriate start-after-network-is-available mechanism than SMF dependencies. ... > milestone/network is not needed and will be replaced by network/profiled as > well. I don't think you should say "replaced" here, we don't want services to just change their dependency on milestone/network to network/profiled. Just say that profiled will be added, and milestone/network will be removed because the function it was performing will be replaced by network profiles. > III. Dependencies: > A lot of services currently depend on the services which the NWAM daemon > will replace. These dependencies will be deleted and NWAM will use profiles > to manage when to bring them online: > > The default standalone profile will disable network related services, even > though some of them can work correctly without outside network connection. > Users can have their customized standalone profile and specify their > preference of enabling certain network service(s) at standalone. > > Below is the table of services that have dependencies on these obsoleted > services: > > service name state in standalone profile > ------------------------------------------------------------------- > milestone/single-user:default enable > > system/identity:node enable, but revisited after online. > system/identity:domain enable, but revisited after > name service By 'revisited', you mean 'refreshed', right? Or do you mean "refreshed if it changes"? > network/ipfilter:default disable > network/iscsi_initiator:default disable > network/ssh:default enable Why should ssh be enabled when there is no network? I think in the vast majority of cases, without a network, it will be a waste of resources. Of course, if someone wants to run sshd without network connectivity, then he can customize the standalone profile. ... > IV. 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. I think we should support upgrade from them, but not support them directly, after NWAM integrates. > 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 Profile (LLP) exists for a given link, NWAM will create > a new LLP for the link in question, and include information from the > hostname.<if> file. > * If a corresponding LLP 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. I think you should treat the repository as authoritative, and if you find that a file has been changed, you should notify the user that the interface is obsolete, and the new interfaces must be used. I believe that's what inetd does if you change inetd.conf. ... > V. host names: > 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. A proposal to fix this is: > 1. Use system/identity:node to keep track of system's hostname. > 2. When the user changes the hostname through the NWAM UI, NWAM will need > to update the node name in the kernel, then update /etc/nodename and > /etc/inet/hosts. > 3. Refresh system/identity:node > 4. All services that use hostname as a rendezvous point, such as autofs and > keyserv, they 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. Would it be too far-fetched to introduce an interface for setting the hostname and subscribing to hostname changes? David
