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

[Busser, Jim]

On 2015-01-15, at 8:03 AM, Karsten Hilbert <address@hidden> wrote:

> On Thu, Jan 15, 2015 at 03:42:51PM +0000, Jim Busser wrote:
> 
>>> "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.
>> 
>> Would there be case where database support personnel who is trusted with 
>> sudo access (but not root) would be unable to fully enough become "postgres" 
>> thus necessitating to assign a password to postgres in order that the 
>> support personnel can do what may be necessary?
> 
> Not that I can think of.
> 
>> And since I do not have such support personnel, is there anyway to revoke 
>> ("unset") having set a password on a system account?
> 
>       passwd -l postgres
> 
> as root should work.
> 
>>> But postgres won't have any permissions to look inside the
>>> parent paths (/root/gnumed). That's why the default is
>>> /tmp/gnumed :-)
>> 
>> This default "is" (or would best be set by users) to be
>> 
>>      /tmp/gnumed
>> 
>> where … in the restore conf?
> 
> Yes. The tarball .conf.example already has that value. It
> didn't propagate into the installed .conf on Debian so far,
> however.

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"

given its permissions of

    drwxr-x---  7 root root  4096 Jan 21 22:36 server

… until I overcame the above by applying

        chmod -R 777 /tmp/gnumed-server.20.2/

and then re-ran the restore script, after which I got farther, but not all the 
way through. The log (attached) includes:

        ERROR:  unrecognized configuration parameter "lock_timeout"
        ERROR:  invalid locale name en_CA
        ERROR:  database "gnumed_v20" does not exist
        FATAL:  database "gnumed_v20" does not exist

The output of the Debian system 'locale' is

    LANG=en_CA.UTF-8
    LANGUAGE=en_CA:en
    LC_CTYPE="en_CA.UTF-8"
    LC_NUMERIC="en_CA.UTF-8"
    LC_TIME="en_CA.UTF-8"
    LC_COLLATE="en_CA.UTF-8"
    LC_MONETARY="en_CA.UTF-8"
    LC_MESSAGES="en_CA.UTF-8"
    LC_PAPER="en_CA.UTF-8"
    LC_NAME="en_CA.UTF-8"
    LC_ADDRESS="en_CA.UTF-8"
    LC_TELEPHONE="en_CA.UTF-8"
    LC_MEASUREMENT="en_CA.UTF-8"
    LC_IDENTIFICATION="en_CA.UTF-8"
    LC_ALL=

and the output of locale -a is:

        C
        C.UTF-8
        en_CA.utf8
        POSIX

Is one of my problems that LC_ALL= is empty, and do I need to do

        sudo update-locale LC_ALL="en_CA.UTF-8"

as someone else suggested here:

        
http://codetheory.in/fixing-locale-warnings-notices-issues-on-linux-server-or-desktop/

but even if that should fix the one problem, what about the upstream 
"lock_timeout" and downstream database "gnumed_v20" does not exist ??

-- Jim

restoring-database-2015-01-21_23-00-48.log
Description: restoring-database-2015-01-21_23-00-48.log