This discussion is archived
1 2 3 4 Previous Next 45 Replies Latest reply: May 8, 2013 8:31 AM by EdStevens Go to original post RSS
  • 15. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    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?
  • 16. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    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.
    [root@vblnxsrv02 ~]# cat /etc/hosts
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    [root@vblnxsrv02 ~]# date;hostname -f;date
    Thu May  2 14:00:17 CDT 2013
    hostname: Host name lookup failure
    Thu May  2 14:01:13 CDT 2013
    [root@vblnxsrv02 ~]#
    and after looking at the man page for 'hostname' also gave this a shot:
    [root@vblnxsrv02 ~]# date;dnsdomainname ;date
    Thu May  2 14:05:16 CDT 2013
    dnsdomainname: Host name lookup failure
    Thu May  2 14:06:12 CDT 2013
    Notice the time delay in both cases .. 56 seconds. About what I was seeing in the logon.

    One other variant, with instant response:
    [root@vblnxsrv02 ~]# date;hostname -v;date
    Thu May  2 14:14:16 CDT 2013
    gethostname()=`vblnxsrv02.vbdomain'
    vblnxsrv02.vbdomain
    Thu May  2 14:14:16 CDT 2013
    [root@vblnxsrv02 ~]#
    Edited by: EdStevens on May 2, 2013 2:15 PM
  • 17. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    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:

    127.0.0.1 vblnxsrv02.vbdomain vblnxsrv02 localhost.localdomain localhost
    ::1 localhost6.localdomain6 localhost6
    192.168.56.5 vblnxsrv02.vbdomain vblnxsrv02
  • 18. Re: logon issue with OL 6.3
    rukbat Guru Moderator
    Currently Being Moderated
    Ed,
    You seem to have sought additional perspectives on this from another forum web site:
    http://www.unix.com/red-hat/222789-ssh-logon-delay.html

    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.
  • 19. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    rukbat wrote:
    Ed,
    You seem to have sought additional perspectives on this from another forum web site:
    http://www.unix.com/red-hat/222789-ssh-logon-delay.html

    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.
  • 20. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Hmm.. what is the significance of this result of 'route -n' ... I followed it up with 'ifconfig' for reference.

    On the 'well behaved' OL 5.6 system:
    [root@vblnxsrv03 ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
    192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
    169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
    0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
    
    [root@vblnxsrv03 ~]# ifconfig -a
    eth0      Link encap:Ethernet  HWaddr 08:00:27:75:FB:5D
              inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:9 errors:0 dropped:0 overruns:0 frame:0
              TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:1522 (1.4 KiB)  TX bytes:3267 (3.1 KiB)
    
    eth1      Link encap:Ethernet  HWaddr 08:00:27:94:37:86
              inet addr:192.168.56.103  Bcast:192.168.56.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:755 errors:0 dropped:0 overruns:0 frame:0
              TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:71215 (69.5 KiB)  TX bytes:67183 (65.6 KiB)
    
    lo        Link encap:Local Loopback
              inet addr:127.0.0.1  Mask:255.0.0.0
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:34 errors:0 dropped:0 overruns:0 frame:0
              TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:5465 (5.3 KiB)  TX bytes:5465 (5.3 KiB)
    
    [root@vblnxsrv03 ~]#
    and on the ill-behaved OL 6.3
    [root@vblnxsrv02 ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.56.1    0.0.0.0         UG    0      0        0 eth1
    10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
    192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
    [root@vblnxsrv02 ~]# ifconfig -a
    eth0      Link encap:Ethernet  HWaddr 08:00:27:50:94:AB
              inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
              inet6 addr: fe80::a00:27ff:fe50:94ab/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:2 errors:0 dropped:0 overruns:0 frame:0
              TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:1180 (1.1 KiB)  TX bytes:1346 (1.3 KiB)
    
    eth1      Link encap:Ethernet  HWaddr 08:00:27:A2:45:04
              inet addr:192.168.56.102  Bcast:192.168.56.255  Mask:255.255.255.0
              inet6 addr: fe80::a00:27ff:fea2:4504/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:286 errors:0 dropped:0 overruns:0 frame:0
              TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:25648 (25.0 KiB)  TX bytes:49563 (48.4 KiB)
    
    lo        Link encap:Local Loopback
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:7 errors:0 dropped:0 overruns:0 frame:0
              TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:687 (687.0 b)  TX bytes:687 (687.0 b)
    
    [root@vblnxsrv02 ~]#
    And this contrast.
    From the 5.6
    [root@vblnxsrv03 ~]# netstat -r
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    10.0.2.0        *               255.255.255.0   U         0 0          0 eth0
    192.168.56.0    *               255.255.255.0   U         0 0          0 eth1
    169.254.0.0     *               255.255.0.0     U         0 0          0 eth1
    default         10.0.2.2        0.0.0.0         UG        0 0          0 eth0
    [root@vblnxsrv03 ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
    192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
    169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
    0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
    [root@vblnxsrv03 ~]#
    from the 6.3
    [root@vblnxsrv02 ~]# netstat -r
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    default         192.168.56.1    0.0.0.0         UG        0 0          0 eth1
    10.0.2.0        *               255.255.255.0   U         0 0          0 eth0
    link-local      *               255.255.0.0     U         0 0          0 eth0
    link-local      *               255.255.0.0     U         0 0          0 eth1
    192.168.56.0    *               255.255.255.0   U         0 0          0 eth1
    [root@vblnxsrv02 ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.56.1    0.0.0.0         UG    0      0        0 eth1
    10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
    192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
    [root@vblnxsrv02 ~]#
    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.
    Edited by: EdStevens on May 3, 2013 11:47 AM
  • 21. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    More follow-up.

    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.
  • 22. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    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.
  • 23. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    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.
  • 24. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    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:

    .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.
    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:
    Ethernet adapter VirtualBox Host-Only Network:
    
       Connection-specific DNS Suffix  . :
       Link-local IPv6 Address . . . . . : fe80::b4f9:a17a:f469:25a4%16
       IPv4 Address. . . . . . . . . . . : 192.168.56.1
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
    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.
  • 25. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Ok, I don't know what I did differently, but ..

    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 ...

    Edited by: EdStevens on May 6, 2013 3:29 PM
  • 26. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    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.
  • 27. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    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
  • 28. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    .... 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.
    I always thought it was enabled by default. I just installed VirtualBox in Windows Guest machine to check. It is indeed enabled by default:

    Server: 192.168.56.100
    lower bound: 192.168.56.101
    upper bound: 192.168.56.254

    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.
  • 29. Re: logon issue with OL 6.3
    AmitShil Newbie
    Currently Being Moderated
    How did you replicate this issue?

    I have just enabled UseDNS entry in the sshd config and did a restart of my VM and also ensure /etc/resolv.conf has unresolvable entries.. still my SSH works superfast!

    sorry, didn't mention VMs havaing OEL 5.6 .. did you replicate teh issue using a 5 variant or 6? i would have thought this should be prevalent irrespective of the OS.!

    Regards Amit

    Edited by: Amit Shil on 07-May-2013 02:55

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points