It would be great if freeciv would remember where it connected last. This is very disturbing if you have your server running somewhere else, Game" it always wants to connect to localhost. When starting up the civclient-gtk and pressing "C&onnecting to Network Please contact ĭate: Sun, 19:59:58 +0100 Package: freeciv-client-gtk Message is talking about, this may indicate a serious mail system (NB: If you are a system administrator and have no idea what this If this is not the case it is now your responsibility to reopen theīug report if necessary, and/or fix the problem forthwith.
This means that you claim that the problem has been dealt with. Regarding freeciv-client-gtk: Does always want to connect to localhost Has caused the Debian Bug report #410558, Subject: Bug#410558: marked as done (freeciv-client-gtk: Does always wantĬontent-Type: multipart/mixed boundary="-=_1532935270-31010-0" But I, too, have been in places where nmap is both faster and more reliable.X-Mailer: MIME-tools 5.508 (Entity 5.508) Your DB admin should tell you what port to use if they don't, your boss should make them do so. (Of course, at its root this isn't a technical problem but a social one. So if I were you, I'd start by doing pgsql -p 5555 and if that doesn't work, do nmap -sV to find out which of the other ports it is. In this particular case, I'd lay a bet that it's port 5555 that is being used - because it's unlikely that a database server to be running freeciv, and it's common for humans to use a portnumer like 5555, 3333, 6666 etc. That will of course take a bit longer than running it with sT, and may trigger intrusion detection alarms if any are in place. If you run nmap with the option -sV, it will actually talk to the port and try different protocol to see which one matches. But it's quite possible to use another port for any service, as you've noticed. Nmap uses a file called nmap-services that lists the common application for each port (if the port is registered with IANA, it will usually be whatever application was registered for that port). pg_lsclusters seems not to be installedįirst, it's not at all certain that it's freeciv that's listening on 5555.lsof does not work (I have no idea whats going wrong on the server.I did see Determining PostgreSQL's port and tried everything from there:
I don't have root permissions on this machine, but I can login with SSH on server A. What can I do to figure out on which port postgreSql is listening (or if it is listening at all)? How can I make it listen to a port (or change the port)? Is it some setting in /path/pgsql/data? (I cannot access this at the moment, but I can ask.) Does this mean that PostgreSQL is not listening to any port? How can I make it listen? Within PostgreSQL I typed SHOW port, but it returned nothing. Not shown: 4868 closed ports, 130 filtered portsĬould port 5025 be PostgreSQL? Other tries $ ps aux | grep postgres | grep -v 'postgres:' When I make the port range higher, I get different results: $ nmap -p 1000-6000 -sT servera.my.url.de Nmap scan report for servera.my.url.de (141.X.YZ.AB) Portscan $ nmap -p 5000-6000 -sT servera.my.url.de Is the server running on host "servera.my.url.de" (141.X.YZ.AB) and acceptingĪnd psql -h servera.my.url.de -p 5932 -U myusername -W -c "select 1" Psql: could not connect to server: Connection refused Is my Python script the problem? psql -h servera.my.url.de -p 5930 -c "select 1"
servera.my.url.de ping statistics -ģ packets transmitted, 3 received, 0% packet loss, time 2001ms Is the server there? ping servera.my.url.de Is the server running on host "servera.my.url.de" (141.X.YZ.AB) andĪccepting TCP/IP connections on port 5432? I've tried adding host=servera.my.url.de but that gave me could not connect to server: Connection refused So my Python script needs to access the PostgreSQL-database from server B connecting to server A. The PostgreSQL database will remain at server A. It currently works fine, but I have to move the script to another server B. I currently have a Python script that needs to fetch some data from a PostgreSQL database.
0 kommentar(er)
