Re: CVS: Head Hurts

[Kit Halsted <kit@gbcom.com>]

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
>>  >  > anoncvs@some.anon.server:/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[18910]: starting.  named 4.9.7-REL 
Thu May 21 19:27:54 1998 
root@localhost:/usr/src/usr.sbin/named/named/obj
Jan 31 13:52:19 ellisisland named[18910]: chrooted to /var/named
Jan 31 13:52:20 ellisisland savecore: no core dump
Jan 31 13:53:46 ellisisland named[19319]: starting.  named 4.9.7-REL 
Thu May 21 19:27:54 1998 
root@localhost:/usr/src/usr.sbin/named/named/obj

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
     kit@ellisisland:/usr/src/sys/arch/i386/compile/GENERIC

>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.

I prefer:

# cat /var/named/named.pid
10707
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.

Thanks,
-Kit