@Dukestep Here goes: For any
Probe the only requirement for GHC is that it returns a Result object from Probe.perform_request(). That Result object should have a function get_report() returning the JSON struct, see here. That JSON struct requires the fields 'success', 'message' and 'response_time' to be present. See for example WMSDrilldown Probe. So you could define an overridden custom MyResult class that adds/returns custom fields to the Resultobject that your (custom) Probe returns. GHC's healthcheck mechanism will assemble (via addResult()) all Results for all Probes of a single Resource. If any has success == False the Resource fails. So you can forget about Checks. These are used in templated Probes that require no custom code like owsgetcaps.py at least where perform_request() is not overridden. The report struct of the last Resource Run is simply something like: last_report = self._resource.last_run within your custom Probe. Then you could compare hashes.
@ambarishroy-git you mean installing SSL certificates like via LetsEncrypt? I recommend always using a HTTP reverse proxy as GHC frontend that handles SSL via an HTTPS endpoint. My favorite is Traefik which is used on the GHC demo site. Traefik requires minimal config and automatically installs SSL certs via LetEncrypt. But you could also use
nginx or Apache2.
@justb4 I am already using Apache2.4 as a web server, but the issue is GHC I am using through docker container and by using HTTP reverse proxy in the Apache2 configuration for GHC it cannot run the GHC application as when ever GHC is running by docker it is taking the relative path internally where the container is stored, how can we fixed the SSL issue by using HTTP reverse proxy in while running GHC through docker.
@ambarishroy-git Perhaps I'm misinterpreting your question, but I hope this helps: you install the certificate on the apache backend and then configure the reverse proxy to connect to the docker instance (localhost:8083 in the examples of the documentation ). Make sure your firewall is set to only accept connections to that port from localhost. Then you don't need to encrypt traffic from apache to the docker instance. The docker documentation gives to options to set this up: the first one doesn't encrypt between apache and docker, the second one does.
@ambarishroy-git to add to @borrob 's answer: if you need to run GHC behind a proxy using a relative path (subpath) see the GHC documentation.
@justb4 and @borrob I have tried using reverse proxy in Apache httpd.conf file for GHC, but the issue is it cannot take the relative path. I am using RHEL as OS and docker for running the geohealthcheck. While running through the docker I am running the command (docker run -d --name geohealthcheck -e GHC_RUNNER_IN_WEBAPP=True -e GHC_SELF_REGISTER=True -p 9090:80 -v ghc_sqlitedb:/GeoHealthCheck/DB geopython/geohealthcheck) for running the pulled image of GHC and now when I am placing proxy-reverse proxy for (http://127.0.0.1:9090/geohealthcheck) in the apache configuration, but it cannot fine. But with http it is running on (http://127.0.0.1:9090) without SSL.
@ambarishroy-git is your Apache instance also running in Docker? Then forwarding to 127.0.0.1 will refer to the Apache container instance. You must then refer to the GHC container-name like http://geohealthcheck:9090. Otherwise it is a mismatch in your Apache (reverse) proxy conf. If you supply a sub-path you will need to set
SCRIPT_NAME in the GHC startup env (-e option), as I indicated above referring to the docs.
@ambarishroy-git so GHC at http://127.0.0.1:9090 is working? Then in your Apache proxy setting (be sure to also test the config with
apache2ctl configtest) have a config entry like (experiment with SCRIPT_NAME): <Location /geohealthcheck>
ProxyPreserveHost On
ProxyPass http://127.0.0.1:9090
ProxyPassReverse http://127.0.0.1:9090
RequestHeader set SCRIPT_NAME /geohealthcheck
</Location>
@tomkralidis Thanks. I've managed to address your comments. Perhaps good to discuss here whether we want to keep
paver around and what the cli command call should be ? - see discussion in #310 .
re: CLI name. I imagine still calling it
ghc is risky enough? GeoHealthCheck doesn’t bother me too much but not sure about others. @justb4 / @archaeogeek ?
re: CLI name. I imagine still calling it
ghcis risky enough?GeoHealthCheckdoesn’t bother me too much but not sure about others. @justb4 / @archaeogeek ?
Yes ghc is Haskell-related. Always short commands and lowercase on Unix (he, I worked for the company that invented ls and cd, and C!), hence my suggestion for geohc. (Still need to go through PR & comments, but this was easy to answer).
There is an error popping on when running the resource tests of GHC with respect to pygeoapi. It does not validate the OpenAPI Compliance with this error:
I didn't dive into this yet, but was there a change with the specs or pygeoapi, or is this a big of GHC ?
GeoHealthCheck.probe - INFO - Result: success=False msg=Validate OpenAPI Compliance:HTTP Error 404: Not FoundI didn't dive into this yet, but was there a change with the specs or pygeoapi, or is this a big of GHC ?
Finally tracked it down I think: read here: opengeospatial/wps-rest-binding#63 , thus looks like no GHC nor pygeoapi error...
here is a screenshot of the issue
Here is the network tab: https://imgur.com/5iEX0Qa
Proxy settings: https://imgur.com/4vtoQOr
its weird if i refresh it works, if i refresh again it breaks again