Client connection problem

[Axel Braun]

Hi,

I have a similar probem as reported recently on the list (unfortunately
without result)

I have set up a new server (2.8.1) and configured it accordingly. The server
is listening on 8000:
de-dd-srv-1325:~ # netstat -tupan | grep python
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
6446/python

Postgres is running:
de-dd-srv-1325:~ # ps aux | grep postgres
postgres 6040 0.0 0.4 93768 8260 ? S 11:21 0:00
/usr/lib/postgresql92/bin/postgres -D /var/lib/pgsql/data
postgres 6041 0.0 0.0 62148 1260 ? Ss 11:21 0:00 postgres:
logger process
postgres 6043 0.0 0.0 93768 1432 ? Ss 11:21 0:00 postgres:
checkpointer process
postgres 6044 0.0 0.0 93768 1436 ? Ss 11:21 0:00 postgres:
writer process
postgres 6045 0.0 0.0 93768 1204 ? Ss 11:21 0:00 postgres: wal
writer process
postgres 6046 0.0 0.1 94580 2676 ? Ss 11:21 0:00 postgres:
autovacuum launcher process
postgres 6047 0.0 0.0 62144 1472 ? Ss 11:21 0:00 postgres:
stats collector process

...and the role for user tryton was changed with a new password:

srv-1325:~ # su postgres
postgres@de-dd-srv-1325:/root> psql -c "ALTER ROLE tryton WITH PASSWORD
'DBAdminPasswort';"
ALTER ROLE

So far so good. Nothing different to the various test installations I did on
the same platform, except that I have a remote machine now and no local
client.

When connecting from an external machine to create the first database I get
the error "Could not connect to server"
From the tryton user FAQ I found the postgres check:

de-dd-srv-1325:~ # su tryton -s /bin/bash
tryton@de-dd-srv-1325:/root> psql -h localhost
psql: FATAL: Ident authentication failed for user "tryton"

...I was looking for this mysterious pg_hba.conf file but could not spot it.
Any idea if this is the reason, or what to try?

Thanks
Axel

[Jesús Martín Jiménez]

2013/7/19 Axel Braun <axel....@gmx.de>

do you mean the password ends with 't'?

 

ALTER ROLE

So far so good. Nothing different to the various test installations I did on
the same platform, except that I have a remote machine now and no local
client.

When connecting from an external machine to create the first database I get
the error "Could not connect to server"
From the tryton user FAQ I found the postgres check:

de-dd-srv-1325:~ # su tryton -s /bin/bash
tryton@de-dd-srv-1325:/root> psql -h localhost
psql: FATAL:  Ident authentication failed for user "tryton"

...I was looking for this mysterious  pg_hba.conf file but could not spot it.
Any idea if this is the reason, or what to try?

Thanks
Axel

--

Jesús Martín

Zikzakmedia SL

Dr. Fleming, 28, baixos

08720 Vilafranca del Penedès

☏ 93 890 21 08

[Jean C]

...I was looking for this mysterious  pg_hba.conf file but could not spot it.
Any idea if this is the reason, or what to try?

 

Depends on your OS. On Mint (and ubunu I guess), it is in /etc/postgresql/9.1/main

Jean CAVALLO

Coopengo

[Tejas]

Hello,

Please manage your database parameters in tryton config file.

--
Thanks,
Tejas L Tank.
Email : Tejas.t...@gmail.com
Mobile : +91 - ( 85 - 111 - 5 - 33 - 98 )
India.

[Axel Braun]

Am Freitag, 19. Juli 2013, 14:16:28 schrieb Jesús Martín Jiménez:

> > ...and the role for user tryton was changed with a new password:
> >
> > srv-1325:~ # su postgres
> > postgres@de-dd-srv-1325:/root> psql -c "ALTER ROLE tryton WITH PASSWORD
> > 'DBAdminPasswort';"
>
> do you mean the password ends with 't'?

Yes, the german spelling of password :-)

Cheers/Ax

[Jesús Martín Jiménez]

2013/7/19 Axel Braun <axel....@gmx.de>

Could you give us your tryton.config and your /etc/postgresql/9.1/main/pg_hba.conf files?

[Axel Braun]

Am Freitag, 19. Juli 2013, 14:43:03 schrieb Jesús Martín Jiménez:

