Thread: Regaining superuser access

Regaining superuser access

From
Bernt Drange
Date:
I have a user with a problem on his PostgreSQL 8.1 server running
Windows:

The server only has one superuser, and for some reason he decided to
remove the logon privilege on this user in PgAdmin III. So now he has
lost superuser access to the database server.

Is there some way to override this setting? Or some way to trick
PostgreSQL into creating a new superuser without superuser access?

I can log on to the database with other users, but even if I add
"trust" to pg_hba.conf PostgreSQL will not let me access the database
as the superuser.

I have remote access to the server, which is now on a ship outside of
Madagascar.

The problem we have seems to be the same as this user reports (but got
no reply):
http://www.nabble.com/Fatal-error%3A-role-%22postgres%22-no-login%21-tp14537100p14541715.html

I have looked in the documentation, but don't seem to be able to find
any solutions. Pointers are welcome!

Kind regards,
Bernt

Re: Regaining superuser access

From
Glyn Astill
Date:
> The server only has one superuser, and for some reason he
> decided to
> remove the logon privilege on this user in PgAdmin III. So
> now he has
> lost superuser access to the database server.
>
> Is there some way to override this setting? Or some way to
> trick
> PostgreSQL into creating a new superuser without superuser
> access?

Start it up in single user mode?

http://www.postgresql.org/docs/8.3/static/app-postgres.html




Re: Regaining superuser access

From
Bernt Drange
Date:
On Sep 18, 2:35 pm, glynast...@yahoo.co.uk (Glyn Astill) wrote:
> > The server only has one superuser, and for some reason he
> > decided to
> > remove the logon privilege on this user in PgAdmin III. So
> > now he has
> > lost superuser access to the database server.
>
> > Is there some way to override this setting? Or some way to
> > trick
> > PostgreSQL into creating a new superuser without superuser
> > access?
>
> Start it up in single user mode?
>
> http://www.postgresql.org/docs/8.3/static/app-postgres.html

Thanks a bunch!

After a lot of fiddling with being able to enter single user mode on a
windows machine (I had to figure out how to run the command line as
the correct user, then for some reason -D didn't work, but SET
PGDATA=xxx worked), I finally managed to fix my problem.

You saved my user's day (of course *I* would never do something that
stupid)!

Bernt

Re: Regaining superuser access

From
Alvaro Herrera
Date:
Bernt Drange escribió:

> After a lot of fiddling with being able to enter single user mode on a
> windows machine (I had to figure out how to run the command line as
> the correct user, then for some reason -D didn't work, but SET
> PGDATA=xxx worked), I finally managed to fix my problem.

Hmm, the -D thing not working should probably be studied -- perhaps
we're missing escaping something somewhere.  Does the PGDATA path
contain spaces or weird chars?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: Regaining superuser access

From
Bernt Drange
Date:
On Sep 18, 7:03 pm, alvhe...@commandprompt.com (Alvaro Herrera) wrote:
> Bernt Drange escribió:
>
> > After a lot of fiddling with being able to enter single user mode on a
> > windows machine (I had to figure out how to run the command line as
> > the correct user, then for some reason -D didn't work, but SET
> > PGDATA=xxx worked), I finally managed to fix my problem.
>
> Hmm, the -D thing not working should probably be studied -- perhaps
> we're missing escaping something somewhere.  Does the PGDATA path
> contain spaces or weird chars?

From memory the path was something like: F:\Postgresql Database\data.
I quoted it with double quotes. Without -D postgres.exe complained
about not finding the data path, with it postgres.exe complained about
not finding the config file, stating that it looked in (from memory
vague) F:\Postgresql Database\data\postgres\somethingmore. Adding the
--config-file parameter didn't help.

Is this enough information for you to start digging a bit more? If
not, I might find the exact messages, but I'm reluctant to do it on
this production database..

Bernt

Re: Regaining superuser access

From
"Scott Marlowe"
Date:
On Fri, Sep 19, 2008 at 2:26 AM, Bernt Drange <badrange@gmail.com> wrote:
> On Sep 18, 7:03 pm, alvhe...@commandprompt.com (Alvaro Herrera) wrote:
>> Bernt Drange escribió:
>>
>> > After a lot of fiddling with being able to enter single user mode on a
>> > windows machine (I had to figure out how to run the command line as
>> > the correct user, then for some reason -D didn't work, but SET
>> > PGDATA=xxx worked), I finally managed to fix my problem.
>>
>> Hmm, the -D thing not working should probably be studied -- perhaps
>> we're missing escaping something somewhere.  Does the PGDATA path
>> contain spaces or weird chars?
>
> From memory the path was something like: F:\Postgresql Database\data.
> I quoted it with double quotes. Without -D postgres.exe complained
> about not finding the data path, with it postgres.exe complained about
> not finding the config file, stating that it looked in (from memory
> vague) F:\Postgresql Database\data\postgres\somethingmore. Adding the
> --config-file parameter didn't help.
>
> Is this enough information for you to start digging a bit more? If
> not, I might find the exact messages, but I'm reluctant to do it on
> this production database..

I'm pretty sure the problem is with the space between Postgresql and
Database.  Not sure if it's fixed in later releases or not.

Re: Regaining superuser access

From
"Tim Bruce - Postgres"
Date:
On Fri, September 19, 2008 07:39, Scott Marlowe wrote:
> On Fri, Sep 19, 2008 at 2:26 AM, Bernt Drange <badrange@gmail.com> wrote:
>> On Sep 18, 7:03 pm, alvhe...@commandprompt.com (Alvaro Herrera) wrote:
>>> Bernt Drange escribió:
>>>
>>> > After a lot of fiddling with being able to enter single user mode on
>>> a
>>> > windows machine (I had to figure out how to run the command line as
>>> > the correct user, then for some reason -D didn't work, but SET
>>> > PGDATA=xxx worked), I finally managed to fix my problem.
>>>
>>> Hmm, the -D thing not working should probably be studied -- perhaps
>>> we're missing escaping something somewhere.  Does the PGDATA path
>>> contain spaces or weird chars?
>>
>> From memory the path was something like: F:\Postgresql Database\data.
>> I quoted it with double quotes. Without -D postgres.exe complained
>> about not finding the data path, with it postgres.exe complained about
>> not finding the config file, stating that it looked in (from memory
>> vague) F:\Postgresql Database\data\postgres\somethingmore. Adding the
>> --config-file parameter didn't help.
>>
>> Is this enough information for you to start digging a bit more? If
>> not, I might find the exact messages, but I'm reluctant to do it on
>> this production database..
>
> I'm pretty sure the problem is with the space between Postgresql and
> Database.  Not sure if it's fixed in later releases or not.
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>
Part of the problem may be the embedded space, as was already mentioned
(even though it shouldn't be an issue).

A good test would be to use the 8.3 directory naming convention which you
can get on Windows by using the "dir /x" command.  On my system,
"C:\Program Files\" is shortened to "C:\PROGRA~1\".  Obviously, you'd have
to look at every directory in the fully qualified filename to pull the 8.3
pathname.

And I'll go back to lurking and learning on the list.

Tim
KB0ODU

--
Timothy J. Bruce

visit my Website at: http://www.tbruce.com
Registered Linux User #325725