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
Version-Release number of selected component (if applicable):
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.
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.
strange... no firewall or xinetd deactivation involved? You are the only one
reporting this and I cannot reproduce it.
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
(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.
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
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.