> Could you give us your tryton.config and your
> /etc/postgresql/9.1/main/pg_hba.conf files?

Sure. In openSUSE, I found the pg_hba.conf file in between in
/var/lib/pgsql/data

# Put your actual configuration here
# ----------------------------------
#
# If you want to allow non-local connections, you need to add more
# "host" records. In that case you will also need to make PostgreSQL
# listen on a non-local interface via the listen_addresses
# configuration parameter, or via the -i or -h command line switches.

# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
#host all all 127.0.0.1/32 ident
host all all 0.0.0.0/0 md5
# IPv6 local connections:
host all all ::1/128 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 ident
#host replication postgres ::1/128 ident

Note: I tried md5 as well as ident for methond in the line 'host'

/etc/trytond.conf is pretty standard:


#This file is part of Tryton. The COPYRIGHT file at the top level of
#this repository contains the full copyright notices and license terms.
[options]

# Activate the json-rpc protocol
#jsonrpc = localhost:8000
jsonrpc = *:8000
ssl_jsonrpc = True

# This is the hostname used when generating tryton URI
#hostname_jsonrpc =

# Configure the path of json-rpc data
#jsondata_path = /var/www/localhost/tryton

# Activate the xml-rpc protocol
#xmlrpc = *:8069
#ssl_xmlrpc = False

# Activate the webdav protocol
#webdav = *:8080
#ssl_webdav = False

# This is the hostname used when generating WebDAV URI
#hostname_webdav =

# Configure the database type
# allowed values are postgresql, sqlite, mysql
db_type = postgresql

# Configure the database connection
## Note: Only databases owned by db_user will be displayed in the connection
dialog
## of the Tryton client. db_user must have create permission for new databases
## to be able to use automatic database creation with the Tryton client.
#db_host = False
#db_port = False
#db_user = False
#db_password = False
#db_minconn = 1
#db_maxconn = 64
# Configure the postgresql path for the executable
#pg_path = None

# Configure the Tryton server password
admin_passwd = admin

# Configure the path of the files for the pid and the logs
#pidfile = False
#logfile = False

#privatekey = server.pem
#certificate = server.pem

privatekey = /etc/trytond/ssl.key/tryton_server.key
certificate = /etc/trytond/ssl.crt/tryton_server.crt

# Configure the SMTP connection
#smtp_server = localhost
#smtp_port = 25
#smtp_ssl = False
#smtp_tls = False
#smtp_password = False
#smtp_user = False

# Configure the path to store attachments and sqlite database
#data_path = /var/lib/trytond

# Allow to run more than one instance of trytond
#multi_server = False

# Configure the session timeout (inactivity of the client in sec)
#session_timeout = 600

# Enable auto-reload of modules if changed
#auto_reload = True

# Prevent database listing
#prevent_dblist = False

# Enable cron
# cron = True

# unoconv connection
#unoconv = pipe,name=trytond;urp;StarOffice.ComponentContext

# Number of retries on database operational error
# retry = 5

# Default language code
# language = en_US

# Timezone of the server
# timezone = False

[Cédric Krier]

On 19/07/13 14:54 +0200, Axel Braun wrote:
> Am Freitag, 19. Juli 2013, 14:43:03 schrieb Jesús Martín Jiménez:
> # Configure the database connection
> ## Note: Only databases owned by db_user will be displayed in the connection
> dialog
> ## of the Tryton client. db_user must have create permission for new databases
> ## to be able to use automatic database creation with the Tryton client.
> #db_host = False
> #db_port = False
> #db_user = False
> #db_password = False

Why don't you setup your db connection parameters?

> #db_minconn = 1
> #db_maxconn = 64
> # Configure the postgresql path for the executable
> #pg_path = None

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/

[Axel Braun]

Am Freitag, 19. Juli 2013, 15:44:02 schrieb Cédric Krier:
> On 19/07/13 14:54 +0200, Axel Braun wrote:
> > Am Freitag, 19. Juli 2013, 14:43:03 schrieb Jesús Martín Jiménez:
> > # Configure the database connection
> > ## Note: Only databases owned by db_user will be displayed in the
> > connection dialog
> > ## of the Tryton client. db_user must have create permission for new
> > databases ## to be able to use automatic database creation with the
> > Tryton client. #db_host = False
> > #db_port = False
> > #db_user = False
> > #db_password = False
>
> Why don't you setup your db connection parameters?

