password authentication failed (SOLVED)

[Gary Roach]

On 07/22/2015 04:44 PM, Chris Angelico wrote:
> 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
pgAdmin3 showed two potential problems.

The first connection listed in pg_hba.conf was: local  all postgres   
radius. I removed this line so that the first line would be: local   
all  all  trust. Since all connections will be handled through Django? 
there should not be a problem with keeping loose security at this point.

The second problem was that all fo the sequence and table files in 
archivedb showed the owner to be root. I changed them all to archive - 
the user listed in Django's settings.py file.

Python manage.py migrate now works with no errors.

Thank you for your help. I found an O'Reilly book - PosgreSQL Up & 
Running, 2nd Edition, by Regina Obe and Leo Hsu that is very good. If I 
had read the book first, I would have avoided some of these problems. 
One of the things that I have found very frustrating is that most of the 
documentation is too compartmentalized. If an author is writing about 
Django they get sloppy with the database setup and visa versa. It now 
seems to me that:
      Postgresql should be set up first, the setup being completely 
disconnected from the Python / Django project
     All communication with the database will pass through Django with 
the exception of admin maintenance.

Please correct me if I'm wrong.

Gary R.