On 06/30/10 06:36, William Schumann wrote:
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.
But the wanboot.conf file is automatically generated by the installadm tool
per client and per service, so I don't see any hazard of scalability
here since
its not exposed to the user. Its not something the user has to maintain.
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/")
Barring my statement above, I don't what other advantages running a script
has over simply using what you described in 1.
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
Storing references to the SC manifest inside the AI manifest would seem
to present the exact disadvantage you're describing for Alternative 1.
In addition, if we stored references to the SC manifest inside the AI
manifest,
how does that make use of the wanbootfs? My understanding of storing the
reference of the SC manifest inside the AI manifest means that the AI client
has to subsequently fetch the SC manifest, after it parses the AI
manifest, etc.
For sparc usage, it would be preferable if the SC manifest came along inside
the wanbootfs that was used for the original boot.
-ethan
William
_______________________________________________
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