Because it always worked without.

DB and Tryton run still on the same machine.

Cheers/Ax

[Cédric Krier]

But you just add a password to your DB user.

[Mark Hayden (local)]

On Fri, 2013-07-19 at 14:54 +0200, Axel Braun wrote:

Am Freitag, 19. Juli 2013, 14:43:03 schrieb Jesús Martín Jiménez:

> Could you give us your tryton.config and your
> /etc/postgresql/9.1/main/pg_hba.conf files?

Sure. In openSUSE, I found the pg_hba.conf file in between in 
/var/lib/pgsql/data

# Put your actual configuration here
# ----------------------------------
#
# If you want to allow non-local connections, you need to add more
# "host" records.  In that case you will also need to make PostgreSQL
# listen on a non-local interface via the listen_addresses
# configuration parameter, or via the -i or -h command line switches.

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
#host    all             all             127.0.0.1/32            ident
host    all             all             0.0.0.0/0            md5

You mentioned that PGSQL is running on the same host as Tryton.  As such you could probably restrict to 127.0.0.1/32 and database would be more secure and Tryton would still work.  I use MD5 and it works for me but my DB is on a different host.

There is more to it than pg_hba however.  If you notice in the comments of this file it subtly reminds you of this.  Besides the host-based-auth of this file you have to ensure postgresql is listening on TCP sockets or it won't matter if the IP address or subnet is configured here (it will only listen on a UNIX socket file and look at the rule for "local" which is using "peer" auth methof here--maybe changing that to MD5 would work?).  I am not certain that Tryton connects to unix sockets--I think even for local databases it uses localhost TCP socket (can the gurus here confirm that?).

There is a file called "postgresql.conf" where you can set the "listen_address" parameter.  Normally default installations DO listen on localhost, but I am not entirely certain what your version of DB and operating system distribution does.  In general though you need to confirm that pg_hba AND the postgresql.conf files both match your intended environment.

Also, don't forget to restart your postgresql services/daemons for any changes to these files to take effect.

To troubleshoot you can use netstat or nmap to make sure it is listening on localhost for the postgresql (5432) TCP port.

# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication     postgres                                peer
#host    replication     postgres        127.0.0.1/32            ident
#host    replication     postgres        ::1/128                 ident

Note: I tried md5 as well as ident for methond in the line 'host'

/etc/trytond.conf is pretty standard:


#This file is part of Tryton.  The COPYRIGHT file at the top level of
#this repository contains the full copyright notices and license terms.
[options]

# Activate the json-rpc protocol
#jsonrpc = localhost:8000
jsonrpc = *:8000
ssl_jsonrpc = True

This part looks right to me...it is listening to external interface...

# This is the hostname used when generating tryton URI
#hostname_jsonrpc =

# Configure the path of json-rpc data
#jsondata_path = /var/www/localhost/tryton

# Activate the xml-rpc protocol
#xmlrpc = *:8069
#ssl_xmlrpc = False

# Activate the webdav protocol
#webdav = *:8080
#ssl_webdav = False

# This is the hostname used when generating WebDAV URI
#hostname_webdav =

# Configure the database type
# allowed values are postgresql, sqlite, mysql
db_type = postgresql

# Configure the database connection
## Note: Only databases owned by db_user will be displayed in the connection 
dialog
## of the Tryton client. db_user must have create permission for new databases
## to be able to use automatic database creation with the Tryton client.
#db_host = False
#db_port = False
#db_user = False
#db_password = False

I am pretty sure the above four DB_* parameters are NOT optional, even for local databases.  I do not know the default values for these if they are optional.  So, to be safe I would suggest you explicitly supply them as such:

db_host = 127.0.0.1 # the hostname localhost should work here too--if it doesn't you'd have bigger problems ;-)
db_port = 5432
db_user = <put the PGSQL user name of the database owner here>
db_password = <put the password that you set in pgsql for the above user here>

[Cédric Krier]

