OpenSolaris

Printable Version Enter a New Search
Bug ID 5093847
Synopsis importing a manifest should create method_context properties even if not set
State 10-Fix Delivered (Fix available in build)
Category:Subcategory utility:smf
Keywords smf | smf-triage
Responsible Engineer Sean Wilcox
Reported Against s10_67
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_113
Fixed In snv_113
Release Fixed solaris_nevada(snv_113)
Related Bugs 6411391 , 6608454
Submit Date 30-August-2004
Last Update Date 22-April-2009
Description
The current behaviour is made clear here:

$ svcprop /network/ssh | grep ^start/
start/exec astring /lib/svc/method/sshd\ start
start/timeout_seconds count 30
start/type astring method

$ svcprop /network/login\:rlogin | grep ^inetd_start/
inetd_start/exec astring /usr/sbin/in.rlogind
inetd_start/group astring root
inetd_start/limit_privileges astring :default
inetd_start/privileges astring :default
inetd_start/project astring :default
inetd_start/resource_pool astring :default
...

The /network/ssh manifest has no <method_context> element in its starter's <exec_method>, so properties such as start/resource_pool are not even created on importing the manifest.

For /network/login:rlogin, the manifest /does/ have a <method_context>, so all properties derived from <method_context> are created, even if they're the default value, as can be seen above.

For usability's sake, we should always get the import manifest operation to create all the properties, even in the (legitimate) absence of a <method_context>.

Worse, if the user adds an empty method_context (for, e.g. specifying the project)
the project is *silently* ignored unless either method_credential or method_profile
is specified.
bustos 2006-04-10

The project part of this has been moved to

	6411391 Empty method_context's don't work
Work Around
Export the service to XML, add stuff by hand, then re-import it making sure to use override/delete where needed.
 xxxxx@xxxxx.com 10/19/04 22:45 GMT
Comments
N/A