Stream: ibm
Topic: Installation
Alexander Kiel (Oct 29 2019 at 09:07):
Hi, I have installed your FHIR Server according to the Guide, but I get the following response on:
curl -k -u fhiruser https://localhost:9443/fhir-server/api/metadata
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>404 Not Found</title></head><body><h1>Not Found</h1><p>The application or context root for this request has not been found: /fhir-server/api/v1/metadata</p></body></html>
Lee Surprenant (Oct 29 2019 at 11:38):
hi Alexander please try curl -k -u fhiruser:change-password https://localhost:9443/fhir-server/api/v4/metadata (note the user password and the "v4" in the path)
Lee Surprenant (Oct 29 2019 at 11:39):
also, if you happen to find a link thats missing that in the docs, please let us know :-)
Paul Bastide (Oct 29 2019 at 14:05):
The site should be updated now. as well as the passwords to the default change-password
Paul Bastide (Oct 29 2019 at 14:05):
we use gatsby so it might be 'uber cached
Alexander Kiel (Oct 29 2019 at 15:00):
@Lee Surprenant Thanks. The path v4 vs. v1 was the problem. I found the password in the config file.
@Paul Bastide Thanks for updating the config.
Something slightly different: Is it possible to use the FHIR server without authentication and without TLS termination?
Lee Surprenant (Oct 29 2019 at 15:00):
its possible but we make you do some work
Lee Surprenant (Oct 29 2019 at 15:00):
its "all TLS" by default
Lee Surprenant (Oct 29 2019 at 15:01):
IIRC our compliance folks asked us to do that a long time ago...we could revisit that decision now that we're open
Alexander Kiel (Oct 29 2019 at 15:01):
I usually run my servers without TLS behind a TLS terminating load-balancer
Lee Surprenant (Oct 29 2019 at 15:01):
i think there's two spots you need to update to run with HTTP
Lee Surprenant (Oct 29 2019 at 15:01):
the easy one is in server.xml
Lee Surprenant (Oct 29 2019 at 15:02):
not sure if you're familiar with WebSphere Liberty (or OpenLiberty) application server
Lee Surprenant (Oct 29 2019 at 15:02):
but server.xml is like the 1 config file that drives everything in Liberty
Lee Surprenant (Oct 29 2019 at 15:03):
there's a line like this: <httpEndpoint host="*" httpPort="-1" httpsPort="9443" id="defaultHttpEndpoint" onError="FAIL"/>
Lee Surprenant (Oct 29 2019 at 15:03):
you can change it to <httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint" onError="FAIL"/>
Lee Surprenant (Oct 29 2019 at 15:03):
or whatever you want
Alexander Kiel (Oct 29 2019 at 15:03):
I'm not familiar with WebSphere Liberty, but with Glassfish and Tomcat.
Lee Surprenant (Oct 29 2019 at 15:04):
should be possible to run our webapp on Glassfish but we've never done it and so there's probalby lots of gotchas
Alexander Kiel (Oct 29 2019 at 15:05):
No it's ok. I didn't mean to try to run it in Glassfish.
Lee Surprenant (Oct 29 2019 at 15:05):
the install should have given you structure like wlp/usr/servers/fhir-server
Lee Surprenant (Oct 29 2019 at 15:05):
thats where you should find server.xml
Lee Surprenant (Oct 29 2019 at 15:05):
this one is a supported config change and the server will even auto-restart to pick it up I think.
BUT, there is also a second spot to change.
Lee Surprenant (Oct 29 2019 at 15:05):
and this one is harder...
Alexander Kiel (Oct 29 2019 at 15:06):
If I add a HTTP port, I get a redirect to https
Lee Surprenant (Oct 29 2019 at 15:06):
getting there...
Lee Surprenant (Oct 29 2019 at 15:07):
our webapp itself has a transport restriction enabled
Lee Surprenant (Oct 29 2019 at 15:07):
Lee Surprenant (Oct 29 2019 at 15:08):
i need to think through the best way to change that...
Lee Surprenant (Oct 29 2019 at 15:09):
@Paul Bastide curious if you have thoughts on this one ^
Lee Surprenant (Oct 29 2019 at 15:09):
ideally we'd have a way for users of the binary release to run with HTTP if they want
Lee Surprenant (Oct 29 2019 at 15:09):
without needing to hack the war file or build it themselves
Lee Surprenant (Oct 29 2019 at 15:10):
@Alexander Kiel wanna open an issue (enhancement request) for this one?
Alexander Kiel (Oct 29 2019 at 15:10):
Ok I see.
Alexander Kiel (Oct 29 2019 at 15:10):
Yes I can do that. Directly on GitHub?
Lee Surprenant (Oct 29 2019 at 15:10):
yes please
Lee Surprenant (Oct 29 2019 at 15:10):
https://github.com/ibm/fhir/issues
Lee Surprenant (Oct 29 2019 at 15:11):
in meantime, you can explode the war file, change this one file to remove the transport-guarantee, re-zip it into a war, and replace the old one in the server. sorry :-P
Lee Surprenant (Oct 29 2019 at 15:12):
actually, probably easier just to clone the project and build it yourself
Lee Surprenant (Oct 29 2019 at 15:13):
no need for full setup...you'd just edit that one file and then run:
mvn clean install -f fhir-parent -DskipTests
Lee Surprenant (Oct 29 2019 at 15:14):
might even get away with just mvn clean install -f fhir-install, but i'm not positive it would rebuild fhir-server-webapp that builds the war
Paul Bastide (Oct 29 2019 at 15:24):
I think we can drop this into a separate war as part of the build. I wouldn't include it in the fhir-install. We could mark-it experimental
Lee Surprenant (Oct 29 2019 at 15:34):
I think I'd rather not introduce separate build artifact for it. I just wish there was a simple way to say "I want to expose this over HTTP and I know what I'm doing so just let me"
Alexander Kiel (Oct 29 2019 at 15:35):
I have my issue here with more context to decide if it fits your FHIR server: https://github.com/IBM/FHIR/issues/331
Paul Bastide (Oct 29 2019 at 15:36):
Thanks, I can look at it in the next 1-2 days. We just need to figure out our build packaging implications
Lee Surprenant (Oct 29 2019 at 15:36):
thanks Alexander. we also run this in our cloud on kubernetes, so its definitely a scenario we want to major in.
Lee Surprenant (Oct 29 2019 at 15:36):
today we do that with TLS on, which our security folks make us do
Lee Surprenant (Oct 29 2019 at 15:37):
on the radar is exploring use of Istio to manage the pod-to-pod TLS
Alexander Kiel (Oct 29 2019 at 15:38):
And do you have an additional TLS terminating load balancer or do you just tunnel the TLS connection though a load balancer?
Lee Surprenant (Oct 29 2019 at 15:38):
mostly because managing the certs is such a huge pain
Lee Surprenant (Oct 29 2019 at 15:39):
yes, we're using IBM Cloud Kubernetes Service (IKS) and I believe its using nginx-ingress under covers
Lee Surprenant (Oct 29 2019 at 15:39):
so thats terminating the TLS
Lee Surprenant (Oct 29 2019 at 15:39):
but then it creates new TLS connection to the app server on the other side
Lee Surprenant (Oct 29 2019 at 15:39):
everything encrypted
Alexander Kiel (Oct 29 2019 at 15:40):
I didn't look into istio, only heard of it. Does it manage the certificates?
Lee Surprenant (Oct 29 2019 at 15:40):
not sure :-)
Lee Surprenant (Oct 29 2019 at 15:40):
i'm hoping it helps us there
Lee Surprenant (Oct 29 2019 at 15:40):
cuz managing the certs is a PITA
Lee Surprenant (Oct 29 2019 at 15:40):
today we just ship with a self-signed cert
Alexander Kiel (Oct 29 2019 at 15:41):
We have the data flow inside the cluster unencrypted. But yes, you are right, one should encrypt everywhere.
Lee Surprenant (Oct 29 2019 at 15:41):
and we just tell all the clients (other pods in the cluster) not to validate the server cert hostname :-P
Lee Surprenant (Oct 29 2019 at 15:41):
but at least its encrypted :shrug:
Alexander Kiel (Oct 29 2019 at 15:43):
I don't like self-signed certificates and using curl -k. :-) That is just bad guidance and negates the advantages of having TLS mostly.
Lee Surprenant (Oct 29 2019 at 15:43):
i don't disagree
Lee Surprenant (Oct 29 2019 at 15:43):
we need better solution for inter-pod (intra-cluster) TLS
Lee Surprenant (Oct 29 2019 at 15:43):
and I think Istio can help us here
Lee Surprenant (Oct 29 2019 at 15:44):
I just havn't gotten to that yet (like so many other things...)
Alexander Kiel (Oct 29 2019 at 15:46):
I agree using TLS for pod-to-pod communication but it should use a proper CA. So maybe Istio is a solution here.
Alexander Kiel (Oct 29 2019 at 15:48):
So please do not jump on the issue implementing dual builds. Just take it as a discussion whether it is more practical to manage proper signed certificates outside of WebSphere or not.
Last updated: Apr 12 2022 at 19:14 UTC