On 19/07/13 09:27 -0600, Mark Hayden (local) wrote:
> On Fri, 2013-07-19 at 14:54 +0200, Axel Braun wrote:
> There is more to it than pg_hba however. If you notice in the comments
> of this file it subtly reminds you of this. Besides the host-based-auth
> of this file you have to ensure postgresql is listening on TCP sockets
> or it won't matter if the IP address or subnet is configured here (it
> will only listen on a UNIX socket file and look at the rule for "local"
> which is using "peer" auth methof here--maybe changing that to MD5 would
> work?). I am not certain that Tryton connects to unix sockets--I think
> even for local databases it uses localhost TCP socket (can the gurus
> here confirm that?).

If you define no host nor port, normally psycopg2 will use unix socket.

> > # Configure the database connection
> > ## Note: Only databases owned by db_user will be displayed in the connection
> > dialog
> > ## of the Tryton client. db_user must have create permission for new databases
> > ## to be able to use automatic database creation with the Tryton client.
> > #db_host = False
> > #db_port = False
> > #db_user = False
> > #db_password = False
>
> I am pretty sure the above four DB_* parameters are NOT optional, even
> for local databases. I do not know the default values for these if they
> are optional. So, to be safe I would suggest you explicitly supply them
> as such:
>
> db_host = 127.0.0.1 # the hostname localhost should work here too--if it
> doesn't you'd have bigger problems ;-)
> db_port = 5432

Only if you want to use TCP socket.

[Mark Hayden (local)]

On Fri, 2013-07-19 at 17:33 +0200, Cédric Krier wrote:

On 19/07/13 09:27 -0600, Mark Hayden (local) wrote:
> On Fri, 2013-07-19 at 14:54 +0200, Axel Braun wrote:
> There is more to it than pg_hba however.  If you notice in the comments
> of this file it subtly reminds you of this.  Besides the host-based-auth
> of this file you have to ensure postgresql is listening on TCP sockets
> or it won't matter if the IP address or subnet is configured here (it
> will only listen on a UNIX socket file and look at the rule for "local"
> which is using "peer" auth methof here--maybe changing that to MD5 would
> work?).  I am not certain that Tryton connects to unix sockets--I think
> even for local databases it uses localhost TCP socket (can the gurus
> here confirm that?).

If you define no host nor port, normally psycopg2 will use unix socket.

That is good to know.  That would mean host and port are optional.  Never wondered about that myself as I connect to separate database server.

> > # Configure the database connection
> > ## Note: Only databases owned by db_user will be displayed in the connection 
> > dialog
> > ## of the Tryton client. db_user must have create permission for new databases
> > ## to be able to use automatic database creation with the Tryton client.
> > #db_host = False
> > #db_port = False
> > #db_user = False
> > #db_password = False
> 
> I am pretty sure the above four DB_* parameters are NOT optional, even
> for local databases.  I do not know the default values for these if they
> are optional.  So, to be safe I would suggest you explicitly supply them
> as such:
> 
> db_host = 127.0.0.1 # the hostname localhost should work here too--if it
> doesn't you'd have bigger problems ;-)
> db_port = 5432

Only if you want to use TCP socket.

That makes sense.  How about username and password?  Axel's file had "peer" for auth method in pg_hba for "local" (unix socket) connections which would get the user name from the OS--presumably the user account running the trytond process.  If no user name or password are supplied in the Tryton config would that be the assumed setup?  In that case I would guess that without any DB settings in the Tryton config file that a person could handle this by making sure trytond is running under a user account with the same name as the database owner in PostgreSQL.

(I apologise for the questions--I forsee a situation where I may install a small/single-server in the future here...)

[Cédric Krier]

On 19/07/13 10:13 -0600, Mark Hayden (local) wrote:
> On Fri, 2013-07-19 at 17:33 +0200, Cédric Krier wrote:
> > > > # Configure the database connection
> > > > ## Note: Only databases owned by db_user will be displayed in the connection
> > > > dialog
> > > > ## of the Tryton client. db_user must have create permission for new databases
> > > > ## to be able to use automatic database creation with the Tryton client.
> > > > #db_host = False
> > > > #db_port = False
> > > > #db_user = False
> > > > #db_password = False
> > >
> > > I am pretty sure the above four DB_* parameters are NOT optional, even
> > > for local databases. I do not know the default values for these if they
> > > are optional. So, to be safe I would suggest you explicitly supply them
> > > as such:
> > >
> > > db_host = 127.0.0.1 # the hostname localhost should work here too--if it
> > > doesn't you'd have bigger problems ;-)
> > > db_port = 5432
> >
> > Only if you want to use TCP socket.
>
> That makes sense. How about username and password? Axel's file had
> "peer" for auth method in pg_hba for "local" (unix socket) connections
> which would get the user name from the OS--presumably the user account
> running the trytond process. If no user name or password are supplied
> in the Tryton config would that be the assumed setup?

