Re: centos 7 / pgadmin 4.7

[Khushboo Vashi]

On Wed, Jun 5, 2019 at 8:16 PM Alex Williams 
wrote:

> Hi Khushboo,
>
> Thanks! This is working after the update. I've put two outputs below, the
> yum update / console output:
>
> Good to hear that everything is working fine.

1. [root@centos7dev output]# yum update
> Loaded plugins: fastestmirror, langpacks
> Loading mirror speeds from cached hostfile
> epel/x86_64/metalink
> |  17 kB  00:00:00
> * base: mirror.es.its.nyu.edu
> * epel: ewr.edge.kernel.org
> * extras: mirror.es.its.nyu.edu
> * nux-dextop: mirror.li.nux.ro
> * updates: mirror.es.its.nyu.edu
> adobe-linux-x86_64
> | 2.9 kB  00:00:00
> base
> | 3.6 kB  00:00:00
> epel
> | 5.3 kB  00:00:00
> extras
> | 3.4 kB  00:00:00
> google-talkplugin
> |  951 B  00:00:00
> nux-dextop
> | 2.9 kB  00:00:00
> pgdg10
> | 3.6 kB  00:00:00
> pgdg11
> | 3.6 kB  00:00:00
> pgdg94
> | 3.6 kB  00:00:00
> pgdg95
> | 3.6 kB  00:00:00
> pgdg96
> | 3.6 kB  00:00:00
> skype-stable
> | 2.9 kB  00:00:00
> updates
> | 3.4 kB  00:00:00
> (1/7):
> epel/x86_64/updateinfo
> | 974 kB  00:00:00
> (2/7):
> pgdg94/7/x86_64/primary_db
> | 259 kB  00:00:01
> (3/7):
> epel/x86_64/primary_db
> | 6.7 MB  00:00:01
> (4/7):
> pgdg95/7/x86_64/primary_db
> | 247 kB  00:00:00
> (5/7):
> pgdg10/7/x86_64/primary_db
> | 231 kB  00:00:02
> (6/7):
> pgdg96/7/x86_64/primary_db
> | 249 kB  00:00:00
> (7/7):
> pgdg11/7/x86_64/primary_db
> | 187 kB  00:00:02
> Resolving Dependencies
> --> Running transaction check
> ---> Package pgadmin4-python-flask.noarch 1:0.12.4-1.rhel7 will be updated
> ---> Package pgadmin4-python-flask.noarch 1:1.0.2-1.rhel7 will be an update
> ---> Package pgadmin4-python-werkzeug.noarch 0:0.11.11-4.rhel7.1 will be
> updated
> ---> Package pgadmin4-python-werkzeug.noarch 0:0.15.4-1.rhel7 will be an
> update
> --> Finished Dependency Resolution
>
> Dependencies Resolved
>
>
> ===
> Package
> Arch
> Version
> Repository  Size
>
> ===
> Updating:
> pgadmin4-python-flask
> noarch
> 1:1.0.2-1.rhel7
> pgdg10 149 k
> pgadmin4-python-werkzeug
> noarch
> 0.15.4-1.rhel7
> pgdg10 460 k
>
> Transaction Summary
>
> ===
> Upgrade  2 Packages
>
> Total download size: 609 k
> Is this ok [y/d/N]: y
> Downloading packages:
> No Presto metadata available for pgdg10
> (1/2):
> pgadmin4-python-werkzeug-0.15.4-1.rhel7.noarch.rpm
> | 460 kB  00:00:01
> (2/2):
> pgadmin4-python-flask-1.0.2-1.rhel7.noarch.rpm
> | 149 kB  00:00:00
>
> ---
> Total
> 476 kB/s | 609 kB  00:00:01
> Running transaction check
> Running transaction test
> Transaction test succeeded
> Running transaction
>   Updating   :
> pgadmin4-python-werkzeug-0.15.4-1.rhel7.noarch
> 1/4
>   Updating   :
> 1:pgadmin4-python-flask-1.0.2-1.rhel7.noarch
> 2/4
>   Cleanup:
> 1:pgadmin4-python-flask-0.12.4-1.rhel7.noarch
> 3/4
>   Cleanup:
> pgadmin4-python-werkzeug-0.11.11-4.rhel7.1.noarch
> 4/4
>   Verifying  :
> 1:pgadmin4-python-flask-1.0.2-1.rhel7.noarch
> 1/4
>   Verifying  :
> pgadmin4-python-werkzeug-0.15.4-1.rhel7.noarch
> 2/4
>   Verifying  :
> 1:pgadmin4-python-flask-0.12.4-1.rhel7.noarch
> 3/4
>   Verifying  :
> pgadmin4-python-werkzeug-0.11.11-4.rhel7.1.noarch
> 4/4
>
> Updated:
>   pgadmin4-python-flask.noarch
> 1:1.0.2-1.rhel7
> pgadmin4-python-werkzeug.noarch
> 0:0.15.4-1.rhel7
>
> Complete!
>
>
>
> 2. Console output on opening pgadmin if FF:
> unreachable code after return statement[Learn More]
> vendor.js:68:25689
> unreachable code after return statement[Learn More]
> vendor.js:68:26103
> exported wcDocker
> vendor.js:93:159528
> sprintf() will be removed in the next major release, use the sprintf-js
> package instead.
> vendor.js:155:171936
> unreachable code after return statement[Learn More]
> vendor.js:68:25689
> unreachable code after return statement[Learn More]
>
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, June 5, 2019 12:16 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
> Hi Alex,
>
> Can you please test the latest packages released by the packager as
> mentioned in the RM https://redmine.postgresql.org/issues/4313?
>
> Thanks,
> Khushboo
>
> On Tue, Jun 4, 2019 at 10:03 PM Alex Williams 
> wrote:
>
>> Also, I've updated the ticket with the info below and the 

Re: BUG #15831: pgadmin bug: add column and comment failure when you alter table

[Aditya Toshniwal]

Hi  Smeda,

By description do you mean comments ? If that is the case, I'm able to do
it.
Could you please share screenshots ?

>
> From: PG Bug reporting form 
> Date: Mon, Jun 3, 2019 at 2:44 PM
> Subject: BUG #15831: pgadmin bug: add column and comment failure when you
> alter table
> To: 
> Cc: <740084...@qq.com>
>
>
> The following bug has been logged on the website:
>
> Bug reference:  15831
> Logged by:  Dada Zhang
> Email address:  740084...@qq.com
> PostgreSQL version: 10.7
> Operating system:   Windows10 Home
> Description:
>
> Hi,
>
> I found a bug.
> pgAdmin latest version(maybe all version)...
> You can't modify a table by adding a column and its description, but you
> can
> add a column first and then add a description of the column.
>
> Thanks,
> Smeda
>
>

-- 
Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB India | Pune
"Don't Complain about Heat, Plant a TREE"

pgpool-II is not following new master node post master fail over

[soumitra bhandary]

Hi ,

I am using repmgr to manage the auto fail over process at PostgreSQL Database 
layer in a 3 node master - slave replication .

Also using pgpool-II to manage the load balancing and application connection 
routing.

But when any master failover is happening at DB side and new master is promoted 
using repmgr pgpool-II is not connecting to new master and still trying to 
connect old master node.

