On 07/19/10 12:34, Dave Miner wrote:
On 07/19/10 07:35 AM, William Schumann wrote:
On 07/14/10 09:47 PM, Dave Miner wrote:
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.
Would you explain in more detail, both generally and specifically, what
criteria you would like to see?
Here I'm operating on the principle that congruity between the
capabilities for associating installation manifests and configuration
manifests would be a good thing. I don't have a specific example in
mind, but think that any differences between them should be
justifiable based on some principle.
The principle I have been going by is that install configuration (the
AI manifests) and system configuration (the SC profiles) represent
two different things and the belief is that the criteria we've defined,
which are client attributes (mostly hardware attributes), help
classify install configuration into categories that can be used by the
server as the selection mechanism to serve that configuration. In
looking at criteria, it didn't seem like they were generally applicable
to classify system configuration. For example, criteria such as cpu
type or memory size didn't seem to have any relevance to select
system configuration. The criteria that did seem relevant were
ones that'd identify specific clients, hence the proposal to specify
configuration manifests with the the client specific association (as
a simplified usage of such criteria).
I can't identify one offhand, though I recognize that sysid was less
flexible than I'm suggesting here.
Admittedly, the assumption I have been going by above is
predominantly based on the set of sysid configuration. We are
allowing for the potential for a much larger set of configuration
to be specified now (as compared to sysid) so perhaps there are
cases where the full set of criteria might be useful, but those cases
just haven't been apparent to me.
-ethan
More narrowly focusing on the above, why wouldn't we provide a
modify-client subcommand rather than overloading create-client?
Ethan pointed out to me that presently 'create-client' is used to
modify.
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.
OK
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.
Indeed, the design relies upon the sysadmin to manage an inclusion
framework.
The most basic way to lessen this impact would be to store the top-level
SC manifest - the one specified on the command line. This would provide
names of the top-level files being included.
Another approach would be to keep names of all included files as
metadata. The 'list-sc' subcommand could display the inclusion tree, as
well as an information about the files: e.g., is the included file still
available? does it still parse? when was it last updated? has it been
updated since the 'installadm' command was launched (possibly stale)?
Still another approach would add comments to the final SC manifest
specifying the source input filenames so that the 'export-sc' subcommand
would display them. (This would mean that the information would appear
on the client, of course, and would be useful for debugging.) The
'list-sc' subcommand could provide the same information as mentioned
just above.
Is dynamic inclusion at install time preferable to static? Should we
provide the option of either?
I would think that dynamic (or "late") binding is closer to users'
expectations than static (or "early") binding of inclusions because
it's more consistent with overall system behavior these days. I'm not
sure I see a case for both...
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
