getting error installing oracle 11gR2: cannot access node I'm installing Oracle 11.2 on dedicated hosted server (centOS 5.5). I've gone through the Oracle Quick Installation guide diligently. I believe I've set everything up correctly, although I'm not a DBA and this is my first time doing such a thing. I'm at the point where I've started the Oracle Installer, and made it step 8 of 11, which is the Prerequisite Checks for "typical" install. I'm getting many errors here, they all point to the same thing (e.g. can't access node). Here's the first error, which is for physical memory:

Physical Memory - This is a prerequisite condition to test whether the system has at least 1GB (1048576.0KB) of total physical memory.

Expected Value

 : n/a

Actual Value

 : n/a

 List of errors: 

 - PRVF-7531 : Physical memory check cannot be performed on node "host2"  - Cause:  Could not perform check of physical memory on the node indicated.  - Action:  Ensure ability to access the node specified and view memory information.

My hosted server has address of www.host2.domainname.com. 

UPDATE1: I've observed that the oracle user cannot ping its own server:

oracle@host2 [~]# ping host2
ping: icmp open socket: Operation not permitted


The root user can ping host2.

Is there some way I can change permissions/etc. to enable oracle user to ping the server? (I'm assuming this is a sympton of the problem, but let me know if I'm on the wrong track here).

UPDATE2: (is anyone reading this?) I've learned that to make the oracle user able to ping, I can adjust the permissions of the /bin/ping file from

-rwxr-xr-x, to
-rwsr-xr-x

However, there are various places that strongly warn against doing this, such as:

http://forums.cpanel.net/f5/ping-icmp-open-socket-operation-not-permitted-14173.html
[http://nixshell.wordpress.com/2007/04/21/suid-shell-scripts-setting-the-sticky-bit/][1]

I haven't changed this permission, not sure if this is the right approach. I'm thinking that the oracle installation instructions are very detailed, and if this was needed, it would be documented to do so. Any oracle experts out there that can offer any advice?

UPDATE 3: I suspect the "server hardening" performed by the hosting company upon provisioning the server has had some effect on the Oracle database installation process, resulting in this error. I implemented chmod 4755 /bin/ping, as well as chmod 4755 /bin/ping6 (logged in as root). I verified that the oracle user can successfully ping host2 now. Then, I ran the Oracle universal installer. The same thing happened -- all of the pre-requisite checks fail (every one of them for the same reason stated above, cannot connect to node: host2). In desperation, I selected "Ignore All" checkbox, and continued the installation. Hey, the install completed successfully! The database runs OK from an initial check. 

I have no idea if changing permissions on the ping and ping6 files were necessary or useful here (e.g. I didn't try to complete the install before changing their permissions, so I don't know if this was actually needed; of course I'm reluctant to revert them back in case things break). Are there any experienced Oracle users that can comment/advise on whether I need the /bin/ping file to be -rwsr-xr-x, or can I change back to -rwxr-xr-x?

Also, the list of server hardening is here:

http://www.liquidweb.com/services/serversecure-linux.html

I'd be interested if anyone has an opinion if any of these hardening rules will impact the use of Oracle database. So far, I've found a workaround for limited permissions for the /tmp directory, which allowed me to complete the installation (but doesn't exist thereafter). Does Oracle db need /tmp directory thereafter? etc.
It looks like the hardening was a little to hard. Oracle does need some access to the server. You can revert back the chmods for ping, Oracle rdbms does not need it. /tmp/ is not required, a usable location for tmp is, mostly for scripting. The rdbms has it's own tricks and storage for sorts.

Never install Oracle as root; use the root.sh at the end of the installation to do the system tweeks required. On some platforms there is a root pre script that should run before installation. The Oracle installation scripts refuse to run using the root account and can be run using any other account.

The access to some server config files has been made a little too tight for the install user to check the prerequisites. If you know they are ok, it's ok. Proving they are ok is a little easier when support issues arise. Check the group ownership of the critical config files and add the Oracle installation user to that group to give it read access.