MariaDB recusa conexões remotas

4

Eu passei por muitos tutoriais e perguntas e ainda não consigo trabalhar.

Já estive em:

Eu instalei o MariaDB no Ubuntu 16.04. Em seguida, configure dois usuários, um dos quais é destinado ao uso público, para que eu possa postá-lo aqui.

Os usuários são adicionados como:

CREATE USER 'anon'@'%' IDENTIFIED BY '';

As conexões locais funcionam?

Sim, posso me conectar como usuários via ssh no servidor:

mysql -u anon

Você verificou se os usuários foram adicionados corretamente?

Eu acho que sim:

MariaDB [(none)]> SELECT User, Host FROM mysql.user WHERE Host <> 'localhost';
+------+------+
| User | Host |
+------+------+
| anon | %    |
| user | %    |
+------+------+
2 rows in set (0.01 sec)

Desbloqueou o firewall?

Pode ser necessário desbloquear o firewall:

[user]@popfreq:/etc/mysql$ firewall-cmd --add-port=3306/tcp 
The program 'firewall-cmd' is currently not installed. You can install it by typing:
sudo apt install firewalld

O firewall não está instalado.

Você verificou o arquivo my.cnf para as configurações corretas?

As configurações incorretas em my.cnf ( [user]@popfreq:/etc/mysql ) podem causar a recusa de conexões. Estes são skip-networking e bind-address . Meu arquivo é assim:

# The MariaDB configuration file
#
# The MariaDB/MySQL tools read configuration files in the following order:
# 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,
# 2. "/etc/mysql/conf.d/*.cnf" to set global options.
# 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.
# 4. "~/.my.cnf" to set user-specific options.
#
# If the same option is defined multiple times, the last one will apply.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.

#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]

# Import all .cnf files from configuration directory
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

Ele não possui as linhas ofensivas.

Você verificou os outros arquivos de configuração?

Sim. Eles também não tinham as linhas ofensivas.

O telnet funciona?

Não.

mint@mint-VirtualBox ~ $ telnet 128.199.203.208 3306
Trying 128.199.203.208...
telnet: Unable to connect to remote host: Connection refused

Não tenho certeza do que isso significa ou como corrigir.

Qual interface o servidor está usando?

Local apenas parece:

[user]@popfreq:/etc/mysql/mariadb.conf.d$ sudo netstat -ntlup | grep mysql
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      16884/mysqld    

Você se lembrou de reiniciar? Sim. Eu reiniciei usando isso entre todas as tentativas:

sudo service mysql restart
    
por Deleet 14.10.2016 / 06:37

2 respostas

5

A solução para o erro no meu caso foi que não havia nenhuma seção [mysqld] nos arquivos my.cnf config. Adicionar isso resolveu o problema:

[mysqld]
bind-address = ::

Não sei porque não foi adicionado por padrão. Observe que o motivo para usar :: over 0.0.0.0 é que :: também funciona para o IPv6 ( mencionado no manual do mySQL , mas não no manual do mariaDB).

Isso também corrigiu o telnet:

mint@mint-VirtualBox ~ $ telnet 128.199.203.208 3306
Trying 128.199.203.208...
Connected to 128.199.203.208.

E a saída da rede é agora:

[user]@popfreq:/etc/mysql$ sudo netstat -ntlup | grep mysql
tcp6       0      0 :::3306                 :::*                    LISTEN      17609/mysqld   

Espero que isso ajude alguém.

    
por 14.10.2016 / 06:37
0

Depois de ter o mesmo problema (no Debian Stretch) e já tentei todas as soluções mencionadas aqui sem sucesso, eu finalmente encontrei isto de onde eu acabei de postar a parte importante:

Edite /etc/mysql/mariadb.conf.d/50-server.cnf, comente o endereço de ligação e adicione a instrução de modo sql:

[...]
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address           = 127.0.0.1

sql-mode="NO_ENGINE_SUBSTITUTION"

[...]

e - funcionou.

    
por 28.03.2018 / 19:02

Tags