What you are seeing about the /etc/hosts file is standard under RHEL 5. The RHEL installation asks for a hostname, but does not know of any TCP/IP address and therefore puts the hostname on the 127.0.0.1 localhost line. This is normally not a problem, although not a common standard and could be RHEL specific.

Btw, the Oracle installer (runInstaller) reads the /etc/hosts file and takes the first entry in the 127.0.0.1 line as the hostname. The hostname becomes part of the directory location for the Oracle dbconsole installation. When people are modifying the /etc/hosts file and remove the hostname from the first position of the 127.0.0.1 line then dbconsole will fail since the directory path does not contain "localhost". The way around it is to set the ORACLE_HOSTNAME variable prior to installing the database. People sometimes reinstall the dbconsole when it fails, but a simple symbolic link would fix the problem.

I don't see anything unusual in your /etc/hosts file. Perhaps you can check if the output of the command "hostname -f" corresponds to your hostname entry in the /etc/hosts file. Can you also check the /etc/ssh/sshd_config file to see the useDNS setting?

Dude wrote:
What you are seeing about the /etc/hosts file is standard under RHEL 5. The RHEL installation asks for a hostname, but does not know of any TCP/IP address and therefore puts the hostname on the 127.0.0.1 localhost line. This is normally not a problem, although not a common standard and could be RHEL specific.

Btw, the Oracle installer (runInstaller) reads the /etc/hosts file and takes the first entry in the 127.0.0.1 line as the hostname. The hostname becomes part of the directory location for the Oracle dbconsole installation. When people are modifying the /etc/hosts file and remove the hostname from the first position of the 127.0.0.1 line then dbconsole will fail since the directory path does not contain "localhost". The way around it is to set the ORACLE_HOSTNAME variable prior to installing the database. People sometimes reinstall the dbconsole when it fails, but a simple symbolic link would fix the problem.

I'd often notice, based on the directory naming of the dbcontrol configuration, that there was some interaction with the hosts file, but had never taken the time to dig into it.

I don't see anything unusual in your /etc/hosts file. Perhaps you can check if the output of the command "hostname -f" corresponds to your hostname entry in the /etc/hosts file. Can you also check the /etc/ssh/sshd_config file to see the useDNS setting?

Very interesting. Before every new test, I restore the vm back to the snapshot taken immediately upon completion of the OS install. That way I'm always working with a know baseline. On this test there was along delay in processing the 'hostname' command. I stacked it with a couple of 'date' commands to show the exact timing involved.

Your delay is most likely caused by an invalid entry or unreachable nameserver TCP/IP address in /etc/resolv.conf.

The nameserver TCP/IP address in /etc/resolv.conf is normally your Router/Gateway address, or DNS nameserver if you have one. You can also use some of the public nameserver's if you have Internet, such as 8.8.8.8.

See if this fixes your hostname -f or dnsdomainname delay.

If the commands return "unknown host" make an additional entry in your /etc/hosts file corresponding to the TCP/IP address of your system for reverse name lookup, e.g:

You linked this thread into there, but perhaps you might have thought to mention that one with a link to it into this thread here.

:)

I've taken care of that for you.

You are correct. I wasn't trying to hide anything from anyone here. I just opened that one yesterday, thinking that since it was a totally different forum environment I might get some fresh eyes to look at the issue.

Also, while staring at the difference in /etc/resolv.conf, I noticed the first, commented line:

; generated by /sbin/dhclient-script

So I decided to see what that script does. It was way over my head, but what I immediately noticed was that the 5.6 version is quite a bit different from the 6.3 version. I fact, the 5.6 version was a bit troubling, with this line in the header contents:

# Updated for Linux 2.[12] by Brian J. Murrell, January 1999.
# No guarantees about this. I'm a novice at the details of Linux
# networking.

