Hi Dave,
I'm just migrating to the fixes in 4.4. Can I just double check one
thing? In my original hack, I needed to create a link "wsgi.py" ->
"pgAdmin4.py", so the the corresponding gunicorn command is something
like this:
gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application
Now, in the documentation updates as part of this fix, the last
argument to that line reads "pgAdmin4:app" and not "wsgi:application".
The reason I though I needed to use the wsgi.py file is that it
contains these lines amongst other:
# Ensure the global server mode is set.
builtins.SERVER_MODE = True
I'm not sure if, by following the updated docs, I am missing a
necessary setting?
Thanks, Shaheed
On Tue, 5 Mar 2019 at 09:11, Dave Page <[email protected]> wrote:
>
> You're welcome. Sorry it took so long to realise the main issue was only
> applicable to Gunicorn!
>
> On Mon, Mar 4, 2019 at 6:29 PM Shaheed Haque <[email protected]> wrote:
>>
>> Dave,
>>
>> Thanks for taking this forward, I look forward to 4.4! I also noted with
>> interest that we can use "pgAdmin4:app" rather than my hacky link to the
>> pgAdmin4.wsgi, so that means a completely hack-free solution :-).
>>
>>
>> Shaheed
>>
>> On Mon, 4 Mar 2019 at 16:33, Dave Page <[email protected]> wrote:
>>>
>>> Hi
>>>
>>> On Fri, Mar 1, 2019 at 9:30 AM Shaheed Haque <[email protected]> wrote:
>>>>
>>>> OK, I got it working. This is how...
>>>>
>>>> On Mon, 25 Feb 2019 at 23:25, Shaheed Haque <[email protected]> wrote:
>>>> >
>>>> > Hi,
>>>> >
>>>> > I'm a relative noob when it comes to the world of nginx, wsgi and so
>>>> > forth, but I do have several other things working (a Django app under
>>>> > gunicorn and the RabbitMQ web UI directly behind nginx). However, I'm
>>>> > rather stuck getting pgAdmin4 to run at http://mydomain.com:80/pgadmin
>>>> > behind nginx. Is there a simple, up-to-date example of how to do this
>>>> > (I'm running the latest, v4.2, of pgAdmin4)?
>>>> >
>>>> > I'm aware of threads such as
>>>> > https://www.postgresql.org/message-id/2197768425D7F5479A0FFB3FEC212F7FF602B871%40aesmail.surcouf.local,
>>>> > and several others but not been able to come up with a clear approach:
>>>> >
>>>> > One of the several variables I'm struggling to understand is the choice
>>>> > of whether to run pgAdmin4.py on port 5050 directly behind nginx, or as
>>>> > a WSGI app under gunicorn. I assume the latter should be easier to set
>>>> > up, but I've tried both (modelled on what I have working, and various
>>>> > references). One combination I tried was:
>>>> >
>>>> > - Creating a softlink from pgadmin4.py to pgAdmin4.wsgi
>>>> > - Using gunicorn to run the pgadmin4.py to a unix domain socket like
>>>> > this:
>>>> >
>>>> > $ /usr/local/bin/gunicorn -w 1 --bind unix:/home/ubuntu/pgadmin.sock
>>>> > pgadmin4:application
>>>> >
>>>> > - Serving behind nginx like this:
>>>> >
>>>> > location /pgadmin {
>>>> > rewrite ^/pgadmin/(.*) /$1 break;
>>>> > include proxy_params;
>>>> > proxy_pass http://unix:/home/ubuntu/pgadmin.sock;
>>>> > }
>>>> >
>>>> > But all I get is a stubborn 404. Any pointers welcome...
>>>>
>>>> First, I got over the 404s (caused, it seems, by me forgetting just how
>>>> much my browser had cached :-0). The next problem was with the nginx
>>>> config fragment: as soon as pgAdmin responded, it of course started the
>>>> browser looking for top level URLs such as /browser and /static which are
>>>> obviously not under /pgadmin. The to this key was a piece of code in
>>>> https://stackoverflow.com/a/50515636/6332554, which basically adds the
>>>> concept of a SCRIPT_NAME by hacking a small wodge of code into pgAdmin4.py.
>>>>
>>>> The SCRIPT_NAME is set by an nginx fragment like this:
>>>>
>>>> location /pgadmin {
>>>> rewrite ^/pgadmin/(.*)$ /\$1 break;
>>>> include proxy_params;
>>>> proxy_pass http://unix:/home/$CLOUD_USER/pgadmin.sock;
>>>> proxy_set_header X-Script-Name /pgadmin;
>>>> }
>>>>
>>>> In addition to that change, as previously noted, I needed to create a link
>>>> to pgAdmin4.wsgi to allow gunicorn to pick it up. I change the name I used
>>>> so I ended up with the link being "wsgi.py" -> "pgAdmin4.py", so the the
>>>> corresponding gunicorn command is something like this:
>>>>
>>>> gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application
>>>>
>>>> Now, IIUC, the notion of SCRIPT_NAME is somewhat standard, and needed to
>>>> solve this issue of running pgAdmin in server mode, but sharing the domain
>>>> with other applications. Would there be interest in making the needed code
>>>> an integral part of pgAdmin? If so, I'd be happy to file a feature request.
>>>>
>>>> Thanks, Shaheed
>>>
>>>
>>> Thanks for your work on this.
>>>
>>> I've committed a change to add the reverse proxy code, and to put some more
>>> examples in the docs:
>>> https://redmine.postgresql.org/projects/pgadmin4/repository/revisions/f401def044c8b47974d58c71ff9e6f71f34ef41d
>>>
>>> FWIW, I think the reason that this was an issue for so long is that you
>>> don't need the extra code if you use mod_wsgi or uWSGI - it's only needed
>>> with Gunicorn. I'll let you guess which of those technologies I'm most
>>> familiar with!
>>>
>>> Unfortunately this commit won't make the 4.3 release later this week, but
>>> it will be in 4.4. The instructions will still be good for scenarios other
>>> than Gunicorn in a sub-directory though.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
