update: Problem solved, solution posted below
I am new to the process of making remote database connections, but it seems that there tends not to be an obvious solution for this error.
pymysql.err.InternalError: Packet sequence number wrong - got 80 expected 0 arises when attempting to make the following pymysql connection
I'm running MacOS 10.12.5, Python 2.7.10 in PyCharm (also tried with Terminal), and PyMySQL 0.7.11 (also tried 0.7.9)
update: also tried on Windows 10, Python 2.7.13 with the same result
The database is hosted on cPanel. Perhaps there are additional settings to change before I can connect. The connecting user has full privileges. My IP was added to the host "access" list.
other notes: As might be expected, if the port number or host IP is randomly changed, it immediately refuses the connection. Otherwise, it takes about 30 seconds before the 'packet sequence' error to arise.
import pymysql.cursors
import pymysql
connection = pymysql.connect(host = hostIPaddress,
port = 2083,
user = username,
passwd = password,
db = dbName,
charset = 'utf8mb4', # also tried 'utf8'
cursorclass=pymysql.cursors.DictCursor)
While the port 2083 is used by the host, each database uses the default port 3306 in this case.
When tested with 3306, access was denied until I added the denied IP to the host "access" list in Remote MySQL on cPanel.
Related
After installing postgres and pgAdmin 4 on Ubuntu 22.04 I want to setup a server listening on localhost.
The pg service is running
but when trying to create a new server I get the following error
I think the terminal error points to the same problem
I think the server is running locally but what am I missing / how can I accept the missing socket connections?
Could you check if the listen_addresses in the postgresql.conf accepts connections from localhost or set it to '*', if no special restriction required
I have my stun / turn server running on local pc (CoTurn). It is tested on "https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/" and works. I have a domain name and configured the modem with public ip. I configured apache2 to make the site visible to the world. I have active and valid letsencript certificates. Everything works in short. But the test application starts the connection (the external pc communicates with the local via socket.io) but then the video is not seen and the console returns the error: ICE failed, your TURN server appears to be broken, see about:webrtc for more details.
The link of the application that I use as a test, because with my original I had no comparisons to make. First time with socket.io. But socket.io send and receive messages so these not appear a problem for now.
https://github.com/anoek/webrtc-group-chat-example
P.S.:
Ok. Server is behind the nat. My app (but linked app too) work very fine on local network (sorry I checked this point first before). These with my turn/stun server, than with public stun/turns google servers. This evidently indicates a bad setting of apache2 server or/and turn server. Where could I find a guide about it?
My server situation: myServerIpLocal-xxx.xxx.xxx.xxx -> nat/router/modem WithPublicIpStatic-xx.xx.xx.xx. I can see my sites from all the world, but turn server not work outside the local network. Inside local network work ok.
these my turn config:
listening-port=3478
tls-listening-port=5349
alt-listening-port=3479
alt-tls-listening-port=5350
listening-ip=xxx.xxx.xxx.xxx /*mylocal ip*/
relay-ip=xxx.xxx.xxx.xxx /*mylocal ip*/
external-ip=xx.xx.xx.xx /*my public ip on nat/ruter/modem */
min-port=49152
max-port=65535
verbose
fingerprint
userdb=/var/lib/turn/turndb
realm=mysite.com
cert=/etc/ssl/certificate.pem
pkey=/etc/ssl/private.key
dh-file=/etc/turn/dhparam.pem
no-stdout-log
log-file=/myhome/.turn/turn.log
lt-cred-mech
user=myusername:mypasswd
# Turn OFF the CLI support.
# By default it is always ON.
# See also options cli-ip and cli-port.
#
no-cli
#Local system IP address to be used for CLI server endpoint. Default value
# is 127.0.0.1.
#
cli-ip=127.0.1.1
# CLI server port. Default is 5766.
#
cli-port=5766
# CLI access password. Default is empty (no password).
#
cli-password=logen
no-sslv3
no-tlsv1
my old code on turn.conf:
lt-cred-mech
user=myusername:mypasswd
but turn work only locally .... probabily because I use:
sudo turnserver -L myPublicIp -o -a myrealm
at every coturn start command ....
actually I try not use the command "turnserver" and I try to use onlu sudo coturn start .....
basically in my turn.conf file I change these:
lt-cred-mech
user=mypasswd:myusername /***** mind the gap ;) *****/
these because my index.js file debug never see my external connection as authrized user ..... magically at these time my app perform webrtc multiple connection with every pc and mobile .... inside and outside my lan .... (I try connect my appa from phone in barcelona spain to other one in london with good result).
May be coturn wiki need to update?
Finally I would like to thank the serverfault and super-user guys who rejected my question. Since I had to make arrangements, I was able to acquire new and interesting information on this subject.
regards
I just restarted my google cloud compute engine instance and now I cannot SSH login to it. Before restarting, it worked fine. I tried fully stopping it and then starting again. There was a webserver on it and if I try to access any API method, I get timeout.
If I try to login from console website:
If I try to login from terminal:
ssh: connect to host 104.197.20.65 port 22: Operation timed out
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255]. See https://cloud.google.com/compute/docs/troubleshooting#ssherrors for troubleshooting hints.
What is wrong?
As the error message suggest the first thing to do is check the firewall rules. There must be a rule allowing connections from any ip (0.0.0.0/0) through the port 22. I assume that your instance's ssh was working before, so it can be two things.
The rule is being applied to a certain network, and the network configuration of the VM was changed when it was shutted down.
The rule is not being applied to the VM, maybe it is in a subnetwork, closing the communication.
To simplify the solution:
A- Add a network tag to your VM. (Ex. ssh-conn)
https://cloud.google.com/compute/docs/vpc/add-remove-network-tags
B- Create a rule to allow connections from any ip and apply it to the network tag previously created.
https://cloud.google.com/compute/docs/vpc/using-firewalls
I had the same problem, and tried lots of way but none of them work.
But the way below is work for me:
Connect to instance by serial console.
vi /etc/ssh/sshd_config, delete the hash tag before Port 22, like this:
Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
Hope it work for you too.
When I try to connect to the remote PostgreSQL database with a Rails 3.2 project I get this error:
FATAL: no pg_hba.conf entry for host "10.0.0.3", user "projectx", database "projectx", SSL off
My configuration on Rails looks like this:
staging:
adapter: postgresql
database: projectx
username: projectx
password: 123456
host: 10.0.0.3
encoding: utf8
template: template0
min_messages: warning
and on PostgreSQL looks like this:
hostssl all all 0.0.0.0/0 md5
hostssl all all ::/0 md5
Both machines are running on an Ubuntu 12.04.
I found posts saying that it should work automatically, which clearly doesn't happen. I found some saying that libpq didn't have SSL enabled and enabling it solved the problem, but no explanation on how to enable it. I can see when I look at the dependencies of libpq that it depends on the some SSL packages, so I would assume SSL support is compiled.
Some posts recommended adding this:
sslmode: require
or this:
sslmode: enabled
to enable ssl mode, but it had no effect for me. I read that it's silently ignored.
I also tried the database string approach, ending up with:
staging:
adapter: postgresql
database: "host=10.0.0.3 dbname=projectx user=projectx password=123456 sslmode=require"
and then I got the error:
could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
which seems to indicate that Rails was trying to connect to localhost or rather, the local PostgreSQL (there's none) instead of 10.0.0.3.
Any ideas?
As you wrote, normally the Ubuntu 12.x packages are set up so that SSL is activated, works out of the box, and in addition is the first method tried by rails, or any client that lets libpq deal with this stuff, which means almost all clients.
This automatic enabling is not necessarily true with other PostgreSQL packages or with a self-compiled server, so the answers or advice applying to these other contexts don't help with yours.
As your setup should work directly, this answer is a list of things to check to find out what goes wrong. Preferably, use psql first to test a connection setup rather than rails, so that generic postgresql issues can be ruled out first.
Client-side
The client-side sslmode parameter controls the sequence of connect attempts.
To voluntarily avoid SSL, a client would need to put sslmode=disable somewhere in the connection string, or PGSSLMODE=disable in the environment, or mess up with one of the other PGSSL* variables. In the unlikely case your rails process had this in its environment, that would explain the error you're getting, given that pg_hba.conf does not allow non-SSL connections.
Another reason to not try SSL is obviously when libpq is not compiled with SSL support but that's not the case with the Ubuntu packages.
The default for sslmode is prefer, described as:
prefer (default)
first try an SSL connection; if that fails, try a non-SSL connection
The SSL=off at the end of your error message relates to the last connect attempt that fails. It may be that SSL was tried and failed, or not tried at all, we can't know from this message alone. The connect attempt with SSL=off is rejected normally by the server per the policy set in pg_hba.conf (hostssl in the first column).
It's more plausible that the problem is server-side, because there are more things than can go wrong.
Server-side
Here are various things to check server-side:
There should be ssl=on in postgresql.conf (default location: /etc/postgresql/9.1/main/)
when connecting to localhost with psql, you should be greeted with a message like this:
psql (9.1.13)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
The ca-certificates package should be installed and up-to-date.
The ssl-cert package should be installed and up-to-date.
Inside the postgres data directory (/var/lib/postgresql/9.1/main by default), there should be soft links:
server.crt -> /etc/ssl/certs/ssl-cert-snakeoil.pem or another valid certificate, and
server.key -> /etc/ssl/private/ssl-cert-snakeoil.key or another valid key.
/etc/ssl/certs and parent directories should be readable and cd'able by postgres.
The postgres unix user should be in the ssl-cert unix group (check with id -a postgres) otherwise it can't read the private key.
If changing postgresql.conf, be sure that postgresql gets restarted before doing any other test.
There shouldn't be any suspicious message about SSL in /var/log/postgresql/postgresql-9.1-main.log at startup time or at the time of the failed connection attempt.
Rails uses the PG gem for postgres to connect see here for the implementation:
https://github.com/rails/rails/blob/02a3c0e771b3e09173412f93d8699d4825a366d6/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb#L881
The PG gem uses libpg (c library) and the documentation on "PG::Connection.new" found here:
http://deveiate.org/code/pg/PGconn.html
Suggests the following options:
host
server hostname
hostaddr
server address (avoids hostname lookup, overrides host)
port
server port number
dbname
connecting database name
user
login user name
password
login password
connect_timeout
maximum time to wait for connection to succeed
options
backend options
tty
(ignored in newer versions of PostgreSQL)
sslmode
(disable|allow|prefer|require)
krbsrvname
kerberos service name
gsslib
GSS library to use for GSSAPI authentication
service
service name to use for additional parameters
So this would indicate that the connection string will not work (since it is not recognised by the adapter, this might be a mysql adapter option)
Also this indicates that the sslmode=required option should work, as this is a basic feature of libpg.
So:
database.yml
staging:
...
sslmode: "require"
...
should definitely do the trick, are you sure you use staging mode? // add sslmode to the other environments too to be sure.
Also libpg uses SSL by default as first try, maybe you see the error with SSL Off because SSL mode failed first, then libpq retried without ssl and eventually raised an error.
Please check your psql version,
older version do not support slmode=require.
It worked for me after upgrading psql to the latest version.
Does anyone know why I am unable to connect to my server using the Notepad++ NppFTP plugin with SFTP?
I have a CentOS 6.4 server with SSH on port 22.
When I try and connect using NppFTP I get the following output:
[NppFTP] Everything initialized
Connecting
[SFTP] Connection failed : Error reading socket
Unable to connect
Disconnected
This used to work when I had my SSH port set to 3264 but when I changed the SSH port back to 22 NppFTP stopped working. All the settings for the profile are correct including the right IP, username, password and port (22).
I can connect with SFTP using FileZilla and WinSCP successfully with these same SFTP details and I can connect with SSH using PuTTY.
I can connect with SFTP to other servers using NppFTP so I believe there is an issue in my server config I'm just not sure where or what.
I looked at the access logs but found no attempt at a connection from NppFTP, I turned the firewall off and still nothing.
In the end I got in touch with my server company and it turns out it was a problem on their end. This is what they had to say:
"This was caused by an IPS rule inspecting the network packets coming into the infrastructure, which helps identify brute force attacks."
Very strange, but after they made the change NppFTP can now connect successfully.