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

[Busser, Jim]

On 2015-01-14, at 11:38 AM, Jim Busser <address@hidden> 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

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"

leaving me scratching my head as to what is causing the above problem with 
authentication failure, which through trial and error turns out to relate to my 
having altered, in

        pg_hba.conf

the line

        local   all             postgres                                peer

by changing 'peer' to 'md5' and which by changing back to 'peer' in both

        /etc/postgresql/9.1/main/pg_hba.conf
        /etc/postgresql/9.4/main/pg_hba.conf

I was able to get system user postgres to be able to connect with each of

        psql
        psql -p 5433

working, with the first of them reporting "psql (9.4.0, server 9.1.14)" and so 
when as root, from inside the server directory ...

        address@hidden:/home/jim/downloads/gnumed-server.20.0/server#

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

??

-- JIm