Es rarísimo la verdad... es un caso para estudiarlo mejor de todas formas.
Como solución temporal, podes hacer el dump remoto y traerte la salida: ssh USUARIO_REMOTO@SERVIDOR 'pg_dumpall -U prueba -s' > /tmp/DBdatos.sql 2016-09-20 11:58 GMT-03:00 Kernel <jucab...@gmail.com>: > El 20/09/2016 a las 14:17, Abel Osorio escribió: > >> Hola! Es raro que la conexión (psql dbdatos...) te funcione y el pg_dump >> no. >> >> ¿Qué tamaño tiene el archivo exportado? (en la máquina principal ls >> -lsh /tmp/DBs.sql) >> En el log de PostgreSQL te debe estar tirando lo que está pasando ahí, >> podrías compartirlo? Podrías mostrarlo en una consola con "tail -f" >> mientras probás la conexión. >> >> Una última cosa, y acá puedo estar diciendo cualquier cosa... ya me >> corregirán. En -f ARCHIVO, ARCHIVO es local o remoto? Probaría, sólo por >> las dudas, cambiar el -f por >, es decir: >> >> pg_dump dbdatos -h 192.168.1.1 -U prueba -s _-f_ /tmp/DBdatos.sql >> pg_dump dbdatos -h 192.168.1.1 -U prueba -s _>_ /tmp/DBdatos.sql >> >> Con eso te aseguras que el archivo se va a crear localmente. >> >> >> Saludos! >> Abel >> >> 2016-09-20 8:37 GMT-03:00 Kernel <jucab...@gmail.com >> <mailto:jucab...@gmail.com>>: >> >> El 20/09/2016 a las 11:36, Francisco Olarte escribió: >> >> Solo una nota: >> >> 2016-09-20 9:52 GMT+02:00 Kernel <jucab...@gmail.com >> <mailto:jucab...@gmail.com>>: >> >> >> Tu copia editada no muestra el usuario del sistema con el que >> estas >> ejecutando y.... >> >> He probado a crear el fichero /home/prueba/.pgpass , con >> permisos 600, pero >> nada >> 192.168.1.1:5432:dbdatos:prueba:prueba >> >> >> , el .pgpass tiene que estar en $HOME/.pgpass ( lo digo porque >> mas de >> uno confunde db-user con os-user , y no tenemos forma de saber >> por lo >> que mandas si ese es tu caso ). >> >> ¿ Has comprobado que las conexiones llegan desde la IP que esperas >> (con algun netstat, ip route y/o tcpdump ) ? ( y no se si ademas >> necesitas que resuelvan en inverso, eso lo deberias mirar >> tambien ) Y >> otra cosa, ¿ es lo que has puesto el pg_hba completo ? ( piorque >> parece que el post esta editado ). >> >> Francisco Olarte. >> >> >> el usuario es prueba, tanto en el sistema como en la base de datos. >> >> La red va bien, esto funciona bien >> >> psql dbdatos -h 192.168.1.1 -U prueba (ok sin problemas no pide >> password ) >> >> debe de ser algo de permisos >> >> >> - >> Enviado a la lista de correo pgsql-es-ayuda >> (pgsql-es-ayuda@postgresql.org <mailto:pgsql-es-ayuda@postgresql.org >> >) >> Para cambiar tu suscripción: >> http://www.postgresql.org/mailpref/pgsql-es-ayuda >> <http://www.postgresql.org/mailpref/pgsql-es-ayuda> >> >> >> > cuando ejecuto pg_dumpall -h 192.168.1.1 -U prueba -s > > Salida : > > > > -------------------------------------------------------------- > -- PostgreSQL database cluster dump > -- > > SET default_transaction_read_only = off; > > SET client_encoding = 'UTF8'; > SET standard_conforming_strings = on; > > -- > -- Roles > -- > > CREATE ROLE pruebas; > ... > .... > ... > -- > -- Database creation > -- > > CREATE DATABASE dbdatos WITH TEMPLATE = template0 OWNER = postgres; > > REVOKE ALL ON DATABASE template1 FROM PUBLIC; > REVOKE ALL ON DATABASE template1 FROM postgres; > GRANT ALL ON DATABASE template1 TO postgres; > GRANT CONNECT ON DATABASE template1 TO PUBLIC; > > > \connect dbdatos > > SET default_transaction_read_only = off; > > > Aqui se queda, si conecta, el mismo usuario si que saca todo desde local. > > El log de la maquina principal, cuando pulso control-C para detenerlo > > pg_dumpall 2016-09-20 16:57:41 CEST postgres postgres LOG: no se pudo > recibir datos del cliente: Conexión reinicializada por la máquina remota > > > > Nota : el servidor tiene SSL > > > > > > > > > > > > > > > > > > > > > > > > > > > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda >
