Обсуждение: PgAdmin4 is not usable when installed from RPMs on Fedora linux

Dear PgAdmin4 maintainers,

I wanted to install PgAdmin4 on my Fedora 24 system. I want to use it
in standalone mode, as a desktop application, essentially as a
replacement for PgAdmin3.

I've already installed the PGDG 9.6 repository RPM because I've
upgraded to Postgresql 9.6, and I've thought that the pgadmin4 RPMs
from that repo would work. Unfortunately the documentation on the
official site (https://www.pgadmin.org/download/linux4.php) merely
pointed me to this repository but didn't tell which packages I need.
I installed all that seemed relevant
(pgadmin4.x86_64, pgadmin4-web.noarch, pgadmin4-docs.noarch)

However, these packages seem half-finished at best, as I've encountered
several problems.

- No "pgadmin4" or similar binary was placed in any directory in $PATH.

- Looking at the contents of the packages, I've found a binary
at /usr/pgadmin4-1.0/runtime/pgAdmin4, however, trying to run this
manually results in a Fatal Error dialog box that says "Failed to
locate pgAdmin4.py, terminating server thread", then (sometimes) a
segfault.

- From the output of strace it turned out that this binary looks for
this pgAdmin4.py at / and /usr/pgadmin4-1.0/runtime, but not at the
correct /usr/lib/python3.5/site-packages/pgadmin4-web, even though
there is an ini file next to the binary, containing this location. (The
ini file is never accessed, though).

- The .desktop file supplied by the package is corrupt. It contains
 Exec==/usr/bin/python3 /usr/lib/python3.5/site-packages/pgadmin4-
web/pgAdmin4.py
instead of Exec=...
After fixing this error by hand, the icon appears in the system's
Application menu, but it doesn't appear to start anything. In any case,
shouldn't it execute the runtime binary instead of the web server?

- So I've tried to run the command in the above Exec line manually.
It printed an error message about config_local.py missing and exited.
So I've tried creating a config_local.py by copying config_distro.py. 
(https://www.pgadmin.org/docs4/1.x/desktop_deployment.html mentions
this file, but with a notice that the steps described there shouldn't
be necessary for normal users.) 
After that it appeared to run, instructing me to point my browser at
localhost:5050, at which location I was greeted by the shiny new
interface.

So at this point I have a desktop application that doesn't work and a
half-baked way to start the interface in the browser, which I don't
want to do. And none of the workarounds described above should be
necessary anyway: I would've expected that after installing the RPM I'd
have an application that works out of the box.

best regards,
Peter Juhasz

Hi,

On Mon, 2016-10-03 at 18:35 +0200, Peter Juhasz wrote:
> I've already installed the PGDG 9.6 repository RPM because I've
> upgraded to Postgresql 9.6, and I've thought that the pgadmin4 RPMs
> from that repo would work. Unfortunately the documentation on the
> official site (https://www.pgadmin.org/download/linux4.php) merely
> pointed me to this repository but didn't tell which packages I need.
> I installed all that seemed relevant
> (pgadmin4.x86_64, pgadmin4-web.noarch, pgadmin4-docs.noarch)
>
> However, these packages seem half-finished at best, as I've encountered
> several problems.

:-(

> - No "pgadmin4" or similar binary was placed in any directory in $PATH.

Created https://redmine.postgresql.org/issues/1818 to track this.

> - Looking at the contents of the packages, I've found a binary
> at /usr/pgadmin4-1.0/runtime/pgAdmin4, however, trying to run this
> manually results in a Fatal Error dialog box that says "Failed to
> locate pgAdmin4.py, terminating server thread", then (sometimes) a
> segfault.

I'd suggest you to run it with:

/usr/bin/python3 /usr/lib/python3.5/site-packages/pgadmin4-web/pgAdmin4.py

...or run:

systemctl start pgadmin4.service

> - From the output of strace it turned out that this binary looks for
> this pgAdmin4.py at / and /usr/pgadmin4-1.0/runtime, but not at the
> correct /usr/lib/python3.5/site-packages/pgadmin4-web, even though
> there is an ini file next to the binary, containing this location. (The
> ini file is never accessed, though).


Will look.

> - The .desktop file supplied by the package is corrupt. It contains
>  Exec==/usr/bin/python3 /usr/lib/python3.5/site-packages/pgadmin4-
> web/pgAdmin4.py
> instead of Exec=...
> After fixing this error by hand, the icon appears in the system's
> Application menu, but it doesn't appear to start anything. In any case,
> shouldn't it execute the runtime binary instead of the web server?

Created a ticket:

https://redmine.postgresql.org/issues/1819


> - So I've tried to run the command in the above Exec line manually.
> It printed an error message about config_local.py missing and exited.
> So I've tried creating a config_local.py by copying config_distro.py. 
> (https://www.pgadmin.org/docs4/1.x/desktop_deployment.html mentions
> this file, but with a notice that the steps described there shouldn't
> be necessary for normal users.) 

This is something that I broke between rc1 and 1.0 gold, I think. 

https://redmine.postgresql.org/issues/1820


> After that it appeared to run, instructing me to point my browser at
> localhost:5050, at which location I was greeted by the shiny new
> interface.
>
> So at this point I have a desktop application that doesn't work and a
> half-baked way to start the interface in the browser, which I don't
> want to do. And none of the workarounds described above should be
> necessary anyway: I would've expected that after installing the RPM I'd
> have an application that works out of the box.

Sorry for these, and I'll fix them ASAP.

Regards,
--
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

I'll confirm here that the Web version doesn't work either from the
Fedora packages.  In the case of the web version, this appears to be
because of confusion between Python2 and Python3 dependencies.

CC'ing Devrim.


On 10/03/2016 09:35 AM, Peter Juhasz wrote:
> Dear PgAdmin4 maintainers,
> 
> I wanted to install PgAdmin4 on my Fedora 24 system. I want to use it
> in standalone mode, as a desktop application, essentially as a
> replacement for PgAdmin3.
> 
> I've already installed the PGDG 9.6 repository RPM because I've
> upgraded to Postgresql 9.6, and I've thought that the pgadmin4 RPMs
> from that repo would work. Unfortunately the documentation on the
> official site (https://www.pgadmin.org/download/linux4.php) merely
> pointed me to this repository but didn't tell which packages I need.
> I installed all that seemed relevant
> (pgadmin4.x86_64, pgadmin4-web.noarch, pgadmin4-docs.noarch)
> 
> However, these packages seem half-finished at best, as I've encountered
> several problems.
> 
> - No "pgadmin4" or similar binary was placed in any directory in $PATH.
> 
> - Looking at the contents of the packages, I've found a binary
> at /usr/pgadmin4-1.0/runtime/pgAdmin4, however, trying to run this
> manually results in a Fatal Error dialog box that says "Failed to
> locate pgAdmin4.py, terminating server thread", then (sometimes) a
> segfault.
> 
> - From the output of strace it turned out that this binary looks for
> this pgAdmin4.py at / and /usr/pgadmin4-1.0/runtime, but not at the
> correct /usr/lib/python3.5/site-packages/pgadmin4-web, even though
> there is an ini file next to the binary, containing this location. (The
> ini file is never accessed, though).
> 
> - The .desktop file supplied by the package is corrupt. It contains
>  Exec==/usr/bin/python3 /usr/lib/python3.5/site-packages/pgadmin4-
> web/pgAdmin4.py
> instead of Exec=...
> After fixing this error by hand, the icon appears in the system's
> Application menu, but it doesn't appear to start anything. In any case,
> shouldn't it execute the runtime binary instead of the web server?
> 
> - So I've tried to run the command in the above Exec line manually.
> It printed an error message about config_local.py missing and exited.
> So I've tried creating a config_local.py by copying config_distro.py. 
> (https://www.pgadmin.org/docs4/1.x/desktop_deployment.html mentions
> this file, but with a notice that the steps described there shouldn't
> be necessary for normal users.) 
> After that it appeared to run, instructing me to point my browser at
> localhost:5050, at which location I was greeted by the shiny new
> interface.
> 
> So at this point I have a desktop application that doesn't work and a
> half-baked way to start the interface in the browser, which I don't
> want to do. And none of the workarounds described above should be
> necessary anyway: I would've expected that after installing the RPM I'd
> have an application that works out of the box.
> 
> best regards,
> Peter Juhasz
> 
> 
> 


-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

On 10/09/2016 04:36 PM, Josh Berkus wrote:
> I'll confirm here that the Web version doesn't work either from the
> Fedora packages.  In the case of the web version, this appears to be
> because of confusion between Python2 and Python3 dependencies.

Leaving out the SQLite bug (see other thread), here's the issues with
the Fedora24 packages:

1. if the user intends to use pgadmin4-web with httpd, then the user
needs to install httpd and python3-mod_wsgi packages (or mod_wsgi on
CentOS and RHEL).

2. the packages need to create the directory /usr/share/httpd/.pgadmin,
and add the SELinux label so that apache can write to it:

chcon -R -t httpd_sys_rw_content_t /usr/share/httpd/.pgadmin

The latter is going to be hard to do if you want the pgadmin4 app to
continue to be independant of httpd (for example, to allow install with
nginx).

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

Hi Josh,

On Sun, 2016-10-09 at 16:36 -0700, Josh Berkus wrote:
> I'll confirm here that the Web version doesn't work either from the
> Fedora packages.  In the case of the web version, this appears to be
> because of confusion between Python2 and Python3 dependencies.

Err, this should not happen, at least I cannot reproduce this on my Fedora box.
Can you please give more details?

Python3 support is Fedora 24+, so we added explicit version in the spec file.

Cheers,
--
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 10/10/2016 03:36 AM, Magnus Hagander wrote:
> 
> 
> On Mon, Oct 10, 2016 at 2:26 AM, Josh Berkus <josh@agliodbs.com
> <mailto:josh@agliodbs.com>> wrote:
> 
>     On 10/09/2016 04:36 PM, Josh Berkus wrote:
>     > I'll confirm here that the Web version doesn't work either from the
>     > Fedora packages.  In the case of the web version, this appears to be
>     > because of confusion between Python2 and Python3 dependencies.
> 
>     Leaving out the SQLite bug (see other thread), here's the issues with
>     the Fedora24 packages:
> 
>     1. if the user intends to use pgadmin4-web with httpd, then the user
>     needs to install httpd and python3-mod_wsgi packages (or mod_wsgi on
>     CentOS and RHEL).
> 
>     2. the packages need to create the directory /usr/share/httpd/.pgadmin,
>     and add the SELinux label so that apache can write to it:

>     chcon -R -t httpd_sys_rw_content_t /usr/share/httpd/.pgadmin
> 
>     The latter is going to be hard to do if you want the pgadmin4 app to
>     continue to be independant of httpd (for example, to allow install with
>     nginx).
> 
> 
> Wouldn't it be better to make it put the files somewhere under
> /var/lib/pgadmin? Seems like a more reasonable location for server-side
> pgadmin. And upstream might want to make that "easily modifiable by
> packagers" so it can be adapter to whatever distro it's being packaged
> on? Surely it's wrong to store metadata file in /usr/share... 

.pgadmin dir is getting written to $WEBHOME, which is why it's in
/usr/share/httpd on Fedora.  On debian it's presumably in /srv/www/.

And you'd need the SELinux perms even if it was in /var/lib/, because of
the nologin status of the Apache user.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

On 10/10/2016 11:26 AM, Magnus Hagander wrote:
> On Mon, Oct 10, 2016 at 6:57 PM, Josh Berkus <josh@agliodbs.com

>     And you'd need the SELinux perms even if it was in /var/lib/, because of
>     the nologin status of the Apache user.
> 
> 
> Yes, but /var/lib is supposed to be for persistant data modified by
> programs. That's a reasonable location for it, and thus it's reasonable
> to unlock it with selinux policy.

True.


-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)