DESCRIPTION The script issues mkdir -p but changes the permissions and ownership only to end directory resulting the base directory to be inaccessible to postgresql user. I know that the rpm package contains the base directory, but people tend to remove this as well when cleaning up the databases. Feel free to close it as WONTFIX, but maybe you would like to fix that. Minimum fix is not to use mkdir -p and have early failure. REPRODUCE # rm -fr /var/lib/pgsql/ # /usr/bin/postgresql-setup initdb Initializing database ... failed, see /var/lib/pgsql/initdb.log # cat /var/lib/pgsql/initdb.log runuser: warning: cannot change directory to /var/lib/pgsql: Permission denied -bash: /var/lib/pgsql/.bash_profile: Permission denied could not change directory to "/root" initdb: could not access directory "/var/lib/pgsql/data": Permission denied 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 "en_US.UTF-8". The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english".
There's no way that the initdb script can fully recover from somebody doing "rm -rf /var/lib/pgsql". At the very least, that will blow away the postgres user's .bash_profile; and he may very well have had other files in there too, since it's his home directory. I don't think we'd be doing anybody a service by making it look like that is supposed to be a supported way to remove the data directory. IMO, if you delete files that were installed by a package, you should expect to have to reinstall the package to recover from that.
Thanks tom, the inidb can recover, it does... as the postgresql-setup actually creates that directory, initdb does not mind .bash_profile or any other variable within $HOME of postgres. If you think it should not recover, I suggest to replace the mkdir -p in this script with test of $(dirname $PGDATA) existence and die early. Thanks!
IMO, this really does not make much sense to fix. We could hack around to infinity trying to catch users mistakes this or similar way. But why not to push to rawhide cleanup fix, as I see the two things are not necessary in the script: (a) check for symlink non-existence and (b) the -p parameter for mkdir (as the script unconditionally fails when /var/lib/pgsql does not exist). I think only Rawhide is usable target for this. Tom, I can close this if it does not make sense to you even that way. diff --git a/postgresql-setup b/postgresql-setup index e566106..a755e11 100644 --- a/postgresql-setup +++ b/postgresql-setup @@ -66,9 +66,9 @@ script_result=0 # code shared between initdb and upgrade actions perform_initdb(){ - if [ ! -e "$PGDATA" -a ! -h "$PGDATA" ] + if [ ! -e "$PGDATA" ] then - mkdir -p "$PGDATA" || return 1 + mkdir "$PGDATA" || return 1 chown postgres:postgres "$PGDATA" chmod go-rwx "$PGDATA" fi
I agree the -p option is kind of pointless in light of this discussion. I'm less sure about removing the -h test ... what exactly does -e do if the target is a dangling symlink? Or mkdir for that matter? I think the idea there was that if you want to put the data directory on some other partition, it should be sufficient to make a symlink leading to the desired place at /var/lib/pgsql/data and then do initdb. Obviously the code will work if you also make a directory at the pointed-to spot, but what if you try to leave that step to the script? OTOH, this may largely be moot now that the script doesn't run as root. It's not clear that there are useful setups in which the parent directory of a relocated data directory would be owned by postgres; and if it isn't, you'd have to make the data directory by hand, as root, anyway.
(In reply to Tom Lane from comment #4) > I agree the -p option is kind of pointless in light of this discussion. Thanks, I'll commit that change. > I'm less sure about removing the -h test ... what exactly does -e do if the > target is a dangling symlink? Or mkdir for that matter? > > I think the idea there was that if you want to put the data directory on some > other partition, it should be sufficient to make a symlink leading to the > desired place at /var/lib/pgsql/data and then do initdb. Obviously the code > will work if you also make a directory at the pointed-to spot, but what if > you try to leave that step to the script? For that functionality, we would have to incorporate readlink and try to create the targed of the symlink, probably. > OTOH, this may largely be moot now that the script doesn't run as root. > It's not clear that there are useful setups in which the parent directory of > a relocated data directory would be owned by postgres; and if it isn't, you'd > have to make the data directory by hand, as root, anyway. I thought about dangling symlink case. But as it was not handled in postgresql-setup (checked by quick testing), /usr/bin/initdb failed to win. This check removal would make very unlikely fail to come little bit earlier in code path - and I think that as users are familiar with initdb requirements, they will not rely on automatic directory creation on a pointed-to place. Thus I'll probably go for -h check removal — if nobody beats me :) — also.
postgresql-9.2.4-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/postgresql-9.2.4-2.fc18
postgresql-9.2.4-7.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/postgresql-9.2.4-7.fc19
Package postgresql-9.2.4-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing postgresql-9.2.4-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-14828/postgresql-9.2.4-2.fc18 then log in and leave karma (feedback).
postgresql-9.2.4-7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
postgresql-9.2.5-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/postgresql-9.2.5-1.fc18
Package postgresql-9.2.5-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing postgresql-9.2.5-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-19316/postgresql-9.2.5-1.fc18 then log in and leave karma (feedback).
postgresql-9.2.5-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.