The user that is running trytond.

> In that case I
> would guess that without any DB settings in the Tryton config file that
> a person could handle this by making sure trytond is running under a
> user account with the same name as the database owner in PostgreSQL.

Yes.

[Axel Braun]

Am Freitag, 19. Juli 2013, 18:34:22 schrieb Cédric Krier:
> > Only if you want to use TCP socket.
> >
> >
> >
> > That makes sense. How about username and password? Axel's file had
> > "peer" for auth method in pg_hba for "local" (unix socket) connections
> > which would get the user name from the OS--presumably the user account
> > running the trytond process. If no user name or password are supplied
> > in the Tryton config would that be the assumed setup?
>
> The user that is running trytond.
>
> > In that case I
> > would guess that without any DB settings in the Tryton config file that
> > a person could handle this by making sure trytond is running under a
> > user account with the same name as the database owner in PostgreSQL.
>
> Yes.

Thanks for your answers, Gentlemen.

So to summarize
- db user name is not required if user und which trytond runs and db-owner are
the same. in this case the user is 'tryton'
- host and socket are not required for local installation of database and
tryton-server
- pg_hba can merely remain unchanged, esp, the line
host all all 127.0.0.1/32 ident
as the connection is still local. Whether ident , md5 or whatever works has to
be tested.

So, I added db_user and password in /etc/trytond.conf, had all daemons
restartet, and still the connection from the client / profile manager does not
work. Now, this coud mean that no db exists (which is true)

So I tried to create a db via the client, and get a dump after entering the
server-IP:
File "/usr/lib/python2.7/site-packages/tryton/gui/window/dbcreate.py", line
70, in server_change
common.refresh_langlist(self.combo_language, host, port)

File "/usr/lib/python2.7/site-packages/tryton/common/common.py", line 248,
in refresh_langlist
lang_list = rpc.db_exec(host, port, 'list_lang')

File "/usr/lib/python2.7/site-packages/tryton/rpc.py", line 57, in db_exec
result = getattr(connection.common.db, method)(None, None, *args)

File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)

File "/usr/lib/python2.7/site-packages/tryton/jsonrpc.py", line 314, in
__request
verbose=self.__verbose

File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)

File "/usr/lib64/python2.7/xmlrpclib.py", line 1294, in single_request
response = h.getresponse(buffering=True)

File "/usr/lib64/python2.7/httplib.py", line 1030, in getresponse
response.begin()

File "/usr/lib64/python2.7/httplib.py", line 407, in begin
version, status, reason = self._read_status()

File "/usr/lib64/python2.7/httplib.py", line 371, in _read_status
raise BadStatusLine(line)

Is this a bug, or a follow-up on the connection problem?

Thanks
Axel

[Mark Hayden (local)]

On Fri, 2013-07-19 at 19:20 +0200, Axel Braun wrote:

Am Freitag, 19. Juli 2013, 18:34:22 schrieb Cédric Krier:
>  > Only if you want to use TCP socket.
> >
> > 
> >
> > That makes sense.  How about username and password?  Axel's file had
> > "peer" for auth method in pg_hba for "local" (unix socket) connections
> > which would get the user name from the OS--presumably the user account
> > running the trytond process.  If no user name or password are supplied
> > in the Tryton config would that be the assumed setup?
> 
> The user that is running trytond.
> 
> > In that case I
> > would guess that without any DB settings in the Tryton config file that
> > a person could handle this by making sure trytond is running under a
> > user account with the same name as the database owner in PostgreSQL.
> 
> Yes.

Thanks for your answers, Gentlemen.

So to summarize
- db user name is not required if user und which trytond runs and db-owner are 
the same. in this case the user is 'tryton'

