Arquivo

Archive for the ‘Banco de Dados’ Category

Exibir usuário com permissão de SA no SQL Server!

12 de abril de 2016 Deixe um comentário
Microsfot SQL Server

Microsfot SQL Server

Por uma questão de segurança, é comum listar os usuários que tem permissão de sysadmin no banco. Sempre é bom ficar verificando essa lista. Segue uma query para listar usuários com permissão de SA.

SELECT
p.name AS [Name] ,r.type_desc,r.is9_disabled,r.create_date , r.modify_date,r.default_database_name
FROM
sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
WHERE r.type = ‘R’ and r.name = N’sysadmin’

A query acima lista os usuários com permissão de sysadmin.

Anúncios

Atualizar Openfire 3.9.1

10 de fevereiro de 2014 6 comentários
Openfire

Openfire

Atualizando Openfire para versão 3.9.1.

O Openfire é um servidor de mensagens instatâneas que permite que clientes de um mesmo domínio troquem mensagens entre si de forma organizada e com regras de acesso. O mesmo pode ser integrado com Active Directory e utilizar um banco de dados externo (Oracle, Sql, Mysql) ou mesmo um bancozinho interno embutido chamado HSQLDB (Não recomendo esse banco, melhor usar um banco com mais opções como Oracle, M$ Sql ou Mysql.) (Correção do nome do banco dada por Alex Borges =]])

Neste final de semana saiu uma nova atualização para o Openfire, a 3.9.1 (A última versão estável foi a 3.8.2, disponibilizada em 28 de maio de 2013, faz tempo eim).

Esta nova versão possui uma série de melhorias, elas podem ser consultadas aqui no changelog.

Vamos lá, primeiro vou descrever meu cenário:

Sistema Operacional: Debian 7.1 64 Bits
Banco de Dados: SQL Server (Windows 2008 R2 Enterprise)
Autenticação: LDAP do Active Directory
Versão do Openfire: 3.8.2
Diretório de Instalação: /opt/openfire

Bom, agora vamos atualizar.

Vale ressalvar que eu estou atualizando do meu jeito pois não vi nada oficial no site do desenvolvedor. Acredito que este tipo de atualização é válida para qualquer tipo de banco de dados e autenticação que você utilize.

Todos os comandos aqui representados são executados como root #!

1 – Baixar o Openfire 3.9.1 ;

wget http://download.igniterealtime.org/openfire/openfire_3_9_1.tar.gz

2 – Descompactar o pacote tar gz;

tar zxvf openfire_3_9_1.tar.gz

3 – Parar o Openfire;

/etc/init.d/openfire stop

4 – Fazer backup do diretório de instalação;

mv /opt/openfire /opt/openfire_3.8.2_to_3.9.1_09022014

5 – Mover o diretório que a descompactação gerou para onde está instalado o openfire;

mv -vif openfire /opt/

6 – Copiar alguns arquivos do openfire antigo para não ter que configurar nada;

cp -arp /opt/openfire_3.8.2_to_3.9.1_09022014/enterprise /opt/openfire/
cp -arp /opt/openfire_3.8.2_to_3.9.1_09022014/conf /opt/openfire/
cp -arp /opt/openfire_3.8.2_to_3.9.1_09022014/plugins /opt/openfire/
cp -arp /opt/openfire_3.8.2_to_3.9.1_09022014/resources /opt/openfire/

6 – Iniciar o Openfire!

/etc/init.d/openfire start

7 – Checar se a porta 5222 subiu, ou teste direto na console.

nmap localhost | grep 5222

8 – Entrar na console de admin do Openfire e atualizar seus plugins, sugiro atualizar um plugin de cada vez, parar o Openfire, logar com o Spark e depois de checar se está tudo okay, atualizar o próximo.

Pronto,  seu Openfire está atualizado e operacional! =]]

