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