Solved pgadmin3 "Server Status" empty

PMc

PMc

While the valuable infos in "Tools->Server Status" were shown in earlier times, since a couple of years these windows may stay empty.
I once tried to figure the reason and found, that it is not a problem with the postgres server, but with pgadmin failing to fill the windows. I gave up at that point.

Finally now I found a discussion where some Linux people tracked down the problem:
The one that works is using wxWidgets 2.8, whilst the others are using wxWidgets 3.0. We've never fully tested with 3.0
Click to expand...

So, easy solution: check if You have any wx30 stuff installed, and if so, remove it and remove pgadmin, revert the Makefile in /usr/ports/databases/pgadmin3 as below, and make install - voila, now it works again.

Just want to share the info, for others who may try to live with this as a minor flaw, like I did.
Diff: 
Index: databases/pgadmin3/Makefile
===================================================================
--- databases/pgadmin3/Makefile (revision 446548)
+++ databases/pgadmin3/Makefile (working copy)
@@ -20,9 +20,9 @@
CONFIGURE_ARGS=        --with-wx-version=${USE_WX} --enable-databasedesigner
CXXFLAGS=      -Wno-c++11-narrowing
USE_GNOME=     libxml2 libxslt
-USE_WX=                3.0
+USE_WX=                2.8
USE_CXXSTD=    c++11
-WX_COMPS=      wx
+WX_COMPS=      wx contrib
INSTALLS_ICONS=        yes
ICON_SIZES=    16 32
 
It is no longer actively developed, which is the reason for this problem not being fixed in the place where it arises from. Current is pgadmin4, which seems to work quite different, and seems currently not present in the ports-tree.
And as databases are rather long running things, and I do not see an extreme urge to upgrade postgres beyond 9.5 immediately, I considered it worth the diskspace to put my finding public.
 
Well, in my opinion you're better off without pgadmin. It's a good program, and it can really help you to get started with database administration, but it also has its flaws. If you're not careful then backups (database dumps) made with pgadmin can be much less portable and usable than those which you made with pg_dump or pg_dumpall.

I know it's basically a frontend which also uses pg_dump, but its default options are sometimes a bit poorly chosen.
 
Well, it all depends on attitude, approach and needs.
A database system of such scope is a complex beast, and that complexity is not meant to be hidden under a smartphone-style frontend.
OTOH, we cannot practically talk plain SQL for all interaction - a GUI is feasible. So, when pgaccess ceased maintenance, I was in the need of a new GUI for my stuff, and I considered Ruby-on-Rails as the most versatile graphical frontend that would support postgres. Now this is perfectly fine for the applications, but here all the database internals are abstracted away. So I still needed a GUI for the structural level: looking at tables, indices, etc. And thats where pgadmin comes into play - practically as a browser for the database structure.

But in addition to these two levels, there is a third level - the server maintenance. Thats where backups etc. belong to. And this, in my opinion, is still best done local, on the server, from the shell prompt, with shell scripts, cronjobs, etc. pgadmin has nothing to do there.
 
abishai said:
Isn't this tool deprecated ? It gave me a lot errors with new postgres.
Click to expand...

Well, now, I brought myself into that malaise, too. :(

While doing my annually ports upgrade, I decided to just do a little more and also move to newest versions for named/bind (just works) and postgres (somebody had the glorious idea to change username and id, so one has to work thru twenty years of scripting where there might be some "-U pgsql" or similar used - but still better than the bacula5 = bareos desaster that changes /etc/services).

So, well, and now I do also see these lots of errors when using pgadmin3. :(
(As I say: upgrades are a nuisance, one should spare them.)

Consequently I looked into pgadmin4 - but that appears to be an architectural dungheap.

From what I understood, there are two modes of operation. pgadmin4 can be installed on a desktop, or it can be installed on a webserver. The desktop, so does the, eh, "documentation" say, puts itself in the system tray. Okay, I have no idea what a system tray ought to be. I have X11 (and I have an ashtray - thats the place where one puts the things one finds in one's nose while being bored). Probably the system tray is the place where the system puts things it wants to get disposed off - that would probably be appropriate.

Okay, forget about the desktop. Lets do a server installation. So, we put the pgadmin onto the Webserver.
Now, wait...

I am personally quite bored about the many well-meant hints telling people they should not put the password for their web-application's database access into the code (that is, into the publicly accessible code-repository on the web). But mostly I am wondering: why do people use passwords at all? You know, a webserver can be hacked, so what point is there to have a password, when the webserver (that is, the person who currently owns the webserver) owns the password? Why don't you simply remove the password - and so make things easier for all parties involved?

Lets have a closer look. Obviousely, the database does not belong to the web-user (the user Apache is running as, usually "www"). The database tables as well do not belong to the web-user. (I am always surprized when looking at all these easy-installation scripts, that they do not take precaution for this case and instead assume that the normal application user is able to modify database structure, i.e. add rowscolumns etc. It should not be that way.)

We can go a step further, and work with views. A view is real-time derived from the original table, and shows it in a modified fashion, i.e. it shows only what is needed. So, the credit card numbers (or the sexual preferences) may be in the real table, but they will not be in the view. And the web-user is allowed to see the view, it is not allowed to see the real table. It is able to put in the credit card number, but it will not be able to see it again. Nobody coming from the web-server's IP will be able to see it. (And yes, your RoR applications will work with views just as well as with real tables.)
So now we can remove the password for the web-user. Instead we use a kerberos key. (Remembering passwords is a nuisance, anyway.)

Okay, back to the topic. So, now we put the pgadmin4 onto the webserver. Pgadmin is made to administer the database. Therefore it needs access to the database. And it does not just need the web-user access, it does not just need the web-application's database owner's access - no, it does need the admin password for the database superuser. On the webserver. Oh well...

The point is: it is no longer the end-user running pgadmin on their platform, and from there connecting the database over some kind of properly secured channel. It is now the webserver who manages the access rights and the access channels.
Honestly I have no idea how to put that into some kind of secure architectural design. It seems, at least one would need to buy a second webserver host - and even then it is crap.
 
I agree, pgadmin4 is a real crap. I still use it to administer 9.6 version. Most stuff works, it emits some non-critical errors, but generally works. I'm looking to dbBeaver and IntelliJ DataGrip (proprietary, but in ports as part of IntelliJ Ultimate).
 
You must log in or register to reply here.
Back
Top