Ethan
On 06/30/10 06:53 PM, Ethan Quach wrote:
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.
OK. Also, I did not sufficiently clarify that if the /etc/netboot
hierarchy is searched for the files to include, they do not need to be
copied, and so it is not a scalability issue.
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.
One advantage is that the wanboot.conf does not need to contain the SC
manifest file names (thus avoiding the awkwardness and potential bugs of
wanboot-cgi having to deal with any wanboot.conf files that only exist
to contain SC manifest filenames) - the SC manifest files are found
automatically by scanning the hierarchy. Another difference - perhaps
an advantage - is that the SC manifests can be contained and protected
in the /etc/netboot hierarchy. The user doesn't have to worry about
file protections on externally maintained SC manifest files.
wanbootutil is responsible for placing the security files in the
hierarchy, and the same logic and perhaps code can be used to place SC
manifest files.
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.
Indeed. I think this was addressed in another thread - this could be
counteracted through use of replacement tags representing service, CID,
and perhaps other criteria, to do install-time substitutions. If
scalability is a criteria, use of replacement tags with a naming scheme
could be powerful. Consider naming scheme /etc/sc_manifest/<CID>.xml -
the <CID>.xml contains only client-specific SC properties. XInclude
could try to include that file, and fallback to a default if it were
missing, for example.
The replacement tag could be in the AI manifest, but better if it were
in a top-level SC manifest that was included directly by the AI
manifest. Perhaps this seems like too much trouble, but I really think
that leveraging replacement tags makes XInclude dynamic and useful.
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.
I've been assuming here that the AI manifest could be included in the
wanbootfs along with SC manifest across platforms. is there something
wrong with this?
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
