Comments in-line:
On 09/29/10 04:34 PM, William Schumann wrote:
Proposed:
Static, vs. Dynamic, vs. first boot:
Static: offer XInclude and templating of known criteria at installadm
time. Resolve all templating and inclusions and store the finalized
profile within the AI server space. The static option is specified
once in the profile (e.g.,<!-- AI[inclusion=installadm] -->, or some
encoding solution friendly to DTD service_bundle).
I'd be inclined to defer the templating yet.
To be clear, by templating here, I'm just referring to substituting in
criteria values taken from the AI client: IP, hostname, network, memory
size, service, MAC.
e.g. ${AI_MAC} ${AI_HOSTNAME}
(see Python Template class, method 'substitute'
http://docs.python.org/library/string.html#template-strings )
Dynamic
- at install time: If user specifies a command, run it and take its
sysout as the starting profile. From the profile, perform templating
of known criteria, and perform XInclude inclusions. (re: XInclude,
this is the default.)
- at installadm time: DTD-validate profiles and store profile
filenames in AI database, SC table, according to service, MAC, or
other criteria.
Why both templating and the command? The case for doing both seems weak.
Templating in the sense I mean here, is just substituting in values.
It's much simpler than having the a user-defined script and can
eliminate the need for it in some circumstances.
Inhibit inclusions and any dynamic processing (to support XInclude
inclusions for files available only at first boot). This option is
specified once in the profile (as with Static):
e.g.,<xi:include href=”<first boot profile path>”<!--
AI[inclusion=inhibit] --> >
With regards to the plain text table- and template-driven proposal, I
would move this to a section for alternatives discussed, not
proposed. In any event, this sort of processing can be provided
through scripts that could be provided as plug-ins, which would make
them more flexible and customizable.
installadm changes: only to recognize profile-related subcommands
and call the appropriate handler script.
wanboot client, wanboot server: 5.2.7.5
After looking into the wanboot process, I think that
wanboot/wanboot-cgi should not be used at all,
I mean, wanboot/wanboot-cgi should not be used at all to deliver SC
profiles.
n favor of a new webserver that refers to the same certificates
(presently put on the client by the wanboot) to authenticate the
client. On SPARC, The wanbootfs provides the certificates to the AI
client securely with the wanboot HMAC and key insertion into
write-only OBP.
Please elaborate on your reasoning here, as replacing this existing
infrastructure requires significant justification.
To deliver SC profiles, it doesn't have to be replaced. I'm proposing a
rather minimal client/server solution for profiles. Security
certificates are shared with wanboot-cgi. SPARC would still boot the
same. In fact, no changes to wanboot or wanboot-cgi would be necessary
(other than the /etc/netboot hierarchy modifications I heard have been
proposed elsewhere).
The work involved to make wanboot/wanboot-cgi handle profiles for either
just SPARC or both platforms would be considerable, for reasons listed
in the design document. (more reasons available on request). Here's
the proposed process (first without security):
New AI client script:
leverages ai_get_manifest.py to fetch AI client criteria
sends criteria via POST
New SC profile CGI script (possibly done as part of whatever mechanism
is used to send AI manifests):
takes criteria and sets environment variables in CGI
invokes the SC locator script (or perhaps a Python method):
SC locator is driven entirely off of AI client criteria
SC locator does database lookup for profiles
SC locator packages up all profiles into a single MIME-encoded string
SC locator writes the string to stdout (we're in CGI, so it's packaged
up and sent to the AI client script)
New AI client script decodes the output, writing the profiles to
/etc/svc/profiles with generated filenames.
With security added in:
SPARC:
wanboot already provided security certificates to the client - the New
AI client script uses them to formulate the HTTPS request.
Apache does server authentication and calls the New SC profile CGI script
The New SC profile CGI script finds corresponding client certificate and
key info in /etc/netboot hierarchy just like wanboot-cgi
Python SSL/TLS code does the client authentication in the New CGI script
x86:
similar, but see below
The only major part from the proposal that I haven't prototyped yet is
the client authentication.
Also, the source of the URL needs to be decided upon - will have to work
with AI webserver designers on that.
RE: x86:
PXE has limitations from having a true secure initial boot file
download, so the certificates provided by SPARC securely thanks to
OBP must be specified some other way on x86. Solutions for the
client obtaining the security certificates include:
- certificate server
- providing certificates on install media
- reading certificates from removable media
- copying certificates from locally secure source
AI client changes: 5.7.2.2 Boot process - describes what has to
happen on the AI client side. Will add description of AI client
script to fetch the profiles (getting criteria, http
request/response, handling multiple profiles). Some implementation
details are still to be decided (request URL determination, wanboot
interaction).
This definitely needs fleshing out. I was unclear as to why a second
request, with seemingly similar (if not identical) input, is required
to obtain the configuration manifest.
One of the project requirements is to decouple AI manifests from SC
profiles. I take this as meaning the fetching process as well.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
