Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals - Mailing list pgadmin-support
From | Shaheed Haque |
---|---|
Subject | Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals |
Date | |
Msg-id | CAHAc2jcyhmpeuR2Y==2m7yD1hXq+t2=+ouRz5N8bv9zzOaZ4BQ@mail.gmail.com Whole thread Raw |
In response to | Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals (Dave Page <dpage@pgadmin.org>) |
Responses |
Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals
|
List | pgadmin-support |
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 <dpage@pgadmin.org> 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 <srhaque@theiet.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" ratherthan 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@pgadmin.org> wrote: >>> >>> Hi >>> >>> On Fri, Mar 1, 2019 at 9:30 AM Shaheed Haque <srhaque@theiet.org> wrote: >>>> >>>> OK, I got it working. This is how... >>>> >>>> On Mon, 25 Feb 2019 at 23:25, Shaheed Haque <srhaque@theiet.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 pgAdmin4to run at http://mydomain.com:80/pgadmin behind nginx. Is there a simple, up-to-date example of how to do this (I'mrunning 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 othersbut 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 5050directly behind nginx, or as a WSGI app under gunicorn. I assume the latter should be easier to set up, but I've triedboth (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 problemwas with the nginx config fragment: as soon as pgAdmin responded, it of course started the browser looking for toplevel URLs such as /browser and /static which are obviously not under /pgadmin. The to this key was a piece of code inhttps://stackoverflow.com/a/50515636/6332554, which basically adds the concept of a SCRIPT_NAME by hacking a small wodgeof 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 pickit up. I change the name I used so I ended up with the link being "wsgi.py" -> "pgAdmin4.py", so the the correspondinggunicorn 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 servermode, but sharing the domain with other applications. Would there be interest in making the needed code an integralpart 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_wsgior 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 stillbe 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
pgadmin-support by date: