I have sent a request mail to tera-byte.

But before they can help me, I need you Cobalt gurus's idea.

I found there was a RED sign right before DNS service
from CP System Status. So, I tried to stop DNS Service and start it again from CP, but failed.

What can I do to start it again? Please give me a dirction or step-by-step guide if possible.

Thanks a lot

Prob. wont help but sometimes restarting the whole server helps

Reboot done.

DNS doesn't work as the same.

Although I haven't gotten a red light for DNS problems, whenever I get a red CP light for other reasons the server sends an e-mail to the admin e-mail address with information on the problem. Have you checked your admin e-mail lately?

Yes I got two e-mails:

the first one:

subject:Cron <root@www> /usr/sbin/init (To: root)
content:bind: Address already in use

the second one:

subject:the DNS server is not responding
content:The DNS server appears to be down. Within the Cobalt server Control Panel,
try turning the service off and then on again to see if this corrects the
problem. If not, try rebooting the server itself. If this still does not
correct the problem, contact Cobalt Technical Support.



What does the first e-mail mean ?

At your own risk, try this:

1) Telnet into your box, switch to root (type su then your password)
2) Type: cp /etc/inetd.conf /etc/inetd.conf.backup
3) Type: cp /etc/inetd.conf.master /etc/inetd.conf
4) Restart the server.

Good luck.

raylin I received the same emails yesterday evening

sit the instructions from intelligenthosting work ?

CF

IntelligentHosting.com,

Thanks a lot.

CF,

I am a little hesitate to do that because I am not familiar with linux O.S. ... :(

I have the exact same problem !

(tera-byte raq3).

Yesterday after i updated the OS, everything worked fine.
Did you updated something before the problem occured ?


Someone HEELP !

I rebooted the server because the email, and ftp were not working ... I did this after the emails came in

the dns went down as soon as I did the reboot

Tera-Byte has a solution I believe

I could not find any trace on the server that this is the BIND exploit .. but then I am a newbie at this so I could very easily miss something

CF

Greetings,

This message has been automatically generated in response to your
message regarding "Emergency!! DNS Failed , Please help me.", the content of which appears below. There is
no need to reply to it now. The Support group has received your message and
it has been assigned a ticket ID of [queue #92451]. Please
include the string

[queue #92451]

in the subject line of all future correspondence about this
problem. To do so, you may reply to this message.


Thank you,

Tera-Byte Network Operations Centre
support@tera-byte.com


-------------------------------------------- Managed by Request Tracker


No response for nearly 12 hours. I can't believe it. :(
(Don't you think is a URGENT request?)

I have called my clients to change DNS setting to tera-byte's Name Servers.

Originally posted by raylin
IntelligentHosting.com,

Thanks a lot.

CF,

I am a little hesitate to do that because I am not familiar with linux O.S. ... :(

As far as modifying things is concerned, this is pretty safe. Step #2 makes a backup copy of the inetd.conf file (which *might* be what's causing the error message); step #3 replaces the old file with a "fresh" one. If you change your mind and want to replace the original file, you can issue this command:
cp /etc/inetd.conf.backup /etc/inetd.conf

IntelligentHosting.com,

I compared the difference between inetd.conf and inetd.conf.master.


[admin /etc]$ diff inetd.conf inetd.conf.master
40,41c40,41
< #shell stream tcp nowait root /usr/sbin/tcpd in.rshd
< #login stream tcp nowait root /usr/sbin/tcpd in.rlogind
---
> shell stream tcp nowait root /usr/sbin/tcpd in.rshd
> login stream tcp nowait root /usr/sbin/tcpd in.rlogind
44,45c44,45
< #talk dgram udp wait root /usr/sbin/tcpd in.talkd
< #ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
---
> talk dgram udp wait root /usr/sbin/tcpd in.talkd
> ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
51,52c51,52
< pop-3 stream tcp nowait root /usr/sbin/tcpd in.qpopper -R
< imap stream tcp nowait root /usr/sbin/tcpd imapd
---
> #pop-3 stream tcp nowait root /usr/sbin/tcpd in.qpopper -R
> #imap stream tcp nowait root /usr/sbin/tcpd imapd
69c69
< #finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
---
> finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
76c76
< #auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -
e -o
---
> auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e
-o
80,81c80
< #gds_db stream tcp nowait.30000 root /usr/local/sbin/gds_inet_serve
r gds_inet_server # InterBase Database Remote Server
< smbd2 stream tcp nowait root /usr/sbin/in.smb in.smb
---
> gds_db stream tcp nowait.30000 root /usr/local/sbin/gds_inet_server
gds_inet_server # InterBase Database Remote Server
[admin /etc]$


From the comparing result, I am afraid that some services the server provides now will not be provided after I restart the server. Am I correct?