Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 22 15:55
    borrob synchronize #310
  • Jan 21 18:18
    borrob synchronize #310
  • Jan 20 21:11
    dersteppenwolf commented #282
  • Jan 20 20:44
    borrob commented #282
  • Jan 18 17:39
    borrob commented #9
  • Jan 17 20:29
    borrob labeled #313
  • Jan 17 20:29
    borrob labeled #313
  • Jan 17 20:28
    borrob opened #313
  • Jan 17 20:13
    borrob assigned #312
  • Jan 17 20:10
    borrob labeled #312
  • Jan 17 20:10
    borrob opened #312
  • Jan 15 17:56
    justb4 commented #311
  • Jan 15 15:46
    borrob labeled #311
  • Jan 15 15:46
    borrob opened #311
  • Jan 15 08:57
    borrob synchronize #310
  • Jan 13 20:54
    borrob synchronize #310
  • Jan 13 20:44
    borrob synchronize #310
  • Jan 09 11:32
    justb4 commented #310
  • Jan 09 11:29
    justb4 milestoned #310
  • Jan 09 11:29
    justb4 labeled #310
Rob van Loon
@borrob
The Python3 PR is ready to rock and roll!
Tom Kralidis
@tomkralidis
thanks @borrob ! @justb4 I can squash/merge once you review/comment
Tom Kralidis
@tomkralidis
@justb4 I am merging #280, ok?
Just van den Broecke
@justb4
@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)
Just van den Broecke
@justb4
fixing readthedocs build (was still on Py2)...
.. build ok now.
Just van den Broecke
@justb4
@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?
Etienne Pelletier
@Dukestep
Hi all, is there any way that GHC can send an email notification ONLY if the content of a WWW-LINK has changed, even if it's still failing?
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.
Rob van Loon
@borrob
@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.
Etienne Pelletier
@Dukestep
@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...)?
Rob van Loon
@borrob
@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.
Etienne Pelletier
@Dukestep
Thanks for the reply. I figured the DB would be best and I don't want to go about messing with the existing models to avoid migration headaches down the line, etc. I've got this working now via including the hash in the result report and that should be good for now.
@borrob Thanks for the pointers, really appreciated it (oh, and the recent work on the Python 3 PR!).
Just van den Broecke
@justb4
@Dukestep @borrob good to hear! Yes, the Result report is a JSON structure stored as a Run string attr in the DB. When using custom Probes/Checks indeed you could even add custom fields. But you found a solution, good!
Etienne Pelletier
@Dukestep
@justb4, hmm, adding custom fields in the report within a Probe/Check would be great... can't seem to find how I do that though. I know I can modify the message as part of self.set_result() but where/how would I add a custom field to the report with a custom Check?
Just van den Broecke
@justb4
@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.
Etienne Pelletier
@Dukestep
@justb4, fantastic! Thanks for sketching that out from A to Z for me. Makes it much more clear. I look forward to implementing this approach :).
Just van den Broecke
@justb4
@Dukestep one correction: a Probe should provide Result as self.result after perform_request().
Etienne Pelletier
@Dukestep
Great! Now that I'm wrapping my head about the architecture of GHC, this doesn't seem like it will be too tricky to implement.
ambarishroy-git
@ambarishroy-git
hello everyone, I have one doubt, can anyone help me out on how to configure SSL configuration in GeoHealthCheck.
Just van den Broecke
@justb4
@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.
ambarishroy-git
@ambarishroy-git
@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.
Rob van Loon
@borrob
@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.
Just van den Broecke
@justb4
@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.
ambarishroy-git
@ambarishroy-git
@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.
Just van den Broecke
@justb4
@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
@ambarishroy-git
@justb4 My apache is running outside the docker in the local machine that is why I am using 127.0.0.1/localhost with port 9090 and running with http.
Just van den Broecke
@justb4
@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>
Rob van Loon
@borrob
I made a PR to fix issue #189 (unify CLI).
Tom Kralidis
@tomkralidis
thanks @borrob . I'll review tomorrow.
Tom Kralidis
@tomkralidis
hi all: FYI as an OSGeo Community project we can request a budget of some funding for 2020 (budget meeting is Monday). Suggesting $500 USD for GHC stickers and the logo that Just paid for. Thoughts?
Just van den Broecke
@justb4
:thumbsup: thought: also budget for GHC domain name/DNS (about $10,- a year, 5-year already paid 2016/11/16-2021/11/16 , think split among @tomkralidis and me) and demo server hosting (I pay about EUR 60,- p/y).
Tom Kralidis
@tomkralidis
+1.
Rob van Loon
@borrob
@tomkralidis Great! +1
Tom Kralidis
@tomkralidis
@borrob sorry for the delay. I’ve done a review of #310 — great work!
Rob van Loon
@borrob
@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 .
Tom Kralidis
@tomkralidis
ok good idea. I say remove paver since users can always use a previous version of GHC that uses Paver. Given we are pre 1.0 we are not bound to supporting a stable branch.
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 ?
Rob van Loon
@borrob
It doesn't bother me either, but I'm a bit hesitant with the capitals
Tom Kralidis
@tomkralidis
true, not very UNIX-y
Just van den Broecke
@justb4

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 ?

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).

Tom Kralidis
@tomkralidis
sigh, ok then. geohc it is.
Tom Kralidis
@tomkralidis
@borrob / @justb4 FYI heads up on next OWSLib release: geopython/OWSLib#641
Just van den Broecke
@justb4
@tomkralidis yes, we're - @borrob - following closely, e.g. geopython/GeoHealthCheck#312.