phpmyadmin não se conectará a uma instância remota do MySQL

3

Eu tenho uma caixa de pilha LAMP (CentOS 6) e outra caixa do CentOS 6 executando o servidor mysql.

Instalei o phpmyadmin na caixa LAMP, mas não consigo falar com minha caixa SQL.

Eu configurei o seguinte em config.inc.php

/* Servers configuration */
$i = 0;

/* Server: usp-ggdb2 [1] */
$i++;
$cfg['Servers'][$i]['verbose'] = 'usp-ggdb2';
$cfg['Servers'][$i]['host'] = '10.1.2.3';
$cfg['Servers'][$i]['port'] = '';
$cfg['Servers'][$i]['socket'] = '';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['user'] = '';
$cfg['Servers'][$i]['password'] = '';

Quando eu navego para o site phpmyadmin, recebo o seguinte erro:

#2002 - Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) The server is not responding (or the local server's socket is not correctly configured).

Eu não sei por que está falando sobre tentar se conectar a um servidor local já que configurei apenas o servidor (e é remoto).

Se eu tcpdump eu posso ver que não faz nenhuma tentativa de estabelecer uma conexão com o IP especificado.

É como se meu arquivo de configuração estivesse sendo ignorado.

Existe uma maneira de ativar mais algumas informações de depuração? Todas e quaisquer sugestões são bem-vindas!

    
por wimnat 02.05.2014 / 02:41

3 respostas

3

Eu resolvi o problema. De fato, meu arquivo de configuração estava sendo ignorado. Eu estava copiando config.inc.sample.php para config.inc.php no diretório de nível superior do site (/ var / www / html / pma).

No entanto, no CentOS 6 existe um diretório de configuração separado - / etc / phpMyAdmin /. Depois que eu copiei minha configuração lá, tudo funciona bem.

    
por 05.05.2014 / 02:08
1

Uma das configurações padrão encontradas no RHEL 6 e no CentOS 6 é o padrão do SELinux para aplicar o modo. Você pode verificar isso com o comando getenforce .

Se no modo Enforcing , a maneira mais rápida de verificar se o SELinux é o culpado geralmente é desabilitar temporariamente o SELinux com setenforce 0 . Se com o SELinux desativado, tudo funciona como esperado, está confirmado.

Retorne o SELinux para o modo de imposição com setenforce 1 e defina a política que rege o acesso ao banco de dados baseado em rede para aplicativos da Web para permitidos:

   setsebool -P httpd_can_network_connect_db 1

Se o banco de dados MySQL estiver ouvindo uma porta não padrão que pode ser insuficiente e você pode tentar permitir a política de rede genérica:

  sesebool -P httpd_can_network_connect 1 
    
por 02.05.2014 / 11:06
1

Eu encontrei outro motivo pelo qual você pode receber esse erro. Você precisa atender as seguintes condições

  1. Use o driver nativo do MySQL para PHP (recomendado)
  2. Use o MySQL 5.6 ou posterior
  3. Use um certificado SSL autoassinado para comunicação do MySQL

Como descrito em este bug do PHP , o MySQLND irá obedecer às preferências do MySQL e tentar validar o Certificado SSL. Como não pode (ser auto-assinado) a conexão simplesmente falha com um erro de 2002 (bom e vago!)

Como observado no bug, o PHP 5.6.16 (também presente no 7.0+) adicionou outra opção de conexão ao mysqli_real_connect chamado MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT , que desabilita a validação dos certificados SSL no lado do MySQLND. Para versões anteriores ao PMA 4.6.0 você terá que editar libraries/dbi/DBIMysqli.php e editar a linha com

$client_flags |= MYSQLI_CLIENT_SSL;

E substitua por (SOMENTE PARA PHP 5.6.16 ou posterior)

$client_flags |= MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT;

Para o PMA 4.6.0 ou posterior, você pode simplesmente definir na configuração

$cfg['Servers'][$i]['ssl_verify'] = false;
    
por 18.02.2016 / 22:11