Bug 89464 - timeconfig in text mode is broken over remote logins
timeconfig in text mode is broken over remote logins
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: timeconfig (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-23 00:26 EDT by Marc MERLIN
Modified: 2007-04-18 12:53 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-11 17:08:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of the brokenness (14.17 KB, image/png)
2003-04-23 00:28 EDT, Marc MERLIN
no flags Details
bad timeconfig screen (10.92 KB, text/plain)
2003-05-27 11:28 EDT, Brent Fox
no flags Details
good timeconfig screen (9.37 KB, text/plain)
2003-05-27 11:29 EDT, Brent Fox
no flags Details
bad authconfig screen (10.42 KB, text/plain)
2003-05-27 11:29 EDT, Brent Fox
no flags Details
good authconfig screen (8.48 KB, text/plain)
2003-05-27 11:30 EDT, Brent Fox
no flags Details
authconfig good (8.48 KB, image/png)
2003-06-02 11:16 EDT, Brent Fox
no flags Details
authconfig bad (10.42 KB, image/png)
2003-06-02 11:17 EDT, Brent Fox
no flags Details
timeconfig bad (10.92 KB, image/png)
2003-06-02 11:17 EDT, Brent Fox
no flags Details
timeconfig good (9.37 KB, image/png)
2003-06-02 11:18 EDT, Brent Fox
no flags Details

  None (edit)
Description Marc MERLIN 2003-04-23 00:26:48 EDT
I log in from inside an xterm/eterm on RH 7.3 as root on a RH 9 server, and
timeconfig, just like some other tools like netconfig looks completely broken.
It's unusable
Comment 1 Marc MERLIN 2003-04-23 00:28:09 EDT
Created attachment 91240 [details]
screenshot of the brokenness

this happens regardless of what I set TERM to
Comment 2 Marc MERLIN 2003-04-23 14:26:55 EDT
hp gave me the reason for this problem, I suppose you can close the bug, but
please look at my answer

----------------------------------------------------------------------------
> You have to match the encoding of mc to the encoding of 
> your terminal. The encoding of mc comes from the locale; for 
> example, LANG=en_US.UTF-8 gives UTF-8 encoding, 
> LANG=en_US.ISO-8859-1 gives Latin-1. 7.3 terminal will be expecting
> Latin-1 by default. RHL 9 gnome-terminal has a menu Terminal->Character Coding
> which can be used to change encoding to match remote systems.

Indeed, thanks for pointing that out, I missed that change (and boy, did I
look for it. Can this be added someone, like in the release notes next time)

I know why you are making this change, but honestly knowing that it breaks
remote connections in a non obvious way, I question the wiseness of this new
default.
It also breaks any other terminal by default (like xterm/Eterm/whatever),       
doesn't it?

> This can't be done automatically because the ssh and telnet protocols do
> not include encoding negotiation. A screwup in those protocols, so 

That's true

> the only solution is to manually set your encodings properly.

Other possible fixes would have been:
1) auto-set lang to en_US.ISO-8859-1 for remote connections
2) have gnome-terminal set a new TERM type (which gets passed by
   telnet/ssh/rlogin) and set lang to en_US.UTF-8 only if this new TERM
   type is detected (like xterm-utf8)
----------------------------------------------------------------------------
Comment 3 Bill McCarty 2003-05-13 01:36:01 EDT
I don't often use X and therefore am not particularly familiar with the ins and
outs of encodings. I use the Win32 client Putty to access my Red Hat Linux host
via SSH. When I run the setup utility, each of its configuration programs works,
except for timeconfig, which fails in the way described by Marc. Putty provides
configuration options for the encoding type. And, fiddling with them alters the
setup program's menu in some interesting ways. But, no setting I've found coaxes
timeconfig into working over the SSH connection. So, it seems that I must travel
to the NOC to reset the timezone on an errantly configured host. 

Perhaps I'm missing the obvious. But, I can't see how to change the encoding in
a way that works around this problem. And, I'm puzzled why the problem affects
only timeconfig, not authconfig and timeconfig's other siblings.
Comment 4 Brent Fox 2003-05-21 15:52:28 EDT
Bill, when I ssh from an xterm on a 7.2 box into a 9 box, all the text utilities
look messed up to me.  I don't think that there's anything different about
timeconfig.

