Skip to content

sweetontology.net

Jump to bottom
Carlos A. Rueda edited this page Mar 28, 2019 · 12 revisions

The Apache settings to dispatch requests against http://sweetontology.net are described below.

Status 2017-12-12

COR-enabled dispatch of requests against http://sweetontology.net

The Apache settings for purposes of resolving requests against sweetontology.net via COR are captured in /etc/httpd/conf.d/sweetontology.conf on the same ESIP AWS instance where the COR is deployed:

<VirtualHost *:80>
    ServerName sweetontology.net
    DocumentRoot "/var/www/html/sweetontology.net"
    AliasMatch "/?" "/var/www/html/sweetontology.net/index.html"

    RewriteEngine  On
    RewriteRule    ^/ont ^/ont/.* [L,R=404]
    RewriteRule    /(.+) http://cor.esipfed.org/ont/api/v0/ont?iri=http://sweetontology.net/$1 [P,QSA,NE,L]
</VirtualHost>

Explanation

  • As a placeholder, I created /var/www/html/sweetontology.net/index.html and set a corresponding alias for resolution of the domain name itself, http://sweetontology.net.

    Such base name request could be used to provide general information about SWEET, etc. Or a simple redirect can also be indicated.

  • Because of the subsequent rule, to avoid confusion in case of requests to http://sweetontology.net/ont or http://sweetontology.net/ont/* (/ont is where COR is deployed on cor.esipfed.org), I set a rule to simply respond with 404. Without this rule, this /ont/* request would be processed by the subsequent rule, resulting in some unintended partial dispatch by the COR, which should simply be avoided.

  • Then comes the key rule for the transparent resolution of http://sweetontology.net/<NAME> via http://cor.esipfed.org/ont/api/v0/ont?iri=http://sweetontology.net/<NAME>. The flags here mean:

2019-03-21 Issue with dispatch of sweetontology.net/

(Thread continued from https://github.com/ESIPFed/cor/blob/master/setup/setup-april-2018.md#2019-03-21)

EDIT (2019-03-28): This issue has been fixed. It was externally caused by a domain name server misconfig. See email thread.

There is an issue serving the RewriteRule /(.+) http://cor.esipfed.org/ont/api/v0/ont?iri=http://sweetontology.net/$1 [P,QSA,NE,L] where any resource requested via sweetontology.net/some/resource is not being correctly serviced by COR at http://cor.esipfed.org/ont/api/v0/ont?iri=http://sweetontology.net/some/resource.

2019-03-23 (am PT)

Some quick checks:

rw-rw-r-- 1 temp temp 1127 Feb 20 2018 /etc/httpd/conf.d/sweetontology.conf

$ sudo tail -f /var/log/httpd/error_log
...
[Fri Mar 22 03:26:59.605499 2019] [proxy:error] [pid 13496] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:9090 (localhost) failed
[Fri Mar 22 03:26:59.605530 2019] [proxy_http:error] [pid 13496] [client 104.175.85.226:56585] AH01114: HTTP: failed to make connection to backend: localhost, referer: http://cor.esipfed.org/

But I'm unable to trigger any error here while trying to reload http://sweetontology.net/realmCryo/FastIce on my browser.

$ docker ps
CONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS              PORTS                      NAMES
4f0f87f3f4ab        mmisw/orr:3.8.3          "catalina.sh run"        7 weeks ago         Up 37 hours         0.0.0.0:9090->8080/tcp     orr
e29978cb25dc        franzinc/agraph:v6.1.1   "/bin/sh -c '/app/ag…"   7 weeks ago         Up 37 hours         0.0.0.0:10035->10035/tcp   agraph
79c22265d64b        mongo:3.4.2              "docker-entrypoint.s…"   7 weeks ago         Up 37 hours         0.0.0.0:27017->27017/tcp   mongo

In particular, the port setup 0.0.0.0:9090->8080/tcp for the orr looks as expected.

So, along with the apache conf, this all should be working.

NOTE According to apache's access_log and the orr's log, it seems that the requests are not even being received by the COR machine.

Apache was recently updated on the machine:

$ /usr/sbin/httpd -v
Server version: Apache/2.4.38 (Amazon)
Server built:   Mar  6 2019 22:00:08

Maybe something changed in the way Apache dispatch things(?)

Name resolution issue? According to ping, cor.esipfed.org=34.216.150.176, but sweetontology.net=199.26.254.133.

And, according to nslookup, 34.216.150.176 resolves to the COR amazon machine (as expected), but 199.26.254.133 does not resolve:

$ nslookup 34.216.150.176
Server:		172.30.0.2
Address:	172.30.0.2#53

Non-authoritative answer:
176.150.216.34.in-addr.arpa	name = ec2-34-216-150-176.us-west-2.compute.amazonaws.com.

Authoritative answers can be found from:

$ nslookup 199.26.254.133
Server:		172.30.0.2
Address:	172.30.0.2#53

** server can't find 133.254.26.199.in-addr.arpa.: NXDOMAIN
Clone this wiki locally