On 08/ 9/10 09:56 PM, Dave Miner wrote:
On 07/28/10 12:38 PM, William Schumann wrote:
Resulting from previous discussions on SC profiles, a second draft
document proposing changes to SC profiles is now on opensolaris.org at:
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/SCProfileProposal.odt
...
Section 5, Overview:
There seems to be an assumption here that delivering a single profile to a client is desired, and perhaps the requirement.
However, SMF allows multiple site-level profiles to be applied; is there a reason to not provide for multiple profile delivery?
The "installadm options and subcommands" table uses the plural "files", intending to indicate one or more SC profile files. Will
try to make this clearer elsewhere.
I don't understand the statement "supports storing properties in tables". What
does this mean, and why is it desirable?
This offers table-driven solutions in which different values for the same property for separate install clients can be stored in a
single table in a single file. For example, root passwords for many systems can be stored in a single table indexed by CID ("01" +
MAC address). The solution is more scalable, since, in this example, the sysadmin needs only to maintain passwords in a single file
for all systems. Will clarify in the text.
Section 5, Static vs. Dynamic:
Please explain the difference between install time and first boot time (I
understand it, but most readers may not).
For caiman-discuss, "install time" refers to the time that the OpenSolaris Automated installation is occurring. RE: SC profiles, it
refers to the moment when the AI client requests the SC profiles. "first boot time" is the first reboot after the Automated
Installer completes the installation. Here, the SC profiles are read as SMF profiles used for configuring the client that has just
been OpenSolaris-installed. Will clarify this in the document.
Under the "Deferring inclusion until first boot" section, I am actually quite confused. From an architectural perspective, we
would like system configuration to be an SMF profile. Your proposal here seems to be some super-set format of the SMF profile
DTD. True? If so, what does this buy us that can't be provided through other means? And, in particular, how would this
interplay with the SMF manifest importation process during first boot?
SMF profiles support XInclude at first boot, so some SMF profiles will be written to use XInclude. The proposal asserts that the
XInclude technology is useful enough to support it *also* on the AI server for building SMF profiles. "Deferring inclusion until
first boot" means that the XInclude is not performed on the AI server, but during first boot. There is no superset or new format -
this is just a switch.
Section 5, Scalability:
You seem to be proposing the scripting option, but this needs much more detail to evaluate its suitability: when are the scripts
executed, under what identity, what functionality is allowed, etc.
The script outputs an SC profile. The option determines whether the script is executed at 'installadm" or install time. If
"installadm" time is selected, the scripts are executed when installadm is launched. The only other option proposed is for the AI
webserver to execute the script at install time with its usual privileges: e.g. user: webservd. Logging and error reporting
techniques for the script can also be added to this document. Will address in more detail in the document.
Section 5, Basing SC profiles...
It's left unclear here whether you are proposing to implement rules-based criteria? If so, what are the proposed additions to
installadm?
After considering the use of criteria in AI manifests, I think it would be better to carry forth the same techniques for SC
profiles, accepting its simplicity, syntax, and limitations. The command table already lists the installadm -o option for declaring
criteria/value pairs for SC profiles.
What is the rationale for adding the new include_file setting to wanboot.conf? Why wouldn't we just extend wanboot-cgi to build
this functionality in automatically?
Ethan recommended a generalized solution so that a reverse dependency is not created; i.e., wanboot should not be dependent on SC
profile code. The proposal attempts to come up with a generalized solution in which a script can be specified in wanboot.conf to
populate wanbootfs.
Section 5, installadm optison and subcommands
It's fine to summarize this here, but providing references from elsewhere in the document would have been helpful. However, I
really don't understand the table. Which installadm sub-commands does each option apply to?
All of create-service, modify-service, create-client
There is little logical mapping of the short options to the extended options; why both?
Having both short and long options is a common practice. Some users can more easily remember options using entire words rather than
single letters. Longer option names are less ambiguous whereas a single letter might mislead the user to specify an unintended
option. Long options can be more readable. The one concern I have is that this is not consistent with the rest of installadm.
These questions are perhaps best resolved by answering my request for
fleshed-out use cases.
Section 5, Security
First question is, does this proposal improve security of server-stored information without requiring the use of any encryption or
authentication? In particular, the problems noted in bug 15362.
15362 will be fixed - will clarify. The proposal could address security precautions for SC profiles that are included at install
time, however it is a task for sysadmins to secure included files. Otherwise, no - encryption and authentication must be configured
for additional security.
The adaptation of the cert & key management functions to installadm seems to be very simple, but it's not clear whether this is in
fact a comprehensive solution for the user; do we end up with 30 pages of docs to actually get a secure solution implemented?
(Hint: the answer needs to be no :-). Not to be a broken record, but this is exactly what fleshing out the use cases will answer.
This does not attempt to expand wanboot security, nor does it require additional tasks for the sysadmin. The only change from the
usual wanboot configuration is that the existing wanboot hierarchy places net-IP above CID, whereas the proposal removes net-IP from
the hierarchy and places service at the same level as CID, which changes where the keys and certificates are placed in the directory
hierarchy. The expected result is that all of wanboot security is leveraged for complete security for AI as well as for SC profiles.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
