I have an IRC report, confirmed, that in RC2 initdb -W (set super-user
password) fails:

	$ initdb -W
	The files belonging to this database system will be owned by user
	"postgres".
	This user must also own the server process.
	
	The database cluster will be initialized with locale C.
	
	creating directory /u/pg/data... ok
	creating directory /u/pg/data/base... ok
	creating directory /u/pg/data/global... ok
	creating directory /u/pg/data/pg_xlog... ok
	creating directory /u/pg/data/pg_clog... ok
	creating template1 database in /u/pg/data/base/1... ok
	creating configuration files... ok
	initializing pg_shadow... ok
	Enter new superuser password: 
	Enter it again: 
	setting password... 
	The group file wasn't generated. Please report this problem.
	
	initdb failed.
	Removing /u/pg/data.

Of course, the obvious solution is not to use -W.  ;-)

I will research this but I wanted to report it right away.  My only
guess is that the standalone backend to alter the super-user password is
messing up things:

    "$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null <<EOF
        ALTER USER "$POSTGRES_SUPERUSERNAME" WITH PASSWORD '$FirstPw';

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 25 Nov 2002 16:30:17 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Problem with initdb -W

> I have an IRC report, confirmed, that in RC2 initdb -W (set super-user
> password) fails:
>
> Enter new superuser password:
> Enter it again:
> setting password...
> The group file wasn't generated. Please report this problem.
>
> initdb failed.
> Removing /u/pg/data.

I had actually experienced this problem as well on a one-off test machine.
However I just put it down to weirdness and didn't follow it up...sorry...

Chris


Mon, 25 Nov 2002 13:38:17 -0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Problem with initdb -W

It was easier than I thought.  As I now remember, it is not a problem if
pg_pwd or pg_group don't exist.  Initdb should check for pg_pwd because
it just added a password, so it better exist, but there is no reason for
pg_group to exist at this point.

I will patch 7.3 and current CVS.  I don't think this warrants another
RC candidate.  This is the type of cleanup we will be doing to the 7.3
branch for the next few months anyway as part of minor releases.


---------------------------------------------------------------------------

Bruce Momjian wrote:
> I have an IRC report, confirmed, that in RC2 initdb -W (set super-user
> password) fails:
> 
> 	$ initdb -W
> 	The files belonging to this database system will be owned by user
> 	"postgres".
> 	This user must also own the server process.
> 	
> 	The database cluster will be initialized with locale C.
> 	
> 	creating directory /u/pg/data... ok
> 	creating directory /u/pg/data/base... ok
> 	creating directory /u/pg/data/global... ok
> 	creating directory /u/pg/data/pg_xlog... ok
> 	creating directory /u/pg/data/pg_clog... ok
> 	creating template1 database in /u/pg/data/base/1... ok
> 	creating configuration files... ok
> 	initializing pg_shadow... ok
> 	Enter new superuser password: 
> 	Enter it again: 
> 	setting password... 
> 	The group file wasn't generated. Please report this problem.
> 	
> 	initdb failed.
> 	Removing /u/pg/data.
> 
> Of course, the obvious solution is not to use -W.  ;-)
> 
> I will research this but I wanted to report it right away.  My only
> guess is that the standalone backend to alter the super-user password is
> messing up things:
> 
>     "$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null <<EOF
>         ALTER USER "$POSTGRES_SUPERUSERNAME" WITH PASSWORD '$FirstPw';
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 25 Nov 2002 16:38:27 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Problem with initdb -W
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> It was easier than I thought.  As I now remember, it is not a problem if
> pg_pwd or pg_group don't exist.  Initdb should check for pg_pwd because
> it just added a password, so it better exist, but there is no reason for
> pg_group to exist at this point.

I think I may have induced this problem during this change:

	Revision 1.113 / (download) - annotate - [select for diffs] , Mon Oct 21 19:46:45 2002 UTC (5 weeks ago) by tgl 
	CVS Tags: REL7_3_STABLE, HEAD 
	Changes since 1.112: +144 -67 lines
	Diff to previous 1.112 
	
	Make CREATE/ALTER/DROP USER/GROUP transaction-safe, or at least pretty
	nearly so, by postponing write of flat password file until transaction
	commit.

I modified user.c to keep track separately of pg_shadow and pg_group
changes, so that it would write only the file it needed to.  Before
that, it probably *was* true that the initial assignment of a password
to the superuser would cause both pg_pwd and an empty pg_group to be
created.  Too bad it didn't occur to me to test initdb -W :-(

> I will patch 7.3 and current CVS.  I don't think this warrants another
> RC candidate.

Agreed, removal of an incorrect error check seems pretty safe ...

			regards, tom lane

Mon, 25 Nov 2002 18:21:46 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Problem with initdb -W 