Post by Robert A. Brooks...for example if server A already has some problems reported, example
in the dcltables.exe ... a new installation does not bring that error,
however your assistant tells you that I have already carried out an
installation but you are not sure that it is from cd but a simple
restor because the new server exhibits the same type of behavior as
server A. the good server B was made with cd and does not exhibit that.
(It is only an example of the dcltables, it is not that it is
happening) but I am wondering if there is a way to know the creation
date and maybe when doing restore brings the same date of the wrong
server and know that an installation was not done from zero but a
simple restore
You look at the image identification to see if the specific image in
question has been replace or not.
Oh my, is this situation ever familiar. More than a few OpenVMS systems
and deployments are managed similarly, too.
The OP has already gotten good information on the limits of the
existing tracking and tooling, and we've all had some experience in
under-automated server operations.
OpenVMS lacks any sort of telemetry and lacks any sort of change
tracking. This outside of what gets written to the audit and accounting
data, into OPCOM and the OPERATOR.LOG files, the PCSI database, the
VMSINSTAL.HISTORY file, into user- or app-specific logs, and which in
aggregate seems like a lot, but it's approximately impractical to
rummage and use that data.
There've been efforts toward this change tracking, DECinspect was one.
There's prolly been third-party tools here, too. (There were some hooks
put in place for change-tracking of OpenVMS itself some years ago too,
via VMSKITBLD.DAT, but that work was never been completed. And it's now
also outdated, given its intended use of MD5 for detecting changes.
This would now best be SHA-2 or newer, as malicious changes are likely
in scope.)
In place of the image headers (which don't always get updated), there's
the MD5 (insecure), SHA-1 (weak), or SHA-2 of the files, given various
places don't necessarily track and change image idents. See the DCL
command CHECKSUM for some assistance here. (The CHECKSUM command has
been around forever, and was updated and documented for V8.something or
other. None of the checksums are cryptographically secure against
malicious attackers, but they'll work fine for non-malicious cases.)
Given DCLTABLES doesn't have any ident or any sort of checksum-ability
that would be useful here, the ugly option is to extract the contents
and compare, using the VERB freeware utility that's been around for a
while, or some other similar means. Or re-load the changes.
The longer-term fix for various sites is to use PCSI or (maybe)
VMSINSTAL kits as manually-installed software is seemingly inevitably
going to have inconsistencies, and to update the local app-build
scripts to always update the image identification values and to use
those versions to re-generate the PCSI kits, and then to also implement
site-specific telemetry for the rest of what's locally required. This
at least gets the contents over into the PCSI database, which can be
quickly reviewed. And most app update installations go a whole lot
faster than the manual-per-file install approach, too. To make even the
local apps into layered products. Which makes all of the software
installations far more reproducible. And if you're doing something
PCSI balks at, maybe try a different approach?
ps: This mess all also ties back into my previous comments around (the
lack of) telemetry and lack of change-tracking, the lack of
profiles-like mechanisms for tailoring an app installation, the various
limitations within PCSI itself, and for better and more isolated app
installation tools, obviously. The difficulties around pushing out
updates, and around re-installing and migrating existing OpenVMS and
layered products and apps without having to go through the whole
manual-install process, too. The auto-answer mechanisms in the
installer tools only get you so far.
--
Pure Personal Opinion | HoffmanLabs LLC