On 12/29/10 08:25 PM, Jack Schwartz wrote:
Hi Jan.
On 12/29/10 08:25 AM, Jan Damborsky wrote:
Hi Jack,
thank you very much for review.
You are welcome!
Replies inline.
Let me address some of your comments - please see my response in line.
I will let Keith respond to the rest of them.
Keith, feel free to let me know if I skipped something which
I should address.
Thank you,
Jan
On 12/28/10 07:21 PM, Jack Schwartz wrote:
Hi Jan and Keith.
I reviewed section (B) sysconfig module - mapping data in DOC & smf
profile generator. Here are my comments:
[...]
usr/src/cmd/system-config/profile/network_info.py
-------------------------------------------------
221: The implicit assumption is made that if there is an error
running dhcpinfo that there will be no output. Callers to
_run_dhcpinfo will ignore errors if it is possible for dhcpinfo to
give both stderr and stdout output.
259-260: Is it correct to say both stateless and stateful equal "yes"?
Yep. That is correct. Those two options represent two IPv6
auto-configuration
mechanisms which can work simultaneously - this is actually default
configuration
when IPv6 NIC is auto-configured by means of ipadm(1m) command.
ipadm(1m) is used
by network/install smf service to apply networking configuration in
case of 'Manual'
scenario. If you are interested in more details, ipadm(1m) man page
and following
PSARC would provide you with additional information:
http://arc.opensolaris.org/caselog/PSARC/2010/164/
OK. Thanks for the tip. I'll read up on this.
The names make it seem like they are opposites when they are not.
That is what you have to work with, and isn't anything you can change.
Yep. If you are curious, I have recently found PSARC document for
ipadm/libipadm:
http://arc.opensolaris.org/caselog/PSARC/2009/306/
usr/src/cmd/system-config/profile/system_info.py
-------------------------------------------------
26: Does "systemwide" mean global zone? If yes, is it possible to
set up non-global zones with different locales?
Actually, most of those sysconfig parameters have per-zone scope
(keyboard layout is the exception - it is inherited from global zone),
thus that comment is misleading and should be changed. I am thinking
that
we could perhaps change it to something like
Defines SystemInfo class which serves as a container for following
system information:
- hostname
- time zone
- locale
language and locale?
Yep. It is more accurate.
- keyboard layout
- terminal type
Do you think it might better capture what that file contains ?
Yes.
ok. Thank you.
[...]
Just curious: 313: How come terminal type is hardwired to vt100?
Text installer sets terminals differently: From text-mode-menu.ksh:
# If connected to SPARC via keyboard/monitor, set TERM to "sun"
# If connected to X86 via keyboard/monitor, set TERM to "sun-color"
# If running on serial console, set TERM to "xterm"
This is a good point. The initial idea behind hardcoding terminal
type to vt100
was that since SCI tool itself does not provide for configuring it,
we would
go with hardwired value which would serve most of the scenarios.
But as you pointed out, we do allow to configure it in text installer.
Based on that, I am wondering if changing the behavior in following way
might better serve needs in that area:
* In case of text installer, terminal type on installed system would
be the same
as the one used during installation.
Sounds good.
* When running SCI tool as a standalone application, I can think about
following possibilities:
[a] terminal type would be configured to 'vt100'. User would be made
aware
of that on Summary screen.
[b] terminal type setting would reflect the one configured on running
system
[c] terminal type would not be configured at all
I slightly prefer [a], since it seems desirable approach in case SCI
tool is used
to configure non-global zone.
OK. Setting the term type to a default value when the SCI tool is
used standalone (after an install) seems like a good idea, since I
assume that each non-global zone will likely operate on its own screen
and so one cannot know how to set it up beforehand.
That said, why not set it to the same text-installer default values
based on Sparc-monitor/X86-monitor/serial-console instead of vt100?
We perhaps could do that. Looking at the algorithm (*), we would end up
with 'xterm'
in non-global zones. If this is acceptable, then I am fine with that
approach.
Thank you,
Jan
(*)
http://src.opensolaris.org/source/xref/caiman/slim_source/usr/src/cmd/text-install/svc/text-mode-menu.ksh#83
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
