Bind 9 F.Y.I. /scripts/upcp updated rpm & dependency failed,


Well-Known Member
Nov 9, 2001
New Jersey
cPanel Access Level
DataCenter Provider
This is an FYI posting.
Comments are welcome.

Here's what I had last night.

/scripts/upcp ran as usual.
It seems to have decided to update from bind 8 to bind 9

Bind-9 rpm successfully downloaded & installed.
Bind-9-utils rpm failed to download, but Bind-9 rpm still installed and ignored the failed dependency. Bind failed to restart. Missing files, etc) That made for a big pain in the butt.

Network connection speed also came to a crawl from this too.
took 5 minutes to connect via PuTty/ssh.

Finally decided I was going to manually install the bind-utils-9 rpm, but not knowing if the actual bind-9 rpm was in good shape either.

Network conenction way too slow to do a &wget& from

Had to &wget& the stuff into another server, and ftp it acrossed. I also wanted to have both the base rpm and the utils rpm for both versions of bind available on the box in case something worsened while attempting to fix. Yes, it took hours to ftp over a few megs of data.

However bind-utils-9 rpm installed ok, and everything was back to normal, including the network connection speed.

It would be a nice thing if the /scripts/upcp ... and or rpmup, had done some dependency checking,... or waited until all the dependency rpm's are successfully downloaded before installing any one of them.

Here is snipped what the log looked like:

arpwatch is up to date
at is up to date
bash is up to date
Downloading bind-9.2.1-0.6x.3.i386.rpm
Preparing... #### [100%] #### [100%]

(I took out some of the ## to save space here)

Downloading bind-utils-9.2.1-0.6x.3.i386.rpm error: skipping - transfer failed - Unknown or unexpected error

cvs is up to date
db3 is up to date

OK... Where's the &Preparing... #### [100%]& part on the second try?? That part didn't happen.

Would it be a good thing for to use a static IP# in the scripts for the updates? I did also have other name servers listed in my resolv.conf file, but seems like that file wasn't doing anything at that point in the failure.


Well-Known Member
May 9, 2002
Linux just accept the first three nameserver lines in the /etc/resolv.conf


nameserver out-source-IP1
nameserver out-source-IP2

if you set it up like this you should not have any problem on resolving, but just make sure your out-source nameservers are working