Toad World® Forums

Unable to start DevOps tool kit


#21

John

What screenshot would you like me to post ?

Yes, I see the same URL in both cases ( proxied and non proxied connection to the internet).

Also, the URLs www.toadworld.com/products/toad-devops-toolkit/p/verify_e mail and community.toadworld.com/products/toad-devops-toolkit/p/verify_email seem to display the same web page.**

Varad

<RESOURCE type="link" category="quest" identifier="tdt_openid_redirecturl">

<URL>

<![CDATA[

https://www.toadworld.com/products/toad-devops-toolkit/p/verify_email

]]>

</URL>

</RESOURCE>


#22

Hey Varad,

The two links may display the same page, but their url addresses are different. The resource XML snippet you just posted shows the correct url, which is different than what you originally posted from the login page (the original one referenced “community.toadworld.com” whereas the one you just posted references “www.toadworld.com”). This tells me that the file you referenced here came from the updated version.

As a result, if you’re still seeing the “community” url in your login page then that machine is pulling its url from a cached version of the file. I would check two things next:

  1. Try the test again, pulling the xml file from a machine behind the proxy and a machine not behind the proxy. They both should display “CDATA[https://www.toadworld…”. If one of them says “CDATA[https://community.toadworld…” then that one is cached.

  2. If they both return “CDATA[https://www.toadworld…”, then perhaps the permissions on your local machine are preventing read/write access to your local application data directory.

    a. Try browsing to your local application data directory (c:\users<username>\AppData\Local\Quest Software\Toad Devops Toolkit) and delete the “online_resources.xml” file located there.
    b. Keep your explorer window open and launch TDTLM.
    c. See if the online_resources.xml is recreated and check its contents for that redirecturl.

-John


#23

John
As soon as I launch the TDTLM tool 2 files got created in C:\Users\vacharya\AppData\Local\Quest Software\Toad Devops Toolkit.
There is no file named ‘online_resources.xml’ in this directory.

The file names are
tdtlm.txt
TDT7D75.tmp

Varad

The contents of the ‘tdtlm.txt’ file are as below. The file named TDT7D75.tmp is empty.

15:16:15:477 Loading Licenses
15:16:15:567 HTTP Response Message: 11004 - 11004: [11004] Valid name, no data record (check DNS setup)
15:16:15:567 Logging in


#24

Hi Varad,

Error code 11004 is a Windows socket error. It’s basically telling you that it cannot reach the destination address. This could be for a number of reasons: DNS misconfiguration, firewall blocking access, proxy blocking access to download the required file, etc; however, based on the error message you’re receiving, it appears to be related to your local DNS/Proxy configuration. It looks like the DNS server is having trouble resolving the named address to an IP address.

Looking back through your posts, I see you listed your proxy host as “http=proxyit.cac.com”. Try removing the “http=” from that string and see if you still have trouble connecting.

-John


#25

John
I updated the proxy host setting to be ‘proxyit.cac.com’ .
Now, after I launch TDLM, it does retrieve the ‘online_resources.xml’ file and this file has the correct value for ‘tdt_redirect_url’ (www.toadworld.com/products/toad-devops-toolkit/p/verify_email).
However, after I submit the login page I briefly see the 'Thank you for verifying email page and I get bounced out back to the login page. The ‘tdlm’ log file shows a HTTP 403 error. Not sure for what action though.

Varad

tdlm.txt

21:15:35:437 Loading Licenses
21:15:35:909 HTTP Response Message: 403 - Forbidden
21:15:35:909 Logging in
21:15:35:937 Logging in
21:16:38:486 Logging in
21:16:59:341 Logging in


#26

Hi Varad,

Is your proxy server configured to strip any headers when making requests? It looks like the authorization code is not making it to the endpoint to validate the request.

-John


#27

As per our Security folks

‘Yes this makes sense…

However, we do not strip any headers.

Our proxy only monitors the initial request and makes sure it is allowed.

The proxy does not do anything with the packets.

Varad


#28

Hey Varad,

Can you e-mail me offline your entire tdtlm log file? I’d like to see the whole thing to help identify what might be going on. Can you either send me a private message on this forum or e-mail it to john[dot]bowman@quest[dot]com?

Thanks!

-John


#29

John
What I posted earlier are the entire contents of the tdlm log file .
I now believe that the issue preventing the API key download to my work machine is something that is local to my work machine/work infrastructure. I say this because after I installed the DevOps TK on my personal computer and ran and logged into TDLM, I was presented with a pop-up screen which displayed the DevOpsTK trial license and access key information. When I tried to dismiss this pop-up screen, I was warned that I had not yet installed an API key on my machine. I dismissed the screen any way.
I will now work with the Desktop engineering team tomorrow and have them help me further in diagnosing the issue.
Just in case you find it useful, I have pasted below the contents of the ‘tdlm’ log file from my personal computer.
Varad

18:28:09:018 Loading Licenses
18:28:09:442 HTTP Response Message: 403 - Forbidden
18:28:09:442 Logging in
18:28:09:504 Logging in
18:28:24:889 Loading Licenses
18:28:26:045 HTTP Response Message: 200 - OK


#30

Hey Varad,

Glad to hear it’s working on your personal computer. One of my coworkers also suggested to make sure you verify your port for the proxy server. In your earlier post, you mentioned you were using port “80”. You may need to verify that port with your network administrator.

Good luck in your research on your end. Feel free to let me know what you find.

-John