[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS: Head Hurts
At 10:17 PM -0600 1/30/01, John Ladwig wrote:
>[ updating BIND ]
>> >> I guess I'm either not being clear or I'm just failing to understand
>> > > the whole process. I updated /usr/src with "cvs -d
>> > > firstname.lastname@example.org:/cvs up -r OPENBSD_2_7 -Pd" thinking it
>> >> would get me source with the latest patches. If I'm understanding the
>> >> instructions correctly, I should then rebuild the kernel, reboot from
>> >> the new kernel, then rebuild binaries. Is this not the case?
>> >Oh, so you want to build the whole system again?
>> >It looks, from your directory listing that you didnt use cvs and got
>> >src.tar.gz and DIDNT get srcsys.tar.gz which houses the kernel src. You
>> >will need to grab that as well.
>> Got it, updated via CVS again, & I'm watching "make build" thoroughly
>> trounce my scrollback buffer as I write. Happy, happy, joy, joy!
>> One last question, or series of questions: the CVS updated source
>> claims to contain all of the patches from errata, so the BIND patch
>> should be in there.
>The recent BIND patches seem to be tagged for both 2.7 and 2.8, so you
>should be good, at least as far as BIND is concerned.
Aaargh. See below.
> > The Patch Branches page instructions end at "make
>> build". It seems to me that I should reboot (or HUP _everything_)
>> after "make build" in order to begin running the new BIND & other
>> binaries. Is this the case, or am I failing to grasp yet another
>> basic concept here?
>Rebooting would insure that you're running all the current versions. A
>HUP on all running daemons won't get you a newly-patched kernel.
Right, but the instructions on the stable page go like this:
1. Make new kernel.
2. Reboot from new kernel.
3. Rebuild binaries.
So I'm already booted from the new kernel, but running old binaries
if I understand correctly.
Anyway, I rebooted again & named still claims to be 4.9.7:
ellisisland# named -d
ellisisland# tail /var/log/messages
Jan 31 13:52:19 ellisisland /bsd: mtrr: Pentium Pro MTRR support
Jan 31 13:52:19 ellisisland /bsd: dkcsum: wd0 matched BIOS disk 80
Jan 31 13:52:19 ellisisland /bsd: root on wd0a
Jan 31 13:52:19 ellisisland /bsd: rootdev=0x0 rrootdev=0x300 rawdev=0x302
Jan 31 13:52:19 ellisisland named: starting. named 4.9.7-REL
Thu May 21 19:27:54 1998
Jan 31 13:52:19 ellisisland named: chrooted to /var/named
Jan 31 13:52:20 ellisisland savecore: no core dump
Jan 31 13:53:46 ellisisland named: starting. named 4.9.7-REL
Thu May 21 19:27:54 1998
Did I update my source before the latest patches got rolled in, or
have I missed a step somewhere? First line of dmesg is as follows:
OpenBSD 2.7-stable (GENERIC) #0: Tue Jan 30 18:45:36 EST 2001
>If it's *just* named you're concerned with, you can do the following (at
>least with bash):
> # kill `head -1 /var/named/named.pid`
> # `tail -1 /var/named/named.pid`
>since named circa v4 plants the PID as the first line, and the complete
>invocation as the second line of the named.pid file, generally
>located in /var/named/
> # /usr/sbin/ndc restart
>might also do; I haven't poked at ndc on OBSD for a while, but I found the
>ISC BIND8 version somewhat, um, nondeterministic.
# cat /var/named/named.pid
named -t /var/named -u named
# kill -HUP 10707
I think every sysadmin I've spoken to has their own favorite way of
HUPping the nameserver.