GUI queen needs database advice

The successor is pgAdmin4, however, this is not in the ports, and while pre-compiled installation packages are provided for Linux, Windows and macOS, we need to try to get around with the sources, in case we want to have it on FreeBSD. I did not try this yet.

That said, pgAdmin4 is a totally different animal than ...3. Actually it provides a web interface to the databases, and the desktop version comes with its own web server in order to achieve this - quote from the documentation:

Working on this matter now.
As I consider postgres being just perfect - it never failed me, and also working with the dev guys on the list is wonderfully constructive - and finding pgadmin3 the magic looking glass to see whats going on inside, I'm currently figuring out how to tackle with that pgadmin4.

What I can say so far: pgadmin4 is designed with an entirely different architecture in mind. It is not an application to be installed on some computer and then run by the user(s) on that computer.
Instead, it seems to be an almost fullsize Web Application Server, designed to run on an arbitrary application server machine, being connected as the middleware by a frontend Web Server (probably running on some other machine), utilizing it's own user administration (just like a website) and then accessing some postgres installations (likely yet on other machines).
The underlying Application Framework appears to be Flask utilizing sqlite3 as it's database backend. (A web application server is the middleware between the frontend web server and the backend database. The sqlite3 here is the backend for the application's persistent storage demands, while the postgres to be administered is the application's payload to work with.)
There is no application to compile, as it is all python. (Neverteless the python module prereqs do contain libaries in native C; these are compiled automatically on package install - when things go well.)
Such an application server is usually not installed by root into the system paths. It is rather installed by some user into their homedirs, putting all the (ever changing) module dependencies right alongside into the application.
Certainly such an architecture can also be concentrated to run on a single machine for a single user - but that's not the most easy way to approach it.
It is probably quite difficult to roll such a beast as a port. It is also kind of sisyphos work, because with every release the module dependencies will change - which would normally be no problem as the application itself carries a list of it's dependencies and can install these per script: just put it into a new directory and throw away the old one.

There is also a more serious problem with it: we have the Kerberos integrated in the base system, and postgres also has the Kerberos integrated. So we would never need passwords for the database (and then we cannot store our production database passwords within the application onto github, like other people seem to do). The pgadmin3 would just let libpg grab the Kerberos tickets as when connecting the database directly, so the single-sign-on works transparently, no password needed.
But now pgadmin4 would split this one securely authenticated connection into two unauthenticated and dubious halfes, and we're quite back to herding passwords, for pgadmin4 AND for the database.
 
the real question is, how much time can you put into it Phishfry ? If you have 20-30 days than you can try to pickup the whole Javascript stack. That is, use Node as web server, and Javascript+html+css for the interface. You will easily find libraries to call whatever db from Node. I did a few projects with this technology, it is good and well understandable if you avoid big frameworks and limit yourself to E.g. jQuery.
 
if you avoid big frameworks and limit yourself to E.g. jQuery.

For the purpose of learning, I would recommend React instead of jQuery.
jQuery is clearly obsolete, most of its features are nowadays useless and the rest (e.g. jQuery UI) can be done in a simple way with modern frameworks such as React with the notable benefit of a much easier application maintenance.

I usually explain React basics in 10 min., so it cannot be called a 'big' framework. ;) It takes more time to learn how to use npm, package.json and webpack than to create your first React form.
 
For the purpose of learning, I would recommend React instead of jQuery.
jQuery is clearly obsolete, most of its features are nowadays useless and the rest (e.g. jQuery UI) can be done in a simple way with modern frameworks such as React with the notable benefit of a much easier application maintenance.

I usually explain React basics in 10 min., so it cannot be called a 'big' framework. ;) It takes more time to learn how to use npm, package.json and webpack than to create your first React form.

I am sorry, my preference is in the complete opposite direction. I consider frameworks for non-programmers . Easy to start with, but giving zero understanding of the subject and mangling creative thought. If somebody does not know jQuery i would seriously doubt he uses javascript at all. JQuery UI, not a big fan of that. I prefer to build pieces that i need and have full control.

