Date: Wed, 15 Nov 2000 20:40:10 -0500 (EST) From: Igor Roshchin <str@giganda.komkon.org> To: kris@FreeBSD.ORG, security@FreeBSD.ORG, str@giganda.komkon.org Subject: Re: problem using sysinstall Message-ID: <200011160140.UAA95904@giganda.komkon.org> In-Reply-To: <20001115150709.A24024@citusc17.usc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Wed, 15 Nov 2000 15:07:09 -0800 > From: Kris Kennaway <kris@FreeBSD.ORG> > To: Igor Roshchin <str@giganda.komkon.org> > Cc: kris@FreeBSD.ORG, rraykov@sageian.com, security@FreeBSD.ORG > Subject: Re: problem using sysinstall > > On Wed, Nov 15, 2000 at 05:58:13PM -0500, Igor Roshchin wrote: > > > I wonder if there is a fundamental reason why /etc needs to be=20 > > overwritten, or it is just because the sysinstall is doing so. > > So, is it possible to specify to sysinstall (as an option) > > to put new /etc into some other directory (/var/tmp/etc, > > or whatever) from the very beginning ? > > That would require breaking the bin distribution up into bin + etc > (since it's extracted by tar), or special casing it and treating it > differently from all of the other distributions (and extracting it in > two stages). Traditionally bin has been the minimum necessary to get a > working FreeBSD system, if we add an etc that no longer becomes true. No change in the tradition is required. How about extracting the bin ditribution into a different "root" (say /var/tmp/updated or whatever), so both, $NEWROOT/etc, $NEWROOT/bin, will be extracted there first, and then $NEWROOT/bin is moved by the sysinstall into /bin, and the necessary part of $NEWROOT/etc into /etc. The "leftovers" of /etc can go into /var/tmp/etc . Well, yes, this will add some time and disk space overhead. But, I as I suggested earlier, it can be an option in sysinstall. At the same time the 1st step, being analogous (in some sense) to "make buildworld" would insure that the bin distribution is unpacked alright, and that the system will not get stuck in a half-way-through upgraded system (not that it's been a major concern so far, so regard it as a "positive side effect"). > > I think the answer is now in the realm of "this is how it's always > worked before, if you want to change it, submit patches" :-) > > Kris > SInce I am not in position to submit patches in this case, and otherwise my idea(s) was made clear (I hope), I just shut_up(8). :) Igor PS. IIRC, there is a work in progress on creating a new sysinstall (is this true?). If that's the case, it doesn't make sense to submit patches, but may be just to implement this behavior in the new generation of sysinstall. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011160140.UAA95904>