gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Restoring a database under Debian


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Restoring a database under Debian
Date: Thu, 15 Jan 2015 09:14:22 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Jan 15, 2015 at 05:21:35AM +0000, Jim Busser wrote:

> > ==> Checking target database status ...
> > could not change directory to 
> > "/root/gnumed/gm-restore-2015-01-14-11-24-53": Permission denied
> > Password:

> More progress …
> 
> after the above step, the script did not abort, but instead at
> 
>       ==> Restoring GNUmed roles …
> 
> prompted me again for my (system, I think) postgres password and the fact 
> that I could not do
> 
>       sudo su postgres 
> 
> led me to suspect that my wheezy VM had never had a password set for system 
> user postgres, which I therefore set with
> 
>       passwd postgres

"postgres" is is not supposed to have any password on Debian.
In fact, that is one of the defences against anyone actually
logging in as postgres. Root can always become "postgres"
without need for a password.

> and which looks like it allowed the script to avoid the above-quoted problem 
> of "could not change directory …" but immediately with the password prompt 
> 
>       ==> Checking target database status ...
>       Password:
> 
> I got
> 
>       psql: FATAL: password authentication failed for user "postgres"

On a normal Debian system the database account "postgres"
does not have a password because it needs to be able to run
maintenance scripts. If it asks for one it must be due to a
modified pg_hba.conf.

> I re-issued the command
> 
>       ./gm-restore_database.sh 
> /media/sf_Shared/backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25.tar
>  
> 
> I was able to get even further through the restore, without any complaint at 
> the stage of
> 
>       ==> Checking target database status …
> 
> which did not even any longer prompt me for a password, however I got a new 
> error at the next stage
> 
>       ==> Restoring GNUmed roles ...
>       ERROR: Failed to restore roles. Aborting.
>               see: ./restoring-roles-2015-01-14_20-59-11.log
> 
> which log says only
> 
>       
> /root/gnumed/gm-restore_2015-01-14_20-59-11/backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25-roles.sql:
>  Permission denied
> 
> which feels strange because the permissions in the directory
> 
>       /root/gnumed/gm-restore_2015-01-14_20-59-11/
> 
> seem to be in order...
> 
>       drwxr-xr-x 2 root     root      4096 Jan 14 20:59 .
>       drwxr-xr-x 3 root     root      4096 Jan 14 20:59 ..
>       -rw-r--r-- 1 postgres  503 383338223 Jan 12 10:00 
> backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-
> 25-database.sql
> -rw-r--r-- 1 postgres  503       527 Jan 14 21:00 
> backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25-roles.sql

But postgres won't have any permissions to look inside the
parent paths (/root/gnumed). That's why the default is
/tmp/gnumed :-)

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

[Prev in Thread] Current Thread [Next in Thread]