Re: dns/bind99 and the migration from FreeBSD 9.x - 10.x

2014-10-19 Thread David Wolfskill
On Thu, Feb 27, 2014 at 03:27:37PM -0800, David Wolfskill wrote:
 I am not at all clear how to perform a migration of machines that
 run authoritative nameservers from FreeBSD 9.x - 10.x, given the
 current setup of the dns/bind99 port.  I'm hoping for some clues,
 if not insight.
 

I seem to have managed to perform the above migration for one of
the two machines that I have here at home that meet the above
description.  (I have not yet attempted it for the other; if things
seem OK after a week, it's next up.)

Unrelated to this issue, I acquired the use of a test machine (to
which I restored the backup images of the file systems of the machine
I just upgraded, then changed the hostname  IP address).  I was
thus able to experiment a bit.

On these machines, I have them set up to boot from either of 2
slices (each of which contains its own / and /usr; /var is the same
file system (on a 3rd slice) regardless of which slice is booted),
and flip from one slice to the other at each upgrade.  I normally
track a stable/N branch, updating weekly.  Salient parts of the
upgrade process for these intra-branch upgrades:

* Clone the running slice to the other one.

* Ensure that the root and usr file systems from the non-booted slice
are mounted at a suitable mountpoint.

* Mount /usr/src and /usr/obj read-only via NFS from the build machine.

* cd /usr/src  \
make installkernel installworld DESTDIR=${other_slice_mountpoint};
mergemaster gets a -D flag for similar purposes.

* Reboot from the newly-populated other slice.

* Mount /usr/src and /usr/obj read-only via NFS from the build machine
(because some ports (e.g., sysutils/lsof) want access to that
information).

* Update installed ports.  (I have been using portmaster -ad for some
time for this.)

* Perform the make delete-old-libs mentioned in src/UPDATING.

* Reboot to ensure that nothing is still using old ports.


For this exercise (9.x - 10.x on a machine running an authoritative
name server), here's what worked for me:

* Mount /usr/src and /usr/obj read-only via NFS from the build machine
(because some ports (e.g., sysutils/lsof) want access to that
information).

* Update installed ports.

* cp -pr /var/named/etc/namedb /usr/local/etc/

* cd /usr/local/etc/namedb  
foreach f (`find . -type d -name RCS -prune -o -type f -print0 | \
xargs -0 grep -l '/etc/'`)
  sed -i  -e 's/\/etc/\/usr\/local\/etc/g' $f
end

* Clone the running slice to the other one.

* Ensure that the root and usr file systems from the non-booted slice
are mounted at a suitable mountpoint.

* Mount /usr/src and /usr/obj read-only via NFS from the build machine.

* cd /usr/src  \
make installkernel installworld DESTDIR=${other_slice_mountpoint};
mergemaster gets a -D flag for similar purposes.

* Reboot from the newly-populated other slice.

* Install ports/misc/compat9x (e.g., portmaster misc/compat9x)/

* Re-install ports/dns/bind99 (e.g., portmaster dns/bind99)/

* service named restart (and verify that lookups are faster now that the
first nameserver listed in /etc/resolv.conf actually has named
running).

* Perform the make delete-old-libs mentioned in src/UPDATING.

* Reboot to ensure that nothing is still using old ports.


Note that while dns/bind99 and misc/compat9x were built/installed under
10.x, the rest of the ports on the system are still running after having
been built/installed under 9.x.  This is intentional, so I have a
relatively easy fallback option in case of Something Bad happening
(reboot from  the previous slice, which still has stable/9 installed).

After a week (or two), I expect to cut over fully, and perform the
process documented near the bottom of portmaster(8) to rebuild/iinstall
all installed ports under stable/10.  And then I expect to do the same
for my laptop and the build machine... and then I'll stop tracking
stable/9.

YMMV, and all that.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpB9XBjVnbhK.pgp
Description: PGP signature


Re: dns/bind99 and the migration from FreeBSD 9.x - 10.x

2014-10-19 Thread Warren Block

On Sun, 19 Oct 2014, David Wolfskill wrote:


After a week (or two), I expect to cut over fully, and perform the
process documented near the bottom of portmaster(8) to rebuild/iinstall
all installed ports under stable/10.


There is a version updated for pkg in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191166

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


dns/bind99 and the migration from FreeBSD 9.x - 10.x

2014-02-27 Thread David Wolfskill
I am not at all clear how to perform a migration of machines that
run authoritative nameservers from FreeBSD 9.x - 10.x, given the
current setup of the dns/bind99 port.  I'm hoping for some clues,
if not insight.

I have been building  running both stable/9  stable/10 (on different
slices) for some time; I'm almost to the point of being ready to switch
to stable/10 on my production machines (which implies that I would
stop building  running stable/9, and that I would be rebuilding all
ports under stable/10).

I have done analogous migrations from 4.x - 6.x; 6.x - 7.x; 7.x -
8.x, and 8.x - 9.x; each has been successful (though some took longer
than others to get there).  (Updates prior tended to be re-installs from
scratch.  I rarely do that any more.)

The big concern I have in this case is that each of the machines in
question is running an authoritative nameserver.

In preparation for this, once BIND was removed from stable/10, I
had installed the dns/bind99 port on each of the machines (using
default options -- in particular, I did *not* select REPLACE_BASE)
while running stable/9.  As a result, the port continued to use the
zone files from their locations from when BIND was part of base
FreeBSD: /var/named/etc/namedb; I merely changed /etc/rc.conf to
specify:

named_program=/usr/local/sbin/named

and on reboot, everything Just Worked.


Now, normally when I do one of these migrations, I migrate the OS, and
let the ports sit for a week or two (by installing the appropriate
misc/compat*x port).  Once things seem to be OK, I then use the process
documented at the end of portmaster(8) to rebuild all of the ports under
the new OS (and then resume my normal weekly update of OS  installed
ports).

Were I to use that migration approach in this instance, one of the
immediate issues is that there would be no startup script to start
named (as the port was built  installed under stable/9).  Unless, of
course, there's some approach I'm overlooking that would allow me to
stage or prepare the stable/9 environment to be (much) more similar
to the stable/10 environment...?

Is there an approach that is intended for this sort of thing?  Or an
approach that others have used successfully?


Thanks for suggestions; I'll be happy to summarize on-topic mail
received off-list.  (I'm subscribed to ports@, so no need to copy me on
list mail.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpunDNK9PbBh.pgp
Description: PGP signature