Given options for locations of SC manifests previously addressed:
0) AI manifest
1) wanboot.conf
2) sc_manifest/ directory in hierarchy
0) AI manifest is unsuitable as the only means of specifying SC
manifests since it forces an association and a dependency that may not
apply to all users.
1) wanboot.conf is unsuitable for reasons given previously.
2) sc_manifest/ directory in hierarchy - this would require a command
set for maintaining the files and the order in which they are processed
on first boot. This is not prohibitive, but not elegant.
After discussion with Ethan, proposing a solution that combines features
of the others. Storing and sending single SC manifest file to the
client would simplify matters. XInclude can be used to perform
inclusions from multiple sources on the AI server side, which would
improve scalability.
installadm command additions:
Specifying an SC manifest with installadm subcommands, where
<sc_manifest_file> is either a path or URL specification:
when creating an AI service:
create-service ... [-s <sc_manifest_file>]
for a custom client, upon creation of the client or to modify an SC
manifest for an existing client:
create-client ... [-s <sc_manifest_file>]
to change an SC manifest associated with an existing service, a new
installadm subcommand is created:
modify-service -s <sc_manifest_file>
To delete SC manifests, the "-S" option (rather than "-s") is specified
in all of the above.
To display an SC manifest for a custom-client or a service:
export-sc { <CID> | <service> }
To list any services, specific services, or specific clients with SC
manifests:
list-sc [ <CID> | <service> ]
Behavior:
installadm parses, verifies, and stores the SC manifest:
- inclusions through XInclude are performed
- XML is verified
- if DTD file is specified in DOCTYPE, validate SC manifest against DTD
- store in /etc/netboot hierarchy according to either service or client
ID (CID) with filename "sc_manifest.xml"
Custom clients without SC manifests will receive the SC manifest
specified for the service, if it exists.
Sample master SC manifest for a server:
This is one way that a server can have custom values for properties.
Here, root password, user name, user password, timezone can be found by
service name in a table, using XInclude "xpointer", or taken from
defaults, using XInclude "fallback":
<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM
"/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="name" >
<service name="ai_properties" version="1" type="service">
<instance name="default" enabled="true" >
<property_group name="ai" type="application" >
<xi:include href="psw.xml" xpointer="element(myservice/1)"> <xi:fallback>
<propval name="rootpass" type="astring"
value="$5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/>
</xi:fallback> </xi:include>
<xi:include href="psw.xml" xpointer="element(myservice/2)"> <xi:fallback>
<propval name="description" type="astring" value="default_user"/>
</xi:fallback> </xi:include>
<xi:include href="psw.xml" xpointer="element(myservice/3)"> <xi:fallback>
<propval name="username" type="astring" value="jack"/>
</xi:fallback> </xi:include>
<xi:include href="psw.xml" xpointer="element(myservice/4)"> <xi:fallback>
<propval name="userpass" type="astring" value="9Nd/cwBcNWFZg"/>
</xi:fallback> </xi:include>
<propval name="timezone" type="astring" value="US/Pacific"/>
</property_group>
</instance>
</service>
</service_bundle>
The XML file containing the table with the specified values (referred to
above as "psw.xml"):
<itemlist>
<item xml:id="someotherservice">
<propval name="rootpass" type="astring"
value="ourencoded5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/>
<propval name="description" type="astring" value="private_user"/>
<propval name="username" type="astring" value="wm"/>
<propval name="userpass" type="astring" value="ourencoded/cwBcNWFZg"/>
</item>
<item xml:id="myservice">
<propval name="rootpass" type="astring"
value="ourencoded5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/>
<propval name="description" type="astring" value="private_user"/>
<propval name="username" type="astring" value="wm"/>
<propval name="userpass" type="astring" value="ourencoded/cwBcNWFZg"/>
</item>
</itemlist>
The above "psw.xml" file has properties for two different services:
"myservice" and "someotherservice".
The above XML source can be tested using "xmllint --xinclude --postvalid
<master XML filename>"
Limitations:
The inclusions are resolved as the time of issuing the installadm
command. This has the dual effect of validating and locking in the
inclusions, and of preventing dynamic install-time processing. To be
considered: a flag indicating dynamic processing of the specified SC
manifest file, deferring inclusions until install time.
There are some limitations to the XInclude syntax that are functional,
but inconvenient, particularly the indexing with the '/' followed by the
index number.
The most limiting part of XInclude is that it is completely static -
there is no parameterization from an external environment, which would
lessen the scalability. For example, if in the above example, the
service name could be passed in and substituted, a single top-level SC
manifest might suffice for all services and clients, doing table lookups
into "psw.xml". Otherwise, each service would have to have its own
top-level XML file that does the lookups. A preprocessor performing
replacements of service name and CID for tags before the XInclude
inclusions are performed could provide this dynamic behavior. This
could be provided by installadm if desired by users, and it can be
performed by the users themselves with document generators such as
Cheetah. Another way to allow more dynamic, scripted behavior would be
to allow users to specify a script (instead of a static SC manifest
file) that, when called from an environment with service name and CID
defined, would use the output of the script as the SC manifest file.
Webserver interface:
The AI webserver, assumed for the moment to be wanboot-cgi, must have a
way to fetch the SC manifest in a generalized way as not to create a
dependency of the AI webserver on SC manifests. wanboot-cgi could be
modified to look a file named "sc_manifest.xml" in the /etc/netboot
hierarchy, including it in wanbootfs if found. A more generalized
approach could be to provide, in wanboot.conf(4), a way to instruct
wanboot-cgi to search the hierarchy for a file and store it in
wanbootfs. Consider a new keyword for wanboot.conf, "bootfs_include":
bootfs_include=<filename>
To pull in SC manifests, wanboot.conf would contain:
bootfs_include sc_manifest.xml
sc_manifest.xml could be copied into the wanbootfs root.
Under investigation is the use of existing wanboot.conf parameter
"system_conf", which has a similar intent in Jumpstart, but is used much
differently.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
