Date: Mon, 8 May 2006 16:17:59 -0700 From: David Wolfskill <david@catwhisker.org> To: Scott Harrison <scott@mithrandir.com> Cc: freebsd-stable@freebsd.org Subject: Re: Best practices for remote upgrade? Message-ID: <20060508231759.GC545@bunrab.catwhisker.org> In-Reply-To: <372C34B7-18BC-4061-99ED-8321E8109CF7@mithrandir.com> References: <372C34B7-18BC-4061-99ED-8321E8109CF7@mithrandir.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 08, 2006 at 02:29:23PM +0200, Scott Harrison wrote: > Hello, > > I have some 4.x servers that I would like to upgrade to 5.x, and > perhaps 6.x. However, I do not have any local access to these > machines. I can ssh into them only. I would like to know whether it > is possible for me to upgrade the machines with only ssh access, and > what one should do to go about upgrading them. Short answer: it depends. One of the ings on which this depends is how those remote systems are set up. One thing I like to do, which IMO makes this type of exercise somewhat more feasible, is to have more than one bootable slice on the machine. Typically, I would allocate a relatively small slice 1 (& slice 2), each of which would have a / and /usr file system on it. I'd put everything else -- stuff that I wanted to remain the same regardless of which slice is the boot slice -- on (say) slice 3. I then have little shell scripts to use "dump | restore" to "clone" the file systems from one slice to the other. One of the nice things this does is allow the machine to be booted form one slice while moderately major "surgery" is performed on the file systems on the inactive slice. There are a few inconveniences -- it does take up disk space; allocating the root file system for slice 2 is moderately annoying using sysinstall, because it gets allocated as partition d, and I like to make it partition "a" -- so use "bsdlabel -e" (or "disklabel -e" on older systems) and change the partition designator, if that's what you prefer. I've seen similar setups where the inactive slice gradually become more and more stale. I avoid this by using the following approach (which could undoubtedly be made cleverer, but I stopped when I found an approach that worked): * "Clone" the file systems from the active slice to the inactive one. * Reboot from the "other" slice (the target of the above operation). * Upgrade in place. * Reboot (without changing active slice). For fallback, reboot from the original slice. This is actaully a variant of an approach that I recall using back on IBM mainframes running MVS (and MVS/ESA and MVS/XA) (ca. 1982 - 1993). Note that "boot0cfg" can change the default boot slice if you're using the FreeBSD boot loader. In my experience, this works better for smaller deltas between upgrades -- so it may not be directly applicable to a 4.x -> 5.x? -> 6.x transition. There may still be something useful for your situation there, though. Peace, david -- David H. Wolfskill david@catwhisker.org Spam received via "opt-out" lists is still spam, and should be treated as such. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060508231759.GC545>