William, some comments and questions in-line:
On 07/14/10 10:13 AM, William Schumann wrote:
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.
I'm still wondering why we wouldn't want to use criteria for
configuration manifests in the same way we do for the AI manifest. This
scheme seems to leave only per-service or per-client behavior without
the other dimensions that the criteria design allows for.
More narrowly focusing on the above, why wouldn't we provide a
modify-client subcommand rather than overloading create-client? Before
going further, I would recommend some consultation with Frank on both
that question and the options; I consider the -s/-S inversion of
operation based on capitalization to be dangerous.
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.
I think this limitation is fairly serious. If I want to update an
included section, how will I know what including manifests need to be
republished to re-resolve the inclusions? Very concerned that this is
too static to scale over the full lifecycle.
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.
system_conf is already being planned for usage as part of image
management, see
http://hub.opensolaris.org/bin/view/Project+caiman/AI+Image+Management
and search for system.conf. Perhaps there's some leverage to be had here.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
