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

[Busser, Jim]

On 2015-01-14, at 10:18 AM, Karsten Hilbert <address@hidden> wrote:

> On Wed, Jan 14, 2015 at 05:53:51PM +0100, Karsten Hilbert wrote:
> 
>>>>    cp: cannot stat `backup-gnumed_v19-2015-01-12-09-59-25.tar': No such 
>>>> file or directory
>>> 
>>> hmm … is it a
>>> path problem?
>> 
>> It is, but differently than you think :-)  I'll tell you the
>> details as soon as time allows.
> 
> So, here's the explanation:
> 
> I noticed that the output of your restore
> 
>>      ==> Setting up workspace ... 
>> Users/djb/gnumed/gm-restore-2015-01-13-10-27-04
>> 
>>       ==> Creating copy of backup file …
>> 
>>      cp: directory Users/djb/gnumed/gm-restore-2015-01-13-10-27-04 does not 
>> exist
> 
> did not show a / at the beginning of the workspace path.
> Going back to your config file that's because it was
> configured that way:
> 
>>      ==> Reading configuration …
> ...
> 
>> # set this to a writable directory on a drive where
>> # there is plenty of disk space available
>> # WORK_DIR_BASE="${HOME}/gnumed"
>> WORK_DIR_BASE="Users/djb/gnumed"
> 
> I should assume this came about when you set up this file to
> match your environment. However, "Users/djb/gnumed" is a
> relative path which leads to the restore script doing the
> following:
> 
>       echo "==> Setting up workspace ..."
>       TS=`date +%Y-%m-%d-%H-%M-%S`
>       WORK_DIR="${WORK_DIR_BASE}/gm-restore-${TS}/"
>       echo "    ${WORK_DIR}"
> 
> create a temporary dir:
> 
>       mkdir -p ${WORK_DIR}
> 
> (which is, however, relative to the current dir because
> $WORK_DIR_BASE is relative...)
> 
>       if test $? -ne 0 ; then
>               echo "    ERROR: Cannot create workspace. Aborting."
>               exit 1
>       fi
>       chmod +rx ${WORK_DIR}
> 
> then change into that directory (which works whether relative
> or absolute):
> 
>       cd ${WORK_DIR}
> 
>       echo "==> Creating copy of backup file ..."
> 
> and *then* copy the backup to the work dir (which will fail
> because it would apply the relative path to the work dir it
> just changed into _again_):
> 
>       cp -v ${BACKUP} ${WORK_DIR}
> 
> Had $WORK_DIR been absolute (courtesy of $WORK_DIR_BASE being
> absolute) this step would have worked.
> 
>       if test $? -ne 0 ; then
>               echo "    ERROR: Cannot copy backup file. Aborting."
>               echo "   "`ls -al ${BACKUP}`
>               exit 1
>       fi
> 
> I'll adjust the script to be more resilient. In the meantime
> please re-run with the _full_ path to the backup file given
> to the script.

Closer … inside the Debian (VirtualBox) VM, within my normal user account 
(jim), I downloaded server 20.0 tarball and then as root, changed into the 
server directory

        cd downloads/gnumed-server.20.0/server

but before proceeding, because I now have postgres 9.1 and 9.4 running in this 
vm which might cause port confusion, I checked their status …

        /usr/bin/pg_lsclusters

giving me

        Ver Cluster Port Status Owner Data directory Log file
        9.1 main 5432 online postgres /var/lib/postgresql/9.1/main 
/var/log/postgresql/postgresql-9.1-main.log
        9.4 main 5433 online postgres /var/lib/postgresql/9.4/main 
/var/log/postgresql/postgresql-9.4-main.log 

and so to ensure that when the restore script calls the right port, I took the 
precaution of

        PGPORT=5433; export PGPORT

and when I then ran the restore script directly, while providing the full path 
to my backup file ...

        ./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

but after being offered to (and choosing not to) alter my roles.sql file there 
was the following …

========================================================================

==> Trying to restore a GNUmed backup ...
    file: 
/media/sf_Shared/backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25.tar

==> Reading configuration ...

==> Setting up workspace ...
    /root/gnumed/gm-restore-2015-01-14-11-24-53/

==> Creating copy of backup file ...
`/media/sf_Shared/backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25.tar'
 -> 
`/root/gnumed/gm-restore-2015-01-14-11-24-53/ed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25.tar'

==> Unpacking backup file ...
 => Extracting (from tarball) ...
tar: Ignoring unknown extended header keyword `LIBARCHIVE.creationtime'
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
-rw-r--r-- root/djb  383338223 2015-01-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
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
-rw-r--r-- root/djb        530 2015-01-12 09:59 
backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25-roles.sql
changed ownership of 
`backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25-database.sql'
 from root to postgres
changed ownership of 
`backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25-roles.sql'
 from root to postgres

==> Adjusting GNUmed roles ...                                                  
                                                                                
        
                                                                                
                                                                                
        
   You will now be shown the roles backup file. Please                          
                                                                                
        
   edit it to only include the roles you need for GNUmed.                       
                                                                                
        

   Remember that in PostgreSQL scripts the comment marker is "--".

   Press <ENTER> to start editing.

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

where I was not sure which password was being asked for, I thought maybe root 
but did not realize it was maybe asking for postgres.

Maybe on account of not having a key file set up, I need to uncomment a prompt 
in one of the config or script files?

-- JIm