Hi FreeBSD users,
Do NOT restart Bind !
I just restarted the Bind, everything was broken!!!
I know nightly upcp was trying to upgrade Bind 9.2.3 to 9.3.
Now, I can't SSH!!!
This is VERY VERY BAD.
PS: This box was doing VERY well.
Thanks.
Hi FreeBSD users,
Do NOT restart Bind !
I just restarted the Bind, everything was broken!!!
I know nightly upcp was trying to upgrade Bind 9.2.3 to 9.3.
Now, I can't SSH!!!
This is VERY VERY BAD.
PS: This box was doing VERY well.
Thanks.
Last edited by eos1; 10-12-2004 at 07:06 PM.
Reboot, upcp to Current version fixed it.
I've also been auto-upgraded to bind 9.3 and found that i suddenly get this problem when editing DNS records:
Bind reloading on cpanelhostxxx using rndc zone: [xxxxx.co.nz]
Error reloading bind on cpanelhostxxx: zone reload queued
This error message doesn't appear to effect the opperation of bind as it reloads normally but the error message i could see raising some questions from my resellers.
On a more important note i am finding that when the server boots it starts bind using /etc/namedb/named.conf, after adding an account bind is reloaded using /etc/named.conf. Both configuration files are identical in their structure however bind using "/etc/named.conf" doesn't seem to work and i have to restart bind from WHM before it acknowledges the hosting of the domain.
In the past i've simply removed the /etc/named.conf file and symlinked the other file to that location but that was for a different problem and i'm not sure it will cure the fault. I'm sure that the cpanel developers will make some changes to accomodate bind 9.3 but in the meantime is anyone else having this problem? I'm running WHM 9.7.2 cPanel 9.7.7-R16
FreeBSD 5.2.1-RELEASE i386
I found out that nightly upcp broke /var/named/domain.com.db.
I just manually corrected now...
What's going on, Nick?
This is really too much problems about Bind and Exim.
Looks like this time, nightly upcp was trying to upgrade the Bind.
some of them got upgraded, however it broke /var/named/domain.com.db.
Boxes that didn't upgrade ---> check what's the bind in your system...if there is no bind 9.X ---> this will be the problem that I just got. (you can't even SSH).
"Can't SSH" was already happened to 2 FreeBSD machines!
One of them got totally destroyed including Kernel. This happened by only "upcp". Adam(cPanel) is looking into it, but I have no idea if he can fix...
This is CRITICAL problem.
IMPORTANT
Check your Bind version at WHM: Service Status.
If you see "bind ()", do NOT restart the Bind!!!
do upcp first!
or else, you'll be like me...![]()
If you see "bind (9.3.0)", then try restart the Bind. and check any errors.
Just a note...
PS: These days, I'm a chicken to reboot or restart services...![]()
Last edited by eos1; 09-27-2004 at 10:02 PM.
Yes, this has been going on for awhile now.Originally Posted by tprice42
Even running Bind 8 the zones are dropped into /etc/namedb/named.conf
In the named.conf file, you will see the path to the db file has changed from
/var/named to /etc/namedb. To fix this so the path to the zones in /var/named can
still be reached we symlinked the named.conf
copy your named.conf to /etc/namedb
remove the named.conf from /etc and
to symlink, run
ln -s /etc/namedb/named.conf /etc/named.conf
However, restarting Bind from WHM still creates a error and there is nothing in the logs
to help trouble shoot why Bind fails. A reboot will be needed. Adding and removing domains
is no longer a issue with the symlink.
Hope this helps some![]()
Last edited by easyhoster1; 09-28-2004 at 05:12 AM.
I have this problem also. When is this going to get fixed??????
was:
NOW:Added Entries to httpd.conf (noip)
Bind reloading on HOST using rndc
Added Named File
Restarting apache
My reseller thought there is something wrong with rndc...it's confusing...Added Entries to httpd.conf (ip)
Adding Proftpd conf entry
Bind reloading on HOST using rndc
Error reloading bind on HOST: server reload successful
Added Named File
Restarting apache
There is indeed a problem with rndc as far as I can tell, please excuse me if I'm totally offbase as this isn't my forte, I tried various bind restart procedures and eventually got an error stating ndc couldn't be found, looking at ndc it's a link to rndc, and rndc in turn is quite simply missing, that can't be right can it? In any event I'm stuck with DNS down and am indeed showing Bind() in service status, what's the definite fix (even if just for temporary results) here? I'm about to try upcp again and see if that makes a difference...
Addendum: it did make a difference, bind is now showing 9.3.0 and starting normally again. The missing rndc file is now present and accounted for, so I'm guessing there's a definite link of some sort there. Someone seriously needs to be shot for this tho :P.
Last edited by Hantai; 10-08-2004 at 10:10 AM.
Adam fixed it yesterday!!!Originally Posted by eos1
![]()
Problems were my customer's scripts and .htaccess setup. I couldn't believe how easy to destroy cPanel...
Thanks soooooooo much, Adam.
[FreeBSD] upcp to 9.9.1-EDGE_9 messed EXIM AGAIN.
downgrading to 9.9.1-CURRENT_5 fixed it.
Just a note...
Keep in mind that by definition Edge builds have a strong potential to mess things out, stick to Current or better for production servers unless you have a desperate need for something present only in an edge build.
Originally Posted by eos1
Had the exact same error. Tried to downgrade to from Current to Release version did not fix it. We found that the /usr/local/lib/libcrypto.so.3 file was missing. We had to copy it over from another machine and this fixed the Exim problem.
Hi all,
One of box running exim (4.42+27), just now, exim was dead.
running /scripts/exim4 fixed.
exim (4.42+27) ---> exim-4.43+28
Looks like related with spamd...
PS: Others running exim (4.42+27) are OK so far, but might need to upgrade exim...
Problem here is:
-You don't receive any alerts.
-cpsrvd failed to report that exim was not working.
To find this issue:
-Your customers might be missed... <--- I got this one![]()
-restarting exim
Just a note for FreeBSD users.
Thanks.
Ca$h
Last edited by eos1; 10-12-2004 at 07:19 PM.
Another Box's Exim failed...after nightly upcp.
Just a note...