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.
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.
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, in 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.
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.
Dave _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
