[Top][All Lists]

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

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

From: Busser, Jim
Subject: Re: [Gnumed-devel] Restoring a database under Debian
Date: Thu, 22 Jan 2015 21:24:39 +0000

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

> On Thu, Jan 22, 2015 at 07:51:07AM +0000, Jim Busser wrote:
>> I tried again. This time, using a .tar prepared from my 
>> successfully-upgraded (under Mac OS) v20.
>> However despite my having, in
>>      /etc/gnumed/gnumed-restore.conf
>> set the parameter as
>>      WORK_DIR_BASE="/tmp/gnumed"
>> it seems that postgres still lacked permission to change directory into
>>      "/tmp/gnumed-server.20.2/server"
> Can you give the exact output of that ?  There's two
> instances of this happening that seem to be
> harmless/informative AFAICT.

I may have made some headway.

1) it seems that when the script switches users from root to system user 
postgres, the latter's lack of permission to be positioned in the server 
directory may indeed have been harmless

2) the ERROR:  unrecognized configuration parameter "lock_timeout" may have 
been a clue that despite my having installed PostgreSQL 9.4 into the Debian VM 
and despite that issuing 'psql --version' from the shell returns '9.4.0' the 
configurational setting of port 5432 in /etc/gnumed/gnumed-restore.conf may 
have caused psql 9.1 to have been called … once I changed the configured port 
to 5433 my retry saw no recurrence of this error.

3) but I remain stuck at the point of locale (see log).

(below my terminal output in which I left-justified my commands, and indented 
status lines returned)

address@hidden:~$ su
cd /tmp

# ensure that I have enough space within the VM hard drive …
df -Ph . | tail -1 | awk '{print $4}'

# better check the settings within gnumed-restore.conf
# --> aha! this turned out to set to the default port 5432 on which PostgreSQL 
9.1 is running
# --> … maybe why the restore was attempted by psql 9.1 antedating 
# --> … despite that if, in the shell, I issue 'psql --version' what I get is 
# --> … which version of PG does not know about configuration parameter
nano /etc/gnumed/gnumed-restore.conf

# (provide root its own copy of server files)
cp -R /media/sf_Shared/gnumed-server.20.2/ .

# show the permissions on the resulting folder
ls -al gnumed-server.20.2
        total 28
        drwxr-x---  3 root root  4096 Jan 22 12:34 .
        drwxrwxrwt 13 root root  4096 Jan 22 12:38 ..
        -rwxr-x---  1 root root 12292 Jan 22 12:34 .DS_Store
        lrwxrwxrwx  1 root root     6 Jan 22 12:34 Gnumed -> server
        drwxr-x---  7 root root  4096 Jan 22 12:34 server

# cd into the server directory wherein the gnumed-restore.conf script resides
cd /tmp/gnumed-server.20.2/server

# run the script, referencing the .tar which had been backed up on Mac OS by 
psql 9.3.1

# the remainder of this is unindented terminal session output ...

==> Trying to restore a GNUmed backup ...

==> Reading configuration ...

==> Setting up workspace ...
    dir: /tmp/gnumed/gm-restore_2015-01-22_12-49-29/

==> Creating copy of backup file ...

==> Unpacking backup file ...
 => Extracting (from tarball) ...
-rw-r--r-- root/staff 383681328 2015-01-21 21:06 
-rw-r--r-- root/staff     10249 2015-01-21 21:05 

==> Adjusting GNUmed roles ...

   You will now be shown the roles backup file. Please
   edit it to only include the roles needed for GNUmed.

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

   There are more instructions inside the file.

   Press <ENTER> to start editing.

==> Checking target database status ...
    db: gnumed_v20
could not change directory to "/tmp/gnumed-server.20.2/server": Permission 

==> Setting data file permissions ...
changed ownership of 
 from root to postgres
changed ownership of 
 from root to postgres

==> Restoring GNUmed roles ...

==> Restoring GNUmed database gnumed_v20 ...
    ERROR: failed to restore database. Aborting.
           log: ./restoring-database-2015-01-22_12-49-29.log


Attachment: restoring-database-2015-01-22_12-49-29.log
Description: restoring-database-2015-01-22_12-49-29.log

reply via email to

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