On 06/24/10 04:55 PM, Dave Miner wrote:
On 06/24/10 10:47 AM, William Schumann wrote:
...
So, the wanbootfs could be used by the webserver to store the AI and
SC manifests for upload. Once the wanbootfs is mounted on the
client, the AI and SC manifests can be copied to their final
destinations.
My only quibble is with the assumption that SC manifests are specified
in the AI manifests. We could just as easily use criteria to
associate SC manifests to client sets and properly include them, were
that judged to meet the requirements better.
I don't see any requirements relating to criteria, other than service
name and CID (01+MAC). The AI manifest has complex criteria concerns,
but the SC manifest does not.
Now, given only the service name and CID as criteria, here are a couple
of alternatives to specifying SC manifests in the AI manifest.
(Assumption: the following assumes wanboot-cgi as the webserver, since
it the idea has been floated and since wanboot-cgi is presently used for
SPARC AI, but another AI webserver design could supply the same
functionality)
Alternative 1) put the SC manifest file paths in wanboot.conf
wanboot-cgi could be modified generally such that wanboot.conf could
supply a list of filenames and wanbootfs destination paths. AI writes
the filename, destination path pairs to a wanboot.conf using a keyword,
"wanbootfs_include":
wanbootfs_include <SC manifest source files> <destination directory
relative to wanbootfs root>
wanbootfs_include /usr/lib/sc_manifest.xml /etc/sc_manifest/
The AI server presently uses wanboot.conf for SPARC custom clients.
wanboot.conf is copied to /etc/netboot/<net-IP>/<CID>/, updated with the
image information during 'installadm create-client'.
I think that the biggest hazard with this is binding the wanboot.conf
with the responsibility of managing SC manifest files. For example, for
a site with many custom clients, but only one SC manifest for all, the
path of that manifest would be replicated in each wanboot.conf, which
goes contrary to principles of scalability, and the replication could
also make tedious management problems when changes are needed. More on
this below.
Alternative 2) put the SC manifest files in the /etc/wanboot hierarchy
under a known directory name: e.g., "sc_manifest/"
In wanboot, client authentication and encryption can be either
customized for individual clients, or a default can be created for the
network or wanboot-cgi server, depending on where the wanboot.conf and
security files are placed in the hierarchy:
/etc/wanboot/<network IP>/<CID> where CID is "01"+MAC address. In
2), suggest that if a directory "sc_manifest/" is found in the
hierarchy, all .xml files in that directory are taken to be SC manifest
files for that CID or server. For wanboot-cgi to do this in a
generalized way, suggest adding a slightly different directive from
wanbootfs_include (in 1), except that a script is specified that, given
QUERY_STRING, outputs a list of pairs of files and wanbootfs-relative
destination pathnames:
wanbootfs_include <script> <destination path>
The script in this case is provided by the AI server and its function is
to locate the SC manifest files in the hierarchy and to output the
filenames and destination paths:
wanbootfs_include /usr/sbin/sc_manifest_fetch.py /sc_manifest/
Note: this doesn't have to be done with a script at all - it could be
done by wanboot-cgi. The script name could be replaced with the name of
a directory for wanboot-cgi to search for in the hierarchy (e.g.,
"sc_manifest/")
A workaround for alternative 1) is for wanboot-cgi to walk the hierarchy
looking for manifest files in any wanboot.conf - not just the
wanboot.conf for the custom client.
The biggest downside to using wanboot.conf (1) is that it may
necessitate copies of wanboot.conf that are ignored, or just used for
the wanbootfs_include facility. wanboot-cgi may need to be altered to
distinguish between these to avoid bugs from missing wanboot.conf
information.
There are two main possibilities for including files for 1) and 2)
hierarchically:
- include all files in the hierarchy at all levels where include files
are specified
- include from the hierarchy only files in the most specific criteria
(i.e., furthest down in the hierarchy) where include files are specified
Since the latter can always XInclude other manifests, I would opt for
the latter.
Given options for locations of SC manifests:
0) AI manifest
1) wanboot.conf
2) sc_manifest/ directory in hierarchy
I think that using the AI manifest is the most straightforward and
the least in need of a UI
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
