Date: Mon, 23 Mar 1998 14:35:37 -0800 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: Derek Flowers <djflow@portwwwbus.tc.cc.va.us> Cc: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>, "Daniel O'Connor" <doconnor@gsoft.com.au>, "Daniel O'Callaghan" <danny@panda.hilink.com.au>, gkshenaut@ucdavis.edu, stable@FreeBSD.ORG Subject: Re: after the release ... Message-ID: <199803232236.OAA16235@passer.osg.gov.bc.ca> In-Reply-To: Your message of "Mon, 23 Mar 1998 15:52:03 EST." <Pine.BSF.3.96.980323154739.13675B-100000@portwwwbus.tc.cc.va.us>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, 23 Mar 1998, Cy Schubert - ITSD Open Systems Group wrote: > > > > > > > > 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 t hen > > 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/sugge st > > > which have pre/co-requisites, and if these are wrong(ie the checksum does n't > > > match or the date is too new/old) then don't apply that group.. ie make e ach > > > 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 > > The best way to go on custom changes is that the patch checks the md5 > checksum of the file it is going to replace and if it does not match, > abort the installation. It seems to me that someone doing custom work on > files should have the sources and the time to patch stuff manually. ... which is what Sun does. > > A binary patch system is mainly for those who do not have the space or the > time to install the sources, make the changes, recompile, and reinstall. > > ---------------------------------------- > Derek Flowers > djflow@erols.com > http://portwwwbus.tc.cc.va.us/~djflow 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?199803232236.OAA16235>