The best thing I can tell you is to follow hp's advice and prepend
'LANG=en_US.ISO-8859-1' to the command to run any of the text based tools.  That
seems to work for me.  Basically, a lot of things are going to be a mess until
everything uses UTF-8 encoding.

I dont't think that there's anything I can do in the context of timeconfig to
fix this problem.  Closing as 'wontfix'.  
Comment 5 Bill McCarty 2003-05-26 01:49:50 EDT
Hi Brent,

Thanks for the additional info. But, I don't think your test using an xterm goes
to the heart of the issue. You point out that everything's messed up with xterm.
That's interesting. 

But, when I use Win32 putty, the only member of the setup program that fails is
timeconfig. Moreover, timeconfig can't be coaxed into working by prepending an
assignment to the LANG environment variable, as suggested. So, timeconfig
differs in some important--and unwholesome--way from the other members of the
setup program.

Make sense?

Cheers,

Comment 6 Brent Fox 2003-05-27 11:27:49 EDT
Ok, I've downloaded putty on my Win2k box.  I get the same behavior as if I was
on a RHL 7.2 box.  All the text mode tools look bad until I prepend
"LANG=en_US.ISO-8859-1" to whatever command I'm running.  Then things look fine.  

I'm attaching screenshots of timeconfig and authconfig to demonstrate the
behavior.  The ones that look good had "LANG=en_US.ISO-8859-1" prepended to the
command.  The ones that look bad did not.
Comment 11 Marc MERLIN 2003-05-27 17:26:34 EDT
Brent, please set the mime type of your attachements to image/png, not text/plain
Comment 12 Bill McCarty 2003-05-31 05:08:51 EDT
Hey y'all,

Here's yet another twist. I have a second RHL 9 host. When I SSH into it by
using Putty, all the programs accessed via the setup command work okay, except
for timeconfig. The screens are a bit messy, but not so bad as to be unusable.
The line drawing characters are substituted by letters with diacritical marks
and such. That's all.

Timeconfig, on the other hand, dies. Running timeconfig directly from the
command line yields a visible stack trace showing that timeconfig is trying to
open the X display:

# timeconfig
Traceback (most recent call last):
  File "/usr/share/redhat-config-date/timeconfig.py", line 29, in ?
    from timezone_map_gui import ZoneTab
  File "/usr/share/redhat-config-date/timezone_map_gui.py", line 18, in ?
    import gtk
  File
"/usr/src/build/218821-i386/install/usr/lib/python2.2/site-packages/gtk-2.0/gtk/__init__.py",
line 43, in ?
RuntimeError: could not open display


Note that the environment variable DISPLAY is not set:

# echo $DISPLAY

# 

Has timeconfig gone GUI-only in RHL 9?

Cheers,
Comment 13 Brent Fox 2003-06-02 11:15:53 EDT
marc: sorry about that.  I thought bugzilla could detect file types...
Comment 14 Brent Fox 2003-06-02 11:16:49 EDT
Created attachment 92080 [details]
authconfig good
Comment 15 Brent Fox 2003-06-02 11:17:31 EDT
Created attachment 92081 [details]
authconfig bad
Comment 16 Brent Fox 2003-06-02 11:17:59 EDT
Created attachment 92082 [details]
timeconfig bad
Comment 17 Brent Fox 2003-06-02 11:18:26 EDT
Created attachment 92083 [details]
timeconfig good
Comment 18 Brent Fox 2003-06-02 11:21:47 EDT
Bill, that particular bug you are seeing is a dupe of bug #90185, which was
fixed in redhat-config-date-1.5.10-1 last week.
Comment 19 Brent Fox 2004-03-11 17:08:37 EST
I'm going to close this bug as 'wontfix' since I don't really see a
way to fix it.  Over time, as everything moves to UTF-8 encoding, this
problem should go away.  In the meantime, prepending
"LANG=en_US.ISO-8859-1" can suffice as a workaround.

Note You need to log in before you can comment on or make changes to this bug.