CDR Tickets

~oseipokuw: Could you please provide screen shots of the host settings dialog box and for a successfully retrieved document in XMetaL following a logon (on DEV) using the settings shown in the first screen shot? Thanks!

I have attached a screenshot of the hosts file. It is located at C:\Windows\System32\drivers\etc. There is no dialog box for updating the hosts file. We update it manually using notepad.

When you launch the CDR loader, you get a dialog box with a button at the bottom to choose which tier you want to talk to. When you click that button you can choose the tier, as well as enter the host names for that tier. That's what I want to see.

I have attached it to the ticket.

Adding API host names to the hosts file did not work. Would you know why when on the CISCO AnyConnect VPN, I can access the cdr servers using the host names (for example cdr.cancer.gov) from the browser or command line but not the IP address? The IP address always times out. Is this the same for you?

Adding API host names to the hosts file did not work.

I'm not surprised, after looking more closely at the IP addresses you've got in your host file. Where did they come from? The IP address you've got for cdr.cancer.gov is 128.231.245.213, but that's nothing like what I get (10.133.204.90) from looking up the DNS name:

$ dig cdr.cancer.gov ALL

; <<>> DiG 9.8.3-P1 <<>> cdr.cancer.gov ALL
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16571
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cdr.cancer.gov.                        IN      A

;; ANSWER SECTION:
cdr.cancer.gov.         2105    IN      CNAME   cdr.ha2.cancer.gov.
cdr.ha2.cancer.gov.     30      IN      A       10.133.204.90

;; Query time: 22 msec
;; SERVER: 156.40.70.10#53(156.40.70.10)
;; WHEN: Fri Mar 16 09:29:47 2018
;; MSG SIZE  rcvd: 70

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10161
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ALL.                           IN      A

;; Query time: 9 msec
;; SERVER: 156.40.70.10#53(156.40.70.10)
;; WHEN: Fri Mar 16 09:29:47 2018
;; MSG SIZE  rcvd: 21

Didn't we have a discussion recently in which we asked you to have your network staff use the IP addresses which they got back from looking up the host names in DNS?

Would you know why when on the CISCO AnyConnect VPN, I can access the cdr servers using the host names (for example cdr.cancer.gov) from the browser or command line but not the IP address? The IP address always times out. Is this the same for you?

Aside from the puzzle over the IP addresses you're using (I can ping both the DNS names and the correct IP addresses from the command line successfully), there are multiple problems with trying to test using IP addresses from a web browser. First of all, as I tried to explain yesterday, we are using a single web server to serve up more than one web site. The web server cannot know which site a request should be routed to without the DNS name to which that site has been bound. Also, the cdrapi sites are not built to work with a web browser. They are used for tunneling the CDR client/server commands between XMetaL and the CDR code.

~duganal: Would you know who William's networking staff should talk to at NIH? My networking expertise is not deep enough to understand what they're trying to do. Thanks.

Thanks, Bob!
The IP addresses are what they call NATed addresses for the site-to-site VPN and they were provided by NIH. It is supposed to be used only when we are in the office. So, when we come home, we turn them off and use the 10.x.... addresses. The site to site VPN only allows traffic to the CDR servers through these IP addresses from the ICF Rockville location. We provided NIH the 10.x.... addresses and they NATed these addresses and provided us with what the 128.... addresses. I am able to successfully ping 10.133.204.90 from home but I am not able to login to XMetal. I get a "HTTP status code from login request:404" error which appears to indicate that my password is wrong but I have verified that my password is right. I will talk with our network team here to see if I can get some help.

Hi ~oseipokuw, talking to your network team sounds like a good next step. As we discussed yesterday, this issue isn't something to be solved within the CDR. I know this is frustrating – you and your team just want to do your work! Let me know if you would like for me to try reaching out to NIH Networking through our CBIIT contacts. It sounds like you have already gotten some support from them already, but not anything that solves all the problems.

I have modified the loader to be able to display the tier in the title bar even if the user provides an IP address instead of the DNS name in the Server Settings dialog box, in the unlikely event that IIS is able to route the requests to the correct site without the DNS name. I don't expect that to happen, but I've implemented the requested modification so we can mark this ticket as resolved. You will still need to work out network permissions problems with the appropriate IT staffs.

https://github.com/NCIOCPL/cdr-client/commit/a13fd7c

Thanks Bob! I will be talking with our network engineering team manager today.

~bkline I assume the loader has been updated for DEV and QA? I will be doing some tests with our network team tomorrow so I want to be sure that it is okay to test.

The change to the loader and DLL are on DEV and QA, but again let me remind you that it won't make it possible for you to connect to the API web service without the DNS name.

Yes, I understand that. I tried connecting from home and I was able to connect with the DNS name in the CDR Server field and the IP address in the API server field (and not the other way around) but I couldn't retrieve any document in XMetal. What I am trying to convince our network team here is to add these settings in our DNS server so that we can connect using the DNS names and avoid updating the hosts file. I am not very hopeful but I want to explore all my options before giving up.

I was able to connect with the DNS name in the CDR Server field and the IP address in the API server field (and not the other way around) ...

Right. The CDR Server is responsible for verifying your credentials, obtaining a session ID for you, and refreshing the client files on your local system. That succeeded because you provided the DNS name for that server. The API server is not used by the loader at all.

... but I couldn't retrieve any document in XMetal.

Again correct. The DLL does all of its client/server using the API tunneling site. Since you provided an IP address instead of the DNS name, the DLL can't find the API site, and therefore cannot handle any request which requires communicating with the repository.

Right. The CDR Server is responsible for verifying your credentials, obtaining a session ID for you, and refreshing the client files on your local system. That succeeded because you provided the DNS name for that server. The API server is not used by the loader at all.

Does it mean that the server name will always require the DNS name? I thought you modified the loader to be able to accept either IP address or DNS name for the server name? I understand that the API server name requires the DNS name.

Please read again very carefully what I wrote above:

I have modified the loader to be able to display the tier in the title bar even if the user provides an IP address instead of the DNS name in the Server Settings dialog box, in the unlikely event that IIS is able to route the requests to the correct site without the DNS name. I don't expect that to happen, but I've implemented the requested modification so we can mark this ticket as resolved. You will still need to work out network permissions problems with the appropriate IT staffs.

I tried to make it very clear that the modification does NOT address the fact that IIS is unable to route the requests to the correct sites without the DNS names.

Okay. Thanks! Seems there is nothing to test so I am marking this as QA verified and maybe we can mark it as closed.