Phillip asks why, when he issues a zlogin -C to a zone, it asks him which terminal
type he’d like to use. For those who might not have seen zlogin before, it’s a tool patterned
on the syntax of rlogin and ssh; one uses it to enter a zone from the global
zone. The “regular” way one would use it is as follows:
$ zlogin myzone
This will insert you into the zone with an appropriate subset (including $TERM) of
your environment propagated from the global zone. So, if you are using an xterm and your $TERM
is “xterm”, then that will be propagated correctly into the zone. This is all implemented using
pseudo-terminals (the same things used to make telnet, ssh, etc. do what they do); they are
pretty easy to deal with– when you need one, you create it from nothing, then start some
processes which are connected to it in some fashion. You have full control of the process environment. In this mode, zlogin will never ask you what terminal type you have; if $TERM is unset in your global zone shell, it will either be
unset, or default to something like dumb inside the zone,
depending upon your shell.
Zones also possess a virtual console, which can be accessed using the zlogin -C command.
And this is where Phillip is having problems.
A console is fundamentally different from a pseudo-terminal. While a pseudo-terminal vanishes once you
stop using it, a console (real or virtual) keeps its state; you can connect to and disconnect from
it at any time. Users familiar with using the tip(1) command or other serial console systems
know that they must often tweak some settings after attaching to a console. Think of the console as
television– the programs are always playing, regardless of whether the set is on or not; you
can choose to watch the set or not by turning it on (i.e. connecting to the console).
Phillip recalls having already answered that question when he installed
the system as a whole. In a subsequent post he is
more critical, since it isn’t intuitive why we ask for this information again.
Since this is my work, hopefully I can show why this isn’t “sloppy” as Phillip
asserts, but rather an unavoidable artifact of the way UNIX consoles function.
To understand this, we need to turn to another important distinction: the terminal type of the system’s
console should usually be set to reflect the kind of hardware which comprises the physical system console.
On Sun’s SPARC boxes, this is sun and on x86 we have sun-color. This is important,
because these terminal types are pretty much incompatible with, for example, the xterm terminal type.
On the other hand, if a machine’s console is instead set to be one of
its serial ports, and is accessed over a tip line, then the default terminal type is usually set to
something fairly benign like xterms (xterm-small) or vt100 or the like– but
this setting must be made by the administrator because there is no protocol for serially connected
terminals to identify their terminal type, a limitation of the hardware.
Zones emulates the latter sort of connection– a zone console is analogous to a serially connected
tip line. At one end is your terminal, the type of which is not automatically known to the console
at the other end. It is probably an xterm (xterms), a gnome-terminal, a dtterm, or the like.
It might also be a vt220, a wyse or any of hundreds of others. So,
just as we do at first system boot (if we can’t work out what type of terminal we are connected to by
querying the openprom device), we query the user the first time the zone is booted. After that, we’ll
remember this setting. I suppose that we could have just defaulted to something such as ‘vt100’ but that
also seems unfriendly; the sysid tools (the stuff that asks you for your hostname, timezone, etc.) make extensive use of curses, which tends to spam your terminal with garbage if it’s idea of your terminal type doesn’t match
your terminal hardware (or emulator). We certainly can’t default to the system’s default setting, since that
is highly unlikely to be compatible with your window system terminals; if the zone operates as though
the terminal is sun and you are using an xterm, you won’t be pleased.
It’s also worth mentioning that you can automate away all of these first-zone-boot questions by
employing an /etc/sysidcfg file.
Next up– how do you change the terminal type if you’ve made a mistake during the sysid configuration? You’ll
know this happened if your screen is filled with gobbledygook characters when you’d normally see the “what is
your hostname?” question. It’s nice that you have the non-console zlogin available when you encounter situations
like this. To repair things, log off of the zone console, and run:
# zlogin myzone /usr/sbin/sys-unconfig
This will halt the zone after blanking it. Boot the zone back up, log onto the console, and start again.
[Update: It’s not the case that after you specify the terminal type for the sysid tools,
this will automatically become the console terminal type; arguably, this would be good, but it also
doesn’t match the behavior of earlier Solaris releases. We’ll take a look. See the tip below for
how to set your console’s terminal type]
What if you changed your mind about what the default terminal type of the console ought to be?
The classic “big hammer” method is to simply run the sys-unconfig utility; this has the
downside of pretty much blanking your system’s networking configuration, but it is effective.
In older versions of Solaris, you can also edit the ttymon line in /etc/inittab.
Starting in recent builds of Solaris 10, all of this is controlled by SMF, the new Service Management
Facility; as a result, changing the terminal is pretty simple. To check your current setting:
$ svcprop -p ttymon/terminal_type system/console-login sun
To see all of the ttymon family of properties, issue:
$ svcprop -p ttymon system/console-login ttymon/device astring /dev/console ttymon/label astring console ttymon/modules astring ldterm,ttcompat ttymon/nohangup boolean true ttymon/prompt astring \\`uname\\ -n\\`\\ console\\ login: ttymon/timeout count 0 ttymon/terminal_type astring sun
And to change your console terminal type (as root):
# svccfg -s system/console-login 'setprop ttymon/terminal_type = sun'
So now we have a supported, upgrade-safe way to change all of the elements of the console’s