Wrong link in mgmt UI

[lcaouen]

In mgmt UI, in the check status view, the link to the Quick Chart is created from the URL in the appliance.xml. This is a problem for 2 reasons :

• if we have a revserse proxy using an other port or url. For instance http://localhost:17668/retrieval/bpl but the reverse proxy is using the IP and port 443 for https
• if the xml is set up with http://localhost:17668/retrieval/bpl and we call it with the local network ip

[jacomago]

The data_retrieval_url doesn't need to match the retrieval_url. It is essentially a url just for the public interface.

[lcaouen]

Sorry my mistake. It's the retrieval_url not the data_retrieval_url

[jacomago]

I mean, I don't really understand the problem. Why can't you set data_retrieval_url to the reverse proxy url?

[minijackson]

With the architecture we plan on deploying with @lcaouen, the Archiver Appliance servers will be inside an isolated "internal" network, so we need to configure retrieval_url to point to the internal IP address.

But, we also want the web interface to be accessible from outside of that network, so we plan on deploying a reverse proxy that is both inside the internal network, and inside the "public" network.

Here's a quick drawing of what I mean:

With this setup, when Archiver Appliance wants to communicate with the other webapps, it should use internal IP addresses (10.x.x.x/24), but when generating URLs for the end user, it should use the IP addresses or domain names that are public (192.168.x.x). The user can't access the internal network, and Archiver Appliance can't use IP addresses in the public network, so there is no good value for retrieval_url.

In our setup, the reverse proxy is also used for authentication and access control, so it's important for us that Archiver Appliance is not accessible directly from the public network.

[jacomago]

Yes, I understood the setup. The retrieval_url is for the archiver to talk with itself and other appliances. But the data_retrieval_url is for external access for exactly the use case you specify. For example, you might set the appliances xml to something like:

 <appliances>
   <appliance>
     <identity>archappl1</identity>
     <cluster_inetport>archappl1:17670</cluster_inetport>
     <mgmt_url>http://internal_ip:17665/mgmt/bpl</mgmt_url>
     <engine_url>http://internal_ip:17666/engine/bpl</engine_url>
     <etl_url>http://internal_ip:17667/etl/bpl</etl_url>
     <retrieval_url>http://internal_ip:17668/retrieval/bpl</retrieval_url>
     <data_retrieval_url>https://archiver.domain.retrieval</data_retrieval_url>
   </appliance>
   <appliance>
     <identity>archappl2</identity>
     <cluster_inetport>archappl2:17670</cluster_inetport>
     <mgmt_url>http://internal_ip2:17665/mgmt/bpl</mgmt_url>
     <engine_url>http://internal_ip2:17666/engine/bpl</engine_url>
     <etl_url>http://internal_ip2:17667/etl/bpl</etl_url>
     <retrieval_url>http://internal_ip2:17668/retrieval/bpl</retrieval_url>
     <data_retrieval_url>https://archiver.domain.retrieval</data_retrieval_url>
   </appliance>
</appliances>

Where https://archiver.domain.retrieval is an address to a reverse proxy sending to http://internal_ip:17668/retrieval, you can even specify the reverse proxy to loadbalance with http://internal_ip2:17668/retrieval/bpl if your cluster is larger than one. Some of this is documented at https://slacmshankar.github.io/epicsarchiver_docs/installguide.html

Does that make sense? And does it work for your use case?

I think another option that can be set up is to separately host the https://github.com/slacmshankar/svg_viewer . But you still need to set the data_retrieval_url to the https://archiver.domain.retrieval.

[lcaouen]

You're totally right. We didn't understand data_retrieval_url parameter could do the job. I'm gonna close the PR !