This is what I understand now as well.  If no user name is present then the user name presented to PostgreSQL for authentication would be the user 'tryton' if that is the account under which your trytond process is running.
Not 100% of password.  If you do not specify one in the tryton config then it would probably use other auhentication methods like peer, ident, gssapi/kerberos depending on what is specified in your pg_hba.conf file.

-  host and socket are not required for local installation of database and 
tryton-server
- pg_hba can merely remain unchanged, esp, the line 
host    all             all             127.0.0.1/32            ident
as the connection is still local. Whether ident , md5 or whatever works has to 
be tested.

Careful with this one.  In our discussions on this thread it was mentioned that "psycopg2" is used for the database interface so its conventions determine how Tryton works with the database.  If no hostname is supplied then the default unix domain socket is used.  Unix soxkets are different from localhost TCP sockets, and the entry you show is for the latter.  If you have a blank host then the pg_hba rule line that applies is the one starting with the word "local", NOT The "host" line with the local IP address.  In my experience the auth method is "peer" for UNIX/local sockets.  Peer auth simply asks the kernel what user is running the client process and that is it--no password is asked for (and the pgsql database user proabably shouldn't even have a password).

A quick Google search reveals that hostname in psycopg2 can also be the absolute/full path name to a UNIX socket (a UNIX socket simply being a special kind of file on your system such as /var/run/postgresql/.s.PGSQL.5432).  If you are having trouble make sure the path of .s.PGSQL.5432 in postgresql.conf (the unix_socket_directory option) matches what you specify in the tryton config if the default/blank hostname does not work.

So, I added db_user and password in /etc/trytond.conf, had all daemons 
restartet, and still the connection from the client / profile manager does not 
work. Now, this coud mean that no db exists (which is true)

if you put a db_user and db_password into tryton's config file it woud probably try password or md5 auth instead of peer and I am not sure if that would work--if you are going to supply username and password the method for "local" should be changed from peer to md5 in your pg_hba file I would think.

Also, when I set up Tryton for myself I went into pgsql and did CREATE DATABASE to make a new database and then assigned my tryton user as owner.  In my system the tryton database user is NOT granted permission to create databases so this was required.  Tryton takes care of creating the schema within the new/blank database and as the owner of the database the tryton user could to that once the empty database was created.

I think it is a followup to the connection problem.

You might want to start with commenting out all the db_ settings (except the one that says to use postgresql) as you had before and making sure trytond is running under user "tryton" and that there is a user "tryton" in pgsql.  Then make sure you go into pgsql and have a database created with the user "tryton" as owner.  That should result in Tryton attempting to use a UNIX socket and "peer" authentication to log into pgsql as user "Tryton" and populate the database with the schema.

From that point I might try the following if that does not work:

1. it could be that tryton is assuming the wrong unix socket directory.  If that is the case you can look for where the unix socket file called .s.PGSQL.5432 is then specify that path in the db host in tryton's config file.  You can select a different location for ths unix socket by specifying a unix_socket_directory in postgresql.conf

2. if the default setup continues to cause trouble maybe go the "brute force" way--explicitly type in db host as 127.0.0.1, port a 5432, user as 'tryton' and password as what you set in pgsql, and make sure the pg_hba entry used the md5 auth method.  I'm pretty sure that would work, especially if there is at least a new/blank database that is owned by tryton user.

Thanks
Axel

[Cédric Krier]

The known_hosts file must be fixed
http://doc.tryton.org/2.8/tryton/doc/usage.html#configuration-file

[Axel Braun]

Am Freitag, 19. Juli 2013, 21:00:15 schrieb Cédric Krier:
> > File "/usr/lib64/python2.7/httplib.py", line 371, in _read_status
> > raise BadStatusLine(line)
> >
> > Is this a bug, or a follow-up on the connection problem?
>
> The known_hosts file must be fixed
> http://doc.tryton.org/2.8/tryton/doc/usage.html#configuration-file

The good part of this would have been that the connection to the server may
work , I I switched off SSL in between to see if it works w/o SSL, an switched
on afterwards.

Anyway, I fixed the known_hosts file and the error message remains

Cheers/Axel

[Dr. Axel Braun]

Hello,

Am Freitag, 19. Juli 2013, 12:55:39 schrieb Mark Hayden:

> > So to summarize
> > - db user name is not required if user und which trytond runs and db-owner
> > are the same. in this case the user is 'tryton'
>
> This is what I understand now as well. If no user name is present then
> the user name presented to PostgreSQL for authentication would be the
> user 'tryton' if that is the account under which your trytond process is
> running.

I have set it up that way...

> Not 100% of password. If you do not specify one in the tryton config
> then it would probably use other auhentication methods like peer, ident,
> gssapi/kerberos depending on what is specified in your pg_hba.conf file.
>
> > - host and socket are not required for local installation of database and
> > tryton-server
> > - pg_hba can merely remain unchanged, esp, the line
> > host all all 127.0.0.1/32 ident
> > as the connection is still local. Whether ident , md5 or whatever works
> > has to be tested.
>
> Careful with this one. In our discussions on this thread it was
> mentioned that "psycopg2" is used for the database interface so its
> conventions determine how Tryton works with the database. If no
> hostname is supplied then the default unix domain socket is used. Unix
> soxkets are different from localhost TCP sockets, and the entry you show
> is for the latter. If you have a blank host then the pg_hba rule line
> that applies is the one starting with the word "local", NOT The "host"
> line with the local IP address. In my experience the auth method is
> "peer" for UNIX/local sockets. Peer auth simply asks the kernel what
> user is running the client process and that is it--no password is asked
> for (and the pgsql database user proabably shouldn't even have a
> password).

right, the user tryton is created without login permission, so 'peer' for the
local entry
local all all peer
should work. In fact, it does :-)