Said that, it is true that @phisfry could solve his problem in (say) 1/5 of the time with a framework. One the other side he would understand nothing of what is happening. Just copy in StackOverflow, fill some templates, reboot, cross your finger, hope it works. If it does not, back to StackOverflow. IMHO This is the cancer of programming. --> If he liked that he would be a Windows guy more than a BSD one ;P
 
extra thought. Framework have their reson d'etre which is crystal clear. Most of the web is just a template, change color-font-picture and put in a bit if text. So, they make a lot if sense. It is just not my corner;)
 
React is inspired by the functional reactive UI idea, although, ironically, it's not a proper FRP UI implementation because it's "merely" functional* and not reactive. Still, it's pretty hardcore, so show some respect.

* if you squint hard enough; to the extent possible in JavaScript.
 
Most of the web is just a template

You're right, but this has nothing to do with frameworks. Frameworks are primarily intended for enterprise application development.

In the beginning, professional developers did what you like to do: developing everything themselves. This led to the development of company-specific frameworks because at some point, you get tired of copy-paste and try and make your life easier by factorizing redundant code and developing coding procedures - which is all a framework is about.

Over time, some developers left the company - retiring, dying of a cancer or taking a new responsibility elsewhere - and new products had to be developed. Both factors make it necessary to hire new developers and in spite of their knowledge of the programming language, it still took them a long time (6 months to a year is usual) to get to know the company's frameworks enough to produce functional and reliable code.

In the meantime, their boss had to pay them without added value in return, while customer unsatisfaction often increases due to the many bugs added to the application as part of the new joiners' learning curve.

But the worse is most certainly when someone (or some team) develops an application in a cryptic and/or dirty fashion and hands its maintenance over to another team (yours) when in production. If the original developer is still in the company, you're very much tempted to have him experience how creative you can be to design new torture techniques. ;)

This is why companies use widespread (and generally also open-source) frameworks as much as possible so they can reduce the learning curve of new joiners, increase the reliability and maintainability of applications, and reduce risk factors in their projects.

Because it is nowadays very important for most companies, they DO NOT want their developers to copy-paste code from Stack Overflow, so they get their developers trained instead. And this is precisely my job, to train developers.

Don't forget that there's a lot of money invested in IT projects and that management positions are most coveted. If you fail to manage your teams and your projects so they create value for your company, someone else will soon be sitting behind your former desk.
 
But the worse is most certainly when someone (or some team) develops an application in a cryptic and/or dirty fashion and hands its maintenance over to another team (yours) when in production. If the original developer is still in the company, you're very much tempted to have him experience how creative you can be to design new torture techniques. ;)

Oh, thats nice! :) Didn't know that style is still contemporary in the new age. It reminds me of good old times - my first boss, back in the 80's, was very fond of keelhauling the people who wrote the software he indended to work with, and that was a wonderful time and a good management style, only I fear it wouldn't be p.c. anymore in these new times.

BTW: Strill trying to get that pgadmin4 into proper shape - anyone ever heard of a document that would have defined an 'X-Script-Name' entity? Looks quite clandestine to me...

And this is precisely my job, to train developers.

You kiddin'. o_O
 
You're right, but this has nothing to do with frameworks. Frameworks are primarily intended for enterprise application development.

We could discuss this for months;) You have some points and certainly see them. It is expecially true that industry wants hire juniors and pretend them to be a regular developer.
Node+Javascript+JQuery+HTML+CSS+Postgres let me build all kind of web application I can imagine (well 95% of them). They are solid, well documented, and change slowly enough to make the learn an investment. If I add a layer more (call it framework or whatever) it is just obfuscation.

Learning all the stuff it is a big investment in time/effort. But offers big rewards. If you can envision something, then you can do it. If your graphic-person come with a crazy idea never seen before [they do it] you can make it real (here you need to know some math).

