2014-05-21 17:11 GMT+02:00 Mathias Behrle <[email protected]>: > * Dale Scott: " Re: [tryton] no connection to trytond running in VirtualBox > NAT" (Wed, 21 May 2014 06:50:40 -0700 (PDT)): > > [...] > > > edited /usr/local/pgsql/data/pg_hba.conf to allow remote access from any > > system on my LAN, > > > > host all all 192.168.10.0/24 md5 > > Since you configured md5, you need to give the tryton role in postgres a > password. > > Put this password into your trytond.conf as the user password for the db > user.
What Mathis says is correct BUT the connection from trytond to postgres is LOCAL (they are in the same machine). If you didn't change the db_host parameter in trytond.conf (is is still commented or 'False') the connection is done throw SOCKET (not IP) so the lines in pg_hba.conf that affects you are what start by 'local'. Anyway, it seems you could create the database so the connection to postgres IS NOT THE PROBLEM. > > And finally I started the Tryton client on a Win7 laptop (I > double-checked > > the client version - it's tryton-3.2.0). I entered the Profile Editor > (btw, > > the client was able to connect to demo32.tryton.org) and added my > server IP > > (192.168.10.125, port 8000) > > If you are using IPv4 addresses, better to also let trytond listen on IPv4 > interface like > > jsonrpc = *:8000,0.0.0.0:8000 > it is what you have take care. If you will use IPv4 connections/IPs, I think is better set only ' 0.0.0.0:8000' to avoid conflicts > > set but it still reports "Could not connect to > > server" (the username in the client is set to "tryton" but I don't > believe > > that's important at this step, is that correct?). > > It is important: The first user created is admin and it is this one, with > which > you connect the first time (providing the password used while creating the > database). It is important because it seems you created the database automatically with the 'trytond -i all' call. I've never done it so I'm not sure which user/password sets but provably it is 'admin/admin'. Before all, check that database is in postgres and check its name (I think it will be 'tryton' but I'm not sure): $ psql -l If it exists, you have to ensure the port is open and accessible from Windows machine. 1. port is open? In server execute: $ netstat -putan | grep 8000 Output shoud be something similar to: (No todos los procesos pueden ser identificados, no hay información de propiedad del proceso no se mostrarán, necesita ser superusuario para verlos todos.) tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 5022/python It says server is listening throw all IPv4 interfaces by port 8000 ( 0.0.0.0:8000) FROM all (0.0.0.0:*) 2. you can access to port 8000 of server from other machine (I put the command to check it from a Linux machine, if you have other linux machine different to server for these test it's OK, it doesn't depends on client SO) $ nmap 192.168.2.230 <-- server IP. put the correct one Output: Starting Nmap 6.40 ( http://nmap.org ) at 2014-05-22 09:11 CEST Nmap scan report for 192.168.2.230 Host is up (0.00036s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 8000/tcp open http-alt ... Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds Maybe nmap is not installed by default, and in some SO it requires to be root to execute. There are other tools to do this check but what I know is that. It shows that port 8000 is accessible from this machine. 3. The last check (or an alternative that you can do from Windows machine) is to try a telnet connection: $ telnet 192.168.2.230 8000 Output: Trying 192.168.2.230... Connected to 192.168.2.230. Escape character is '^]'. Now you can write something (for example "fa") and press "Enter": Output (in telnet): <head> <title>Error response</title> </head> <body> <h1>Error response</h1> <p>Error code 400. <p>Message: Bad request syntax ('fa'). <p>Error code explanation: 400 = Bad request syntax or unsupported method. </body> Connection closed by foreign host. Output in server log: <client ip> - - [<timestamp>] code 400, message Bad request syntax ('fa') If all of these works, the connection is available and the problem is in the used credentials in login windows (db name, user and/or password). > There were no new > > messages in the ssh terminal session in which I invoked trytond, and no > > messages in the log file (which I had configured in trytond.conf). > > > > Is there any way to debug whether the connection request from the client > is > > being received by the server at all? I don't understand the stack (i.e. > > psycopg2 et all). Is there any way to check if the connection is getting > > through the individual components of the stack? I've been reading a lot > of > > posts, and while I haven't found anything specific, did read references > to > > whether or not the database hostname, etc. is required in trytond.conf, > and > > that psycopg2 will use unix sockets by default, and wonder if this might > be > > related at all. > > You can try to connect to the postgres database from your windows machine > (e.g. with pgadmin3). NO. It doesn't test anything because of the explanations above. The test you can do to check if DB connection is OK are (for the record because I think you haven't to do that because you could initialize the DB): - with the same UNIX user that executes trytond, try to connect to postgres with "psql" using the credentials set in db_* parameters: a) if these parameters are commented: $ createdb <DBNAME> <-- trytond can create DB $ psql <DBNAME> b) if there are db_user and db_password set $ createdb -U <db_user> -W <DBNAME> $ psql -U <db_user> -W <DBNAME> Good luck! -- Guillem Barba http://www.guillem.alcarrer.net
