Hi Karen,
thank you for your comments.
Please see my response in line.
Jan
On 09/24/10 10:10 PM, Karen Tung wrote:
Hi Jan,
Thank you for all the explanations. I have a couple
more follow up questions inline. I removed all the comments
that I have no further questions.
On 09/23/10 05:57 AM, Jan Damborsky wrote:
General questions or comments:
--------------------------------
- Can the SCI tool be used to re-configure an already configured
system/zone?
No. We assume that SCI tool would be used only for configuration
of freshly installed or un-configured system. That means configured
system
has to be un-configured first before SCI tool is run in order to
achieve desired
state. As far as un-configuration step is concerned, Jean is working
on that
and she is discussing potential approaches with smf team.
OK. This sounds good. Please add something early in the document
specifying
the tool is only for configuring freshly installed or un-configured
systems.
When I see the name "system configuration interactive tool", I
immediately assume
it is used for all system configurations scenarios.
Yep. I will clarify that in updated document.
Also, what tool should
people use to re-configure their system?
Let me demonstrate on example of cloned zone, how SCI tool could
participate.
This is not the final design, just one of potential approaches:
* cloned zone is created from existing configured one (using 'zoneadm
clone')
As part of cloning process, resulting zone is 'marked' to be
un-configured on
first boot.
* cloned zone is booted into dedicated state where smf framework
activates unconfiguration mechanism.
* After unconfiguration is done, standard boot is resumed during which
SCI tools is brought up (alternatively, non-interactive configuration
takes place).
Thanks for the example. When I ask the question, I was thinking more
about the global zone case where people are already running on a
configured
system, and they want to reconfigure it. I think in that case, they will
run the unconfigure tool to put their system in an unconfigured state so
the SCI tool will come up for them when they reboot.
Yes. This is how we envision it would work. I will make sure it is better
explained in design spec.
Section 12.2:
--------------
- I am confused by the first bullet.
"SCI tool invoked by start method of
svc:/system/install/config:default smf service".
I thought the SCI tool is invoked as a standalone application.
To me, that means that is something a user/role would
execute a command to run. What does that have to do with a SMF
service?
Let me try to clarify. By standalone application it is meant that it
is not part
of text installer, but instead separate 'binary'.
In most common scenarios (e.g. installed/cloned/migrated zone), we
want that
tool automatically be invoked during first boot of installed system
at the right
point - this is why it is called from
svc:/system/install/config:default smf service.
So, is it correct to say that the SCI tool, standalone, will only be
invoked via SMF scripts?
Will it ever be a case that this tool get invoked after the system is
fully booted?
For example, will it ever be a case where a user assume the root role
and run the tool?
For scenarios we have considered so far, the standalone SCI tool would
be invoked
via SMF.
However, there might be cases we are not aware of right now when user might
want to invoke SCI tool from command line. For instance, slightly
enhanced SCI
tool could be used to generate sample SC profile.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
