DA interface gone

TeraSoft

Verified User
Joined
Mar 21, 2007
Messages
31
I got DA yesterday.
For POP3 and Imap to work I had to convert to dovecot.
Then I upgraded Apache to 2.0.59 and then again to 2.2.4.
All works perfect

Then I updated PHP to 5.2.1 Using: http://www.directadmin.com/forum/sho...ght=update+php
Got the libxml error but fixed it by using the posted yum.
Edit: Zend was installed and Frontpage was uncommented in httpd.conf

I restarted httpd and then this:
http://**.*.***.***:2222/ (Solved so censured my IP)

Then Interface dont respond anymore.
I tried to restart httpd again and also rebooted.

I don't know what to do.

The htttpd works fine: http://playr.dk
So do the ftp, webmail. phpmyadmin etc.
 
Last edited:
Since DA does not run on httpd then restarting httpd is not going to help. Try restarting DA and then note any errors you can find anywhere.
 
I did not say anything about rebooting the server. I said
Try restarting DA
Often when you try to start a service and there is a problem an error will be reported there on the command line.

You can also check the messages log and DA's log.
 
thx for helping me Floyd :)

The system.log says:
2007:03:21-23:49:02: directadmin restarted
2007:03:22-00:10:02: Tally All Begin
2007:03:22-00:10:02: Tally Reseller playr Begin
2007:03:22-00:10:02: Tally User playr Begin
2007:03:22-00:10:02: Tally User playr Complete
2007:03:22-00:10:02: Tally Reseller playr Complete
2007:03:22-00:10:02: Tally Reseller admin Begin
2007:03:22-00:10:02: Tally User admin Begin
2007:03:22-00:10:02: Tally User admin Complete
2007:03:22-00:10:02: Tally Reseller admin Complete
2007:03:22-00:10:02: Tally All Complete
2007:03:22-00:11:02: httpd restarted
2007:03:22-02:40:32: signal TERM received. Waiting for children to exit
2007:03:22-13:54:58: signal TERM received. Waiting for children to exit
2007:03:22-13:54:58: Clean shutdown successful

error.log:
2007:03:22-09:04:16: Timeout from from 127.0.0.1 : last flagged: Request::readAndProcess(*skt, 127.0.0.1, 127.0.0.1)

[root@server1 directadmin]# service directadmin restart
Stopping DirectAdmin: [ OK ]
Starting DirectAdmin: [ OK ]
[root@server1 directadmin]#

Still no response :(

I dont know if this tell you anything:
[root@server1 directadmin]# telnet localhost 2222
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
*****
<table width=100% height=100% cellspacing=0 cellpadding=5>
<tr>
<td valign="middle" align="center">
<p align="center">Your connection has timed out</p>
</td>
</tr>
<tr>
<td height=1 valign="middle" align="center">
<table width = 50%>
<tr><td bgcolor="#C0C0C0"> </td></tr>
</table>
</td>
</tr>
<tr>
<td valign="top" align="center">
<p align="center"><b>Details</b></p>
<p align="center">Either your request was invalid or the program hasn't completed your request.<br>
Please notify the server admin</p>
</td>
</tr>
</table>
*****

So it seems like DA is running but it times out, some where.

I am clueless
 
Last edited:
And the firewall could be on the server or on your own pc. But probably the server since I cannot connect to it either.
 
Thanks to both of you, I guess I should have tried that, but I just didn't think about it at all :D

iptable where blocking 2222 on the server.

Thanks again :)
 
You might want to look at either KISS or APF+BFD, both discussed on these forums, for controlling iptables; they're both optimized for hosting servers, and the versions pointed to herein have generally been optimized for ports you need open for DA.

Jeff
 
Thanks :D

I was aiming for KISS.
There is just so many neat things to discover :)

Thanks again.
 
Overnight we ran into an interresting issue that caused a new server which allowed DA access on port 2222, to not allow it after the cron.daily ran.

We discovered that the company who built (and rents out) the dedicated server, installs the BFD firewall through a script in /etc/rc.d/init.d.

When we configured the server for DA we made sure APF was stopped, and we made sure the output of chkconfig --list apf showed that apf was turned off.

But we didn't notice there was a script that restarted apf in cron.daily, and it restarted it whether or not it was on when the script ran.

We've now disabled the script in cron.daily. We don't see any good reason to run a script in cron.daily to restart the firewall every night. The danger is that you'll have added some manual changes to iptables, and if so they'd all disappear when the firewall is restarted.

Just another place to have to look if port 2222 worked but then stops working.

:(

Jeff
 
Back
Top