Sunday January 23, 2005
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 myzoneThis 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-unconfigThis 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 sunTo 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 sunAnd 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 configuration. Sweet!
(2005-01-23 17:30:00.0) Permalink Comments [3]
Trackback: http://blogs.sun.com/dp/entry/clearing_up_confusion_about_zlogin


cat sysidcfg.testzone system_locale=C terminal=xterm network_interface=primary { hostname=testzone.example.org } security_policy=NONE name_service=NONE timezone=US/Eastern cp sysidcfg.testzone /zones/testzone/root/etc/sysidcfg zoneadm -z testzone boot when I then did a zlogin -C, I expected the sysidcfg value would have been set the terminal type to xterm, but I got: zlogin -C testzone [Connected to zone 'testzone' console] testzone.example.org console login: root Password: Jan 23 23:03:50 testzone.example.org login: ROOT LOGIN /dev/console Sun Microsystems Inc. SunOS 5.10 s10_72 December 2004 # echo $TERM sun # svcprop -p ttymon/terminal_type system/console-login sunPosted by Bill Hathaway on January 23, 2005 at 08:38 PM PST #
Posted by Dan Price on January 24, 2005 at 12:56 AM PST #
I must admit I got <em>bitten</em> by terminal type confusion a couple of times already and it was no fun at all. I've got a couple of comments and a couple of questions.
Comment Why the default terminal type of sun-color? Surely xterm or vt100 would have been better, mainstream choices. Since so much of remote system admin (well OK <em>all</em> remote sys admin - in my case) is done via SSH and xterm, there's a good argument to be made for making xterm the default.
sysidcfg file I tried to define a sysidcfg file - to save time and trouble (when my zlogin turned to spagetti due to the <em>wrong</em> terminal definition) and copied it to the required location during zone creation. However it was rejected due to some issue (something out of place). There was no useful error message emitted - just a fleeting error msg indicating that it had been rejected. So I figured: "well I have a good zone over here - why don't I just generate a sysidcfg from it and then use this as my "golden"/standard sysidcfg for the next zone creation". I looked around for a way to generate a sysidcfg from a known good machine or zone and found a reference to kdmconfig -d filename. After playing with this I discovered that it you spec "Xorg" and take the defaults, it exits on the 2nd "F2" keypress and does nothing. If you pick XSun you get the X-Server config portion of a sysidcfg ... but not the "main" portion that I was looking to create. Question Is there a way to generate a sysidcfg from a known good machine or zone?
Question Is there a tool that I can run a sysidcfg file through to validate it? One that will, hopefully, help me identify structural defects in the file or mere typos?
Comment I figured out, all by myself :), that a sys-unconfig could be used within a zone to resolve my issue with the bad sysidcfg file. At the time I had two root login xterms (among many other xterms) in a large workspace window associated with the V20Z I was working on, which is physically located in a CoLo facility. Guess what ... you got it ... I typed the sys-unconfig command into the wrong window (the one associated with the global zone) - and took down the machine. Naturally the CoLo guy did'nt have an admin network setup or I could have used the V20Zs service processor to reboot it! :( I see that you run this command by entering it as a argument to a zlogin command line - now I know why!
Great work (your blog) BTW and thanks for taking the time to write it up.
Posted by Al Hopper on March 03, 2005 at 08:52 AM PST #