I've found this question in comp.protocols.dns.bind newsgroup http://www.deja.com/getdoc.xp?AN=567916235 and when checked my own linux box discovered, that corresponding S* files really disappeared from /etc/rc.d/rc[3-5].d directories. Checked original and latest updates RPMs (both for sparc and intel) and send the following to the newsgroup mentioned (now it's forwarded to moderator for approval). Hope this helps a bit. -- andrei Date: Wed, 26 Jan 2000 08:55:30 GMT From: Andrei Ivanov <iva.lv> To: comp-protocols-dns-bind.org Newsgroups: comp.protocols.dns.bind Subject: Re: named won't start at boot - Redhat In article <OSoj4.58$FS.20657.qc.ca>, "Liang Ma" <Liang.Ma.ca.NO_SPAM> wrote: > Try "ln -s ../init.d/named S45named" in /etc/rc.d/rc3.d. > > I don't know if this is the right way, but it works with my > Red Hat 6.1 Oops! Checked my RH60 box and found that S55named script really diappeared after upgrade. The following run control scripts were installed during initial installation: $ rpm -qlp redhat-6.0/i386/RedHat/RPMS/bind-8.2-6.i386.rpm | grep /etc /etc/rc.d/init.d/named /etc/rc.d/rc0.d/K45named /etc/rc.d/rc1.d/K45named /etc/rc.d/rc2.d/K45named /etc/rc.d/rc3.d/S55named /etc/rc.d/rc4.d/S55named /etc/rc.d/rc5.d/S55named /etc/rc.d/rc6.d/K45named But newest version of BIND rpm does not provide S* scripts: $ rpm -qlp updates/redhat-6.0/i386/bind-8.2.2_P3-1.i386.rpm | grep /etc /etc/logrotate.d/named /etc/rc.d/init.d/named /etc/rc.d/rc0.d/K45named /etc/rc.d/rc1.d/K45named /etc/rc.d/rc2.d/K45named /etc/rc.d/rc3.d/K45named /etc/rc.d/rc4.d/K45named /etc/rc.d/rc5.d/K45named /etc/rc.d/rc6.d/K45named So, after upgrade it's necessary to create symbolic links in rc[345].d directories manually. -- andrei
This is intentional. We disable all network services by default until someone turns them on. chkconfig --levels 35 named on is probably what you're looking for. Alternatively, use some graphical tool that does the same thing, like ntsysv or ksysv.
Any ascii/graphical tool should be used during initial installation. Upgrade of the package on running system is a bit different case. It would be wise to check current state (in preinstall script (I'm not very familiar with RPM intrinsics, but hope that you have smth appropriate)) and restore the same state right after package upgrade automatically. For example, I last rebooted the linux box about a week _before_ RH provided new version of BIND, and only occasionally discovered, that after next re-boot I would go w/out one of my services :-(