I think poor knowledge of basic structure and infrastructure is the root of many web evils. Look at this forum page for example, I am at Frankfurth airport right now, on the phone, a vulgar iPhone used by millions, the top part layout of the page is horribly mangled. And this why? Poor command of Javascript I say.

Boarding !!!! I hope i did not make to many typos :p
bye



FreeBSD-forum-mangled.jpg
 
I think poor knowledge of basic structure and infrastructure is the root of many web evils. Look at this forum page for example, I am at Frankfurth airport right now, on the phone, a vulgar iPhone used by millions, the top part layout of the page is horribly mangled. And this why? Poor command of Javascript I say.

Careful there, you not far from Spartrekus' territory. This is a typical "responsive design" resizing behavior.
 
BTW: Strill trying to get that pgadmin4 into proper shape - anyone ever heard of a document that would have defined an 'X-Script-Name' entity? Looks quite clandestine to me...

I've just had a glimpse at pgadmin4's source code and it seems to be a mixture of Python and JavaScript... :(

You might be interested in phppgadmin, it just needs Apache + PHP + Postgresql and is already available as a FreeBSD package.
 
Careful there, you not far from Spartrekus' territory. This is a typical "responsive design" resizing behavior.

I have not been much present in the last months, but if i remember well Spartrekus was a C language admirer, last time I talked to him he was trying to build a spreadsheet for the terminal. He may have converted to JS in the meanwhile ;)

I discussed some of the graphical issues of the forum with Trihexagonal a long time ago. But we didn't actually push for a change. As far as I am concerned the forum is fine as it is, well organized, good content, collaborative people. So, well, these graphical glitches are really a minor thing. It was just an handy example.
 
You might be interested in phppgadmin, it just needs Apache + PHP + Postgresql and is already available as a FreeBSD package.

Putting it short: does it support Kerberos5/GSSAPI/SPNEGO ticket proxying?

Background: if you run postgreSQL with K5 auth, you never need a passwort, and neither a certificate. It's single-sign-on: at login, the user enters their password and get a "ticket". That ticket automatically authenticates them for some time (e.g. a workday), without further action.
But changing to a web application gives a couple of additional tasks with this:
  1. the webserver must be able to receive and handle such tickets.
    Apache does, with www/mod_auth_kerb2 or www/mod_auth_gssapi.
  2. the application must be able to receive that ticket and understand it.
  3. the application must be able to talk to postgreSQL authenticated with that ticket on the user's behalf.
    This gets interesting, as we will have multiple users acting simultaneously, and the respectively correct ticket must be associated with each PGconnect() invocations.

For pgadmin4, the developers seem to not have fully understood the task, as Stephen Frost here has quite well pinpointed it.)
That was two years ago, alright, and I have not yet figured the current state of affairs, although my guts say it will not have got much better.
For phppgadmin I did not find any informations.

But, looking a bit closer, it seems nowadays people believe in SSL. And they do that by offering the user a private filespace on the webapp-server. And then, to upload the certificate and certificate KEY. Onto the webapp-server. Well, obviousely, as that's the only way to get such a scheme to work.
But then also, from that point onwards such webapp-server is in fact a security device (carrying secret keys)!
And this is exactly the way how Rome was lost.
 
Putting it short: does it support Kerberos5/GSSAPI/SPNEGO ticket proxying?

I don't know if it does, but going back to the start of the thread, such a setup doesn't seem to match the OP's need, which seemed to be more about learning, if I understood correctly. And learning is easier if you start with something simple and add more and more complexity as your knowledge grows.
 
I don't know if it does, but going back to the start of the thread, such a setup doesn't seem to match the OP's need, which seemed to be more about learning, if I understood correctly. And learning is easier if you start with something simple and add more and more complexity as your knowledge grows.

Ack on that. But since You quoted my efforts in making pgadmin4 work, I erroneously supposed You were addressing me. Sorry for misunderstanding.

Anyway, krb5 is a native part of FreeBSD as well as postgreSQL, so it's rather legit to consider if it's supported. And we have a high ranking on google here, so we are writing for a large base of invisible readers as well.
 
Back
Top