I was upgrading from sarge to etch and had this symptom well.
My problems appear to be self-inflicted but there may actually be
a problem in the postinst. So the information below is for your
perusal, in case it helps resolve things.
The root cause in my case was the existing database was owned by a
UID that was in NIS. During the upgrade another 'postgres' UID was
created, in /etc/passwd, and this UID was not able to access the
directory /var/lib/postgresql/8.1/main, which has permissions 0700
and was owned by the NIS UID.
What the package did at installation time was correct behaviour,
and it tried to warn me about the problem at the time.
But is it worth adding a check to the startup scripts that tests
whether the postgres instance directory (/var/lib/postgresql/8.1/main)
is owned by the correct UID, and if not send a warning to the postgres
logs or maybe to syslog? A check like this in the init script would have
made it easier to find the issue.
Thanks for your work on this package.
Details
-------
I was dist-upgrading an amd64 from sarge+a_few_backports to etch.
The old versions were
ssl-cert 1.0.12bpo1
postgresql-8.1 8.1.4-6~bpo.1
The new versions
ssl-cert 1.0.14
postgresql-8.1 8.1.9-0etch1
The relevant bits of the upgrade log are
------------------- log snippet/ ------------------------------------
Preparing to replace postgresql-8.1 8.1.4-6~bpo.1 (using
.../postgresql-8.1_8.1.9-0etch1_amd64.deb) ...
Stopping PostgreSQL 8.1 database server: main Error: The
cluster is owned by user id 93 which does not exist any more
failed!
invoke-rc.d: initscript postgresql-8.1, action "stop" failed.
dpkg: warning - old pre-removal script returned error exit status 1
dpkg - trying script from the new package instead ...
Stopping PostgreSQL 8.1 database server: main Error: The
cluster is owned by user id 93 which does not exist any more
failed!
invoke-rc.d: initscript postgresql-8.1, action "stop" failed.
dpkg: error processing
/var/cache/apt/archives/postgresql-8.1_8.1.9-0etch1_amd64.deb (--unpack):
subprocess new pre-removal script returned error exit status 1
Starting PostgreSQL 8.1 database server: main Error: The cluster is owned
by user id 93 which does not exist any more
failed!
invoke-rc.d: initscript postgresql-8.1, action "start" failed.
dpkg: error while cleaning up:
subprocess post-installation script returned error exit status 1
------------------- /log snippet ------------------------------------
The error about user id 93 is because we have that uid (user 'postgres')
in our NIS database and the machine did not have NIS running at the
time it came to upgrade postgresql. The machine was in "single-user"
mode at that time.
However in my case just rerunning the dist-upgrade (with the machine
running at runlevel 2) did not work.
Neither did removing and reinstalling. (I did not 'purge'.)
This is where I thnk there may a remaining problem.
# apt-get remove postgresql-8.1
(worked ok)
# apt-get install postgresql-8.1
Starting PostgreSQL 8.1 database server: main* The PostgreSQL server
failed to start. Please check the log output:
FATAL: could not access private key file "server.key": Permission denied
failed!
invoke-rc.d: initscript postgresql-8.1, action "start" failed.
dpkg: error processing postgresql-8.1 (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
postgresql-8.1
E: Sub-process /usr/bin/dpkg returned an error code (1)
I grabbed the .deb and unpacked it manually, so I could see the state
before the configuration runs (dpkg --configure)
dpkg --unpack postgresql-8.1_8.1.9-0etch1_amd64.deb
Digging around in /var I found
/var/lib/postgres/
*and*
/var/lib/postgresql/
The former is empty. The latter contains the server.key symlink:
/var/lib/postgresql/8.1/main/server.key ->
/etc/ssl/certs/private/ssl-cert-snakeoil.key
which exists.
Check the permissions, working upward: these seem ok
# ls -l /etc/ssl/private/ssl-cert-snakeoil.key
-rw-r----- 1 root ssl-cert 887 2006-09-04 14:45
/etc/ssl/private/ssl-cert-snakeoil.key
# ls -ld /etc/ssl/private/
drwx--x--- 2 root ssl-cert 1024 2006-09-04 14:45 /etc/ssl/private/
# groups postgres
postgres : postgres ssl-cert postgres
# ls -ld /etc/ssl
drwxr-xr-x 4 root root 1024 2007-07-11 15:51 /etc/ssl
Check 'postgres' can actually read the file: it can
# su - postgres
[EMAIL PROTECTED]:~$ stat --printf "%n %s\n"
/etc/ssl/private/ssl-cert-snakeoil.key
/etc/ssl/private/ssl-cert-snakeoil.key 887
Check the log files in /var/log/postgresql/
There is a mention of 'root.crt', presumably
/var/lib/postgresql/8.1/main/root.crt ->
/etc/postgresql-common/root.crt
This file exists and the permissions are ok
# ls -l /etc/postgresql-common/root.crt
-rw-r--r-- 1 root root 540 2006-09-04 14:45 root.crt
# su - postgres
[EMAIL PROTECTED]:~$ stat --printf "%n %s\n" /etc/postgresql-common/root.crt
/etc/postgresql-common/root.crt 540
I can't find a config file that mentions server.key
find /etc /var/lib/postgresql /usr/share/postgres* -type f \
-exec grep -l server.key {} \;
The answer:
# grep postg /etc/passwd
postgres:x:104:104:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
Oh.
# grep passwd /etc/nsswitch.conf
passwd: files nis
# grep group /etc/nsswitch.conf
group: files nis
Uh-oh.
# vi /etc/passwd
<comment out the postgres user>
# apt-get install postgresql-8.1
Reading package lists... Done
Building dependency tree... Done
postgresql-8.1 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Setting up postgresql-8.1 (8.1.9-0etch1) ...
Starting PostgreSQL 8.1 database server: main.
Removing the entry in /etc/passwd allowed the NIS entry (uid 93)
to be used as the resolution for the user 'postgres'.
This is the uid that owns the directory
/var/lib/postgresql/8.1/main
# ls -lnd /var/lib/postgresql/8.1/main
drwx------ 10 93 2 4096 2007-07-17 13:32 /var/lib/postgresql/8.1/main/
Removing the /etc/passwd entry restored access.
I removed the /etc/shadow entry as well.
I could have also renumbered the /etc/passwd entry to use uid 93,
as no other package on the machine is using it at present, but I think
that's a packaging policy violation.
Cheers
Vince
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
