From owner-freebsd-questions Thu Mar 20 19:25:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA21353 for questions-outgoing; Thu, 20 Mar 1997 19:25:15 -0800 (PST) Received: from mixcom.mixcom.com (mixcom.mixcom.com [198.137.186.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA21345 for ; Thu, 20 Mar 1997 19:25:12 -0800 (PST) Received: from hilltop.mixcom.com by mixcom.mixcom.com (8.6.12/2.2) id VAA08181; Thu, 20 Mar 1997 21:25:05 -0600 Message-Id: <3.0.32.19970320211953.00ce226c@mixcom.com> X-Sender: sysop@mixcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Mar 1997 21:19:54 -0600 To: Doug White From: "Jeffrey J. Mountin" Subject: Re: 2.2 Upgrading for idiots? Cc: questions@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 01:28 PM 3/20/97 -0800, Doug White wrote: >Perhaps. sysinstall for the pre-2.2 series was pretty solid though. It >sounds like our little crew here won't be all together to do the upgrade >for a while, but if we find anything tweaky, Jordan will be the first to >know :) Had to do some thinking and it was the 2.1.0 -> 2.1.5 that was a problem for me. Have to smile at the warnings and disclaimer, but will say that from 2.1.5 -> 2.1.6 and -> 2.1.7 were smoother. First to know or first to fix? ;-) >> OK, but I would imagine that it would be a good idea to recompile some of >> the packages, unless there is a new version. Some standard things I do as >> a package, usually from sysinstall. Others have been customized, so I keep >> the source out of the way of upgrades. > >True. I generally consider packages separate from the rest of the system. >I certainly wouldn't want to force on upgrades to anyone -- we run some >pretty old stuff on resnet, and if it was auto-upgraded we'd be in >trouble. Hehe. We have some older version of programs and call me lazy, I don't feel like updating and adding any customizations. There are a few and the BSDi server that users see will be going away... some day. >> >We've gone to the pain of doing this for you -- unless you have need to >> >build from edited source, save yourself and your computer some aspirin. >> >> Uh, no. Not really. 8-) > >Can you elaborate? I could use some education on "when to build and when >to install" since I don't do builds because of lack of disk. On not wanting a headache? If you are refering to packages, the expedient thing would be to remake them, but I am not enough of a hack to really say. Only some what familiar with the libraries and their functions. Right now I am trying to track down a problem in a compiled program, but I plan to poke around around before posting. >The new installer doesn't even touch /etc, so any customizations are >preserved. You'll still want to merge across sysconfig, otherwise you'll >get odd ipx messages because of some new directives added to sysconfig. >If an item is missing from sysconfig, the results are somewhat undefined, >usually the missing item will be activated. If I am reading this right, the new installer - when upgrading - will *not* do anything with /etc ?? Or are you referring to permissions? If it does nothing, then one would need to merge the current, but older files, but then where would the "new" /etc files be located. Just a touch confused at what you are saying here. 8-) I would expect when the binaries are updated that they go back to the default permissions. However I have seen a system with botched permissions. Rather irritating when /tmp is not mode 1777 (vi doesn't work) and sendmail does not have 2111 (hard to mail otherwise). This I cannot say was an install problem, as the box is a friends, so I'm not sure what happened. At least I fixed it. One would hope that if something were missing in sysconfig it would not be activated. Only on one install did I have a problem with this file, which was easily compared with a clean install of the same build. Still /etc/rc has: # If there is a global system configuration file, suck it in. if [ -f /etc/sysconfig ]; then . /etc/sysconfig fi So a missing item should not be activated and there are some '!=' ifs as well. ------------------------------------------- Jeff Mountin - System/Network Administrator jeff@mixcom.net MIX Communications Serving the Internet since 1990