Mysql não aceita senha de root no Mac os X Lion, o que fazer? (serve para o snow leopard)

Standard

Bom, pessoal, nós do app gostaríamos de detalhar algo.
NÃO precisa ter senha de root para operar o mysql, isto dá-se em detrimento ao poder de root, porém com certas restrições que cada usuário do sistema possui.

Se eu quiser entrar no mysql para criar base de dados e trabalhar com o bd (após seguir nosso how to de instalação do apache, php, e mysql no mac os x lion ou instalação do apache, php, e mysql no mac os x snow leopard

mysql

mysql

) basta fazer o seguinte:

Mac-Pro-de-little-oak:etc little_oak$ sudo /usr/local/mysql/bin/mysql –user=little_oak

Pronto, você precisa lembrar que –user=little_oak deve ser susbsituído por –user=usuário_do_SEUMAC

Depois disso trabalhe normalmente.

Perceba uma coisa forte, o MAC OS X não precisa de root para fazer as coisas (dentro do mysql), ele já sabe que você, usando sudo É O CARA, por isso basta rodar este comando no terminal:

Little-oaks-appunixlabs: /usr/local/mysql/bin/mysql –user=little_oak

Troque o little_oak por seu usuário. Depois disso é só alegria.

Abraços galera e clique em SHARE, please!

Replicação de dados no Mysql sob SSL no Debian Squeeze

Standard

Esse how to tem 2 pontos chave:

1 – inibir o man in the middle

2 – replicar dados entre bases de dados para que, em uma eventual falha de hardware possamos estar beeeeem providos :).

 

Considerações iniciais:

master.appunixlabs.com.br -> 10.0.0.1

slave.appunixlabs.com.br -> 10.0.0.2

 

Nos 2 servers, como root devemos rodar o seguinte comando:

apt-get install mysql-server mysql-client -y

Assim que rodarmos o comando acima será solicitada confirmação de senha do root do banco de dados:

New password for the MySQL “root” user: <—– Devemos colocar a senha de root
Repeat password for the MySQL “root” user: <– Devemos repetir a senha de root

 

O que iremos fazer agora é verificar os recursos de ssl do server mysql, veja que devemos logar antes como root do banco de dados mysql:

mysql -u root -p

No mysql console devemos exibir as variáveis de SSL:

mysql> show variables like ‘%ssl%’;
Saída que mais interessa -> have_openssl e have_ssl:

+—————+———-+
| Variable_name | Value    |
+—————+———-+
| have_openssl  | DISABLED |
| have_ssl      | DISABLED |
| ssl_ca        |          |
| ssl_capath    |          |
| ssl_cert      |          |
| ssl_cipher    |          |
| ssl_key       |          |
+—————+———-+
7 rows in set (0.00 sec)

mysql>

Vamos sair do mysql:

quit;

 

Precisamos editar os confs do mysql para dar suporte ao SSL:

vim /etc/mysql/my.cnf

Na sessão * Security Features devemos acrescentar SSL, pode ser usado da seguinte forma:

 

# * Security Features
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
ssl
# ssl-ca=/etc/mysql/cacert.pem

Devemos validar nossa alteração, para isto vamos reiniciar o mysql com o seguinte comando:


/etc/init.d/mysql restart

Para confirmarmos o suporte o SSL em ambos os servers (presumindo que você está seguindo até aqui o passo-a-passo nos 2 servidores) devemos logar no mysql como root e verificar as variáveis de ssl:

mysql -u root -p

Logando-se como root devemos usar:

mysql> show variables like ‘%ssl%’;

A saída deste comando deve assemelhar-se com:

+—————+——-+
| Variable_name | Value |
+—————+——-+
| have_openssl  | YES   |
| have_ssl      | YES   |
| ssl_ca        |       |
| ssl_capath    |       |
| ssl_cert      |       |
| ssl_cipher    |       |
| ssl_key       |       |
+—————+——-+
7 rows in set (0.00 sec)

mysql>

Pule fora do mysql:

mysql> quit;

No servidor MASTER devemos colocar o suporte a acesso remoto ao mysql, do contrário não teremos a replicação de dados em tempo real em hipótese alguma :P, para isto devemos fazer o seguinte, no conf do mysql temos de editar a parte de bind-address:

vim /etc/mysql/my.cnf

# 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

somente comentando bind-address estamos evitando que o acesso remoto só ocorra por lookup.

Ainda no server master temos de validar nossa alteração:

/etc/init.d/mysql restart

Vamos ver os sockets abertos do mysql na porta com suporte a SSL:

netstat -tap | grep mysql

A saída deve assemelhar-se com:

