Exibir usuário com permissão de SA no 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.

Atualizar Openfire 3.9.1

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!!!

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 – 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_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

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 .

Conectando remotamente no MYSQL usando o Shell!

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!

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

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.

 

Alterando o Collate Default do Servidor SQL Server

Na hora de instalar o MS SQL nem sempre instalamos com o Collate certo e posteriormente queremos mudar o mesmo, fiz isto algumas vezes e sempre recorro ao meu email para lembrar de como eu fiz. Acredito que mais pessoas tenham tido essa dor de cabeça, portanto segue um mini tuto para ajudar nesta tarefa.

Este procedimento vem funcionando desde o SQL 2005, ou seja funciona no SQL 2008 e 2012. Mas faça isso por sua conta em risco, o responsável pelo seu banco de dados é você mesmo que administra ele, não eu! Esse procedimento eu faço nos meus e funciona normal!

O que é Collation de uma Base de dados, como alterar?
Existem configurações para conjuntos de caracteres e Collations em quatro níveis: servidor, banco de dados, tabela e conexão. Collation nada mais é que a codificação de caracteres existente no Banco de Dados. Quando você realiza a migração do conteúdo de um banco de dados, algumas vezes, pode haver conflitos no collation do banco migrado. O resultado deste conflito é a ausência de caracteres especiais quando informações são consultadas no banco. Por exemplo: Você cadastrou a palavra “Chapéu” no seu banco de dados, mas quando a programação do seu site busca este item, retorna o resultado “Chap?u”. Ou seja, os caracteres com acentuação como (é, ã, õ, etc.) são substituídos pelo sinal ”?” (interrogação).
Resumindo, quando você emite um relatório e as informações não sãe como deveriam, muito provavelmente é conflito de collate.

a – Recomendo fortemente um backup das bases, include as system. Lembrem-se, só Deus salva, o resto faz backup.
b – Certifique-se que você não possui nenhuma base de dados em readonly, restoring ou qualquer outro status que impeça sua alteração e garanta que as bases não estão sem espaço livre.
c – Verifique o Collate default atual do servidor, com a query:

SELECT SERVERPROPERTY(‘servername’) As “Nome do Servidor”,
SERVERPROPERTY(‘productversion’) As Versão,
SERVERPROPERTY (‘productlevel’) As “Service Pack”,
SERVERPROPERTY (‘edition’) As Edição,
databasepropertyex(‘master’,’collation’) as “Collation”,
@@Version As “Sistema Operacional”

O resultado deverá ser algo como a imagem abaixo. Nota-se que o collate atual do meu servidor é SQL_Latin1_General_CP1_CI_AS

d – Pare o serviço do SQL Server. É possível usar vários métodos, um deles é parar os serviços usando o utilitário SQL Server Configuration Manager (sqlservermanager10.msc) como faço na figura abaixo.

e – No prompt de comando vá até o diretório de instalação do SQL Server. Localize o arquivo sqlservr.exe e execute sqlservr -m -T4022 -T3659 -q”collate_que_deseja_utilizar”.
Observação importante: O -T tem que ser maiúsculo e caso a instalação o SQL Server estiver utilizando um nome de instância, a opção -s<nome_da_instância> deve ser adicionada.

Comando: sqlservr.exe -m -T4022 -T3659 -q”SQL_Latin1_General_CP1_CI_AI

f – O comando fará com que o SQL Server seja iniciado em modo Single-User e irá alterar o collate do servidor e todas as bases para o collate especificado no opção -q.
g – O final do comando vai ser apresentado com a mensagem “Recovery is Complete.”. Quando isso aparecer você dá Ctrl+C para finalizar e deverá aparecer mais 4 mensagens do SQL e voltará a solicitar comando no prompt, acusando que o comando anterior foi executado e finalizado. Conforme tela abaixo.

i – Pronto, agora reinicie o MSSQL Server e execute a query novamente para certificar-se que o collate foi alterado.

SELECT SERVERPROPERTY(‘servername’) As “Nome do Servidor”,
SERVERPROPERTY(‘productversion’) As Versão,
SERVERPROPERTY (‘productlevel’) As “Service Pack”,
SERVERPROPERTY (‘edition’) As Edição,
databasepropertyex(‘master’,’collation’) as “Collation”,
@@Version As “Sistema Operacional”

A query acima, deverá retornar algo como a imagem a baixo e assim alteramos o collate SQL_Latin1_General_Cp1_CI_AS para SQL_Latin1_General_Cp1_CS_AI.

Prontinho moçada!

Boa sorte ae! []’s