Install utility (INSTALL)

[Lucinda_1]

What ensures that the old version of an Installed image will not be used when the system reboots. I need documentation that details how INSTALL works. This is a SOX issue (Sarbanes). The auditors deem it a risk that we do not have a procedure in place to know if the version of the application installed in memory after a reboot was the same version of the sofware that was there before the reboot.

[Robert Brooks_1 · Accepted solution]

I'm not sure I completely understand the question. Is the concern that if there are multiple versions of an image in a directory, that INSTALL will not always install the highest version?

Is the auditor concern regarding versions of HP-distributed shareable images, or your locally-written application?

Or is the auditor's concern regarding the "scrubbing" of physical memory used by the old image prior to the reboot?


-- Rob (VMS Engineering)

[Lucinda_1]

This is the note from my manager: (we have inhouse developed applications)

One of the items that had come up on our audit related to putting new applications into production. We described to them that if development put a new application into production, the user would not be able to use it until we installed it in memoryâ ¦that was a good control to them. However, I went on to tell them that when the system rebooted, the latest version of the application was installed in memory and there is no procedure in place for us to know if the version of the application installed in memory after reboot was the same version of the software that was there before the rebootâ ¦they deemed this as a risk.

[Jim_McKinney]

> "there is no procedure in place for us to know if the version of the application installed in memory after reboot was the same version of the software that was there before the reboot"



There is no record of what was previously INSTALLed. I suppose that you could have SYS$MANAGER:SYSHUTDWN.COM invoke INSTALL LIST to produce a listing each time you shut down the system (though this doesn't address system crashes / power failures).

[Lucinda_1]

i am thinking the system crashes would be more vital than anything. i think i am looking for something to tell me that INSTALL works in such a way, that it would not allow me to go back to an old version just because of a system crash, once the version is installed. or that the old version cannot be accessed without going thru install

[Phillip Thayer]

If the application image that is installed on your system is not in VMSINSTAL.DAT then it has to be installed via a command procedure somewhere during the startup process. All you have to do is edit this command proceudre and force it to use an explicit version number of the image. this will ensure that when the system boots the image that is installed is the version that you want it to use. This also means that everytime you build a new version and install it you will have to update the command procedure that installs the image to change the version number.

The problem that the auditors are trying to prevent is a scenario where some body writes a program that copies all the files on a system to an external system, compiles the program, copies it to the application directory using the name of the installed application image and causes a system crash. On reboot the system will run their little copy program and before anybody realizes what is going on the person is gone with a bunch of crucial data for sale to the highest bidder. Not good but it could happen.

[Lucinda_1]

this sounds like a good solid "procedure" to avoid a bad situation. I will suggest this, thanks. Still open to further comment, until tommorrow.

[John Gillings]

Lucinda,

If I understand your problem, you're trying to avoid the situation where a new version of some software product is installed on a node, but not deployed (for want of a better description).

In other words, we copy the files, but don't start it, then the system crashes and before we expected it, the new version is "live"? Yes?

I guess that's a similar situation to someone using SYSGEN to set a CURRENT value for a non-dynamic parameter, then later the system reboots and the new value becomes live.

In an environment like OpenVMS with long uptimes, this is a very real risk as the value change may have occurred months or even years prior to the reboot that makes it live.

For the case in point, I'd put the onus of keeping track back on the installation procedure/process - don't copy any files until you're ready for the cutover to the new version, and make sure the new version is deployed immediately after installation (if that requires a reboot, then so be it).

Other than that, maybe you could write a procedure that examined important application images, and flagged any prior versions found.

If images are known to be INSTALLed, another option is to check at shutdown time. Use INSTALL LIST and/or F$FILE(file,"KNOWN") to identify which file is installed, and make sure it isn't occluded by a newer version. Granted this only helps for a planned shutdown.

[Lucinda_1]

Thanks for all the input. We will have to use this information to decide on the best "procedure" for tracking this.