[...] > >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 > > I am not sure I get this part. You mean somebody wants his service to run at no-network and don't start it when network available?
>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. > > But basically, I think the issue should be solved by allowing users to have their own customized standalone profile? ( Section III, dependencies, second paragraph) >And perhaps more importantly, network profiles are a more appropriate >start-after-network-is-available mechanism than SMF dependencies. > >... > > yep. point taken >>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. > > true. Agreed. [...] >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. > >... > > I think the answer to this would be the same as "whether to enable inetd or not". Or a more generic qustion is, should we enable those services that can work properly at no network but without a network they don't really anything? >>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? > > > > John, your turn? :-) -Jan
