Is there a structured format of version info for OS-level executables?

Question

I am looking for a structured format of version info for OS-level executables, such as in /usr/bin and /usr/local/bin. The problem we are having is the inconsistent architecture between our PROD and TEST environments and we are finding that many executables in our lower environments have had patches applied whereas PROD has not, which invalidates a lot of testing -- stuff works in TEST but doesn't in PROD because of such system discrepancies.

So I would like to run a system assurance check to list all executables and get the version number but nothing else and then produce deltas. Some commands don't support the -version option but even those that do display very verbose, free-text format of a version narrative and the version number is buried somewhere within, with no way to extract it programmatically.

Alternatively, I was thinking to run a file-level cksum for every executable as an option of last resort but I was hoping that there would be a way to extract version info relevant fields programmatically.

Thanks

Answer 1

I'm inclined to say there is no easy way to do this. I say this because versioning is not at all a standarized procedure in UNIX/Linux or with any of the vendors at least at a program level.

A suggestion might be to examine the installed package information which does contain versioning information.

However, if people install products not using the standard package manager for your distribution, then you'll have faulty information as well.

To be absolutely sure, you'll probably have to go with some type of testing checksums between the systems.

Answer 2

As you already received an answer from @mdpc I'll just provide an opinion to your original problem. I wouldn't go down this road as this opens a can of worms and your programs in general should run on all systems (also check if your system still works if you run in a different local). You should also not really rely on the output/commands themselves but use the appropriate API to access/modify the information.

Anyway here are some ways which could help to mitigate your problem:

1. Use configuration management and specify which programs/libraries have to be installed on the machine. You can typically also specify the version number. Another great thing about using configuration management is that you can typically get all the information about your system, i.e. which kernel is running, how many NICs are in the system etc.
2. Depending on the programming language you are using you may want to look into virtualized environments, i.e. bundler for ruby or virtualenv for python.
3. Use chroots to setup an environment to your specific needs or (even better)
4. Just ship your environment as a VM-image

Answer 3

Packages are the answer (you should know that if you come from SunOS).

On CentOS you should use RPMs - nothing else.

Force your developers to deliver everything as rpm - then you will have that structured information in your RPM-database (which can even be queried with standard SNMP-tools).

Answer 4

As far as Solaris 10 is concerned, files belonging to the OS and files provided by third parties in the form of SVR4 packages are already versioned/checksumed and identified. e.g. :

 # pkgchk -l -p /usr/bin/ls
Pathname: /usr/bin/ls
Type: regular file
Expected mode: 0555
Expected owner: root
Expected group: bin
Expected file size (bytes): 18700
Expected sum(1) of contents: 1763
Expected last modification: Mar 25 00:04:57 2010
Referenced by the following packages:
        SUNWcsu
Current status: installed

Most of this information is in the /var/sadm/install/contents file. Files that weren't installed using the standard tools, i.e. file provided as a tarball or a zipped archive are unknown of the package database so must be processed a different way. Checksums comparison looks like a good approach to detect discrepancies as there is no standard anyway.