I changed the line

host all all 127.0.0.1/32 ident

to
host all all 127.0.0.1/32 peer
and with this setting the postgres server failed to start. Probably due to the
fact that the user 'tryton' does not have a password.
If I set the parameter 'md5' the database starts, and the login test
sudo -u tryton psql -h localhost template1 tryton
works. I have to enter the database password for the user tryton.
So it seems that md5 works for the 'host' line

> A quick Google search reveals that hostname in psycopg2 can also be the
> absolute/full path name to a UNIX socket (a UNIX socket simply being a
> special kind of file on your system such
> as /var/run/postgresql/.s.PGSQL.5432). If you are having trouble make
> sure the path of .s.PGSQL.5432 in postgresql.conf (the
> unix_socket_directory option) matches what you specify in the tryton
> config if the default/blank hostname does not work.

The unix socket file for openSUSE is in /tmp.
But which option in /etc/trytond.conf tells the tryton server in which
directory to look for s.PGSQL.5432?

> > So, I added db_user and password in /etc/trytond.conf, had all daemons
> > restartet, and still the connection from the client / profile manager does
> > not work. Now, this coud mean that no db exists (which is true)
>
> if you put a db_user and db_password into tryton's config file it woud
> probably try password or md5 auth instead of peer and I am not sure if
> that would work--if you are going to supply username and password the
> method for "local" should be changed from peer to md5 in your pg_hba
> file I would think.
>
> Also, when I set up Tryton for myself I went into pgsql and did CREATE
> DATABASE to make a new database and then assigned my tryton user as
> owner. In my system the tryton database user is NOT granted permission
> to create databases so this was required. Tryton takes care of creating
> the schema within the new/blank database and as the owner of the
> database the tryton user could to that once the empty database was
> created.

I tried this now as well.
As it did not work, I had a look into various log files, and found in the
system log:
SSLError: [Errno 336265218] _ssl.c:364: error:140B0002:SSL
routines:SSL_CTX_use_PrivateKey_file:system lib

Asking Google, it pointed out that this may be an access problem:

On the other hand, it should be readable for group tryton
dir /etc/trytond/ssl.key
-rw-r--r-- 1 root tryton 3243 Jul 18 12:14 tryton_server.key

I changed the permissions to tryton:tryton, but that was obviously not the
problem, as the error remains. In full:

