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. 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. XML document error
messages are not always the easiest of messages to understand when
trying to fix validation errors. 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.
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.
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.
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?
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.
"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.
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.)
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?
Darren
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
