From owner-freebsd-isp Tue Oct 20 11:47:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA18362 for freebsd-isp-outgoing; Tue, 20 Oct 1998 11:47:30 -0700 (PDT) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA18357 for ; Tue, 20 Oct 1998 11:47:29 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id NAA17760; Tue, 20 Oct 1998 13:47:04 -0500 (CDT) Received: from aridius-23.isdn.mke.execpc.com(169.207.66.150) by peak.mountin.net via smap (V1.3) id sma017757; Tue Oct 20 13:46:37 1998 Message-Id: <3.0.3.32.19981020133335.0106947c@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 20 Oct 1998 13:33:35 -0500 To: Paul Stewart , freebsd-isp@FreeBSD.ORG From: "Jeffrey J. Mountin" Subject: Re: 3.0 Upgrade Question In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:46 AM 10/20/98 -0400, Paul Stewart wrote: >I would first like to thank everyone for their response to my secure >server not working in 3.0-RELEASE.... I shouldn't have played with >fire..:) Since, I have re-installed the server to 2.2.7-RELEASE and >everything is working fine.... thank you. A little fast out of the gate. ;) >On a side note, we have several machines running on 122597-SNAP releases. >They are running just fine except I can't compile UCD-SNMP on them which >is now needed. So, I was thinking of updating them to 3.0-RELEASE. Am I >playing with fire again? I can't take these machines offline for a long >period of time. Can I CVSUP them to the newest kernel trees and remake >the kernel? Is this a safe practice? For myself I've only been reading current for about a month, but there seemed to be problems in cvsup'ing up to 3.0, especially from an older release or even from a 1-2 month old -current. Mainly the problems were related to the aout -> elf issues and buildworld's failing for whatever reasons. I'd pass on this method. >As you can tell, I'm not used to upgrading these machines. They run >currently like a dream but I don't want to fall a LONG ways behind in the >current kernels...:) If planned well you can upgrade them is less than an hour. Generally my preference is to keep the OS and ports on one drive (or set of partitions) and local/user data and such on other drive/partitions. The reason I say drives is that way you can disconnected them for absolute certainty. Liking to start fresh, I either repartition or at least newfs, but only after a double backup. One to tape, the other for config file on a drive/partition that will not be touched during the install. If you go the newfs way, write down or copy your current disklable(s). When you mount the partitions add the newfs flag , so they are redone. Forget the option, but then I like to wipe it clean. Usually to adjust the partition sizes, since it seems like the minimum needs of / have grown slightly. The advantage of keeping mainly the OS and ports on one drive is even clearer if you have a spare server. Then it's a matter of installing, adding ports, and configuring the "new" server, actually a drive, and swapping. Before shutting down both servers for the drive swap it is best to remove the production system from the network and connect it to the upgrade server, which is already configured, and transfer any data/logs over. Do this right and you have less than 30 minutes downtime. Another issue is the ports collection. When doing an upgrade ala fresh install on a production server, the ports are not part of my install. Either I tarball what I need from a system already upgraded, or install it after the reboot when install is finished. That way while the collection is installing, the server config is being set and a kernel is tweaked and ready to install. I vaguely recall what is was like upgrading BSDi, or any OS for that matter and starting fresh seems the best way, but only if you can afford _some_ downtime and it isn't too complex. Never did a drive swap yet, but still keep all but one out of several dozen upgrades to less than an hour. However, my next 2 upgrades are bit more complex with some hardware swapping and in one case a 2nd processor will be added and the system is going to a mirrored drive config with a DPT controller. This will be an almost complete swap with 2 drives being transferred to the new setup along with all the logs. I've planned this out for months and hope to be up and running in less than an hour. The system won't be quite set exactly the way I want, but it will be back online and fully functional. Later on it will be a matter of remotely shuffling some files and eventually removing the old drives. Honestly, I can't recall the last time I used the upgrade function of sysinstall and the longest time spent on an upgrade was less than 2 hours. At first I did try an upgrade (to 2.2.5 at the time), which failed horribly. No real panic since the basic config was copied onto the drive with all the web data, so I just did a full, clean install and updated all the config files with my settings. Not sure how much sysinstall's upgrade function has improved, but it has always had a warning. And with the transition from aout -> elf, I'm not sure how "clean" it is. YMMV, but come upgrade time it really shows how important it is to separate services. Having 2 servers for DNS, mx, and authentication goes far on taking the pressure off while upgrading. Not that there isn't a certain zest to the feeling that an error or 3 may make for a long night. It isn't fun restoring from tape. ;) luck Jeff Mountin - Unix Systems TCP/IP networking jeff@mountin.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message