Hi Rainer,
On 03/26/10 11:27 AM, Rainer Orth wrote: > Hi Jan, > >> Please feel free to take a look and speak up in case >> I missed any comments or misunderstood anything. > > all my issues have been adressed, thanks. You are welcome. > > On second reading, I've got a couple of questions, mostly related to the > Strategy section. > > * 2.2 Automated Installer > > I suppose you can have different service tags within a single SMF > profile? Otherwise, I wondered how to e.g. set the > ttymon/terminal_type property which lives in svc:/system/console-login > from the profile that sets system/install/config properties. Yep - since SC manifest is in form of regular SMF profile, more services can be listed there - e.g. for * setting terminal type * setting root password * choosing NWAM as network manager the appropriate portion of SC manifest could look like: ... <service name="network/physical" version="1" type="service"> <instance name="default" enabled="false"> </instance> <instance name="nwam" enabled="true"> </instance> </service> <service name="system/install/config" version="1" type="service"> <instance name="default" enabled="true"> <property_group name="root_account" type="application"> <propval name="password" type="astring" value="$5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/> <propval name="type" type="astring" value="normal"/> </property_group> </instance> </service> <service name="system/console-login" version="1" type="service"> <property_group name="ttymon" type="application"> <propval name="terminal_type" type="astring" value="vt100"/> </property_group> </service> ... > > 2. nodename > > How is this supposed to work? It doesn't seem practical to have an > individual SMF profile per client, differing from the (say) > site-global one only by nodename, > especially since the information can > usually be obtained either from a name service or per DHCP. I agree. It is generic problem with scalability of SC manifest. We have discussed it a bit, but haven't fully solved it yet. For instance, we could allow applying more than one profile - then we could separate common settings from client specific configuration. Or (in case of nodename) identity:node coudl be taught to dynamically fill in nodename at the first boot - e.g. the parameter could be obtained by querying the appropriate database. There is definitely more investigation to be done and we are open to ideas. We would also appreciate sharing experiences with how that problem is handled in existing infrastructures. > Besides, > changing the nodename requires changes to /etc/inet/hosts, too. Is > this already handled by the updated identity:node service? At this point, it is supposed to be handled by identity:node service - it would associate 'nodename' with loopback address in /etc/inet/hosts. > > And, just out of curiosity, could you share the updated manifest and > method script for that service? These have not been designed yet - once the design specification for that stuff is available, it will be published for review - in the same way as it was done for SC SMF service. > > 3. not yet in SMF > > typo: b*e*ckend Thanks for catching this - corrected. > > 4. not in SMF > > How is the name service switch configuration supposed to be handled? As far as configuration of naming services is concerned, there will be dedicated configuration SMF service provided by networking team - see CR 6923168 for more details: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6923168 > > * 5 Requirements > > 5.1 user account > > expire: typo: password(1) -> passwd(1) > > last line: typo: is need*ed*/desired Corrected. > > 5.2 root account > > expire: password(1) again Result of copy-paste approach :-) > > * 9 Related bugs, projects > > bug -> CR? Corrected. > > * 10.4.1 Fatal errors > > first bullet: markup: usermod(1M), useradd(1M) -> bold Corrected. > > I know a considerable part of this are nits. Let me know if we should > better handle this in private mail. I believe you brought up valid points which will have to be addressed. Thank you very much ! Jan
