Problems installing DirectAdmin

R

roarkh

Verified User
Joined
Aug 30, 2005
Messages
141
Location
Bellingham, WA
I am attempting to install DirectAdmin on a new Centos 6.0 64-bit server, it makes it through searching for the fastest mirror and then this is happening (the last thing it says before the problem starts is "/usr/sbin/setenforce: SELinux is disabled)".
Code: 
--2011-09-15 09:00:14--  (try: 6)  https://www.directadmin.com/cgi-bin/daupdate?uid=xxxx&lid=xxxx
Connecting to www.directadmin.com|66.51.122.131|:443... failed: Connection timed out. Retrying.
I obfuscated my client and license id's above but I double checked and they were entered correctly. I let it try 10 times before giving up and stopping the installer. I ran the installer again just to make sure and the same thing happened. Does anyone know what I need to do to resolve this issue?
 
Do you have a firewall running or is iptables active?
It's a connection timeout, the directadmin domain is being resolved so I'm thinking a firewall is blocking access.
Could also be that the iptables output policy is set to closed.
You can check this in a root shell with this command:
iptables -L
 
Richard G said:
Do you have a firewall running or is iptables active?
It's a connection timeout, the directadmin domain is being resolved so I'm thinking a firewall is blocking access.
Could also be that the iptables output policy is set to closed.
You can check this in a root shell with this command:
iptables -L
Click to expand...
I did consider the possibility it was a firewall causing the problem so earlier today I installed the system-config-firewall-tui utility, ran it and made sure the "enabled" checkbox was not checked (I thought that would disable the firewall), then I rebooted the server and tried again with the same results. However, iptables is still running so perhaps disabling the firewall with that utility is not enough. Tomorrow morning I will stop iptables entirely and try again. Thanks for your recommendation.
 
You're welcome.

Maybe you can try these commands (as root):
iptables --flush
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

to temporarily disable the firewall to be able to install Directadmin.

And after installing DA you could consider to install csf/lfd (configserver) firewall which has a DA plugin which can be added during installation of csf.
 
I went ahead and completely disabled iptables and am still having the same problem, DirectAdmin support said to see if I can download files from a different server using https so I fired up Lynx, visited a secure site we have hosted on another DirectAdmin server here and was able to view the site and download files with no problem.

I also just tried another site as well at https://www.fortify.net/download.html and was able to download a file (Fortify-1.4.6-unix-x86.tar.gz) from their download page using Lynx as well so it does not seem that our ISP is blocking downloads on port 443.

This is getting quite frustrating. Any other ideas what might be going on? I have installed DirectAdmin on another server here in the past using the same ISP and Network Configuration (just with a different ip addresses).
 
Problem Solved

Well, it looks like I have found the problem and I just finished getting DirectAdmin installed.

When I set up this machine I installed two nics in it, eth0 and eth1. I gave eth0 my main ip address (the one that DirectAdmin is licensed to). I also set up an eth0:0 and an eth0:1 with two other addresses provided from our ISP. Also, I had added a 2nd nic and given it an internal class ip address hoping that I would be able to ftp backups to a computer that was on the other side of our firewall without needing to use a port forward.

I removed the aliases to eth0 and disabled the 2nd NIC with the internal address and the install worked without a hitch. I have a feeling it was probably eth1 with a 192.168.0.x ip address that was somehow causing the problem.

Now that it is installed I may try activating that 2nd NIC again to see what happens, but if I can't have that at all it would not be the end of the world.

Thanks everyone for your input.
 
I wish we had known that about all those nics before, then we would have known that also could be an option.
You can check by enabling them one by one again.
My guess is that when certain nics are enabled, the gateway and routing is not correct anymore so the system is not knowing anymore where to send the outgoing data to.
This would explain the timeout every time.

So if you enable the nics again, check the routing table and the gateway if everything goes the correct way outside.
 
You must log in or register to reply here.
Back
Top