Hi, in FC6, the telnetd service refuse the connection if the nameserver is down. (see this bug): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223448
But in this tread: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221583
people say witch this problem is not a bug ....
In previous fc version, if the nameserver is down, the connection is however accepted .
Someone can give me more information to this issue?. It will be resolved (or not) in future?
Many thanks.
Dario Lesca wrote:
Hi, in FC6, the telnetd service refuse the connection if the nameserver is down. (see this bug): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223448
But in this tread: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221583
people say witch this problem is not a bug ....
In previous fc version, if the nameserver is down, the connection is however accepted .
Someone can give me more information to this issue?. It will be resolved (or not) in future?
Many thanks.
I don't have telnetd installed, so I can not check it, but take a look at /etc/xinetd.d/telnet and see if it has something like:
log_on_success += HOST DURATION log_on_failure += HOST
I suspect you have something like the first line, and with DNS down, it refuses connections, because it can not log the machine. Try commenting out the line(s). You will have to restart xinetd.
Mikkel
Il giorno lun, 26/02/2007 alle 14.34 -0600, Mikkel L. Ellertson ha scritto:
/etc/xinetd.d/telnet
it contain only 'log_on_failure += USERID'
but if I comment it none is change.
A workaround is delete the 'dns' keyword from /etc/nsswitch.conf from 'hosts: files' line.
Thanks Mikkel.
On Mon, 2007-02-26 at 22:00 +0100, Dario Lesca wrote:
Il giorno lun, 26/02/2007 alle 14.34 -0600, Mikkel L. Ellertson ha scritto:
/etc/xinetd.d/telnet
it contain only 'log_on_failure += USERID'
but if I comment it none is change.
A workaround is delete the 'dns' keyword from /etc/nsswitch.conf from 'hosts: files' line.
Thanks Mikkel.
-- Dario Lesca d.lesca@solinos.it
Actually the "HOST" part is not in /etc/xinetd.d/telnet but in /etc/xinetd.conf:
log_on_failure = HOST log_on_success = PID HOST DURATION EXIT
Calin
================================================= There is no proverb that is not true. -- Cervantes
kalinix wrote:
Actually the "HOST" part is not in /etc/xinetd.d/telnet but in /etc/xinetd.conf:
log_on_failure = HOST log_on_success = PID HOST DURATION EXIT
I guess I changed the default setup here. In any case, the settings in /etc/xinetd.conf are the default settings, but they can be overridden, or added to, by the individual service config files in /etc/xinetd.d - take a look at any of the IMAP or POP entries...
Mikkel
On Mon, 2007-02-26 at 17:10 -0600, Mikkel L. Ellertson wrote:
kalinix wrote:
Actually the "HOST" part is not in /etc/xinetd.d/telnet but in /etc/xinetd.conf:
log_on_failure = HOST log_on_success = PID HOST DURATION EXITI guess I changed the default setup here. In any case, the settings in /etc/xinetd.conf are the default settings, but they can be overridden, or added to, by the individual service config files in /etc/xinetd.d - take a look at any of the IMAP or POP entries...
Mikkel
Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
No doubt they can be override (as anything in linux world :) ), but I was talking about FC6 default settings for xinetd and/or telnet, the ones Dario uses on his system.
Calin
================================================= Bucy's Law: Nothing is ever accomplished by a reasonable man.
Il giorno mar, 27/02/2007 alle 00.51 +0200, kalinix ha scritto:
Actually the "HOST" part is not in /etc/xinetd.d/telnet but in /etc/xinetd.conf: log_on_failure = HOST log_on_success = PID HOST DURATION EXIT
Also comment out this line (this is my file part of xinetd.conf after comment)
# Define general logging characteristics. log_type = SYSLOG daemon info # log_on_failure = HOST # log_on_success = PID HOST DURATION EXIT
and restart xinetd the problem persist.
Probably the problem is into resolver function, called from xinetd, like bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221583 say
Comment #6 From Jakub Jelinek on 2007-01-05 13:17 EST [reply]
nsswitch.conf containing hosts: ... dns and missing resolv.conf is an admin error, either you should remove dns from nsswitch.conf, or supply a valid resolv.conf. The missing resolv.conf is the same as resolv.conf containing no nameserver lines and that causes libresolv to return TRY_AGAIN, the same as if a DNS is unreachable. For that EAI_AGAIN is the correct answer, instead of silently pretending DNS replied, but said there is no DNS entry for that IP address.
Many thanks Kalinix
On Tue, 2007-02-27 at 00:40 +0100, Dario Lesca wrote:
Il giorno mar, 27/02/2007 alle 00.51 +0200, kalinix ha scritto:
Actually the "HOST" part is not in /etc/xinetd.d/telnet but in /etc/xinetd.conf: log_on_failure = HOST log_on_success = PID HOST DURATION EXIT
Also comment out this line (this is my file part of xinetd.conf after comment)
# Define general logging characteristics. log_type = SYSLOG daemon info # log_on_failure = HOST # log_on_success = PID HOST DURATION EXIT
and restart xinetd the problem persist.
Probably the problem is into resolver function, called from xinetd, like bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221583 say
Comment #6 From Jakub Jelinek on 2007-01-05 13:17 EST [reply]
nsswitch.conf containing hosts: ... dns and missing resolv.conf is an admin error, either you should remove dns from nsswitch.conf, or supply a valid resolv.conf. The missing resolv.conf is the same as resolv.conf containing no nameserver lines and that causes libresolv to return TRY_AGAIN, the same as if a DNS is unreachable. For that EAI_AGAIN is the correct answer, instead of silently pretending DNS replied, but said there is no DNS entry for that IP address.
Many thanks Kalinix
-- Dario Lesca d.lesca@solinos.it
Dario,
from bug 221583:
"Sorry you are correct if a nameserver is configured correctly it return the IP address as expected...
and ... nsswitch.conf containing hosts: ... dns and missing resolv.conf is an admin error, either you should remove dns from nsswitch.conf, or supply a valid resolv.conf."
Do you have a nameserver configured (defined in /etc/resolv.conf) on your telnet server?
Calin
================================================= You will gain money by an illegal action.
Il giorno mar, 27/02/2007 alle 02.03 +0200, kalinix ha scritto:
Do you have a nameserver configured (defined in /etc/resolv.conf) on your telnet server?
Yes, but some time it is down, or the nameserver into resolv.conf is not set.
Is a internal DNS, the local network in not property configured, the DNS is not use. In this scenario the version fc[1-5] work great.
Now I have check (on telnet server) to point the nameserver to 127.0.0.1 and start bind (whitout configure it). The connection from a telnet client now work (without the nsswitch.conf modify). The problem is disappeared.
Then:
On fc6 the nameserver must set, and must point to a existent nameserver. If nameserver is NOT set, or is set to a IP down or a generic host (not a nameserver) the xinetd connection (like telnet ) do not work.
It is therefore? Is this right?
Thanks to all
On Tue, 2007-02-27 at 01:49 +0100, Dario Lesca wrote:
On fc6 the nameserver must set, and must point to a existent nameserver.
Or, there must be a name server on the same machine:
man resolv.conf
"On a normally configured system this file should not be necessary. The only name server to be queried will be on the local machine; the domain name is determined from the host name and the domain search path is constructed from the domain name."
-
Dario Lesca -
kalinix -
Mikkel -
Tim