On advice from the thread I have at [url http://www.unix.com/red-hat/222789-ssh-logon-delay.html#post302802531]The Unix and Linux Forums I tried two things.

First, I commented out the entire contents of /etc/resolv.conf. That made for an immediate (no restart required) fix, but of course is not persistent since that file gets regenerated at least at ever boot up. But following up from that, I replaced the contents with those from one of my OL5.6 machines. With those settings, the 6.3 was back to the 56-second delay. Very odd.

Second, I modified /etc/ssh/sshd_config, changing

#UseDNS yes

to

UseDNS no

That did not provide an immediate fix, but after reboot, (and subsequent resetting of resolv.conf back to its original values) did fix the problem.

So, at this point I have a workable solution, but you know me - I want to know why. I don't like "here, do this - it works". I want to learn something from it. Particularly why it would be different on the 6.3. Since no one seems to be having this issue it must be something I'm doing, but I'm at a loss as to what it would be. I'm thinking the answer lies in the result of the 'route' command I posted earlier, but I don't know enough to understand just what it would be.

You DNS delay is very likely the result of a DNS query timeout. This is usually the case if the DNS server is not working properly or not responding.

Have you seen my previous response?

Fixing your /etc/hosts file should fix your "Host name lookup" or Unknown host" failure. It will not fix a DNS issue, but it will fix the DNS timeout when querying the local machine.

I was actually successful to reproduce you DNS delay, but I have not been able to reproduce any ssh login delay regardless of the useDNS setting.

I wonder about the follwowing:

Are you using the VirtualBox host-only adpater with a fixed TCP/IP address and NAT (dhcp) for outgoing connections? I suggest you check the host-only adapter (vboxnet0) network setting in the VirtualBox application preferences.

TCP/IP addresses 192.168.56.100 - 254 in VirtualBox are by default reserved for host-only DHCP. If you configured 192.168.56.103 as a static address you can cause an internal VirtualBox routing issue and a TCP/IP address conflict. I suggest to set the TCP/IP address of the host-only adapter between 192.168.56.100 1 - 99.

I was finally able to reproduce the SSH login delay. So by default, the SSH server, unlike I assumed, does indeed perform a reverse DNS lookup. The delay for every invalid or unreachable DNS nameserver in my setup is however only 10 seconds, and there is actually no delay for any unresolved IP as such, which is why I did not notice the problem.

Your 55 seconds delay can perhaps be explained by your DNS server configuration. Setting the useDNS no parameter should resolve you SSH login delay, but will not fix your DNS nameserver configuration.

It is generally a good idea to use any of the reserved domain names for your internal network, like:

.test
.example
.invalid
.localhost

(http://tools.ietf.org/html/rfc2606)

The use of .vboxdomain might be related to your problem.

Any you might still want to check you are using fixed IP numbers according to range defined in your VirtualBox virtual host adapter (DHCP) to avoid TCP/IP conflicts and routing issues.

Dude wrote:
I was finally able to reproduce the SSH login delay. So by default, the SSH server, unlike I assumed, does indeed perform a reverse DNS lookup. The delay for every invalid or unreachable DNS nameserver in my setup is however only 10 seconds, and there is actually no delay for any unresolved IP as such, which is why I did not notice the problem.

Your 55 seconds delay can perhaps be explained by your DNS server configuration. Setting the useDNS no parameter should resolve you SSH login delay, but will not fix your DNS nameserver configuration.

It is generally a good idea to use any of the reserved domain names for your internal network, like:

Any you might still want to check you are using fixed IP numbers according to range defined in your VirtualBox virtual host adapter (DHCP) to avoid TCP/IP conflicts and routing issues.

I reassigned the fixed ip address on eth1 (hostonly) to 192.168.56.5 then restarted the machine. No change in behavior.
FWIW, I couldn't find any reference in the VBox docs about reserving a range of addresses for host-only dhcp. Would that even matter, since I am not configuring the host-only adapter (eth1) for dhcp?

Keep in mind that any solution is going to lead to the question "why wasn't that an issue with my OL 5.x machines?" And ideally whatever solution is found - if it is necessarily different from what has been my past practice, will be back-compatible to the 5.x machines.

Just as a quick recap of my configuration ..
VBox adpter on the host os:

On all of my vm's (OL 5.x and this OL 6.3),
-- NIC 1 is NAT, goes to eth0, dhcp.
-- NIC 2 is host-only, goes to eth1, is assigned ip address 192.168.56.10n or 192.168.56.20n, where 'n' is simply the one-digit sequence to differentiate.
-- I have always used 'vbdomain' as the default domain for machines running under vbox, 'vmdomain' for machines running under VMworkstation. (I don't use VMware any more, but have retained my naming conventions that made the distinction).

Back on the 'what is different' front, when I create a 5.x machine, nothing in the setup asks me about a dns server. On the 6.3 setup, it asks and I've given it variously nothing, 192.168.56.1, and 192.168.56.2. All really just shots in the dark, as I don't know what I'm doing with that. the ".2" address was a hold-over from VMware, where I found that their adapter apparently ran a dns server at that address (if vmnet8 was at, say 192.168.2.1, dns was at 192.168.2.2). Under VMware, if I didn't get the dns address right, I coulnd't log on at all. With Vbox, it doesn't seem to matter.

One of my 'guiding principles' is that my vm's should be invisible to the outside world -- especially any net administrators. So I was really surprised to see config files that it had somehow found my company's dns servers and configured with their ip addresses.

I just rebuilt the vm from scratch, meticulously documenting every step. First putty session after reboot, and password prompt and following connection were nearly instantaneous. Now I've got to go back and compare all the current config files to what I've previously posted ..

------------

Thought I was on to something with having NOT provided a DNS address at all during setup. Then when comparing notes I noticed the eth0 was configured ONBOOT="no", and as a result, ifconfig showed eth0 wasn't even started. Fixed that, rebooted, and back to the drawing board ...

The host-only network adapter is configured in the VirtualBox application settings, not the VM settings. You will find it under "Network". There you can add additional virtual adapters and configure DHCP fixed and automatic IP ranges.

Dude wrote:
The host-only network adapter is configured in the VirtualBox application settings, not the VM settings. You will find it under "Network". There you can add additional virtual adapters and configure DHCP fixed and automatic IP ranges.

Yes, the 'hostonly' (likewise NAT) is configured at the VBox console. Double-checking the general (not specific to a given vm) network settings, there is a single host-only net adapter listed, it is at 192.168.56.1, and DHCP server is NOT enabled for it. All that is default. I've never touched it.

The mac address that the vbox manager shows for the NAT adapter matches eth0, which is configured dhcp.
The mac address that the vbox manager shows for the hostonly adapter matches eth1, which is configured with the fixed ip address 192.168.56.102

If you have it disabled than no problem with your IP address range, otherwise you may run into a problem when configuring a static IP and have any other machine trying to use the same address as a DHCP address.