password authentication failed

Chris Angelico rosuav at gmail.com
Wed Jul 22 19:44:03 EDT 2015


On Thu, Jul 23, 2015 at 9:35 AM, Gary Roach <gary719_list1 at verizon.net> wrote:
> At this point, I'm confused about a few things. Does the postgresql server
> and my archivedb reside globally or are they inside my archivedb virtual
> environment. I think globally.

Your virtual environment is a Python construct only. That's where
Python packages get installed, so if you don't activate it, you might
not be able to use psycopg2, but as you surmise, the database itself
is elsewhere on the system.

> To get pgAdmin3 to work, I  have to have it set so that it logs in as gary (
> no choice with this) and set group to root. Then in application > advanced
> options set run as different user to root. This assumes that you are using a
> KDE4 desktop and have these option by right clicking the icons.
>
> pgAdmin3 data:
>     Server Group > Server(1) > archivedb
>                                                     |_ Host name - 127.0.0.1
>                                                     |_ username - archive
>                                                     |_ connected - no
> Archivedb requires a password to go deeper and takes the xxxxxx password
> that is in the django settings.py file. This opens up access to archivedb
> and lists archivedb > Schema(1) > public > tables(10). At this point I found
> that all  of the sequences and all of the tables are owned by root. This is
> probably the root (no pun intended) cause. Now what do I do about it. I'm
> not sure how this came about so don't know how to fix it.

Ah, all owned by root. Okay! I've never actually tried this, but you
might be able to directly reassign a bunch of things:

http://www.postgresql.org/docs/9.4/static/sql-reassign-owned.html

Make sure you have a backup. Reassigning root in this way is quite
possibly a bad idea.

If there aren't too many tables, you could use ALTER TABLE:

http://www.postgresql.org/docs/9.4/static/sql-altertable.html

ALTER TABLE tablename OWNER TO archives;

But in theory, you shouldn't need to worry about owners at all - just
make sure permissions are all assigned. Which you have done. So it's
entirely possible none of this will change anything. :(

Worst case, you may need to do an SQL dump of the entire database,
then check the export, make sure ownership is correct, and reimport
into a brand new database. Tedious, but it's certain to fix the
problem.

ChrisA



More information about the Python-list mailing list