You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

My apologies if this ends up being a book. I'm having an issue on two Fedora Core 13 machines where I can ping others by hostname, but the hostname resolution fails whenever I use ssh/scp/vnc/etc. I can still do these things by IP address, just not by hostname. RHEL5.3 machines on the same network with the same configuration do not seem to have this problem.

Here's the not-so-quick-and-dirty description of the situation:

Physical machines are on 192.168.30.0
Virtual machines are on 192.168.31.0

I know that there is a virtual router at 192.168.31.1 and another at 192.168.30.1. I also know that there is another network (let's call it 90.90.90.0) and on that network lies a number of resources. By nature of this configuration, any machine on 90.90.90.0 can be accessed by any 192.168.x.x, but not the other way around. Beyond that is out of my hands and currently out of my scope of knowledge.

I have a dnsmasq server on 90.90.90.10 that operates as a secondary nameserver, another machine out of my sphere of influence is the primary nameserver (90.90.90.31).

The secondary nameserver on 90.90.90.10 holds the hostnames of our development machines. The problem is that in some cases, while I can ping by hostname all day long, services such as ssh, scp, vncviewer, etc all fail to resolve the hostname. In other cases I can do all of these things.

Every machine has an equivalent resolv.conf:

> cat /etc/resolv.conf
nameserver 90.90.90.31
nameserver 90.90.90.10

As an example, I will show the output of a handful of my development machines:

Additionally, the SERVFAIL reply from 90.90.90.31 is expected since my dnsmasq server is on the secondary server.

Note that the only machine that can both ping and ssh/scp/etc by hostname is nibbler, which also happens to be the only one of the three running RHEL5.3 instead of FC13. Other virtual and physical machines running on the 192.168.31.0 and 192.168.30.0 networks (all running RHEL5.3) work just like nibbler does. So the problem seems to only affect machines running FC13.
-----------------------------------------------------------------

atlantis> ssh discovery
ssh: Could not resolve hostname discovery: Name or service not knownatlantis> ssh columbia
ssh: Could not resolve hostname columbia: Name or service not knownatlantis> ssh nibbler
ssh: Could not resolve hostname nibbler: Name or service not known

No clues in ssh -vvv, just the standard hostname error. BUT -- commenting out 90.90.90.31 did the trick! All of a sudden I could ssh to anything from anywhere. Also, switching the order works just as well, putting 90.90.90.10 first in resolv.conf.

So now I know the cause of the problem and I have a workaround.

But let me ask you this: Is there anything you can think of that may be causing this difference in behavior between RHEL5.3 and FC13? The RHEL 5.3 installs don't seem to care what order these nameservers are listed in. And if there is something specific causing it, is there anything I can do about it (besides the obvious, of course )

I'm really not sure why you're seeing the difference in behavior, especially since RHEL and FC are like family. I'd guess it's either a difference in ssh configs, or a difference in ssh version. You could try diff'ing the configs, and/or upgrading ssh.

Regardless of your local problem tho, there is obviously a problem with 90.90.90.31 too. If this is the primary server for your domain, then it should not be SERVFAIL'ing. I think your best bet would be to contact the owner of this box and just have him fix his stuff. That would solve your problem and you wouldn't even need the workaround. And who knows, maybe this DNS server is SERVFAIL'ing your entire domain and noboby knows it because end clients are gracefully using their secondary DNS (unlike your FC13 box).

Hi,
This is my first post in LQ. This discussion helped me lot.
I am having this problem for long. Now it sorted out after editing
the /etc/resolv.conf . I can access remote mechine by hostname over ssh.
It works fine Fedora 16.
Thanks ..