LMP key validation
Article ID: 252792
Updated On:
Products
Issue/Introduction
Is there a way to tell any product to read and verify the CALMP KEYS file once it has been updated?
If not, how frequently does the key get read and potential errors get written to the console?
Environment
VM Product Manager and VM:Manager suite of products
Resolution
If you update the CALMP KEYS file and choose to NOT recycle any of the products, when each of the products reassesses the file the next time (within an hour), the product will recognize that the file has changed and reprocess all the keys to pick the "best one". And, you will see the results of reading/validating each key in the product's console. If any are invalid, expired, whatever..., that should be indicated for that particular key.
For each product/code as long as there is a valid and unexpired key in the CALMP KEYS file for that product/code, the product will not give violation messages when commands are issued. If there are multiple valid and unexpired keys for a product/code, then the "best" key is used ... that is, the one that has the longest expiration date into the future.
When keys are within 30 days of expiring you will get messages on the product console about "the key will expire in NN days", but commands will not get violation messages until the keys expire.
We recommend when you first see the "keys are expiring" messages on the console(s), obtain new keys and install them. After, you will see that the "keys are expiring" messages go away (within an hour) on each product console.
Additional Information
Leaving the old keys in the file (that are not yet expired, but possibly expiring) and adding in the new keys gives you the ability to confirm the new keys you have added are valid (do not get some error message after they are processed) when the product sees the CALMP KEY file has changed and reprocesses every key in the file showing the results on the consoles. If there is a problem with the new keys, you'll see it and can correct the problem while the products continue to run on the previous set of keys.
Also a point to note is that the validation (lack of an error message following each key) on the console of *any* product means the keys are validated. In other words, you don't need to specifically verify the key for VM:Spool (as an example) on the VMSPOOL server. If the VM:Spool key gets no error when VM:Spool processes the product/code key and issues no error following the key, it is validated. After the "pre-validation" you can then remove the old keys leaving just the new/current set.
Since all Broadcom keys are now "SITEID Keys" (meaning they are not tied to a specific CPU), you can do this "pre-validation" on any test system. Then you can use your preferred method of simply replacing the CALMP KEYS file on all your other systems with the pre-validated CALMP KEYS file from your test system after you have removed the previous set of keys, so you won't have to have both sets of keys in the file on your production systems for any amount of time.
Feedback
