Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

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 <srhaque(at)theiet(dot)org> 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 <dpage(at)pgadmin(dot)org> wrote:
>
>> Hi
>>
>> On Fri, Mar 1, 2019 at 9:30 AM Shaheed Haque <srhaque(at)theiet(dot)org> wrote:
>>
>>> OK, I got it working. This is how...
>>>
>>> On Mon, 25 Feb 2019 at 23:25, Shaheed Haque <srhaque(at)theiet(dot)org> 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