Bug 54060 - cannot telnet to server after install of telnet-server-0.17-18.i386.rpm
Summary: cannot telnet to server after install of telnet-server-0.17-18.i386.rpm
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: telnet   
(Show other bugs)
Version: 7.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Ben Levenson
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-09-26 19:19 UTC by mitchell mcgee
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-17 15:39:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description mitchell mcgee 2001-09-26 19:19:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)

Description of problem:
In response to security advisory, upgraded telnet-server-0.17-
18.i386.rpm.  Following upgrade and reboot, could no longer telnet to the 
affected servers.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.rpm -Fvh|-Uvh telnet-server-0.17-18.i386.rpm
2.reboot after install
3.initiate telnet from external host

Actual Results:  When attempting to telnet from another LINUX server, 
received messaged connection refused, from NT received various messages, 
such as cannot locate IP HOST; specific message dependant on client 

The same results occurred on two different servers, COMPAQ Proliant 1600, 
and ML370.  Both are running the 2.2.19-7.0 kernel.

Expected Results:  Establish connection with target host.

Additional info:

Problem was temporarily remedied by reinstalling telnet-server-0.17-7 from 
RH 7.0 CD, however, until the latest release can be effectively installed 
our telnet continues to be vulnerable.

Comment 1 Harald Hoyer 2001-12-13 14:01:56 UTC
strange... no firewall or xinetd deactivation involved? You are the only one 
reporting this and I cannot reproduce it.

Comment 2 mitchell mcgee 2001-12-13 14:55:18 UTC
Our agency has a firewall, but we're accessing the LINUX servers across our LAN 
which is behind the firewall.  I had a similar experience with the recent wu-
ftp upgrade associate with Security Advisory - RHSA-2001:157-06.  After 
applying the rpm, we can no longer FTP to the affected server (Connection 
refused.)  I tried several changes to the ftpaccess config file and even 
resorted to restoring the original config file.  The only thing that worked was 
reinstalling the wu-ftp rpm from the Red Hat 7 install CD.

If the firewall or xinet deactivation were the cause, I would think this would 
affect the versions installed from the Red Hat 7 installation CD as well.

Are there configurations that need to be reset when the telenet or ftp upgrades 
are applied?  

(I've begun to notice that one needs to be alert to changes or replacements in 
configuration files when RPM's are applied and I can find no documentation that 
alerts a user as to what changes may occur and how to safe guard current 
settings.  For example, after applying the rpms for RHSA-2001:112-10 we had to 
recreate all our printfilters.  The recent Apache upgrade replaces the httpd 
file, among others, of which our original has been customized and needed to be 
restored.  Fortunately, we're not allowing up2date to automatically install 
downloaded rpm's, so, we can at least review any warnings that were issued 
during the upgrades, which provide some clues as to what's being altered.)

Since, the original problem log our kernels have been upgraded to 2.2.19-7.0.12 
on the affected servers; one of which is running smp.  If there's any further 
information I can provide regarding our specific installation to help you 
replicate this, please let me know.  Thanks.

Comment 3 Harald Hoyer 2001-12-13 15:09:51 UTC
ok, after installation you may do:

$ chkconfig telnet on
$ service xinetd reload

If rpm replaces a configuration file you should get a message like this:
File foo saved as foo.rpmsave
File foo saved as foo.rpmnew

Comment 4 mitchell mcgee 2001-12-17 15:39:34 UTC
Running ...
chkconfig telnet on
service xinetd reload

after rpm -Uvh telnet*.rpm and rebooting seems to have resovled the problem on 
our test server.  I have not, yet, made the same change to our production 
server, but anticipate no problems.


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