Date: Mon, 23 Mar 1998 07:00:32 -0800 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>, "Daniel O'Callaghan" <danny@panda.hilink.com.au>, gkshenaut@ucdavis.edu, stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <199803231500.HAA10455@cwsys.cwsent.com> In-Reply-To: Your message of "Mon, 23 Mar 1998 11:31:08 %2B1030." <199803230101.LAA28437@cain.gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > Another consideration: What if somebody modifies the O/S at their
> > site. MVS, for example, uses USERMODS which automatically get dumped
> > when patches (PTF's or APARFIXES), or new product (FMID's) are applied.
> > Would those of us maintaining FreeBSD sites be willing to follow a
> > regimen as specified by the chosen patch philosophy? On the other hand
> > would Sun's simpler approach work -- if the file's checksum (MD5?)
> > doesn't match what the patch expects, abort?
> Well, that is the whole can of worms IMHO..
> I mean if you could guarantee that the system would be in a given state then
a
> binary upgrade would be quite easy. The main problem IMHO would be making a
> system which didn't mangle any custom stuff you've done to your machine..
That's right! That's why a philosophy should be chosen and strictly
adhered to. Every sysadmin would need to follow this or he/she would
have a mess, e.g. patches would not install if the state was not
consistent with what was expected, and a reinstall would be required to
get back to a know state.
>
> I see making a 'patch' consist of a group of things to apply/change/suggest
> which have pre/co-requisites, and if these are wrong(ie the checksum doesn't
> match or the date is too new/old) then don't apply that group.. ie make each
> group atomic, so that if part of it fails, then back the whole group out.
That's where the USERMOD would be used. The individual sysadmin would
need to tell the system by using a packaged application to modify the
system. This way the system would know why any particular binary (or
source module) would be inconsistent with expectations. (The USERMOD
process would allow modifications but make backup copies of "vendor"
supplied binaries and sources in the process.) If a USERMOD was
detected, the backup copy would be used and the USERMOD would be
verbosely deleted. The sysadmin would need to re-apply their
customization.
I'm not saying that we need to adopt IBM's approach. We just need to
consider _all_ of the ramifications and do it right.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
UNIX Support OV/VM: BCSC02(CSCHUBER)
ITSD BITNET: CSCHUBER@BCSC02.BITNET
Government of BC Internet: cschuber@uumail.gov.bc.ca
Cy.Schubert@gems8.gov.bc.ca
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803231500.HAA10455>