Release Automation

Hi,

does anyone currently use SSL within their installation?

If you do have you experienced an upgrade? was it successful?

I tested an upgrade of non SSL install from v5.0.2 to v5.5.2 which was successful-ish - some post upgrade manual redoing to do (tomcat users/RUN_AS_USER reconfig).

I tested an upgrade of an SSL configured installation from v5.0.2 to v5.5.2 and i can't get the datamanagement appr to start - errors relating to jmx console parameters (these use to be present in webapps/datamanagement/WEB-INF/wrapperContext.xml but somewhere between v5.0.2 and v5.5.2 these now reside in distributed.properties but no amount of hacking will allow me to start the datamanagment app, I haven't gotten to the execution server upgrade yet but presume this will be the same albeit the jmx-console ssl params were originally in the applicationContext.xml but are now missing.

I have a feeling there is a problem with the install4j coding that simply isn't expecting anyone to configure jmx-console params and therefor just doesn't know what to do with params that are picked up during the evaluation during upgrade? Is a guess.

very interested if anyone has experienced the above and if so i'm hoping you can help me progress - ca support are not the quickest to respond as i've experienced.

thanks in advance.

Hi

not yet, but planning to do so soon. Actually I am planning to do a fresh install and somehow be able to update the database. I have played a lot with SSL under 5.0.2, trying to use our official keystores but in the end it failed due to bugs in the nimi implementation. Certificates with any extension don't work with nimi, and the official certificates we get do have those extensions. I hope this is fixed in 5.5.

I am not aware of any problems from what I've seen here in Support, but please keep us posted. If you do run into any problems, we'll be glad to jump right on this for you, as naturally this is a feature we want to work smoothly right on through the upgrade.

Hi,

Yeah there are issues. Previously jmx.web.console.ssl.* config was done in wrapperContext.xml (for DM) and applicationContext.xml (for Executionserver). Sometime after v5.0.2 this moved to the distributed.properties file. This config does not get upgraded so manual intervention is required.

Repository – even if your previous server.xml is configured only for https post upgrade seems to reenable non https too – so you have to manually comment out that section again.

Non ssl related

tomcat-users.properties in the repository does not get upgraded.

If you set RUN_AS_USER= in any of the start scripts for INIT integration – this gets wiped.

The new 64bit agent installer doesn’t even have a RUN_AS_USER= option, even though the install stdout instructions tell you to find and edit accordingly – I had to add this in manually ☹.

The watchdog script doesn’t work with ssl – you have to add a ‘-k’ to the curl command (this is not upgrade to v5.5.2 specific – simply missed by CA Dev in all ) – I raised a support case for this, and advised them of the problem and the fix. Bearing in mind this is a paid for product and this particular script is part of the core HA functionality and is a script not a config file, the response was that I, a customer, should make the edit to the script myself and the fix CA were proposing was to add some text to the online v5.5 documentation. WOW! I’d expect that kind of behaviour from open source not a paid for product – very cheeky.

The nolio_server.sh script has a bit of logic to determine the OS – there is a ‘tr’ command in it that needs modifying – by either surrounding the pattern match with single quotes or removing the square braces altogether. Bad scripting.

There are heaps more like this but I need to get back to my day job and stop moonlighting (albeit unpaid and without any agreement) as one of CA’s RA debug/test team.

I can only assume the CA RA test team are focusing their testing elsewhere?

Cheers

Stuart

I was not involved in that work so I cannot speak to that; however I can say our Development team is not ignoring any issues, but some do take longer than others to improve upon -- such being the nature of the beast unfortunately. I've let management know about your concerns, especially with having to edit the script. I'm sure the support engineer who advised that had a valid reason for doing so, but we can go back and revisit that to see if there might be something more we can do.  I'll check on that.

I also recommend logging some Ideas (enhancement requests) here in the Communities for the items you listed above, as Product Management does see and review every single one, and that would ensure management eyes on these items.

We absolutely positively do not expect customers to act as debuggers or testers, but unfortunately no product is perfect, and sometimes it's customers who have to point out defects -- which we strive to resolve as swiftly as possible. I know the development team is trying to reduce such occurrences with every subsequent release we put out as we push to make the software more and more reliable and predictable as move forward.

The SSL configuration the customer has to configure in numerous files is identical to that of version 5.0, meaning the customer has to do all the manual changes on all RA components. Not something I am execting from a commercial software. I expect a GUI where I can upload my certificates, a set of configuration options where I can enable/diasable stuff like HTTP/HTTPS, SSL between NAC and NES, SSL between NES and agents, etc. None of this here, plus the same major bug in NIMI implementation preventing you from using certificates with SSL extensions. I am sadly disappointed by CA, I am under the impression that the customer is not taken seriously enough. I also share the impression of being a debugger/tester with all the problem I had with the cert issue. I had certs with only Server extension, I was told I need Server + Client, so I reissued a whole set of new certs, still it did not work. In the end support said that SSL extension would not work with NIMI. All this took weeks of my time, sending logs and configuration. Worst of all this is still not fixed in 5.5.

I am very sorry to hear you're disappointed with your experience thus far. Speaking as a Support Engineer, my team and I take our customers extremely seriously.  I will contact management regarding your concerns as well, and would very much like to follow up with you to see what we can do to improve your experience.

I'm really sorry for your experience, however this is a valid feedback and we can improve.

So far we worked on improving our documentation on SSL, but we are not stopping there

I'm taking your feedback to QA and product management.

I would also like to encourage you to vote for the following idea:

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

Cheers,

Julia

Julia Reingold
CA Technologies
Support Delivery Manager

CA Limited | Ditton Park | Riding Court Road | Datchet, Slough | SL3 9LL
Office: +44 (0) 1753 577733 ext.20846 | Mobile: +44 (0) 7909 891155 | Julia.Reingold@ca.com

Thanks Julia for pointing this to me. Voted for! This is really a must if RA is to be labelled entreprise ready software. In its present state it's more akin a not ripe open source piece of code. I am managing another commercial software for which we have similar hardening requirements. There is a web GUI where you can upload the certificate, you don't have to manually edit a set of files, that's taken care of behind the curtains. Sadly this Communities idea has not even attracted enough attention to be considered by product management (at least it is not labelled that).

No worries, it has attention. Even if not yet evident, each and every single Idea gets Product Management eyes on it.  There are a lot of enhancements to review, so responses may not be as swift as we'd like them to be, but all are absolutely given careful attention.