upcp breaking named?

[Brian_Wilson]

ERROR: RHN Proxy could not successfully connect to the RHN Satellite/server.

up, so I tried updating with the suggestions listed in this thread and got:

ERROR: RHN Proxy could not successfully connect to the RHN Satellite/server.

My resolve.confg is already set to use the planets name servers.


Anyone have any suggestions?

 

[Arvand]

Brian. That is the pain with planet servers. Their RHN satellites break all the time or half of my servers can't connect to them. I have a ticket open with them to fix that issue so I can fix my named issue. Id suggest you open a ticket with them.

 

[rpmws]

http://216.127.74.88/files/bind-libs-9.2.4-14_EL3.i386.rpm

use that RPM .. thanks to John on the EV1 forums

 

[chirpy]

Brian. That is the pain with planet servers. Their RHN satellites break all the time or half of my servers can't connect to them. I have a ticket open with them to fix that issue so I can fix my named issue. Id suggest you open a ticket with them.

I have the saem on my TP servers. It seems that they are simply overloaded at 04:00 SM/TP local time. If you wait an hour or so they usually start working again. It's been happening for well over a year there.

 

[vannaco]

I got the same issue, someone at TP is looking yet has to find the solution. The RPM was installed but no luck with restarting named.

 

[Brian_Wilson]

I have the saem on my TP servers. It seems that they are simply overloaded at 04:00 SM/TP local time. If you wait an hour or so they usually start working again. It's been happening for well over a year there.

I just checked the redhat network and the server I'm having a problem with hasn't even checked in with redhat since 2006-01-10 04:28:07 EST

Weird it's not been a problem before now, especially when my other server is configured identically to the one that is having a problem. And the other server is working just fine.

Oh well, I guess I'll jsut wait for theplanet to respond to the trouble ticket.

Thank god I'll be off theplanet soon and on to softlayer. As soon as they announced the merger with EV1 we started plans to move. Works out good since we're ready to expand and upgrade anyway.

 

[rpmws]

I just checked the redhat network and the server I'm having a problem with hasn't even checked in with redhat since 2006-01-10 04:28:07 EST

Weird it's not been a problem before now, especially when my other server is configured identically to the one that is having a problem. And the other server is working just fine.

Oh well, I guess I'll jsut wait for theplanet to respond to the trouble ticket.

Thank god I'll be off theplanet soon and on to softlayer. As soon as they announced the merger with EV1 we started plans to move. Works out good since we're ready to expand and upgrade anyway.

If your named is still down you can always use that RPM I posted above to get it back up for now.

 

[vannaco]

If your named is still down you can always use that RPM I posted above to get it back up for now.

the rpm doesn't do a thing for my server.

 

[Brian_Wilson]

If your named is still down you can always use that RPM I posted above to get it back up for now.

yeah, I did see that...thanks!

I figure I'll just leave it for theplanet to fix since I'm having another issue anyway (the redhat thing).

The server being affected here is only a DB server, and secondary name server...so it's not gonna cause me any problems if named is down for a couple hours.

Of course, if they don't finish by the time I'm through my morning coffee and a little more awake I guess I'll just deal with it myself.

Don't you just love waking up to the sound of your cell phone telling you a server is malfunctioning.

 

[hpsmaster2]

access your ssh

pico /etc/resolv.conf and put down any ip of other server dns (exameple a ip dns of other your server)

after

up2date -u bind-libs

and you will solve this.

 

[elleryjh]

The fix above did not work for me.

[email protected] [~]# up2date -u bind-libs

Fetching package list for channel: rhel-i386-es-3...
########################################

Fetching package list for channel: rhel-i386-es-3-extras...
########################################

Fetching package list for channel: rhel-i386-es-3-devsuite...
########################################

Fetching Obsoletes list for channel: rhel-i386-es-3...

Fetching Obsoletes list for channel: rhel-i386-es-3-extras...

Fetching Obsoletes list for channel: rhel-i386-es-3-devsuite...

Fetching rpm headers...
########################################

Name                                    Version        Rel
----------------------------------------------------------
bind-libs                               9.2.4          14_EL3              i386 


Testing package set / solving RPM inter-dependencies...
########################################
bind-libs-9.2.4-14_EL3.i386 ########################## Done.
[email protected] [~]# service named restart
Stopping named:                                            [FAILED]
Starting named:                                            [FAILED]

 

[spiff06]

access your ssh

pico /etc/resolv.conf and put down any ip of other server dns (exameple a ip dns of other your server)

after

up2date -u bind-libs

and you will solve this.

Yes. That fixes it.

ServerMatrix users see also http://forums.theplanet.com/viewtopic.php?p=158985#158985

 

[vannaco]

Yes. That fixes it.

ServerMatrix users see also http://forums.theplanet.com/viewtopic.php?p=158985#158985

doesn't seem to work for all servers the same way. I tried it 10 times and still doesn't work. someone at TP has been on the server for 2 hours and still has not found the problem.

 

[spiff06]

Didn't see elleryjh's post until now, I guess BIND can still fail after the update in some cases...

 

[flash7]

You need to make sure that the first nameserver entry in /etc/resolv.conf is a working DNS resolver. For example, it would be a good idea to use the DNS resolver that your datacenter provides. If you don't know what they are, you'll need to seek help from your server provider, unless it's your own hardware and OS, of course.

It's a salutary reminder that you do need to have disperate nameservers defined in resolv.vonf incase the local resolver goes down, as it is in these cases.

All right, fixed

 

[XPerties]

The fix above worked on 2 of my servers but on one I can't get **** to work on it.

Anyone else have any suggestions?

 

[Solokron]

This also appears to fail if you run it before the upcp. I have a server with named still hosed.

 

[Solokron]

lol expect this thread to explode. cPanel needs to put a safeguard in place for this.

 

[elleryjh]

For me " up2date -u bind-libs " did not work, but eth0's file (thanks, rpmws) worked. Only this newer version of bind-libs worked for me.

http://216.127.74.88/files/bind-libs-9.2.4-14_EL3.i386.rpm

rpm -i bind-libs-9.2.4-14_EL3.i386.rpm

OR

rpm -U bind-libs-9.2.4-14_EL3.i386.rpm

 

[[MuTe]]

Still having nightmares!

The fix worked but I am still having problems with the bind

Bind reloading on xxx using rndc zone: [xxx]
Error reloading bind on xxx: rndc: connection to remote host closed
This may indicate that the remote server is using an older version of
the command protocol, this host is not authorized to connect,
or the key is invalid.

Zone Modified!

It saves the changes but bind will not reload the changes !

I added my ISPs nameserver to the resolv.conf to fix the initial problem could this now be causiing this?

Any ideas guys?

Thx All