Hi It worked fine when I tested it. If you don't get any errors and you get a login prompt, it should all be good.
On Thu, Apr 4, 2019 at 3:01 PM Shaheed Haque <shaheedha...@gmail.com> wrote: > 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 <dp...@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 <srha...@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" 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 <dp...@pgadmin.org> wrote: > >>> > >>> Hi > >>> > >>> On Fri, Mar 1, 2019 at 9:30 AM Shaheed Haque <srha...@theiet.org> > wrote: > >>>> > >>>> OK, I got it working. This is how... > >>>> > >>>> On Mon, 25 Feb 2019 at 23:25, Shaheed Haque <srha...@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 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 > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
