This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 20566 - Locales are not fine for xinetd's services
Locales are not fine for xinetd's services
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-09 04:41 EST by Milan Kerslager
Modified: 2007-04-18 12:29 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Milan Kerslager 2000-11-09 04:41:15 EST
There should be 

LC_ALL=C

and maybe unset LANG and others variables too. With locale (for example) 
FTP service not work inside Midnight Commander and other tools due 
localized messages in output from the FTP daemon (this output can't be 
correctly parsed and some programs hagns due this reason).

This is the fastest (but maybe not best) correction of this bug. The 
wu.ftpd daemon should be probably fixed too (internal ls command).
Comment 1 Milan Kerslager 2000-11-09 05:14:37 EST
I frogot - LC_ALL=C should go into the /etc/init.d/xinetd.
Comment 2 Trond Eivind Glomsrxd 2000-11-09 14:20:57 EST
I don't think this is a bug.. The world is more than English.
Comment 3 Milan Kerslager 2000-11-09 17:31:31 EST
Yes. But every frontend (like Midnight commander, Netscape, CuteFTP, WSftp, ...)
expect *English* reply. The system with localized FTP daemon is completly
unusable. I mean this is bad when daemon like FTP speaking Czech or German
because nobody will underestand what this daemon tell to them (connecting people
may be from any country on the world not only from my country). English is (in
this case) the only one acceptable language.
You may fix FTP daemon (or xinetd) to not accept locale but there are other
daemons so unsetting locale environment variables for xinetd in its starting
script is the safest (and fastest for now) way to keep all possible boxes
speaking correctly to connecting clients.
Me and users in my country are happy to see output from 'ls' command in our
language BUT we will never be happy when all clients (the users may use to
connet to this Linux box) will not work due to stupid localized configuration in
the wrong and unneded place.
Believe me, I'm working on our national distribution for long long time and I
know about what I'm speaking. Localization and corrections of "mistakes" made by
english-speaking-programmers are endless and at this time this is the only one
real and biggest trouble we have with Linux when we are trying to use it. I
underestand that who is speaking english don't underestand to ours national
troubles as I can't underestand to japanese troubles. But what we need is the
usable international system without repeating manual fixing of hundreds bugs
every time new distro is out.
Any more questions? :-)
Comment 4 Trond Eivind Glomsrxd 2000-11-14 09:53:16 EST
In the case of ftp messages from the server, wouldn't looking at the return
codes be better? Depending on server-specific text sounds broken...

Anyway, I'm changing it because I think i18n should be on the client, not the
server - the server in general doesn't know which locale it should respond in. 
The changes should be made in  2.1.8.9pre13-1, which will show up in Rawhide at
some point.

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