A bunch of recently released extensions impacted by the same faulty implementation

[Adrian_I]

Hello,

Recently we have face the need to enable some Plugins on our tenants, mostly the type of Plugins that are somehow involved with creating Synthetic Monitors and pushing events to existing ones. Unfortunately, getting those to work as expected was not an easy task and in my opinion the biggest blocker was trying to get the right support in order to find out the culprit.

After a few days of troubleshooting the plugins: custom.remote.python.sftp (version 1.021) and custom.remote.python.thirdparty_dns (also version 1.021) I concluded that most of our problems are related to the common libraries those two plugins are using. I will enumerate here some concerns that we had to troubleshoot and overcome on our own.

1. Both plugins failed to interact with the Synthetic API if the restInterface module is not enabled on the Active Gate that's executing the plugin (I couldn't find this stated as a requirement).

2. Both plugins implement the same method build_proxy_url which incorrectly builds the proxy url when a proxy address is given. The problems comes from the fact the proxy address is always prefixed with the character @ even when no username and password is given, resulting in an incorrect proxy url.

3. Both plugins have bundled an outdated urllib3 package (1.26.15) that can cause a incorrect SSL verification error  when a proxy is passed to any type of request:

 Max retries exceeded with url: /e/<our_env_id>/api/v1/synthetic/ext/tests (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1131)')))'

Can someone investigate this reported issues and give us some insight if there is any plan to address them? For now we're manually adapting the code to make the plugin work.

Regards,
Adrian

[Mike_L]

We'll look into it and get back to you. Do you mind sharing the support case(s) so we can look into what went wrong there?

[Adrian_I]

Hello Mike, 

There were two open items on this topic: 
- Support case Id #180446 (which is an ongoing issue right now)
- Support case Id #172770 (were we gave up waiting on a solution and we altered the plugin ourselves)

Please let me know how your investigation is going on.

[Mike_L · Accepted solution]

I talked it over with the developer and:

#1 will be added to the documentation.

#2 is indeed an issue which we'll resolve in an upcoming version.

Point #3 looks like you entered an https address to an http proxy, which would provide the error message you pointed out. Alternatively you entered a proxy address when the endpoint is going to localhost.

[Mike_L]

#1 has been added to the hub tile of the ping, port and DNS tiles.

[Adrian_I]

Hello Mike, thanks for your time looking into this!

Indeed for point #3, since we no longer have the option to provide the Dynatrace URL ourselves it will always use a localhost address (at least in our setup) for making the API calls.

I gave it a try with dropping the proxy address entirely and it works out as expected. So can you confirm that when making the API calls in this manner the workflow goes like:

Request from RemotePlugin to localHost address -> ActiveGate (gateway) simply gets the request and forwards it further (if given, via the proxy defined under section [http.client]) -> and finally gets to the Dynatrace Cluster .

Basically, what I am trying to ask if the ActiveGate (gateway module) simply acts as a proxy in this case.

[Mike_L]

You're spot on, the AG is just a proxy in this case and it'd use the http.client if configured.