NGINX wrapper for Omnis CGI
Thanks for all the explanations and examples.
The location “/cgi-bin/nph-omniscgi” is just that, a location. There is
no such directory or file on the NGINX server. I just named the location
this so that I wouldn’t have to change any of the HTML files that were
originally hosted on an Apache server.
It seems that I can’t access Omnis directly after all, at least not via
HTTP. We are still in Omnis Studio 5, and if I remember correctly, in
order to talk to Omnis you need to create the appropriate header for
each request (something with OMNIS_ORFC etc). From Studio 6 and up,
there’s the RESTful service, which (I think) comes which its own built
in web server. This is just me speculating though, I could be way off.
Anyway, I decided to proxy to Apache instead and this seems to work just
fine. The NGINX server is still running only NGINX, the Omnis server now
has Apache, which is only approachable over the NGINX server.
We still have some ways to go with setting up NGINX to our liking, but
now we have a working solution with Omnis that we can fool around with.
Thanks again for all the help!
On 19 Mar 2018, at 21:33, Clifford Ilkay wrote:
> On Mon, Mar 19, 2018 at 11:57 AM, Nick Renders <email@example.com>
>> Thanks for the feedback, guys.
>> I tried setting up a reverse proxy in my NGINX config that refers to
>> Omnis runtime, but I couldn’t get it working properly.
>> The request actually goes through to Omnis, but for some reason it is
>> handled by the Omnis Web Service.
>> Our Omnis runtime runs on a different machine, but I don’t think this
>> the reason why it is not working.
> Hi Nick,
> Bruno wrote that you don’t even need the CGI wrapper. If that is the
> ensure that Omnis will respond appropriately on 10.0.0.1:5912. Once
> are certain that it does, then concentrate on the nginx configuration.
> location directive is NOT intended to match specific files. This
> provides a good explanation of how to use the location directive
> Here is the official documentation on it. < > nginx.org/en/docs/http/ngx_http_core_module.html#location>
> Here is how the VM Configuration Django application in my project is
> served. <paste.ngx.cc/e9> (That will be automatically deleted
> four days.)
> I want to point out a few things.
> * The backend knows nothing about HTTPS. The frontend only serves
> over HTTPS.
> directly via nginx due to the /static location block.
> * The /media location block is not used on this project for now. That
> be for user-uploaded files and in this application, we don’t have any
> those at the moment.
> * The /django-ws location block is a handler for WebSockets.
> * The / location block proxies all other requests to Django, which is
> served via a UWSGI application server. E.g. if the system
> wants to configure the VM, he would navigate to
> Nginx would do a redirect to vmconfig.example.com (line 7 =>
> 12 =>
> 23 => 29 => and then a combination of 65 and 73). Django would check
> if the
> user is authenticated and if not, do an internal redirect to /login
> and the
> user would have to enter a valid username and password pair. Once
> authenticated, Django does an internal redirect to /home, which
> the user with the Virtual Machine Appliance dashboard. To render the
> dashboard, every location block other than /media, is used. We’re
> /health-check every second and the response from that endpoint is
> by /django-ws so that we can increment an uptime clock.
> This is what /etc/nginx/proxy_params contains.
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto $scheme;
> add_header Front-End-Https on;
> proxy_redirect off;
> You should be able to adjust this configuration file to suit your
> particular case. I would get this working without HTTPS first and then
> with HTTPS.
> When you have this working and if Omnis is on the same host, there is
> reason to have Omnis listen on anything other than 127.0.0.1 so you
> change the Omnis configuration to reflect that and make the necessary
> change in the nginx location block. If Omnis is running on a different
> host, you should block all requests to 10.0.0.1:5912 except from the
> that nginx is running on by firewall rules.
> Clifford Ilkay
> +1 647-778-8696
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:firstname.lastname@example.org
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:email@example.com