Caso ele não esteja =[[, siga os passos abaixo para desfazer tudo que você fez e voltar para sua versão 3.8.2 ou qualquer outra versão que seu Openfire se encontra.

1 – Pare o Openfire.

/etc/init.d/openfire stop

2 – Remova o diretório com o Openfire na versão 3.9.1

rm -rf /opt/openfire

3 – Volte o backup de seu Openfire Antigo

cp -arp /opt/openfire_3.8.2_to_3.9.1_09022014 /opt/openfire

4 – Inicie seu Openfire.

/etc/init.d/openfire start

5 – Pronto seu Openfire já está okay.

Openfire é bem simples e quase nunca dá problema. Recomendo o uso do Plugin Content Filter. Este plugin aliado com expressões regulares dão asas ao Openfire.

Resolvendo erro PHP Fatal error!!!

23 de janeiro de 2014 Deixe um comentário
PhpLogo

phpLogo

Resolvendo erro PHP Fatal error:  Maximum execution time of 30 seconds exceeded

Quando alguma aplicação sua der erro no PHP, e o log constar “PHP Fatal error:  Maximum execution time of 30 seconds exceeded …” a solução é simples, basta aumentar a opção max_execution_time do PHP.INI, que deve estar localizada dentro do apache. Tive um problema deste tipo em uma guia gigante de internação onde o php validava alguns campos e em seguida fazia insert’s sucessivos no SQL. Como o xml era muito grande com muitos ítens, ele dava erro por TIMEOUT!

Primeiro vamos identificar onde está o arquivo php.ini. Para isso vamos criar uma página para nos gerar as configurações do php. Dentro do /var/www vamos criar um arquivo chamado infophp.php e inserir as configurações do php que nos exiba as confs dele.

echo "<?php phpinfo(); ?>" > /var/www/infophp.php

Pronto, agora você acessa esta página digitando o ip do seu servidor e a página criada (http://IP/infophp.php)

http://168.168.168.168/infophp.php

Agora você vai procurar duas informações: “max_execution_time” e “Configuration File (php.ini) Path”. A opção max_execution_time lhe dirá em segundos, quanto tempo o PHP esperará antes de dar erro por timeout (PHP Fatal error:  Maximum execution time of 30 seconds exceeded). Já a segunda opção diz onde o arquivo de configuração global do PHP está localizado.

No print abaixo, você conseguirá identificar o caminho do php.ini, que é o arquivo onde ficam todas as configurações globais do PHP. No caso do print abaixo, o caminho seria ‘/etc/php5/apache2’.

Caminho do PHP.ini

Caminho do PHP.ini – Arquivo de configuração global do PHP

No print abaixo, você consegue identificar a opção max_execution_time, que é a opção que diz ao PHP que ele deve esperar tantos segundos antes de dar timeout.

Max_E_T

max_execution_time

No caso do meu max_execution_time, o tempo já está em 60 segundos, mas o default é 30 segundos

Para aumentar seu max_execution_time e evitar que suas aplicações gerem erros por conta de timeout, basta ir no php.ini e alterar a variável. Para o caso de um php com caminho igual ao do print acima, basta executar o comando:

# sed -i "s/max_execution_time = 30/max_execution_time = 60/g" /etc/php5/apache2/php.ini

sed -i “s/max_execution_time = 30/max_execution_time = 60/g” /etc/php5/apache2/php.ini

O comando acima executado diretamento na console altera o arquivo /etc/php5/apache2/php.ini trocando o valor de “max_execution_time =30” para “max_execution_time = 60”.

Ou você pode evitar na mão o arquivo /etc/php5/apache2/php.ini e alterar a opção max_execution_time de 30 apra 60.

Após isso, basta reiniciar o apache2 e executar a sua rotina novamente ver se vai dar problema

service apache2 restart

ou

/etc/init.d/apache2 restart

Ou simplesmente

killall -1 apache2

Prontinho!




Copiar Tabela SQL (MYSQL) ou duplicar

21 de janeiro de 2014 Deixe um comentário
Comandos SQl e Mysql

Comandos Sql e Mysql

Duplicar ou copiar uma tabela inteira para outra no MYSQL E SQL SERVER.

Hoje tive que fazer um update daqueles em uma tabela do Mysql, para poder melhorar os índices. Entretanto, como estou acostumado com o SQL Server, apanhei um pouco na hora de escrever a sintaxe correta no MYSQL. Por esta razão estou postando os comandos tanto do SQL SERVER quanto do MYSQL para o dump da tabela.

Lembrando que fazer cópia de uma tabela antes de aplicar um update complicado, é muito importante, pois assim, você não precisa restaurar o banco todo, mas sim apenas voltar a tabela em questão!

Para ambos os casos ( Mysql e Sql) o comando em questão é o INSERT INTO junto com um select. Ou seja, ele faz uma consulta, e depois insere esta consulta em algum lugar.

1 º) SQL SERVER

USE NOME DO BANCO
SELECT * INTO TABELA_NOVA FROM TABELA_ORIGINAL

2 º) MYSQL

CREATE TABLE tabela_nova LIKE tabela_original;
INSERT INTO tabela_nova SELECT * FROM tabela_original;

A diferença além da sintaxe, basicamente é que no Mysql você deve primeiro criar a tabela_nova, antes de executar o comando INSERT INTO, enquanto que no Sql Server você não precisa criar a tabela primeiro, no momento do INSERT INTO, a tabela_nova é criada com a mesma estrutura da tabela_original .

Categorias:Banco de Dados, Mysql, Sql Server Tags:

Conectando remotamente no MYSQL usando o Shell!

7 de junho de 2013 Deixe um comentário

Conectando remotamente no MYSQL usando o Shell!

Quando precisar acessar um Banco Mysql remotamente via shell, utilizar a sintaxe abaixo:

mysql -u username -p -P n_port -h ip_host database_name

Exemplo:

mysql -u jacques.beijer -p -P 73307 -h 201.201.201.745 cafeina_database

Lembrando que você precisa definir permissão de acesso (grant) para o host que irá acessar, essa permissão tem que ser feita no host que hospeda o banco de dados. Esta permissão (tem um post meu só sobre permissões) pode ser definida com o comando abaixo:

root@takakaos:~# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.

mysql> grant all privileges on *.* to usuario@ip_host_remoto 
IDENTIFIED BY 'senha_xpto';
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> exit
Bye
root@takakaos:~#

Para conectar usando tunel, usar a sequência abaixo:

ssh -L 73307:mysql.host.com:3306 user@host.com
mysql -u user -p -P 73307 -h 127.0.0.1 database

Conectar remotamente no Mysql do Zimbra!

5 de junho de 2013 5 comentários
Zimbra

Zimbra

Conectando remotamente no Mysql do Zimbra!

Hoje ao tentar conectar no banco Mysql do Zimbra usando o Mysql Query Browser a partir da minha máquina, vi que não estava conseguindo por estar com acesso negado e ao ir fazer a liberação notei que as configurações do mysql não estavam como default.

Para resolver este problema podemos agir da seguinte forma.

Logar na conta do zimbra:

su zimbra

Em seguida conectar no banco com usuário padrão do zimbra:

mysql -u zimbra

Ele irá logar normalmente. Após isto, vamos conceder a permisssão no Mysql:

grant all privileges on *.* to `usuario`@`ip_remoto` IDENTIFIED 
BY "senha_desejada" WITH GRANT OPTION;
flush privileges;
exit

Substitua o termo usuario para o login que você deseja utilizar, bem como senha_desejada para a senha que você irá utilizar e o ip_remoto para o ip do computador a qual você pretende utilizar para acessar o banco.
Pronto, agora temos um usuários para acessar o banco do Zimbra, lembrando que você pode inserir ‘root’@’%’ para dar acesso root a partir de qualquer host da rede. Lembrando que o Mysql do Zimbra Utiliza a porta 7306.

Agora precisamos abrir o Mysql para aceitar conexões não apenas localmente, mas de outros hosts também. Para fazer esta alteração, temos que editar o arquivo /opt/zimbra/conf/my.cnf e comentar a opção bind-address = localhost e salvar o arquivo:

vim /opt/zimbra/conf/my.cnf
#bind-address = localhost

Após esta alteração, reinicie o mta com os comandos abaixo e seu acesso estará permitido.

zmcontrol stop
zmcontrol start

Pronto.

[]’s

Permitir conexão remota ao Banco Mysql

2 de junho de 2013 2 comentários
MySQL

MySQL

Permitir conexão remota ao Banco Mysql

 

Faço parte de várias listas de discussões Linux e vejo que é recorrente o assunto de permitir conexão remota no banco de dados MySQL. Este problema ocorre basicamente por dois motivos, o MySQL nativamente vem configurado para apenas ser acessado localmente e também para acessar a base você precisa de permissão para o que vai acessar, de onde vai acessar e o como irá acessar.

O MySQL utiliza por default a porta 3306 via protocolo TCP. Com essa informação podemos perguntar ao servidor se esta porta esta aberta e qual o estado dela. Podemos dar um “netstat -ln | grep 3306” que irá nos retornar a saída abaixo:

tcp        0      0 127.0.0.1:3306            0.0.0.0:*               OUÇA

Bingo. O MySQL está ouvindo normalmente na porta 3306, só que apenas está definido como 127.0.0.1:3306, ou seja, só permite conexões do próprio servidor (comunicação loopback). Precisamos mudar essa opção, permitindo assim que outros hosts possam se conectar no MySQL. Para Sistemas como Slackware e Debian (E derivados deles) você tem o arquivo de configuração do MySQL em /etc/my.cnf dentro deste arquivo temos uma variável chamada bind-address que deve estar definida com 127.0.0.1, ou seja, localhost. Sugiro que você comente esta variável e/ou coloque ‘bind-address = 0.0.0.0′ e caso tenha uma variável chamada skip-networking, comente ela também.

Antes de tudo, vamos fazer um backup do arquivo de configuração do MySQL para evitar maiores dores de cabeça.

cp -ar /etc/my.cnf /etc/my.cnf.ori

Abra o arquivo.

vim /etc/my.cnf

Localize e comente as linhas abaixo (a bind-address poderá aparecer com 127.0.0.1 ou com 0.0.0.0):

#skip-networking
#bind-address=0.0.0.0 ou #bind-address=127.0.0.1

Após isso, salve o arquivo my.cnf e reinicie o MySQL.

/etc/init.d/mysql restart;

Pronto, agora o banco de dados está aceitando conexões em todas as interfaces e de todos os hosts, o que nos leva ao segundo ponto, a permissão para este acesso.

Para dar permissão de acesso, basta acessar o mysql:

mysql -u root -p

E digitar estes comandos:

grant all privileges on *.* to root@192.168.254.254 IDENTIFIED BY 'lisarB';
flush privileges;
exit

O primeiro comando concede todos os privilégios a todas as bases para o usuário root, que poderá se conectar a partir do host 192.168.254.254 com a senha lisarB. Pronto, o host 192.168.254.254 conseguirá conectar no banco agora como usuário root. O segundo comando atualiza os privilégios, o terceiro, sai do mysql.

Caso você queira liberar o acesso root proveniente de qualquer host, basta executar o comando abaixo:

grant all privileges on *.* to root@% IDENTIFIED BY 'lisarB';
flush privileges;
exit

Quando usado ‘root@%’ significa dizer que o usuário root pode se conectar de qualquer host.

Lembrando que não é recomendável dar acesso root, use-o apenas para dar manutenção e administrar o banco. Crie usuários específicos com permissões específicas para trabalhar no banco de dados. Este tipo de liberação deve ser feita em conjunto com medidas de segurança, lembre-se que você está abrindo brechas…

Definição do desenvolver do MySQL para as duas variáveis alteradas:

bind-address: The MySQL server listens on a single network socket for TCP/IP connections. This socket is bound to a single address, but it is possible for an address to map onto multiple network interfaces. The default address is 0.0.0.0. To specify an address explicitly, use the --bind-address=addr option at server startup, where addr is an IPv4 address or a host name. If addr is a host name, the server resolves the name to an IPv4 address and binds to that address.

skip-networking: Don’t listen for TCP/IP connections at all. All interaction with mysqld must be made via Unix sockets. This option is highly recommended for systems where only local requests are allowed. Since you need to allow remote connection this line should be removed from my.cnf or put it in comment state.