tcp        0      0 *:mysql                 *:*                     LISTEN      2792/mysqld

Devemos criar agora os certificados para dar suporte a camada segura, tanto no main server como no slave, para isso iremos rodar o seguinte comando:

mkdir /etc/mysql/newcerts && cd /etc/mysql/newcerts

Em paralelo iremos instalar também o openssl:

apt-get install openssl

Vamos criar os certificados agora com chave beeeeeeeem gorda para CA:

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem

Vamos criar os certificados do servidor master:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout master-key.pem > master-req.pem
openssl x509 -req -in master-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > master-cert.pem

Agora vamos criar o ceritificado do server slave:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout slave-key.pem > slave-req.pem
openssl x509 -req -in slave-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > slave-cert.pem

Agora que criamos os certificados no servidor Master, deveremos enviar os certificados para o servidor SLAVE, os quais lhe pertencem -> ca-cert.pem, slave-cert.pem e slave-key.pem.

No servidor Slave, como root criaremos a pasta dos certificados:

mkdir /etc/mysql/newcerts

Agora no Servidor Master devemos enviar os certificados para pasta de certificados do servidor Slave:

scp /etc/mysql/newcerts/ca-cert.pem root@10.0.0.2:/etc/mysql/newcerts

scp /etc/mysql/newcerts/slave-cert.pem root@10.0.0.2:/etc/mysql/newcerts

scp /etc/mysql/newcerts/slave-key.pem root@10.0.0.2:/etc/mysql/newcerts

 

No servidor MASTER temos de ativar o suporte aos certificados recém criados, para isto iremos editar novamente o conf do mysql na sessão de Segurança (aonde colocamos a linha SSL):

vim /etc/mysql/my.cnf

Seu conf deverá ficar parecido com este:

# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
ssl
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/master-cert.pem
ssl-key=/etc/mysql/newcerts/master-key.pem

Agora iremos reiniciar o mysql para validar os certificados:

/etc/init.d/mysql restart

Agora, ainda no Master Server temos de dar permissão de replicação ao server Slave dentro do Mysql:

mysql -u root -p

No console do mysql rode:

mysql>GRANT REPLICATION SLAVE ON *.* TO ‘LOGINdoSLAVEserver’@’%’ IDENTIFIED BY ‘Senha_Slave’ REQUIRE SSL;

Para forçar um usuário que você criou para conectar-se somente por SSL, neste caso LOGINdoSLAVEserver devemos fazer o seguinte:

mysql>GRANT USAGE ON *.* TO ‘LOGINdoSLAVEserver‘@’%’ REQUIRE SSL;

mysql> FLUSH PRIVILEGES;

mysql> quit;

Os dois comandos acima dizem: Atualize os privilégios (no caso logins e senhas, ou mudanças de permissões de banco de dados para usuários) e saia fora ;).

Agora precisamos setar a base de dados de logs e dizer quem é o master. Faremos isto assim:

vim /etc/mysql/my.cnf

# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db            = basedelogsdb

Chamamos nossa base de dados de logs que iremos compartilhar de basedelogsdb e para validar a mudança do servidor Master temos de reiniciar o mysql:

/etc/init.d/mysql restart

Teremos agora de fazer um dump da base de dados de logs para deixar o slave correndo no mesmo embalo do master, para isto faremos o seguinte:

mysql -u root -p

Depois de logar-se no Mysql:

mysql>USE exampledb;
mysql>FLUSH TABLES WITH READ LOCK;
mysql>SHOW MASTER STATUS;

O último comando deve exibir:

+——————+———-+————–+——————+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000001 |      106 | exampledb    |                  |
+——————+———-+————–+——————+
1 row in set (0.00 sec)

mysql>
Neste ponto não devemos dar quit, é muito importante isto, pois, no server Master ainda, iremos abrir outro terminal (se estiver direto no shell use CTRL + ALT + F2), abrindo uma nova shell logue-se como root e vamos continuar nosso how to. Como root rode os comandos:

cd /tmp

mysqldump -u root -p aSENHAdoMysql –opt basedelogsdb > cluster.sql

scp snapshot.sql root@10.0.0.2:/tmp

Nos passos acima entramos na pasta temporária, como root do banco de dados geramos um dump da base de dados de logs do main server e enviamos para o /tmp do servidor SLAVE.

Agora você pode sair da segunda tela, voltar para a primeira (CTRL + ALT+ F1, caso esteja 100% na shell) e rodar:

mysql> UNLOCK TABLES;

mysql> quit;

 

No servidor SLAVE iremos editar o conf do mysql na sessão [mysqld] e inserir as strings:

