@tomkralidis see my review at #280. We're good to go! After merge in about 15 mins we can check on https://demo.geohealthcheck.org.
(crossing msgs :-))
(as Docker image is built on GH push and pulled on demo site)
(and crossing fingers)
.. build ok now.
@borrob and I had some discussion on a Paver/Click issue. Realized GHC needs a PSC. @tomkralidis shall we initiate a PSC, modeling after pygeoapi PSC?
We're getting a lot of "Still Failing" notifications for a WWW-LINK resource. The resource is an extraction of error messages in a log. We'd like to be notified only if the content of the page has changed since the last check even if it continues to fail.
@Dukestep I think checking with respect to a previous run will be very tricky, since GHC doesn't store the actual response for every run. Perhaps you can make a custom check that stores a md5 hash of the response and verifies the response with that? When it does change, then you'll have to update the hash again.
@borrob Yeah, I was thinking of writing a custom check (without the md5 hash approach, but that's a good idea!). Where would you suggest I store the hash? I was thinking the check could store the hashed response in the result message, I could then call the GHC API for that resource in the custom check and compare the hashes?
Not sure if that's a "smart" approach though.
The challenge here is that if there is no difference between the hashes I'd have to set the the check result to True and that would make GHC believe the check has passed when it technically should still be failing (since there are still log errors on the page but they're just the same as the last run...)?
@Dukestep When you are creating your own plugin, you have full control on when the check should pass or fail. You could make it such that once the content (or the hash) is the same, GHC shouldn't bother with the rest. The database would be the obvious choice to store the (hashed) response. I like your idea to put it in the result report. Perhaps you can access the database directly and you don't need to go over the api.
@borrob Thanks for the pointers, really appreciated it (oh, and the recent work on the Python 3 PR!).
@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).