Here is my pgpool-II conf file parameters . Am I missing anything ?


backend_hostname0 = 'server1'
   # Host name or IP address to connect to for 
backend 0
backend_port0 = 5432
   # Port number for backend 0
backend_weight0 = 1
   # Weight for backend 0 (only in load 
balancing mode)
backend_data_directory0 = '/data/pgdata/10/data'
   # Data directory for backend 0
backend_flag0 = 'ALLOW_TO_FAILOVER'
   # Controls various backend behavior
   # ALLOW_TO_FAILOVER or DISALLOW_TO_FAILOVER
backend_hostname1 = 'server2'
backend_port1 = 5432
backend_weight1 = 10
backend_data_directory1 = '/data/pgdata/10/data'
backend_flag1 = 'ALLOW_TO_FAILOVER'

backend_hostname2 = 'server3'
backend_port2 = 5432
backend_weight2 = 10
backend_data_directory2 = '/data/pgdata/10/data'
backend_flag2 = 'ALLOW_TO_FAILOVER'

Re: pgAdmin4 4.8 Kubuntu issues

[richard coleman]

Dave,

On Wed, Jun 5, 2019 at 12:13 PM Dave Page  wrote:

> Richard,
>
> On Wed, Jun 5, 2019 at 4:55 PM richard coleman <
> rcoleman.ascen...@gmail.com> wrote:
>
>> Dave,
>>
>> Actually I thought I was being quite restrained in my assessment.  With
>> version 4.8 the developers completely upended the end user experience.
>> From pgAdmin3 through all versions of pgAdmin4 *prior to the current one*,
>> the end user could start pgAdmin and then get to work creating connections,
>> modifying databases, running queries as their postgreSQL permissions
>> allowed.  If they wanted to save a password, that was their choice (though
>> it didn't always work).  Suddenly with pgAdmin4 4.8 they are *locked out* of
>> the application by a *required* Master Password.  To make matters worse,
>> there is *no* simple or even well defined way to disable this change.
>> The *solution* is to dig through the documentation, then *rummage* around
>> on your file system (as the exact location varies by OS or distribution)
>> for a *sample* file (the config file isn't actually documented in the
>> official documentation).  *Then* create a brand new file, make sure you
>> include the *magic setting*, restart pgAdmin4 and you will *finally* get
>> back to working the way you did *before* you let pgAdmin4 update itself
>> from 4.7 to 4.8.
>>
>
> I've committed changes to improve the documentation.
>
>
>>
>> The only situation I can envision (and perhaps I'm just not paranoid
>> enough) is if someone breaks into my computer, gets my login credentials,
>> gets the separate login credentials to the VPN I use to connect to the
>> corporate network, and *then* manages to start pgAdmin4 as myself to
>> connect to a postgreSQL database, that I've just happened to have had
>> pgAdmin4 save the password to and commit some sort of mischief with my
>> level of access.
>>
>> So, to summarize an attacker would have had to:
>>
>>1. hack my machine
>>2. hack into the corporate network through my VPN credentials (which
>>they would have to hack)
>>3. run pgAdmin4 *as* me
>>4. have relied on me having pgAdmin4 *save* my passwords.
>>
>> Nope. Way easier than that. A flaw in a browser plugin or browser, or
> effective social engineering, or a malicious application can leak files on
> your system, and as stored passwords are stored in, well, files.
> All passwords are stored in files of one sort or another.  Hopefully those
> files are effectively encrypted (assuming of course that you had even had
> pgAdmin4 save your passwords to begin with).
> Now you may have a VPN, but you also may use the same password for
> different things, or other people might use servers that are less hard to
> reach.
>  The same sort of people who use the same password for a number of things
> are just going to use that self same password as their *master password* in
> pgAdmin4.
>
>> The only thing I gain from the new *Master Password* requirement is that
>> *if* I had pgAdmin4 save my passwords, an attacker would have need to
>> know one more password to *unlock* pgAdmin4.
>>
>> Unfortunately if I *don't* have pgAdmin4 save my passwords, I still have
>> to remember a *Master Password*.  Why?  Without step 4 above, it doesn't
>> actually provide anymore security.
>>
>> To add insult to injury I (like *many* people currently using pgAdmin4)
>> have root access (or Administrator level credentials for those Windows
>> users) to my own machine.  Which means it's possible for me to jump through
>> all of the hoops to disable the *Master Password *mechanism.  So what
>> did not having a setting in the Preferences UI gain in terms of security?
>> If you wanted to restrict changing that setting to users with the required
>> level of access you could have simply gated it with a sudo/administrator
>> credentials dialog.
>>
>
> How? pgAdmin has no way of doing that over what is essentially a web
> application - and even if it did, allowing a remotely accessible
> application (particularly one in which external programs can be configured
> and executed by users) to modify it's own configuration is a *really* bad
> idea.
>  Well for a start Edge uses Microsoft's user credentials as a master
> password.  Any number of applications can access files in a *protected
> area *and prompt for a sudo/administrator credential.  As for the choice
> to make pgAdmin4 a python version of phpPgAdmin, there's been a lot of
> discussion, most of it not very favorable.  I guess you can chalk this up
> to one more reason converting pgAdmin from an application to a *web app* was
> probably not the best idea.
>
>>
>> So basically what we have is a *major* UI change (users are literally
>> locked out of the application) caused by upgrading a minor version level
>> (4.7 to 4.8) with no simple way to revert the behavior all for a dubious
>> increase in security.
>>
>
> I don't wish to be rude, but it's clear you don't fully appreciate the
> possible risks here - and I really don't agree 

Re: pgAdmin4 4.8 Kubuntu issues

[richard coleman]

Michel,

I appreciate your taking the time to weigh in on this.  As I mentioned
previously, I can understand why this feature was added, other applications
have a "*master password to protect other saved passwords*"
feature.   Chrome *used to* before they went to protecting it with your
Google account.  Firefox (FF) still does.  The problem as I see it was in
the implementation.  In FF it's opt-in, and basically transparent to the
user.  Unless you want to *view* the saved passwords in plain text, none of
the features are effected.  Contrast that with how pgAdmin4 has chosen to
implement it.  It's a *painful* opt-out and it locks nearly everything
except the preferences regardless of whether or not you've had pgAdmin4
save *any* passwords at all.  Basically the developers have decided that
you are going to use this new *Master Password* mechanism or you are not
going to have access to the program or any of the server connections you've
already created.  One day you are going along using pgAdmin4, then there's
an update.  You update pgAdmin4 and *Bam!* You *must* enter a master
password, or else.  Now you are posting on lists like this one, or scouring
the internet looking for some way to turn this stupid thing off. Or you're
just going to enter something like "a" as your password (or "password", or
the exact same password you use to login/email/and everything else).

I feel it was *badly* handled.  No warning, painful opt-out, locks *way too
much* functionality.

I really do hope the devs reconsider this poor decision.

rik.



On Wed, Jun 5, 2019 at 1:27 PM Michel Feinstein 
wrote:

> Hi Richard,
>
> I am jumping-in specially because I am the guy to blame for this new
> feature. I identified the security risks and reported it, so I understand
> your frustration and feel bad that your work flow is not as comfortable as
> it was before. I hate when this happens to me.
>
> I also think that using the OS method for storing secrets would be more
> desirable, but I also understand this is way harder to achieve, since there
> would be Windows, Linux and Mac specific code into the project, which is
> way harder to develop than a simple Master Password.
>
> In my particular case, I have some very big alphanumeric passwords for my
> database users and a more user-friendly Master Password on my machine.
> Having to remember the database passwords is a pain, so I store them
> encrypted, so having a simpler Master Password is a very convenient
> solution for my use case, as I don't trust any passwords to be stored
> without encryption.
>
> I am not a developer into the pgAdmin project, I am just pointing out how
> this feature can be good and help some people, while improving security.
>
> I would argue that this discussion on opt-in VS opt-out should be
> investigated according to user impact. If lots of people complain, than
> this should be changed, if they don't, then keep it, as it's more secure. I
> know it's not going to help in your case, but seems more balanced to me on
> security vs. Usage, on a more democratic way.
>
> And again, I think the docs should explain this at length.
>
> Sorry if my input wasn't very helpful on your use case.
>
> Michel.
>
> On Wed, Jun 5, 2019, 14:03 richard coleman 
> wrote:
>
>> Michel,
>>
>> Thanks for jumping into the conversation.
>>
>> On Wed, Jun 5, 2019 at 12:18 PM Michel Feinstein <
>> michelfeinst...@gmail.com> wrote:
>>
>>> Let me just add some points to the discussion:
>>>
>>> 1 - Your use case is different than most people, you have a VPN in the
>>> middle of your workflow. Besides, you are imaging someone breaking into
>>> your computer, but the attack vector is much simpler than that.
>>>
>>> Someone can craft a malware that will automatically scan for pgAdmin
>>> passwords, upon arriving on any machine, and send whatever it's found to
>>> his creator. This could spread all over the internet, and one of your
>>> employees with less security awareness could click the wrong email
>>> attachment and then leak his database credentials. Google employees have
>>> been victim to physhing attacks (that's why they use smart cards now), I
>>> can't imagine this won't happen somewhere else.
>>>
>>> Yep, that *could* happen.  But the proposed solution is to add yet
>> *another* password?  If the developers were *truly *trying to increase
>> the security of pgAdmin4 from this attack vector, the simplest solution
>> would be to *remove* the ability of pgAdmin4 to save passwords.  Many of
>> our machines use ip or other non-password based security to control access
>> to our databases.  pgAdmin could force some other non-password security if
>> the user wanted to save their credentials.  Or pgAdmin could save their
>> credentials protected by the same mechanism the OS saves user
>> credentials.
>>
>> Many companies don't have their databases behind a VPN, specially in
>>> cloud environments (some use a VPC, some don't for many reasons, not
>>> related to this topic).
>>>
>>> 

Re: pgAdmin4 4.8 Kubuntu issues

[Michel Feinstein]

Hi Richard,

I am jumping-in specially because I am the guy to blame for this new
feature. I identified the security risks and reported it, so I understand
your frustration and feel bad that your work flow is not as comfortable as
it was before. I hate when this happens to me.

I also think that using the OS method for storing secrets would be more
desirable, but I also understand this is way harder to achieve, since there
would be Windows, Linux and Mac specific code into the project, which is
way harder to develop than a simple Master Password.

In my particular case, I have some very big alphanumeric passwords for my
database users and a more user-friendly Master Password on my machine.
Having to remember the database passwords is a pain, so I store them
encrypted, so having a simpler Master Password is a very convenient
solution for my use case, as I don't trust any passwords to be stored
without encryption.

I am not a developer into the pgAdmin project, I am just pointing out how
this feature can be good and help some people, while improving security.

I would argue that this discussion on opt-in VS opt-out should be
investigated according to user impact. If lots of people complain, than
this should be changed, if they don't, then keep it, as it's more secure. I
know it's not going to help in your case, but seems more balanced to me on
security vs. Usage, on a more democratic way.

And again, I think the docs should explain this at length.

Sorry if my input wasn't very helpful on your use case.

Michel.

On Wed, Jun 5, 2019, 14:03 richard coleman 
wrote:

> Michel,
>
> Thanks for jumping into the conversation.
>
> On Wed, Jun 5, 2019 at 12:18 PM Michel Feinstein <
> michelfeinst...@gmail.com> wrote:
>
>> Let me just add some points to the discussion:
>>
>> 1 - Your use case is different than most people, you have a VPN in the
>> middle of your workflow. Besides, you are imaging someone breaking into
>> your computer, but the attack vector is much simpler than that.
>>
>> Someone can craft a malware that will automatically scan for pgAdmin
>> passwords, upon arriving on any machine, and send whatever it's found to
>> his creator. This could spread all over the internet, and one of your
>> employees with less security awareness could click the wrong email
>> attachment and then leak his database credentials. Google employees have
>> been victim to physhing attacks (that's why they use smart cards now), I
>> can't imagine this won't happen somewhere else.
>>
>> Yep, that *could* happen.  But the proposed solution is to add yet
> *another* password?  If the developers were *truly *trying to increase
> the security of pgAdmin4 from this attack vector, the simplest solution
> would be to *remove* the ability of pgAdmin4 to save passwords.  Many of
> our machines use ip or other non-password based security to control access
> to our databases.  pgAdmin could force some other non-password security if
> the user wanted to save their credentials.  Or pgAdmin could save their
> credentials protected by the same mechanism the OS saves user
> credentials.
>
> Many companies don't have their databases behind a VPN, specially in cloud
>> environments (some use a VPC, some don't for many reasons, not related to
>> this topic).
>>
>> Besides, I could be wrong, but I think a malware on your computer could
>> read your pgAdmin passwords, then submit queries to your company's database
>> from inside your own computer, since it's already connected to your VPN,
>> and then send back to the attacker the results, so it won't have to steal
>> any VPN credentials, just use your own connection as a bridge. It doesn't
>> have to target you specifically, just send a ping back whenever it detects
>> pgAdmin passwords in a machine and then go to "Bridge mode". I might be
>> wrong since I almost never use a VPN and am not used to its inner workings.
>>
>>  Which just goes back to my earlier point of; 'if that's what you are
> worried about, then don't let users save passwords'.
>
>> 2 - I think the opt-out should be more streamlined, the security risks
>> should be better informed and the Master Password should only be asked if
>> the user decided to save a password in the first place.
>>
>
> I think it should be an *opt-in*.  That's how most other applications
> that utilize a master password work.
>
>>
>> 3 - pgAdmin could create an empty configuration file by default, so it
>> would be easier to locate it in all Linux distributions.
>>
>> It shouldn't need one, the user should be able to use or not use a master
> password from the Preferences UI.  If they want to use one, fine.  If not,
> that's OK too.  If they were and want to stop, warn the user and wipe all
> of the existing passwords.
>
>> Those are my 2 cents.
>>
>> Thanks again,
>
> rik.
>
>> On Wed, Jun 5, 2019, 12:55 richard coleman 
>> wrote:
>>
>>> Dave,
>>>
>>> Actually I thought I was being quite restrained in my assessment.  With
>>> version 4.8 the developers 

Re: pgAdmin4 4.8 Kubuntu issues

[richard coleman]

Michel,

Thanks for jumping into the conversation.

On Wed, Jun 5, 2019 at 12:18 PM Michel Feinstein 
wrote:

> Let me just add some points to the discussion:
>
> 1 - Your use case is different than most people, you have a VPN in the
> middle of your workflow. Besides, you are imaging someone breaking into
> your computer, but the attack vector is much simpler than that.
>
> Someone can craft a malware that will automatically scan for pgAdmin
> passwords, upon arriving on any machine, and send whatever it's found to
> his creator. This could spread all over the internet, and one of your
> employees with less security awareness could click the wrong email
> attachment and then leak his database credentials. Google employees have
> been victim to physhing attacks (that's why they use smart cards now), I
> can't imagine this won't happen somewhere else.
>
> Yep, that *could* happen.  But the proposed solution is to add yet
*another* password?  If the developers were *truly *trying to increase the
security of pgAdmin4 from this attack vector, the simplest solution would
be to *remove* the ability of pgAdmin4 to save passwords.  Many of our
machines use ip or other non-password based security to control access to
our databases.  pgAdmin could force some other non-password security if the
user wanted to save their credentials.  Or pgAdmin could save their
credentials protected by the same mechanism the OS saves user
credentials.

Many companies don't have their databases behind a VPN, specially in cloud
> environments (some use a VPC, some don't for many reasons, not related to
> this topic).
>
> Besides, I could be wrong, but I think a malware on your computer could
> read your pgAdmin passwords, then submit queries to your company's database
> from inside your own computer, since it's already connected to your VPN,
> and then send back to the attacker the results, so it won't have to steal
> any VPN credentials, just use your own connection as a bridge. It doesn't
> have to target you specifically, just send a ping back whenever it detects
> pgAdmin passwords in a machine and then go to "Bridge mode". I might be
> wrong since I almost never use a VPN and am not used to its inner workings.
>
>  Which just goes back to my earlier point of; 'if that's what you are
worried about, then don't let users save passwords'.

> 2 - I think the opt-out should be more streamlined, the security risks
> should be better informed and the Master Password should only be asked if
> the user decided to save a password in the first place.
>

I think it should be an *opt-in*.  That's how most other applications that
utilize a master password work.

>
> 3 - pgAdmin could create an empty configuration file by default, so it
> would be easier to locate it in all Linux distributions.
>
> It shouldn't need one, the user should be able to use or not use a master
password from the Preferences UI.  If they want to use one, fine.  If not,
that's OK too.  If they were and want to stop, warn the user and wipe all
of the existing passwords.

> Those are my 2 cents.
>
> Thanks again,

rik.

> On Wed, Jun 5, 2019, 12:55 richard coleman 
> wrote:
>
>> Dave,
>>
>> Actually I thought I was being quite restrained in my assessment.  With
>> version 4.8 the developers completely upended the end user experience.
>> From pgAdmin3 through all versions of pgAdmin4 *prior to the current one*,
>> the end user could start pgAdmin and then get to work creating connections,
>> modifying databases, running queries as their postgreSQL permissions
>> allowed.  If they wanted to save a password, that was their choice (though
>> it didn't always work).  Suddenly with pgAdmin4 4.8 they are *locked out* of
>> the application by a *required* Master Password.  To make matters worse,
>> there is *no* simple or even well defined way to disable this change.
>> The *solution* is to dig through the documentation, then *rummage* around
>> on your file system (as the exact location varies by OS or distribution)
>> for a *sample* file (the config file isn't actually documented in the
>> official documentation).  *Then* create a brand new file, make sure you
>> include the *magic setting*, restart pgAdmin4 and you will *finally* get
>> back to working the way you did *before* you let pgAdmin4 update itself
>> from 4.7 to 4.8.
>>
>> The only situation I can envision (and perhaps I'm just not paranoid
>> enough) is if someone breaks into my computer, gets my login credentials,
>> gets the separate login credentials to the VPN I use to connect to the
>> corporate network, and *then* manages to start pgAdmin4 as myself to
>> connect to a postgreSQL database, that I've just happened to have had
>> pgAdmin4 save the password to and commit some sort of mischief with my
>> level of access.
>>
>> So, to summarize an attacker would have had to:
>>
>>1. hack my machine
>>2. hack into the corporate network through my VPN credentials (which
>>they would have to hack)
>>3. 

Re: pgAdmin4 4.8 Kubuntu issues

[Dave Page]

Richard,

On Wed, Jun 5, 2019 at 4:55 PM richard coleman 
wrote:

> Dave,
>
> Actually I thought I was being quite restrained in my assessment.  With
> version 4.8 the developers completely upended the end user experience.
> From pgAdmin3 through all versions of pgAdmin4 *prior to the current one*,
> the end user could start pgAdmin and then get to work creating connections,
> modifying databases, running queries as their postgreSQL permissions
> allowed.  If they wanted to save a password, that was their choice (though
> it didn't always work).  Suddenly with pgAdmin4 4.8 they are *locked out* of
> the application by a *required* Master Password.  To make matters worse,
> there is *no* simple or even well defined way to disable this change.
> The *solution* is to dig through the documentation, then *rummage* around
> on your file system (as the exact location varies by OS or distribution)
> for a *sample* file (the config file isn't actually documented in the
> official documentation).  *Then* create a brand new file, make sure you
> include the *magic setting*, restart pgAdmin4 and you will *finally* get
> back to working the way you did *before* you let pgAdmin4 update itself
> from 4.7 to 4.8.
>

I've committed changes to improve the documentation.


>
> The only situation I can envision (and perhaps I'm just not paranoid
> enough) is if someone breaks into my computer, gets my login credentials,
> gets the separate login credentials to the VPN I use to connect to the
> corporate network, and *then* manages to start pgAdmin4 as myself to
> connect to a postgreSQL database, that I've just happened to have had
> pgAdmin4 save the password to and commit some sort of mischief with my
> level of access.
>
> So, to summarize an attacker would have had to:
>
>1. hack my machine
>2. hack into the corporate network through my VPN credentials (which
>they would have to hack)
>3. run pgAdmin4 *as* me
>4. have relied on me having pgAdmin4 *save* my passwords.
>
> Nope. Way easier than that. A flaw in a browser plugin or browser, or
effective social engineering, or a malicious application can leak files on
your system, and as stored passwords are stored in, well, files.

Now you may have a VPN, but you also may use the same password for
different things, or other people might use servers that are less hard to
reach.


> The only thing I gain from the new *Master Password* requirement is that
> *if* I had pgAdmin4 save my passwords, an attacker would have need to
> know one more password to *unlock* pgAdmin4.
>
> Unfortunately if I *don't* have pgAdmin4 save my passwords, I still have
> to remember a *Master Password*.  Why?  Without step 4 above, it doesn't
> actually provide anymore security.
>
> To add insult to injury I (like *many* people currently using pgAdmin4)
> have root access (or Administrator level credentials for those Windows
> users) to my own machine.  Which means it's possible for me to jump through
> all of the hoops to disable the *Master Password *mechanism.  So what did
> not having a setting in the Preferences UI gain in terms of security?  If
> you wanted to restrict changing that setting to users with the required
> level of access you could have simply gated it with a sudo/administrator
> credentials dialog.
>

How? pgAdmin has no way of doing that over what is essentially a web
application - and even if it did, allowing a remotely accessible
application (particularly one in which external programs can be configured
and executed by users) to modify it's own configuration is a *really* bad
idea.


>
> So basically what we have is a *major* UI change (users are literally
> locked out of the application) caused by upgrading a minor version level
> (4.7 to 4.8) with no simple way to revert the behavior all for a dubious
> increase in security.
>

I don't wish to be rude, but it's clear you don't fully appreciate the
possible risks here - and I really don't agree that being asked for a
password once when the application starts (not an instance of the UI, but
the server itself, which may support a number of concurrent or intermittent
sessions) is a major UI change. Not that I'd recommend it, but you could
have an extremely short password that you type and then press enter. You
could even ask your browser to save that password if you're less concerned
about security, and then we're talking about *a single mouse click* at the
start of your day, or if you're like me, start of your week.

Hardly a major inconvenience.


> Yes, I think I have been quite restrained in my assessment.
>
> Thanks,
>
> rik.
>
>
>
> On Wed, Jun 5, 2019 at 10:59 AM Dave Page  wrote:
>
>> Richard,
>>
>> On Wed, Jun 5, 2019 at 3:22 PM richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> Dave,
>>>
>>> And where would *that* be?  pgAdmin4 the executable and the shared
>>> library is located in /usr/bin/.  There are *no* entries in /etc/ for
>>> pgAdmin4.  There is a pgadmin4.db in 

Re: pgAdmin4 4.8 Kubuntu issues

[Dave Page]

Richard,

On Wed, Jun 5, 2019 at 3:22 PM richard coleman 
wrote:

> Dave,
>
> And where would *that* be?  pgAdmin4 the executable and the shared
> library is located in /usr/bin/.  There are *no* entries in /etc/ for
> pgAdmin4.  There is a pgadmin4.db in /home/u/.pgadmin/  but *no* config
> files of any kind there either.
>

I have no idea, I don't use Ubuntu or any of it's derivatives and don't
know where it installs. Have you tried searching for config.py? That is
*not* optional, and must exist.


> So it's looking like the only way to actually *use *the current version
> of pgAdmin4 is to create an undocumented file (the help page says you can
> use config.py as a reference, but guess what?  That file doesn't exist
> either.) in an unknown location, and manually add the magic string;
>
> "*MASTER_PASSWORD_REQUIRED=False"*
>
>
I think that's a little hyperbolic don't you? It works as intended, with no
changes required if you set the password and re-enter it when you restart
pgAdmin. You only need to modify anything if you want to change the
behaviour.

And to be clear; if config.py is not present on your system, then there is
no way pgAdmin will even start, let alone work.


>
> I get *why* you added this feature, but I think it was implemented *completely
> backwards*.  Instead of making *every* end user jump through these
> ridiculous hoops just to *continue* to use pgAdmin4 as they had been up
> to this point, a better option would be to allow security conscious sys
> admins to add the configuration:
>
>  "*MASTER_PASSWORD_REQUIRED=True"*
>
> to a non-user writable configuration file.  In that way the vast majority
> of people running pgAdmin4 can continue to do so and the few that
> wanted/needed the added security could do so as well.
>

That is not how security works. Without the master password feature, there
are possible attack vectors in which a stored password could be accessed by
third parties. We aim for secure by default; if you don't care about the
risk, then you can actively choose to run in a less secure way.


>
>
> So, now I'm using dBeaver as I *can't* disable the Master Password dialog
> box and pgAdmin4 won't let me *do* anything.
>
> Any other thoughts?  Anyone?
>
> Thanks,
>
> rik.
>
> On Wed, Jun 5, 2019 at 10:03 AM Dave Page  wrote:
>
>>
>>
>> On Wed, Jun 5, 2019 at 2:44 PM richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> Dave,
>>>
>>> Sorry, but after an e*xhaustive* search of the several terabytes on my
>>> machine, there is *no* config_local.py file.  Do you have any idea
>>> where it's supposed to be located?
>>>
>>
>> You need to create it if it doesn't exist, in the same directory as
>> pgAdmin's config.py.
>>
>>
>>>
>>> Thanks,
>>>
>>> rik.
>>>
>>> On Wed, Jun 5, 2019 at 9:30 AM Dave Page  wrote:
>>>


 On Wed, Jun 5, 2019 at 1:16 PM richard coleman <
 rcoleman.ascen...@gmail.com> wrote:

> Cherio,
>
> I am sorry to inform you, but there is *no* mention of "config_local.py"
> on that page, nor any indication of where I would find it.
>


 https://www.pgadmin.org/docs/pgadmin4/4.x/desktop_deployment.html#configuration


>
> rik.
>
> On Tue, Jun 4, 2019 at 5:06 PM Cherio  wrote:
>
>> Put "MASTER_PASSWORD_REQUIRED = False" line into your
>> "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
>> docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html
>>
>> On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> To whomever,
>>>
>>> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.
>>> There are a couple of glaring issues.
>>>
>>> First: It keeps prompting to; "Set Master Password"
>>> I don't want to set another password that I'll just end up
>>> forgetting.
>>>
>>> Second: When I click the "?" button on that dialog box it takes me
>>> to this page:
>>> "http://127.0.0.1:33681/help/help/master_password.html;
>>> Which returns "404 Not Found"
>>>
>>> Hopefully there is a simple solution to these issues.
>>>
>>> Thanks,
>>>
>>> rik.
>>>
>>

 --
 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

Re: [EXTERNAL] - Re: pgAdmin IV

[Dave Page]

I've rejected that I'm afraid, with the note:

=
Bug 2880 refers to what happens if you execute "EXPLAIN SELECT..." as the
query, and that still works fine.

We use JSON output when you use the EXPLAIN *button*, because we need to
parse the output to render it in the graphical viewer. Whilst it's true
pgAdmin 3 parsed the output from the non-JSON EXPLAIN, it was complex code
that wasn't reliable or future-proof.
=

In short, if you want to see multi-line, indented text plans, prepend
"EXPLAIN " to the query and run it. If you use the EXPLAIN button, the
returned data is in JSON format and is intended for graphical rendering.

On Wed, Jun 5, 2019 at 3:32 PM Strauch, Sheldon  wrote:

> Issue #4327  created.
>
> On Wed, Jun 5, 2019 at 12:27 AM Aditya Toshniwal <
> aditya.toshni...@enterprisedb.com> wrote:
>
>> Hi Michelle,
>>
>> On Wed, Jun 5, 2019 at 12:42 AM Michelle Schwan 
>> wrote:
>>
>>> Aditya,
>>>
>>>
>>>
>>> That is not very intuitive!  Why can’t the information be displayed?
>>> All of the other database tools for other databases allow this.
>>>
>> This can be done if we split the JSON data and show it in multiple rows.
>> Kindly raise a feature request here-
>> https://redmine.postgresql.org/projects/pgadmin4/issues/new
>> 
>>
>>>
>>>
>>> Thanks,
>>>
>>> Michelle
>>>
>>>
>>>
>>> *From:* Aditya Toshniwal 
>>> *Sent:* Tuesday, June 04, 2019 10:50 AM
>>> *To:* Michelle Schwan 
>>> *Cc:* pgadmin-support lists.postgresql.org
>>> 
>>> 
>>> *Subject:* [EXTERNAL] - Re: pgAdmin IV
>>>
>>>
>>>
>>> You need to double click on the "[" cell. It is a json data.
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Aditya Toshniwal
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jun 4, 2019, 20:10 Michelle Schwan  wrote:
>>>
>>> This is in all versions of pgAdmin IV.
>>>
>>>
>>>
>>> When generating an explain plan for a query, the data output only
>>> returns “[“.  In pgAdmin III, there was a detailed output.
>>>
>>> It is easier to read the detailed data output than the explain pictures
>>> – I have to keep my mouse on the picture to read it, very inconvenient.
>>>
>>>
>>>
>>> Same query in pgAdmin III
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Michelle Schwan
>>>
>>> Database Architect
>>>
>>> msch...@opentext.com
>>>
>>> Phone: (519) 888 7111 ext 3241
>>>
>>> Website:
>>>
>>> www.opentext.com
>>> 
>>>
>>>
>>>
>>> [image:
>>> http://mimage.opentext.com/alt_content/binary/images/emailsupport-logo-opentext.gif]
>>> 
>>>
>>> This email message is confidential, may be privileged, and is intended
>>> for the exclusive use of the addressee. Any other person is strictly
>>> prohibited from disclosing or reproducing it. If the addressee cannot be
>>> reached or is unknown to you, please inform the sender by return email and
>>> delete this email message and all copies immediately.
>>>
>>>
>>>
>>>
>>
>> --
>> Thanks and Regards,
>> Aditya Toshniwal
>> Software Engineer | EnterpriseDB India | Pune
>> "Don't Complain about Heat, Plant a TREE"
>>
>
>
> --
>
> Look after your data, and your database will look after you. -- Simon Riggs
>
> Sheldon E. Strauch
> *Data Architect, Data Services *
> *O* 312-676-1556
> *M* 224-723-3878
>
> *Enova International, Inc.*
> *This transmission is confidential and may be privileged or proprietary.
> If you are not the intended recipient, you are not authorized to use the
> information in this transmission in any way. Please inform the sender
> immediately if you have received this transmission in error and permanently
> delete and destroy the original and any copies of the information.*
>


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [EXTERNAL] - Re: pgAdmin IV

[Strauch, Sheldon]

Issue #4327  created.

On Wed, Jun 5, 2019 at 12:27 AM Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Michelle,
>
> On Wed, Jun 5, 2019 at 12:42 AM Michelle Schwan 
> wrote:
>
>> Aditya,
>>
>>
>>
>> That is not very intuitive!  Why can’t the information be displayed?  All
>> of the other database tools for other databases allow this.
>>
> This can be done if we split the JSON data and show it in multiple rows.
> Kindly raise a feature request here-
> https://redmine.postgresql.org/projects/pgadmin4/issues/new
> 
>
>>
>>
>> Thanks,
>>
>> Michelle
>>
>>
>>
>> *From:* Aditya Toshniwal 
>> *Sent:* Tuesday, June 04, 2019 10:50 AM
>> *To:* Michelle Schwan 
>> *Cc:* pgadmin-support lists.postgresql.org
>> 
>> 
>> *Subject:* [EXTERNAL] - Re: pgAdmin IV
>>
>>
>>
>> You need to double click on the "[" cell. It is a json data.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Aditya Toshniwal
>>
>>
>>
>>
>>
>> On Tue, Jun 4, 2019, 20:10 Michelle Schwan  wrote:
>>
>> This is in all versions of pgAdmin IV.
>>
>>
>>
>> When generating an explain plan for a query, the data output only returns
>> “[“.  In pgAdmin III, there was a detailed output.
>>
>> It is easier to read the detailed data output than the explain pictures –
>> I have to keep my mouse on the picture to read it, very inconvenient.
>>
>>
>>
>> Same query in pgAdmin III
>>
>>
>>
>> Thanks,
>>
>> Michelle Schwan
>>
>> Database Architect
>>
>> msch...@opentext.com
>>
>> Phone: (519) 888 7111 ext 3241
>>
>> Website:
>>
>> www.opentext.com
>> 
>>
>>
>>
>> [image:
>> http://mimage.opentext.com/alt_content/binary/images/emailsupport-logo-opentext.gif]
>> 
>>
>> This email message is confidential, may be privileged, and is intended
>> for the exclusive use of the addressee. Any other person is strictly
>> prohibited from disclosing or reproducing it. If the addressee cannot be
>> reached or is unknown to you, please inform the sender by return email and
>> delete this email message and all copies immediately.
>>
>>
>>
>>
>
> --
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB India | Pune
> "Don't Complain about Heat, Plant a TREE"
>


-- 

Look after your data, and your database will look after you. -- Simon Riggs

Sheldon E. Strauch
*Data Architect, Data Services *
*O* 312-676-1556
*M* 224-723-3878

*Enova International, Inc.*
*This transmission is confidential and may be privileged or proprietary. If
you are not the intended recipient, you are not authorized to use the
information in this transmission in any way. Please inform the sender
immediately if you have received this transmission in error and permanently
delete and destroy the original and any copies of the information.*

Re: pgAdmin4 4.8 Kubuntu issues

[Dave Page]

On Wed, Jun 5, 2019 at 2:44 PM richard coleman 
wrote:

> Dave,
>
> Sorry, but after an e*xhaustive* search of the several terabytes on my
> machine, there is *no* config_local.py file.  Do you have any idea where
> it's supposed to be located?
>

You need to create it if it doesn't exist, in the same directory as
pgAdmin's config.py.


>
> Thanks,
>
> rik.
>
> On Wed, Jun 5, 2019 at 9:30 AM Dave Page  wrote:
>
>>
>>
>> On Wed, Jun 5, 2019 at 1:16 PM richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> Cherio,
>>>
>>> I am sorry to inform you, but there is *no* mention of "config_local.py"
>>> on that page, nor any indication of where I would find it.
>>>
>>
>>
>> https://www.pgadmin.org/docs/pgadmin4/4.x/desktop_deployment.html#configuration
>>
>>
>>>
>>> rik.
>>>
>>> On Tue, Jun 4, 2019 at 5:06 PM Cherio  wrote:
>>>
 Put "MASTER_PASSWORD_REQUIRED = False" line into your
 "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
 docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html

 On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
 rcoleman.ascen...@gmail.com> wrote:

> To whomever,
>
> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There
> are a couple of glaring issues.
>
> First: It keeps prompting to; "Set Master Password"
> I don't want to set another password that I'll just end up
> forgetting.
>
> Second: When I click the "?" button on that dialog box it takes me to
> this page:
> "http://127.0.0.1:33681/help/help/master_password.html;
> Which returns "404 Not Found"
>
> Hopefully there is a simple solution to these issues.
>
> Thanks,
>
> rik.
>

>>
>> --
>> 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

Re: pgAdmin4 4.8 Kubuntu issues

[Cherio]

File location (assuming you have python 3.5) is
"lib/python3.5/site-packages/pgadmin4/config_local.py" relative to the
pgadmin install directory. You may have to create it as the file is
optional. You use it when you need to override default configuration. I
like to keep pgadmin 4 configuration separate from pgadmin3 so mine looks
like this

$> cat ./opt/pgadmin4/lib/python3.5/site-packages/pgadmin4/config_local.py
import os
DATA_DIR = os.path.realpath(os.path.expanduser(u'~/.pgadmin-v4/'))
LOG_FILE = os.path.join(DATA_DIR, 'pgadmin4.log')
SQLITE_PATH = os.path.join(DATA_DIR, 'pgadmin4.db')
SESSION_DB_PATH = os.path.join(DATA_DIR, 'sessions')
STORAGE_DIR = os.path.join(DATA_DIR, 'storage')
SERVER_MODE = False
MASTER_PASSWORD_REQUIRED = False


On Wed, Jun 5, 2019 at 9:44 AM richard coleman 
wrote:

> Dave,
>
> Sorry, but after an e*xhaustive* search of the several terabytes on my
> machine, there is *no* config_local.py file.  Do you have any idea where
> it's supposed to be located?
>
> Thanks,
>
> rik.
>
> On Wed, Jun 5, 2019 at 9:30 AM Dave Page  wrote:
>
>>
>>
>> On Wed, Jun 5, 2019 at 1:16 PM richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> Cherio,
>>>
>>> I am sorry to inform you, but there is *no* mention of "config_local.py"
>>> on that page, nor any indication of where I would find it.
>>>
>>
>>
>> https://www.pgadmin.org/docs/pgadmin4/4.x/desktop_deployment.html#configuration
>>
>>
>>>
>>> rik.
>>>
>>> On Tue, Jun 4, 2019 at 5:06 PM Cherio  wrote:
>>>
 Put "MASTER_PASSWORD_REQUIRED = False" line into your
 "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
 docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html

 On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
 rcoleman.ascen...@gmail.com> wrote:

> To whomever,
>
> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There
> are a couple of glaring issues.
>
> First: It keeps prompting to; "Set Master Password"
> I don't want to set another password that I'll just end up
> forgetting.
>
> Second: When I click the "?" button on that dialog box it takes me to
> this page:
> "http://127.0.0.1:33681/help/help/master_password.html;
> Which returns "404 Not Found"
>
> Hopefully there is a simple solution to these issues.
>
> Thanks,
>
> rik.
>

>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>

Re: pgAdmin4 4.8 Kubuntu issues

[richard coleman]

Dave,

Sorry, but after an e*xhaustive* search of the several terabytes on my
machine, there is *no* config_local.py file.  Do you have any idea where
it's supposed to be located?

Thanks,

rik.

On Wed, Jun 5, 2019 at 9:30 AM Dave Page  wrote:

>
>
> On Wed, Jun 5, 2019 at 1:16 PM richard coleman <
> rcoleman.ascen...@gmail.com> wrote:
>
>> Cherio,
>>
>> I am sorry to inform you, but there is *no* mention of "config_local.py"
>> on that page, nor any indication of where I would find it.
>>
>
>
> https://www.pgadmin.org/docs/pgadmin4/4.x/desktop_deployment.html#configuration
>
>
>>
>> rik.
>>
>> On Tue, Jun 4, 2019 at 5:06 PM Cherio  wrote:
>>
>>> Put "MASTER_PASSWORD_REQUIRED = False" line into your
>>> "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
>>> docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html
>>>
>>> On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
>>> rcoleman.ascen...@gmail.com> wrote:
>>>
 To whomever,

 Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There
 are a couple of glaring issues.

 First: It keeps prompting to; "Set Master Password"
 I don't want to set another password that I'll just end up
 forgetting.

 Second: When I click the "?" button on that dialog box it takes me to
 this page:
 "http://127.0.0.1:33681/help/help/master_password.html;
 Which returns "404 Not Found"

 Hopefully there is a simple solution to these issues.

 Thanks,

 rik.

>>>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [EXTERNAL] - Re: pgAdmin4 4.8 Kubuntu issues

[Dave Page]

On Wed, Jun 5, 2019 at 1:26 PM Michelle Schwan  wrote:

> It’s not just on Kubuntu – it also occurs on Windows as well.
>
>
>
> There should be a user-friendly way to turn that off.
>

No there shouldn't, unless you like security problems, as I explained in my
earlier email on the topic.


>
>
> pgAdmin III seems a lot better for functionality and usability.
>
>
>
>
>
> *From:* richard coleman 
> *Sent:* Wednesday, June 05, 2019 8:17 AM
> *To:* Cherio 
> *Cc:* pgAdmin Support 
> *Subject:* [EXTERNAL] - Re: pgAdmin4 4.8 Kubuntu issues
>
>
>
> Cherio,
>
>
>
> I am sorry to inform you, but there is *no* mention of "config_local.py"
> on that page, nor any indication of where I would find it.
>
>
>
> rik.
>
>
>
> On Tue, Jun 4, 2019 at 5:06 PM Cherio  wrote:
>
> Put "MASTER_PASSWORD_REQUIRED = False" line into your
> "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
> docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html
> 
>
>
>
> On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
> rcoleman.ascen...@gmail.com> wrote:
>
> To whomever,
>
>
>
> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There are
> a couple of glaring issues.
>
>
>
> First: It keeps prompting to; "Set Master Password"
>
> I don't want to set another password that I'll just end up forgetting.
>
>
>
> Second: When I click the "?" button on that dialog box it takes me to this
> page:
>
> "http://127.0.0.1:33681/help/help/master_password.html;
>
> Which returns "404 Not Found"
>
>
>
> Hopefully there is a simple solution to these issues.
>
>
>
> Thanks,
>
>
>
> rik.
>
>

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: pgAdmin4 4.8 Kubuntu issues

[Dave Page]

On Wed, Jun 5, 2019 at 1:16 PM richard coleman 
wrote:

> Cherio,
>
> I am sorry to inform you, but there is *no* mention of "config_local.py"
> on that page, nor any indication of where I would find it.
>

https://www.pgadmin.org/docs/pgadmin4/4.x/desktop_deployment.html#configuration


>
> rik.
>
> On Tue, Jun 4, 2019 at 5:06 PM Cherio  wrote:
>
>> Put "MASTER_PASSWORD_REQUIRED = False" line into your
>> "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
>> docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html
>>
>> On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> To whomever,
>>>
>>> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There
>>> are a couple of glaring issues.
>>>
>>> First: It keeps prompting to; "Set Master Password"
>>> I don't want to set another password that I'll just end up
>>> forgetting.
>>>
>>> Second: When I click the "?" button on that dialog box it takes me to
>>> this page:
>>> "http://127.0.0.1:33681/help/help/master_password.html;
>>> Which returns "404 Not Found"
>>>
>>> Hopefully there is a simple solution to these issues.
>>>
>>> Thanks,
>>>
>>> rik.
>>>
>>

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

RE: [EXTERNAL] - Re: pgAdmin4 4.8 Kubuntu issues

[Michelle Schwan]

It’s not just on Kubuntu – it also occurs on Windows as well.

There should be a user-friendly way to turn that off.

pgAdmin III seems a lot better for functionality and usability.


From: richard coleman 
Sent: Wednesday, June 05, 2019 8:17 AM
To: Cherio 
Cc: pgAdmin Support 
Subject: [EXTERNAL] - Re: pgAdmin4 4.8 Kubuntu issues

Cherio,

I am sorry to inform you, but there is no mention of "config_local.py" on that 
page, nor any indication of where I would find it.

rik.

On Tue, Jun 4, 2019 at 5:06 PM Cherio 
mailto:che...@gmail.com>> wrote:
Put "MASTER_PASSWORD_REQUIRED = False" line into your 
"lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the docs: 
https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html

On Tue, Jun 4, 2019 at 4:41 PM richard coleman 
mailto:rcoleman.ascen...@gmail.com>> wrote:
To whomever,

Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There are a 
couple of glaring issues.

First: It keeps prompting to; "Set Master Password"
I don't want to set another password that I'll just end up forgetting.

Second: When I click the "?" button on that dialog box it takes me to this page:
"http://127.0.0.1:33681/help/help/master_password.html;
Which returns "404 Not Found"

Hopefully there is a simple solution to these issues.

Thanks,

rik.

Re: pgAdmin4 4.8 Kubuntu issues

[richard coleman]

Christoph,

pgAdmin4 updated itself this morning, and now the "?" on the Set Master
Password dialog returns an actual page, not a 404.  Unfortunately it isn't
all that clear.  It suggests;

"You can disable the master password by setting the configuration parameter
MASTER_PASSWORD_REQUIRED=False"

but there is no such setting in the Preferences UI of pgAdmin and it
doesn't direct me to the proper config file either.

Thanks,

rik.

On Wed, Jun 5, 2019 at 5:15 AM Christoph Berg  wrote:

> Re: Dave Page 2019-06-05  agzdhljj...@mail.gmail.com>
> > > Second: When I click the "?" button on that dialog box it takes me to
> this
> > > page:
> > > "http://127.0.0.1:33681/help/help/master_password.html;
> > > Which returns "404 Not Found"
> > >
> >
> > That sounds like an issue with the packaging - that file is certainly
> there
> > in the source, and works when I click the button (though I do not use the
> > Ubuntu packages).
>
> Hi Richard,
>
> do you have the pgadmin4-doc package installed?
>
> At the moment, it is "Suggested" by pgadmin4-common. I'll promote that
> to a "Recommends".
>
> Christoph
>

Re: pgAdmin4 4.8 Kubuntu issues

[Christoph Berg]

Re: Dave Page 2019-06-05 

> > Second: When I click the "?" button on that dialog box it takes me to this
> > page:
> > "http://127.0.0.1:33681/help/help/master_password.html;
> > Which returns "404 Not Found"
> >
> 
> That sounds like an issue with the packaging - that file is certainly there
> in the source, and works when I click the button (though I do not use the
> Ubuntu packages).

Hi Richard,

do you have the pgadmin4-doc package installed?

At the moment, it is "Suggested" by pgadmin4-common. I'll promote that
to a "Recommends".

Christoph

Re: Enter master password

[Aditya Toshniwal]

Hi Christoph,

We have a RM for that - https://redmine.postgresql.org/issues/4310 and the
fix is underway. Should be available in next release.

On Wed, Jun 5, 2019 at 2:42 PM Christoph Berg  wrote:

> Hi,
>
> in the master password entry popup, it would be awesome if I could
> simply hit Enter to confirm.
>
> Christoph
>
>
>

-- 
Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB India | Pune
"Don't Complain about Heat, Plant a TREE"

Enter master password

[Christoph Berg]

Hi,

in the master password entry popup, it would be awesome if I could
simply hit Enter to confirm.

Christoph

Re: 4.8 docs build error

[Christoph Berg]

Re: Dave Page 2019-06-05 

> This just works around the problem, and will result in incomplete docs. The
> correct solution is to ensure that you have the application dependencies
> installed in the environment in which you build the docs (it's actually a
> subset of them - you probably just need to add the cryptography module).

Thanks Dave, that fixed it.

We already had almost all python runtime dependencies mirrored as
build-dependencies, but python3-crypto{,graphy} was indeed missing.

Will look at the other issue now and then update the package.

Christoph

Re: pgAdmin IV

[Dave Page]

Hi

On Tue, Jun 4, 2019 at 3:28 PM Michelle Schwan  wrote:

> From version pgAdmin IV 4.6 and up, I am now receiving the following error
> message when I import a database into PostgreSQL.
>
>
>
> The database loads fine, but the error that public already exists seems
> strange.  Public is the default schema when creating a database – should
> the message just give a warning instead of an error?
>
> Having a Failed (exit code: 1) error makes it seem like the file did not
> load – when in fact it did.
>
> This should be handled better.
>
>
Those errors don't come from pgAdmin - they come from pg_restore (which is
part of PostgreSQL). pgAdmin is just displaying the output it gets from the
tool.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: pgAdmin4 4.8 Kubuntu issues

[Dave Page]

On Tue, Jun 4, 2019 at 9:41 PM richard coleman 
wrote:

> Second: When I click the "?" button on that dialog box it takes me to this
> page:
> "http://127.0.0.1:33681/help/help/master_password.html;
> Which returns "404 Not Found"
>

That sounds like an issue with the packaging - that file is certainly there
in the source, and works when I click the button (though I do not use the
Ubuntu packages).

Adding Christoph.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: pgAdmin4 4.8 Kubuntu issues

[Dave Page]

Hi

On Tue, Jun 4, 2019 at 10:54 PM Michel Feinstein 
wrote:

> It would be easier if the system when prompting for the Master Password,
> had a "I don't want to define a Master Password" or something like that,
> which would set that config_local.py property automatically.
>

We very intentionally don't do that as 1) allowing pgAdmin to rewrite it's
own application configuration would create a security hole, and b) it would
prevent sysadmins from being able to enforce a security policy on their
users in managed environments.


>
> On Tue, Jun 4, 2019, 18:06 Cherio  wrote:
>
>> Put "MASTER_PASSWORD_REQUIRED = False" line into your
>> "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
>> docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html
>>
>> On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> To whomever,
>>>
>>> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There
>>> are a couple of glaring issues.
>>>
>>> First: It keeps prompting to; "Set Master Password"
>>> I don't want to set another password that I'll just end up
>>> forgetting.
>>>
>>> Second: When I click the "?" button on that dialog box it takes me to
>>> this page:
>>> "http://127.0.0.1:33681/help/help/master_password.html;
>>> Which returns "404 Not Found"
>>>
>>> Hopefully there is a simple solution to these issues.
>>>
>>> Thanks,
>>>
>>> rik.
>>>
>>

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: 4.8 docs build error

[Dave Page]

Hi

On Tue, Jun 4, 2019 at 2:11 PM Christoph Berg  wrote:

> Re: To pgAdmin III support 2019-06-04 <20190604124400.ga4...@msg.df7cb.de>
> > The problem is in docs/en_US/build_code_snippet.py:
>

This just works around the problem, and will result in incomplete docs. The
correct solution is to ensure that you have the application dependencies
installed in the environment in which you build the docs (it's actually a
subset of them - you probably just need to add the cryptography module).

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company