Darren,
On 09/10/10 05:41 AM, Darren Reed wrote:
Hi,
The first thing I'd like to mention is the requirement for a system
administrator to edit XML in order to design a SC profile. In my
view this is going back to the days of having to edit .c and .h files
for SunOS4 when building a kernel. My view on XML is that it is
"source code" equivalent for documents.
Agreed on that point.
It seems convenient and reasonable for a sysadmin to provide an init file with
simple property=value pairs.
Representing arrays or lists in a simple .ini-like format is another matter.
Furthermore, the input requirements are all per-service basis. Services are continually undergoing development. Any such utility
to process the .ini-like file would need to keep pace with the service changes as well as maintain compatibility across versions.
In the last revision of the proposal, a utility called aimanifest, which is being designed for command line editing of AI manifests,
is proposed for SC manifests. A similar application for SC manifests could allow command composition of SC profiles:
load <sc_profile.xml> # open an existing manifest template containing
defaults from provided samples
set <section> <property>=<value>
There are several intermediate tags and attributes that would have to be supplied, making this approach still complex.
smf_template(5) could be used by such an SC version of the utility to fill out trivial attributes. Again, this would rely on
smf_template being current for the OS version being installed. More complex properties normally stored as arrays, lists, or
dictionaries would have to be accommodated. This utility, with some refinement, might be leveraged to simplify setting properties.
So to summarize, supporting a Jumpstart-like initialization file should keep pace with SC developments and other complexities of SMF
properties, so perhaps solutions should focus rather on making it easier to produce SMF profiles.
In jumpstart, the configuration
files were simple text. Whilst they may not have been "verifiable"
they were very easy to read and review. Having them be verifiable
should not be the goal for the user interface.
I think that XML and DTD validation is a very useful service to the sysadmin
composing XML.
XML document error messages are not always the easiest of messages to
understand when
trying to fix validation errors.
An understatement.
What I'd like to have seen was
something that builds the required XML file from a text file that
looks more like what the jumpstart configuration files are - or even
one to do exactly that. I shouldn't need to know how to edit or write
XML in order to build a configuration file that is loaded by the
server for a network based client to install.
Utilities such as xmllint(1) have traditionally been used to validate. The validation messages are very general and hard to
interpret. I think that we can improve upon this by parsing with the lxml class and generating more helpful messages displaying
more of the offending source code.
In case you're wondering, I kind of feel the same way about the need
to edit XML for all of the SMF stuff. XML is what I'd consider a low
level text language and there should be something easier to edit for
those that are not interested in using GUIs.) Yes I know, the decision
has probably been made on this so maybe I should just file an RFE
for a higher level text document that can be transformed into
the requisite XML.
We are interested in these ideas for this project right now.
At least if there was a higher level text document that was translated
into XML it would allow the XML to be a private interface and more
easily changed in the future. That is for those that either shun or
don't use the GUI.
Please look at some of the scripting examples from the use cases in section 6
version 1.5 of the document.
In the document it talks about scripts and XSL, etc. Is it possible
to provide something that effectively turns a jumpstart profile (and
optionally also the sysidcfg file) into a SC manifest/install manifest
pair?
There will be a upgrade utility.
Moving on...
5.4.3.1
"Solaris release number" - shouldn't this be a string? In the past
we've had "2.5.1", so a simple decimal is not enough. We could
easily have "11.1" or something else in the future. The decisions
about this are not always left with engineers so it might help to
be flexible here.
OK. The release identifier could also wind up being according to an IPS
release, or maybe a marketing release.
"machine class" - this should be the output of a particular uname
command line invocation, be it uname -i or uname -m or something
else. Names such as "Huron" are generally unknown in the outside
world. If it's the output from uname -something, it becomes easier
to script the generation of SC files.
For SPARC, uname gives more meaningful hardware information than the x86 version. It would be nice to tie it to a particular
command output as you say.
5.11.5.1
You say:
"a trusted Certificate Authority (CA) or can be self-generated through creating a
CA."
All that you need to say is:
"a Certificate Authority (CA)."
People who are familiar with CA's or who research them are going
to learn about self-signing, etc and I don't think there is any
benefit from this document trying to distinguish between them
in this document (really, it is beyond the scope of it.)
OK
I was going to ask why aren't you doing username/userpass to set
the root password, but it seems like the document structure does
not allow for an arbitrary number of users in the SC?
The number of supported users will be dependent upon the SMF service. At the moment, I'm aware of only a root user and one
additional user.
Thank you,
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