vim /etc/mysql/my.cnf

server-id=2
master-connect-retry=60
replicate-do-db=basedelogsdb

Este ID que estamos vendo JAMAIS poderá ser igual em servers que estão replicando dados.

Para validar nossas mudanças rode:

/etc/init.d/mysql restart

Agora iremos criar a base de dados de logs dentro do servidor SLAVE:

mysql -u root -p

mysql> CREATE DATABASE exampledb;
mysql> quit;

Ainda no servidor SLAVE iremos restaurar o dump chamado cluster.sql:

/usr/bin/mysqladmin –user=root –password=SenhaROOTmysql stop-slave
cd /tmp
mysql -u root -p SenhaROOTmysql basedelogsdb < cluster.sql

Agora iremos logar-nos como root no SLAVE server para poder ativar as variáveis de Show Master exibidas no main server, ou seja, o que foi exibido lá deverá ser ativado aqui, por isso tome muito cuidado:

mysql -u root -p

mysql> CHANGE MASTER TO MASTER_HOST=’10.0.0.1′, MASTER_USER=’LOGINdoSLAVEserver‘, MASTER_PASSWORD=’Senha_Slave‘, MASTER_LOG_FILE=’mysql-bin.000001’, MASTER_LOG_POS=106, MASTER_SSL=1, MASTER_SSL_CA = ‘/etc/mysql/newcerts/ca-cert.pem’, MASTER_SSL_CERT = ‘/etc/mysql/newcerts/slave-cert.pem’, MASTER_SSL_KEY = ‘/etc/mysql/newcerts/slave-key.pem’;

mysql> START SLAVE;

Para confirmarmos se tudo ficou filé:

mysql> SHOW SLAVE STATUS G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.1
Master_User: LOGINdoSLAVEserver
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 106
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 251
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: basedelogsdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 106
Relay_Log_Space: 407
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem
Master_SSL_CA_Path:
Master_SSL_Cert: /etc/mysql/newcerts/slave-cert.pem
Master_SSL_Cipher:
Master_SSL_Key: /etc/mysql/newcerts/slave-key.pem
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)

mysql>

 

Com isto todas as mudanças que ocorrerem em basedelogsdb no master server estarão replicadas no Slave Server.

 

Abraços a todos e bons estudos.
Equipe AppUnix.

Fontes:

Parallels Plesk Windows: Domínio não funciona o DNS, já tentei restore dns zone, já tentei renomear -> SOLUÇÃO AQUI!

Standard

Essa dica é bem quentinha e gostosa!

Sintomas:

Registro.br não mostra autoridade sobre o domínio ou dá falha de dns,
Já tentei restaurar a zona de dns do zero, já inseri manualmente a zona de dns do domínio, já renomeei o domínio do cliente e retornei ao original e até mesmo mudei o ip do domínio do cliente e voltei o que era antes e NADA!

Galera, nada de pânico! Mr little está lhe passando mastigadinho e gostoso, para sair dessa tranqueira entre no remote desktop de seu servidor Windows, cujo server opera o plesk 9.x (essa dica rola para o 8.x, mas aplico no 9.x):

Abra o MS-DOS, e dentro dele digite:

cd C:\Program Files\Parallels\Plesk\admin\bin

Nesta hora você estará nos binários de administração do plesk, mas antes copie o banco de dados PSA do plesk para uma área segura, ele está em:

C:\Program Files\Parallels\Plesk\admin\db\psa.mdb (psa.mdb é o nome do bandido!)

Rode o seguinte comando na pasta bin que chegamos via DOS:

dbclient.exe –direct-sql –sql=”select * from dns_zone where name like ‘domíniolascado.com.br’

Isso vai lhe retornar (no primeiro valor numérico) o ID do domínio, anote-o em um lugar ULTRA seguro!

Agora rode o comando abaixo:

dbclient.exe –direct-sql –sql=”delete from dns_zone where id=777″ (777 NÃO é o número obrigatório MEU, este número é o ID que falei acima, pode ser qualquer número inteiro positivo).

Após, vamos ajustar as coisas:

dbclient.exe –direct-sql –sql=”update dns_zone set status=0 where id=777″ (777 NÃO é o número obrigatório MEU, este número é o ID que falei acima, pode ser qualquer número inteiro positivo).

E por fim:

dnsmng.exe update *

Caso dê certo, please, EU QUERO UMA CAIXA DE BIS do preto!

Abraços!

Fonte: http://littleoak.wordpress.com/2009/09/01/parallels-plesk-windows-dominio-nao-funciona-o-dns-ja-tentei-restore-dns-zone-ja-tentei-renomear-solucao-aqui/