Date: Wed, 07 Aug 2002 11:46:17 -0500 From: Christopher Schulte <schulte+freebsd@nospam.schulte.org> To: Josh Paetzel <friar_josh@webwarrior.net>, BSD Freak <bsd-freak@mbox.com.au> Cc: Roger 'Rocky' Vetterberg <listsub@401.cx>, FreeBSD Questions <freebsd-questions@FreeBSD.ORG> Subject: Re: There must be a better way to maintain older systems Message-ID: <5.1.1.6.2.20020807112827.05fde6f8@localhost> In-Reply-To: <20020807111625.B207@twincat.vladsempire.net> References: <e5fe64e5c22e.e5c22ee5fe64@mbox.com.au> <e5fe64e5c22e.e5c22ee5fe64@mbox.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:16 AM 8/7/2002 +0000, Josh Paetzel wrote: >It's already been suggested that you build a machine specifically >for doing buildworlds on and then installing all the other machines >off the first one. Total downtime for production server == one >reboot to load the new kernel. One curiosity I've considered with this method. If I buildworld on a generic box with a generic make.conf, will the installworld on target machine with mounted /usr/src and /usr/obj follow its local version of make.conf with install? Such as, if I don't want to install bind on one specific target machine, will -- /etc/make.conf -- NO_BIND= true -- /etc/make.conf -- on target prevent bind from being installed with an installworld even though it was built with buildworld on the build server? If so, I could generate a daily generic 'build' as well as custom kernels for all of my servers automatically after my local cvsup server pulled an update from cvsupxx.freebsd.org. Then as an update was required on any specific server, it would be a matter of mounting the build directories, and taking it from there. World and kernel would be all fresh and warm. Perhaps cp -Rp over from the network first so I can properly boot into single user mode and not rely on the network to finish the install. Hell, that too could be automated so /usr/src and /usr/obj are populated on the local disk of every machine. Some sanity checks would need to be done before issuing the actual update commands, but I could see this method working. Comments? -- Christopher Schulte http://www.schulte.org/ Do not un-munge my @nospam.schulte.org email address. This address is valid. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.1.6.2.20020807112827.05fde6f8>