Distsrv and expire.cfg

[Anon Anon]

So between this bug

 

https://communities.ca.com/ideas/235720621 

 

Yes I feel it's fair to consider this a defect, it worked this way for years and now it does not. I feel it was both reasonable and responsible for us to build firewall rules around this legacy behavior

 

and this bug:

 

https://na4.salesforce.com/articles/Case_Summary/Probe-license-update-is-not-working?popup=true

 

I am posed to have some headaches when my licenses expire here shortly. I would like to get ahead of this by triggering the probes that have expiration dates to go update the epoch timestamp in the expire.cfg file BEFORE my expiration date hits, without having to either corrupt the expire.cfg checksum (thus forcing the robot to recreate this file with the updated epoch time) or redeploy the probe.

 

Does anyone know how to get the probes to update this timestamp outside of the two ways I listed above? I am guessing not but thought I would ask.

[Yu Ishitani]

Hello. Regarding the article.

https://na4.salesforce.com/articles/Case_Summary/Probe-license-update-is-not-working?popup=true

 

I am sorry that you have headache.

You are right what you mentioned.

 

Redeploy probe from distsrv (which has new license info) to robot will update expire.cfg with probe's new license expiration date.

This would be actionable if there are few probes to remedy.

 

Move expire.* from robot directory, then restart controller will force robot to retrieve new lincese from distsrv and re-generate expire.cfg with the latest license info.

It is expected to work because controller restart is involved in the step. However, the article mentioned, controller restart is necessary.

 

Thanks

Yu Ishitani

[GraemeMcHale]

I've had a fix/change to the tunnel port allocation algorithm added to the backlog for the Hub / Robot team.

 

We've started looking in to the expire.cfg work flow and I may contact you with further questions.

 

Regards,

Graeme McHale

Software Architect, CA Technologies.

[Anon Anon]

Happy to answer any questions case is 00167740 if you have not already been pulled into on the back-end. Despite two webex's and various updates I still was not left with 100% certainty that they understand why this is going to be an issue for me or what the problem is.

 

I feel at this point my only solution is to either push the new licenses down since I can't rely on the robots being able to communicate with the distrv OR as in intent of my case script something that I can time trigger and coordinate with forcing the robot to update the probes entry in expire.cfg. In my testing, corrupting (and I must assume moving) the expire.cfg resulted in robot inactive alerts, which is an even bigger headache in my env. In my env I have 10,000 entries on the expire.cfg not updated thus far. The last thing I need is for the expired probes alarms to trickle in over the course of net 6 months when the robot is restarted and check the datestamp. 

 

Thanks as always.