trytond[487]: Traceback (most recent call last):
trytond[487]: File "/usr/lib64/python2.7/SocketServer.py", line 582, in
process_request_thread
trytond[487]: self.finish_request(request, client_address)
trytond[487]: File "/usr/lib64/python2.7/SocketServer.py", line 323, in
finish_request
trytond[487]: self.RequestHandlerClass(request, client_address, self)
trytond[487]: File "/usr/lib64/python2.7/SocketServer.py", line 636, in
__init__
trytond[487]: self.setup()
trytond[487]: File "/usr/lib/python2.7/site-
packages/trytond/protocols/jsonrpc.py", line 258, in setup
trytond[487]: self.request = SSLSocket(self.request)
trytond[487]: File "/usr/lib/python2.7/site-
packages/trytond/protocols/sslsocket.py", line 13, in SSLSocket
trytond[487]: ssl_version=ssl.PROTOCOL_SSLv23)
trytond[487]: File "/usr/lib64/python2.7/ssl.py", line 381, in wrap_socket
trytond[487]: ciphers=ciphers)
trytond[487]: File "/usr/lib64/python2.7/ssl.py", line 141, in __init__
trytond[487]: ciphers)
trytond[487]: SSLError: [Errno 336265218] _ssl.c:364: error:140B0002:SSL
routines:SSL_CTX_use_PrivateKey_file:system lib

So, here I'm stuck again....

[Axel Braun]

Am Samstag, 20. Juli 2013, 09:15:29 schrieb Dr. Axel Braun:

Regarding the latest issue in connecting....

> trytond[487]: Traceback (most recent call last):
> trytond[487]: File "/usr/lib64/python2.7/SocketServer.py", line 582, in
> process_request_thread
> trytond[487]: self.finish_request(request, client_address)
> trytond[487]: File "/usr/lib64/python2.7/SocketServer.py", line 323, in
> finish_request
> trytond[487]: self.RequestHandlerClass(request, client_address, self)
> trytond[487]: File "/usr/lib64/python2.7/SocketServer.py", line 636, in
> __init__
> trytond[487]: self.setup()
> trytond[487]: File "/usr/lib/python2.7/site-
> packages/trytond/protocols/jsonrpc.py", line 258, in setup
> trytond[487]: self.request = SSLSocket(self.request)
> trytond[487]: File "/usr/lib/python2.7/site-
> packages/trytond/protocols/sslsocket.py", line 13, in SSLSocket
> trytond[487]: ssl_version=ssl.PROTOCOL_SSLv23)
> trytond[487]: File "/usr/lib64/python2.7/ssl.py", line 381, in wrap_socket
> trytond[487]: ciphers=ciphers)
> trytond[487]: File "/usr/lib64/python2.7/ssl.py", line 141, in __init__
> trytond[487]: ciphers)
> trytond[487]: SSLError: [Errno 336265218] _ssl.c:364: error:140B0002:SSL
> routines:SSL_CTX_use_PrivateKey_file:system lib

...i found a similar problem in openERP:
https://bugs.launchpad.net/openobject-server/+bug/682579
seems to be older already, anyway.

Just to make sure that there is no problem with the keys I changed the ssl-
keys against a pair that is known to work. But that did not solve the problem.

Basically I have twice nearly the same setup:

- Installation on Virtualbox, openSUSE 12.3, 32bit, LXDE-Dektop
- Installation on VMWare, openSUSE 12.3, 64bit, no Desktop

The largest difference is 32/64bit, which may cause the problem. I will try
another setup of 64bit on virtualbox - see if that behaves different.

Or shall I file a tryton bug against it?

Cheers/Ax

[Axel Braun]

After some trials and tests the solution was quite simple:

chmod +x /etc/trytond
(on the directory that holds the keys....)

I have updated the wiki accordingly.
Thanks for your help!
Axel

[arafat aree]

please i need help installing GNU HEALTH how can i manually install gnu-health i try moving the gnu-health modules to trytond directory and it didn't work could somebody help me please

[Axel Braun]

Am Sonntag, 24. November 2013, 02:03:39 schrieb arafat aree:
> please i need help installing GNU HEALTH

A good place to start:

https://en.wikibooks.org/wiki/GNU_Health/Operating_System-Specific_Notes
http://www.tryton.org/download.html (the 'install' section)
http://wiki.tryton.org/

> how can i manually install
> gnu-health i try moving the gnu-health modules to trytond directory and it
> didn't work could somebody help me please

A little more information about your system and setup could be helpful.

The probably easiest way to install is:
https://en.wikibooks.org/wiki/GNU_Health/Operating_System-Specific_Notes#Installing_GNU_Health_on_openSUSE

HTH
Axel