Por que o VI tem sintaxe colorida como usuário normal e como usuário root não?

OK, é uma dica bem básica mas que deixa muitos iniciantes quebrando a cabeça…

Você abre o Vi como usuário normal e o texto é exibido colorido, de acordo com a sintaxe do arquivo (SQL, C, etc.); mas quando você abre o mesmo arquivo como usuário root, o texto é exibido sem cor nenhuma. Por que isso ocorre?

Na maioria das vezes seu sistema tem 2 versões do Vi instalado: a versão original, básica, o Vi, e a versão melhorada, o Vim (Vi IMproved).

Geralmente o usuário root utiliza a versão Vi (que fica em /bin/vi) e o usuário normal utiliza a versão Vim (que fica em /usr/bin/vim).

Para ter certeza disso, execute o seguinte comando “which vi” como usuário normal e como usuário root:

[root@dbserver ~]# which vi
/bin/vi

[abrantesasf@dbserver ~]$ which vi
alias vi='vim'
 /usr/bin/vim

Como você pode ver, o usuário root utiliza o Vi (em /bin/vi) e o usuário normal utiliza o Vim (em /usr/bin/vim) através de um alias. Para fazer o usuário root usar o Vim, basta criar um alias editando o arquivo .bashrc no diretório home do usuário root e acrescentar a seguinte linha:

alias vi='/usr/bin/vim'

Agora o usuário root também usará o Vim e terá a sintaxe colorida nos arquivos.

Instalar PostgreSQL 9.4.4 no CentOS 7

O PostgreSQL é o melhor gerenciador de bancos de dados open-source na atualidade, embora um pouco mais complexo do que sistemas alternativos como o MariaDB (que substituiu o MySQL como alternativa open-source após este ser adquirido pela Oracle).

O CentOS 7.1 traz a versão 9.2.13 por padrão mas a última versão disponível no site do PostgreSQL, na data da produção deste texto, é a 9.4.4. Se a versão 9.2 atende seus objetivos, basta instalar os pacotes através do yum. Mas, se você pretende ficar com a versão mais nova, deve fazer uma instalação personalizada.

Existem duas formas de fazer a instalação:

  • A primeira é utilizando o repositório YUM do próprio PostgreSQL, que contém os RPMs com as versões mais novas para várias distribuições Linux. É o jeito mais rápido e fácil, e o mais indicado para iniciante, mas tem como desvantagem não poder personalizar configurações individuais do PostgreSQL. Se optar por esta forma de instalação, siga as instruções em PostgreSQL YUM Installation. Esta forma de instalação não será mostrada neste texto.
  • A segunda é fazendo o download do código fonte e compilando o PostgreSQL especificamente para sua distribuição Linux. É o jeito mais flexível para configurar opções para o binário gerado e o método mais indicado para usuários avançados, mas tem como desvantagem a maior complexidade para fazer todos os componentes envolvidos (PostgreSQL e suas dependências) funcionaram corretamente para a compilação. É exatamente essa forma de instalação que será detalhada neste texto.

1) Compilação e instalação:

  1. Como usuário root, instale os pré-requisitos para a compilação do código fonte do PostgreSQL (muitos já estarão instalados por padrão e alguns não são obrigatórios; aqui mostro todos os pré-requisitos, exceto os necessários para compilar a documentação; se quiser instalar uma Tcl mais nova, siga as instruções deste post e não instale a tcl e a tcl-devel no comando abaixo):
    yum install make gcc tar gzip bzip2 readline readline-devel zlib perl perl-libs perl-devel perl-ExtUtils-Embed python python-devel gettext gettext-common-devel gettext-devel gettext-libs openssl openssl-libs openssl-devel openldap openldap-devel pam pam-devel krb5-libs krb5-devel flex flex-devel bison bison-devel tcl tcl-devel libxml2 libxml2-devel libxslt libxslt-devel
  2. Como usuário normal, faça o download do código fonte do PostgreSQL 9.4.4 (ou outro mais recente que esteja em produção) diretamente em http://www.postgresql.org/ftp/source. Descompacte o arquivo.
    tar -jxvf postgresql-9.4.4.tar.bz2
  3. Como usuário normal, entre no diretório criado e execute o comando configure. Abaixo está um exemplo com todas as principais opções; se você não precisa de alguma feature, basta retirar do comando abaixo (obs.: no exemplo abaixo estou usando uma Tcl instalada que não é a padrão do CentOS):
    ./configure --prefix=/usr/local/pgsql --enable-nls --with-perl --with-python --with-tcl --with-tclconfig=/usr/local/lib/tcl8.6.4/lib --with-openssl --with-pam --with-ldap --with-readline --with-libxml --with-libxslt
  4. Se o comando configure retornou algum erro você terá de descobrir como resolver consultando a documentação de instalação do PostgreSQL. Se tudo correu bem, execute o make world (como usuário normal) para compilar o PosrgreSQL, a documentação (HTML e man pages) e todos os módulos adicionais (contrib):
    make world
    (output da compilação omitido)
    PostgreSQL, contrib, and documentation successfully made. Ready to install.
  5. Se a mensagem final mostrada acima aparecer, você conseguiu compilar o PosrgreSQL, os módulos contrib e e documentação. Agora vamos testar a compilação executando, como usuário normal, o comando:
    make check
    (output dos testes omitido)
    =======================
     All 145 tests passed. 
    =======================
  6. Se você recebeu a mensagem de que toda a compilação passou nos testes, o PostgreSQL está pronto para ser instalado. Lembre-se que no comando configure (etapa 3) nós ajustamos o diretório de instalação do PostgreSQL para /usr/local/pgsql. Entretanto, eu não gosto de instalar diretamente nesse diretório por um motivo simles: para facilitar upgrades futuros de versões. Assim, nós vamos criar um diretório específico para a versão do PostgreSQL e vamos criar o /usr/local/pgsql como um link simbólico que aponta para o diretório específico. Agora, como usuário root, crie o diretório específico, o link simbólico e execute o make install:
    mkdir /usr/local/pgsql-9.4.4
    ln -s /usr/local/pgsql-9.4.4 /usr/local/pgsl
    make install-world
    (output da instalação omitido)
    PostgreSQL, contrib, and documentation installation complete.
  7. Agora o PostgreSQL está instalado no diretório /usr/local/pgsql-9.4.4, sendo acessado através do link simbólico /usr/local/pgsql, mas não está pronto para ser utilizado. Siga as tarefas pós-instalção agora.

2) Tarefas pós-instalação:

  1. Crie um grupo de sistema, um usuário de sistema e uma senha para administrar o PostgreSQL:
    groupadd -r postgres
    
    useradd -d /usr/local/pgsql -g postgres -r -s /bin/bash postgres
    
    passwd postgres
  2. Agora vamos ajustar as permissões:
    chown postgres:postgres /usr/local/pgsql-9.4.4 -R
    
    chmod 755 /usr/local/pgsql-9.4.4
  3. Agora, como usuário postgres, vamos acertar alguns arquivos em nosso diretório home (/usr/local/pgsql). Primeiro crie o arquivo .bash_profile (não esqueça o ponto no começo do nome do arquivo) com o seguinte conteúdo:
    # .bash_profile
    
    # Funções e aliases básicos
    if [ -f ~/.bashrc ]; then
     . ~/.bashrc
    fi
    
    
    # Configuração do ambiente
    export PATH=/usr/local/pgsql/bin:$HOME/.local/bin:$HOME/bin:$PATH
    export LD_LIBRARY_PATH=/usr/local/pgsql/lib:$LD_LIBRARY_PATH
    export MANPATH=/usr/local/pgsql/man:$MANPATH
  4. Agora crie o arquivo .bashrc (não esqueça o ponto no começo do nome do arquivo) com o seguinte conteúdo:
    # .bashrc
    
    # Ativa definições globais
    if [ -f /etc/bashrc ]; then
     . /etc/bashrc
    fi
  5. Agora você já tem um ambiente adequado para começar a usar o PostgreSQL mas, ainda, não tem um banco de dados criado. A primeira coisa a fazer é decidir em que diretório do sistema salvar o banco de dados. Eu gosto de colocar os dados sob /var/lib/pgsql. Como usuário root, faça o seguinte:
    mkdir /var/lib/pgsql
    
    chown postgres:postgres /var/lib/pgsql
    
    chmod 750 /var/lib/pgsql
  6. Agora, como usuário postgres, vamos criar um diretório para os dados, outro para os logs, e um arquivo de log para o servidor:
    cd /var/lib/pgsql
    
    mkdir data log
    
    chmod 700 data
    
    touch log/server.log
  7. Agora precisamos inicializar o cluster do banco de dados (Database Cluster) do PostgreSQL. Eu sempre inicializo os cluster com locale=C e encoding=utf8 para permitir qualquer character set nos bancos de dados. Faça o seguinte, como usuário postgres:
    initdb --locale=C --encoding=utf8 -D /var/lib/pgsql/data
    
    (output omitido)
    
    Success. You can now start the database server using:
    
     postgres -D /var/lib/pgsql/data
    or
     pg_ctl -D /var/lib/pgsql/data -l logfile start
  8. Agora sim podemos iniciar o PostgreSQL (o comando deve ser digitado em uma única linha!):
    pg_ctl start -s -w -p /usr/local/pgsql/bin/postmaster -D /var/lib/pgsql/data -l /var/lib/pgsql/log/server.log
    
    cat /var/lib/pgsql/log/server.log 
    LOG: database system was shut down at 2015-09-25 20:52:54 BRT
    LOG: MultiXact member wraparound protections are now enabled
    LOG: autovacuum launcher started
    LOG: database system is ready to accept connections
  9. Se o log mostrou que o sistema está pronto para aceitar conexões, meus parabéns! Você compilou, instalou, configurou e iniciou o PostgreSQL no CentOS 7. Mas lembre-se: você ainda NÃO TEM UM BANCO DE DADOS para uso próprio! O PostgreSQL foi iniciado e criado com 3 bancos de dados administrativos, do sistema do próprio PostgreSQL (o banco postgres, o banco template0 e o banco template1). Como ainda temos algumas coisas para configurar antes de podermos usar o PostgreSQL, vamos parar o banco de dados (o comando deve ser digitado em uma única linha):
    pg_ctl stop -s -w -m smart -p /usr/local/pgsql/bin/postmaster -D /var/lib/pgsql/data -l /var/lib/pgsql/log/server.log
    
    cat /var/lib/pgsql/log/server.log 
    LOG: database system was shut down at 2015-09-25 20:52:54 BRT
    LOG: MultiXact member wraparound protections are now enabled
    LOG: autovacuum launcher started
    LOG: database system is ready to accept connections
    LOG: received smart shutdown request
    LOG: autovacuum launcher shutting down
    LOG: shutting down
    LOG: database system is shut dow

3) Script para o systemd:

As distribuições linux mais novas (CentOS 7, Oracle Linux 7, Red Hat Enterprise Linux 7, SuSE Enterprise Linux 12 e outras) utilizam o systemd como substituto ao antigo método init de inicialização do linux, e como substituto dos scripts de inicialização e término de serviços em /etc/init.d. Assim, precisamos criar um arquivo de serviço do systemd para podermos iniciar e parar o banco, bem como configurar a inicialização automática do PostgreSQL durante o boot e o término automático durante o shutdown.

Como usuário root, vá para dentro do diretório /etc/systemd/system/multi-user.target.wants e crie o arquivo postgresql.service com o seguinte conteúdo (atenção, os comandos maiores devem ser digitados em uma única linha):

# Arquivo de controle do PostgreSQL personalizado

[Unit]
Description=PostgreSQL 9.4.4 (instalação personalizada)
After=network.target

[Service]
Type=forking

User=postgres
Group=postgres

Environment=PGPORT=5432

Environment=PGDATA=/var/lib/pgsql/data
Environment=PGLOGFILE=/var/lib/pgsql/log/server.log
Environment=PGRUNFILE=/usr/local/pgsql/bin/postmaster
Environment=LD_LIBRARY_PATH=/usr/local/lib/tcl8.6.4/lib:/usr/local/pgsql/lib:$LD_LIBRARY_PATH
Environment=PATH=/usr/local/lib/tcl8.6.4/bin:/usr/local/pgsql/bin:$PATH

# StandardOutput=syslog

# Desabilita OOM kill no postmaster
OOMScoreAdjust=-1000

ExecStart=/usr/local/pgsql/bin/pg_ctl start -s -w -p ${PGRUNFILE} -D ${PGDATA} -t 300 -l ${PGLOGFILE}
ExecStop=/usr/local/pgsql/bin/pg_ctl stop -D ${PGDATA} -s -w -m smart -l ${PGLOGFILE}
ExecReload=/usr/local/pgsql/bin/pg_ctl reload -D ${PGDATA} -s

# Tempo de timeout para início/shutdown
TimeoutSec=300

[Install]
WantedBy=multi-user.target

Agora vamos dar um reload do daemon do systemd para que o arquivo de controle acima seja lido. Ainda como root, execute o seguinte comando:

systemctl daemon-reload

E agora é a hora da verdade: vamos testar nosso novo serviço de inicialização e shutdown do PostgreSQL, como root:

systemctl start postgresql.service

tail /var/lib/pgsql/log/server.log
(output omitido)
LOG: shutting down
LOG: database system is shut down
LOG: database system was shut down at 2015-10-22 15:04:18 BRST
LOG: MultiXact member wraparound protections are now enabled
LOG: database system is ready to accept connections
LOG: autovacuum launcher started

systemctl stop postgresql.service

tail /var/lib/pgsql/log/server.log
(output omitido)
LOG: MultiXact member wraparound protections are now enabled
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
LOG: received smart shutdown request
LOG: autovacuum launcher shutting down
LOG: shutting down
LOG: database system is shut down

systemctl start postgresql.service

systemctl status postgresql.service
postgresql.service - PostgreSQL 9.4.4 (instalação personalizada)
 Loaded: loaded (/etc/systemd/system/multi-user.target.wants/postgresql.service)
 Active: active (running)
(... restante do output omitido ...)

Como visto acima o systemd já está controlando adequadamento o PostgreSQL e cuidando da inicialização/término automático durante o boot do sistema.

4) Instalando linguagens procedurais:

Para a criação de funções, procedures e triggers no PostgreSQL precisamos de instalar pelo menos uma linguagem procedural no banco de dados template1 (que é o template a partir do qual, normalmente, todos os bancos de dados dos usuários são criados). A linguagem padrão é a PL/pgSQL, mas existem outras, como a PL/Perl, a PL/Python e a PL/Tcl.

Inicialmente, vamos ver quais as linguagens procedurais instaladas. Como usuário postgres, dê o seguinte comando:

$ createlang -l template1
Procedural Languages
    Name | Trusted? 
---------+----------
 plpgsql | yes

Conforme ilustrado acima, somente a PL/pgSQL está instalada no banco de dados template1. Para instalar a PL/Perl e a PL/Tcl, faça o seguinte:

$ createlang plperl template1
$ createlang pltcl template1
$ createlang -l template1
Procedural Languages
    Name | Trusted? 
---------+----------
 plpgsql | yes
 plperl  | yes
 pltcl   | yes

Conforme ilustrado acima agora o template1 já tem as 3 linguagens procedurais mais importantes: PL/pgSQL, PL/Perl e PL/Tcl. Note que essas linguagens são marcadas como “Trusted”, o que significa que as funções, triggers e procedures criadas nessas linguagens não permitem o acesso às funções internas do PostgreSQL e/ou do sistema de arquivos, sendo consideradas seguras para uso por todos os usuários (não permitem que usuários acessem dados ou ojetos que de outra forma eles não teriam acesso). Qualquer usuário pode criar código usando essas linguagens.

Existem versões “Untrusted” da linguagem PL/Perl e PL/Tcl. Também existe uma versão “Untrusted” da PL/Python (não existe uma versão Trusted da PL/Python ainda). Essas linguagens “Untrusted” permitem que o usuário acesse mecanismos internos do banco de dados e/ou do sistema subjacente, não sendo consideradas de uso seguro por todos os usuários. Como são linguagens “Untrusted”, somente o usuário administrador do PostgreSQL pode criar código nessas linguagens.

Para instalar as versões “Untrusted” das linguagens procedurais, faça o seguinte:

$ createlang plperlu template1
$ createlang pltclu template1
$ createlang plpythonu template1
$ createlang -l template1
 Procedural Languages
    Name   | Trusted? 
-----------+----------
 plpgsql   | yes
 plperl    | yes
 pltcl     | yes
 plperlu   | no
 pltclu    | no
 plpythonu | no

Conforme ilustrado acima o banco template1 agora está com todas as principais linguagens procedurais instaladas, tando as “Trusted” quanto as “Untrusted”.

5) Aumentando a segurança:

Caso você não tenha notado o usuário postgres tem acesso garantido ao PostgreSQL e nem mesmo uma senha é solicitada (por isso você instalou as linguagens procedurais diretamente).

Isso ocorre pois o PostgreSQL aceita conexões locais pelo método de autenticação “trust”. Para aumentar a segurança, temos que criar uma senha para o usuário postgres e depois alterar a configuração de acesso do PostreSQL.

Primeiro vamos criar uma senha para o usuário postgres. Siga o exemplo abaixo:

[postgres@host ~]$ psql 
psql (9.4.4)
Type "help" for help.

postgres=# alter role postgres
postgres-# with encrypted password 'senha';
ALTER ROLE
postgres=# \q

[postgres@host ~]$

Agora tente entrar solicitando explicitamente a senha:

[postgres@host ~]$ psql -W
Password: senha
psql (9.4.4)
Type "help" for help.

postgres=# \q

[postgres@host ~]$

Pronto, agora que você já configurou uma senha para o usuário postgres, vamos alterar o mecanismo de acesso ao PostgreSQL. Edite o arquivo /var/lib/pgsql/data/pg_hba.conf e alterar as linhas de acesso para algo mais seguro, como por exemplo:

# TYPE   DATABASE   USER   ADDRESS        METHOD
local    all        all                   md5
host     all        all    127.0.0.1/32   md5
host     all        all    ::1/128        md5

O exemplo acima está permitindo conexões ao PostgreSQL via socket locais (type local) ou através dos endereços IPv4 e IPv6 de localhost (127.0.0.1/132 e ::1/128). Todas essas conexões exigem o uso do método de autenticação md5, que solicita uma senha criptografada. Note que a configuração acima não permite que o PostgreSQL aceite conexões de outros hosts: só aceita conexões originadas dentro do próprio host do PostgreSQL (localhost). Depois veremos como liberar conexões a partir de outros hosts, mas por enquanto, essa segurança está adequada.

Para fazer o PostgreSQL ler as novas configurações do arquivo pg_hba.conf, temos que dar um restart como usuário root:

[root@host ~]# systemctl restart postgresql.service

Agora, como usuário postgres, tente acessar o PostgreSQL: será solicitada uma senha como no exemplo abaixo:

[postgres@host data]$ psql
Password: senha
psql (9.4.4)
Type "help" for help.

postgres=#

6) Alterando configurações do PostgreSQL para o português:

O PostgreSQL até agora está configurado com os padrões da língua inglesa. Para alterar os principais parâmetros para o português, edite o arquivo /var/lib/pgsql/data/postgresql.conf e deixe os seguintes parâmetros conforme o exemplo abaixo:

log_timezone = 'Brazil/East'

datestyle = 'iso, dmy'

timezone = 'Brazil/East'

lc_monetary = 'pt_BR.UTF-8'

lc_numeric = 'pt_BR.UTF-8'

lc_time = 'pt_BR.UTF-8'

default_text_search_config = 'pg_catalog.portuguese'

Para que as alterações tenham efeito, será necessário reiniciar o PostgreSQL como usuário root:

[root@host ~]# systemctl restart postgresql.service

7) Em resumo

Até agora você configurou, compilou e instalou o código fonte para ficar com o PostgreSQL 9.4.4 em seu CentOS 7.

Além disso criou um usuário postgres e diretórios padronizados para a instalação.

Instalou linguagens procedurais no banco template1 e aumentou a segurança das conexões ao exigir somente conexões com senha criptografadas.

Você também criou um arquivo para o systemd iniciar e parar o PostgreSQL de forma automática, e via usuário root.

Também configurou os principais parâmetros de linguagem para o português.

Nesse momento você já tem uma instalação do PostgreSQL totalmente funcionante e pronta para uso!

O único porém é que a configuração atual de nosso PostgreSQL só aceita conexões de localhost. Se isso é tudo que você precisa, meus parabéns! Trabalho feito!

Por outro lado, se você precisa que seu PostgreSQL aceite conexões de outros hosts (da mesma rede ou até via internet, por exemplo), teremos que alterar as configurações, criar conexões SSL por segurança e alterar o firewall do CentOS. Isso será visto em outro post. Até lá!

Como usar o FreeTDS e o UnixODBC em um CentOS 7 com PHP 5.4 para acessar bancos de dados SQL Server e Sybase ASA

Este texto mostrará como configurar conexões ao SQL Server e ao Sybase ASA, a partir de um CentOS 7, usando o FreeTDS, UnixODBC e  o PHP/Apache.

Dependendo das versões de cada um dos componentes envolvidos as configurações necessárias poderão ser um pouco diferentes das que serão mostradas aqui mas, mesmo assim, você saberá por onde começar e o caminho das pedras a seguir. Especificamente as configurações foram feitas no seguinte ambiente:

  • CentOS 7.1, rodando:
    • Apache 2.4.6
    • PHP 5.4.16
    • FreeTDS 0.95
    • UnixODBC 2.3.1
  • MS SQL Server 2008 R2, rodando em um Windows 2008 R2 Server
  • Sybase Adaptive Server Anywhere (ASA) 9.0.2, rodando em Windows 2008 R2 Server

Como você pode ver, o host linux (CentOS está atualizado) mas o SQL Server e o Sybase já são versões muito antigas (bem, foi o que conseguimos para testar).

Se você tem versões mais novas do SQL Server ou do Sybase, siga as instruções abaixo e altere, se necessário, as configurações para seu ambiente. Você terá que consultar a documentação na internet.

Observação: o Sybase Adaptive Server Anywhere (Sybase ASA) foi renomeado para Syabse SQL Anywhere nas versões mais novas. Note também que existe um outro produto, o Sybase Adaptive Server Enterprise (Sybase ASE). Independentemente do produto Sybase que você está usando, as configurações são semelhantes ao descrito aqui (talvez você tenha que ajustar um ou outro parâmetro, consulte a documentação na internet).

Mãos à obra!

1) Atualize o CentOS

Recomendação padrão antes de qualquer coisa: atualize o CentOS para garantir que todos os pacotes estejam nas últimas versões, com os patches de segurança instalados:

yum check-update
yum update

2) Instale os pacotes necessários

Você precisará, minimamente, do Apache, PHP e do UnixODBC:

yum install httpd httpd-tools php php-common php-cli php-odbc php-pdo unixODBC unixODBC-devel

A configuração do Apache e do PHP estão fora do escopo deste documento. Consulte Instalação do Apache, PHP e MySQL (MariaDB) no CentOS 7 para maiores informações.

3) Instale e configure o FreeTDS

O FreeTDS é uma implementação open source do protocolo TDS (Tabular Data Stream) usado pelo SQL Server e pelo Sybase, e permite que hosts unix/linux consigam se conectar a esses bancos de dados.

O CentOS não traz um pacote pronto para a instalação do FreeTDS, mas no repositório EPEL (Extra Packages for Enterprise Linux) existe um pacote prontinho para uso. Configure o CentOS para usar o repositório EPEL e instale o FreeTDS:

yum install epel-release
yum check-update
yum install freetds freetds-devel

O arquivo de configuração do FreeTDS é o /etc/freetds.conf. Edite esse arquivo para ficar semelhante ao seguinte (prestando atenção aos itens em vermelho):

[global]
 # Versão global do protocolo TDS
 #tds version = 4.2
 tds version = 5.0

 # Armazenar dump (TDSDUMP file) para debug?
 dump file = /tmp/freetds.log
 debug flags = 0xffff

 # Timeouts
 timeout = 10
 connect timeout = 10

 # Tamanho do buffer para campo TEXT para evitar
 # erros do tipo out-of-memory errors
 text size = 64512


[nome_banco_sybase]
 host = ip_do_servidor
 port = porta_do_servidor
 tds version = 5.0


[nome_banco_sqlserver]
 host = ip_do_servidor
 port = porta_do_servidor
 tds version = 7.0

Agora temos que testar se a conexão ao Sybase e ao SQL Server, via FreeTDS, está funcionando corretamente. Para isso usamos o utilitário tsql do FreeTDS.

Teste de conexão ao Sybase:

# tsql -S nome_banco_sybase -U usuario -P senha
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
1> quit

Se você chegou no prompt “1>”, conforme mostrado acima, pode dar o quit e sair feliz pois a conexão FreeTDS ao Sybase está funcionando corretamente.

Teste de conexão ao SQL Server:

# tsql -S nome_banco_sqlserver -U usuario -P senha
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
1> quit

Se você chegou no prompt “1>”, conforme mostrado acima, pode dar o quit e sair feliz pois a conexão FreeTDS com o SQL Server está funcionando corretamente.

Se alguma dessas conexões não foi bem-sucedida, você terá que procurar uma solução antes de continuar. Em particular o nome do banco do Sybase é uma configuração chata: qualquer errinho nesse nome e você verá uma mensagem de erro conforme a seguir:

# tsql -S nome_banco_sybase_errado -U usuario -P senha
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
Msg 911 (severity 16, state 0) from [nome_banco_sybase_errado]:
 "ASA Error -83: Specified database not found"
There was a problem connecting to the server

A mensagem acima é típica de uma configuração do FreeTDS usando o nome do banco de dados do Sybase errado. Consulte seu DBA para saber exatamente o nome do banco de dados que tem que ser configurado no FreeTDS.

4) Configure o UnixODBC

Até o momento já temos o FreeTDS instalado, configurado e acessando os bancos SQL Server e Sybase (se você não conseguiu completar a seção 3, nem adianta seguir adiante: consulte a documentação e faça o FreeTDS se conectar corretamente aos bancos de dados, pois o UnixODBC usará essa conexão).

Agora é hora de configurar o UnixODBC.

Edite o arquivo /etc/odbcinst.ini e deixe com o seguinte conteúdo:

[ODBC]
Trace = No
TraceFile = /tmp/sql.log
ForceTrace = No

[FreeTDS]
Driver = /usr/lib64/libtdsodbc.so.0
FileUsage = 1

No arquivo acima estamos dizendo que o UnixODBC deve usar o driver do FreeTDS (/usr/lib64/libtdsodbc.so.0) para as conexões. Se quisermos, para debug de conexões problemáticas, podemos habilitar os trace file mudando de No para Yes (em sistemas de produção, deixar como No).

Agora crie ou edite o arquivo /etc/odbc.ini e deixe com o seguinte conteúdo:

# Data Source Name (DSN) para o MS SQL-Server:
[alias1]
Description = Conexão ao SQL Server 2008 R2
Driver = FreeTDS
Trace = No
Server = ip_do_servidor
Database = nome_banco_sqlserver
Port = porta_do_servidor


# Data Source Name (DSN) para o Sybase:
[alias2]
Description = Conexão ao Sybase ASA 9
Driver = FreeTDS
Trace = No
Servername = nome_banco_sybase  # igual ao /etc/freetds.conf
Port = porta_do_servidor
TDS_Version = 5.0

Explicando o arquivo acima para o SQL Server:

  • alias1 = é um alias arbitrário, o nome do DSN. Pode ser qualquer coisa e será usado nas chamadas de conexões ao SQL Server
  • Server = IP do servidor SQL Server
  • Database = nome do banco de dados ao qual você quer se conectar
  • Port = porta do SQL Server para receber conexões

Explicando o arquivo acima para o Sybase:

  • alias2 = é um alias arbitrário, o nome do DSN. Pode ser qualquer coisa e será usado nas chamadas de conexões ao Sybase
  • Servername = atenção com esse parâmetro: apesar do parâmetro se chamar “servername”, ele significa o nome do banco de dados do Sybase, idêntico ao nome do banco de dados do Sybase configurado no arquivo /etc/freetds.conf. O DSN alias2 procurará pela entrada “Servername” em /etc/freetds.conf para saber como estabelecer a conexão.
  • Port = porta do Sybase para receber conexões

Agora vamos testar as conexões aos bancos de dados via UnixODBC, através do utilitário isql do UnixODBC.

Teste de conexão ao SQL Server, usando o DSN alias1:

# isql alias1 usuario senha -v
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> select count(*) from tabela;
+------------+
|            |
+------------+
| 2094       |
+------------+
SQLRowCount returns 1
1 rows fetched
SQL> quit

Muito bom, tudo funcionando. Nos conectamos ao DSN chamado alias1 (que no arquivo /etc/odbc.ini aponta para um SQL Server) com um usuário e senha. A conexão foi bem-sucedida e fizemos um select simples de uma tabela qualquer que tinha 2094 linhas. Como tudo funciona, demos o quit para sair.

Agora vamos testar a conexão ao Sybase, usando o DSN alias2:

 # isql alias2 usuario senha -v
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> select count(*) from tabela;
+------------+
| count(*)   |
+------------+
| 347342     |
+------------+
SQLRowCount returns 1
1 rows fetched
SQL> quit

Perfeito, tudo funcionando! Nos conectamos ao DSN chamado alias2 (que no arquivo /etc/odbc.ini aponta para um Sybase) com um usuário e senha. A conexão foi bem-sucedida e fizemos um select simples de uma tabela qualquer que tinha 347342 linhas. Como tudo funciona, demos o quit para sair.

5) Ajuste o SELinux

O CentOS 7 traz o SELinux (Security Enhanced Linux) habilitado por padrão e, por causa dessas de segurança, o Apache não pode acessar recursos de rede nem de bancos de dados.

Para configurar o SELinux com as permissões corretas, liberando o Apache para acessar recursos de rede e de banco de dados, temos que ajustar duas propriedades booleanas no SELinux, com os comandos abaixo:

setsebool -P httpd_can_network_connect on
setsebool -P httpd_can_network_connect_db on

6) Configure o acesso via PHP

A configuração do PHP é simples: basicamente é definir as conexões aos bancos de dados em um arquivo .php, via PDO ou via odbc_connect.

O seguinte arquivo teste.php testa a conexão ao SQL Server via PDO e ao Sybase via odbc_connect:

<?php

 $ip = "ip_do_servidor_sqlserver";
 $porta = "porta_do_servidor";
 $banco = "nome_do_banco";
 $usuario = "usuario";
 $senha = "senha";

 $conexao1 = new PDO("odbc:Driver=FreeTDS; Server=$ip; Port=$porta; Database=$banco; UID=$usuario; PWD=$senha;");
 if (! $conexao1 ) {
 print '<h3>Não foi possível conectar ao MS SQL-Server.</h3>';
 } else {
 print '<h3>Conexão ao MS SQL-Server, via PDO, concluída com sucesso!</h3>';
 }

?>

<?php

 $banco = "alias2";
 $usuario = "usuario";
 $senha = "senha";

 $conexao2 = odbc_connect("Driver=FreeTDS;DSN=$banco", $usuario, $senha );
 if (! $conexao2 ) {
 print '<h3>Não foi possível conectar ao Sybase.</h3>';
 } else {
 print '<h3>Conexão ao Sybase, via odbc_connect, concluída com sucesso!</h3>';
 odbc_close($conexao2);
 }

?>

Como usamos diretamente o PDO sem especificar um DSN para acessar o SQL Server, tivemos que especificar IP, porta, etc. Poderíamos ter feito a conexão com um DSN também, ficaria assim (a variável $dsn deve apontar para o alias do DSN do SQL Server definido em /etc/odbc.ini):

$conexao1 = new PDO("odbc:Driver=FreeTDS;DSN=$dsn", $usuario, $senha);

Para acessar o Sybase usamos o DSN configurado em /etc/odbci.ini, portanto tivemos que usar o alias configurado nesse arquivo.

Se tudo correu bem você verá em seu browser duas mensagens de conexões concluídas, uma para o SQL Server e a outra para o Sybase.

Você pode acessar tanto o SQL Server quanto o Sybase pela PDO ou pelo odbc_connect. Qual é melhor? Não sei, não sou desenvolvedor PHP…

7) Busque ajuda

Se tudo está dando errado, busque documentação nesses sites:

Conexão PHP com o PostgreSQL (e o MySQL) no CentOS 7

Após a instalação do PHP, PostgreSQL e MySQL no CentOS 7, ao tentar fazer um simples teste de conexão do PHP com o PostgreSQL, estava recebendo a seguinte mensagem de erro:

Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running on host “localhost” (127.0.0.1) and accepting TCP/IP connections on port 5432?

O código de teste foi o seguinte:

<?php

 $casa = "localhost";
 $banco = "nome_do_banco";
 $porta = 5432;
 $usuario = "nome_do_usuario";
 $senha = "senha_do_usuario";

 $conexao = pg_connect("host=$casa dbname=$banco port=$porta user=$usuario password=$senha");

 if (! $conexao ) {
 print "<h3>Não foi possível conectar ao PostgreSQL.</h3><br />";
 pg_errormessage();
 } else {
 pg_close($conexao);
 print "<h3>Conexão OK.</h3>";
 }

?>

Eu já tinha ajustado as configurações do pg_hba.conf e postgresql.conf e, mesmo assim, o PHP não conseguia estabelecer uma conexão com o PostgreSQL. Por segurança, chequei as regras do firewall e estavam todas corretas também.

Aí me lembrei: o SELinux! Será que o SELinux estaria bloqueando por padrão as conexões ao banco de dados? Bem, o comando abaixo (como root) retorna as configurações do SELinux para os servidores web:

# getsebool -a | grep httpd
httpd_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_connect_ftp --> off
httpd_can_connect_ldap --> off
httpd_can_connect_mythtv --> off
httpd_can_connect_zabbix --> off
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> off
httpd_dbus_sssd --> off
httpd_dontaudit_search_dirs --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_graceful_shutdown --> on
httpd_manage_ipa --> off
httpd_mod_auth_ntlm_winbind --> off
httpd_mod_auth_pam --> off
httpd_read_user_content --> off
httpd_run_preupgrade --> off
httpd_run_stickshift --> off
httpd_serve_cobbler_files --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_sys_script_anon_write --> off
httpd_tmp_exec --> off
httpd_tty_comm --> off
httpd_unified --> off
httpd_use_cifs --> off
httpd_use_fusefs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
httpd_use_openstack --> off
httpd_use_sasl --> off
httpd_verify_dns --> off

Pronto, identificamos o problema! A propriedade httpd_can_network_connect_db está em “off” (e a httpd_can_network_connect também) e o SELinux está impedindo a conexão do PHP com o PostgreSQL. Para permitir que o SELinux deixe o PHP se conectar ao PostgreSQL (e ao MySQL), faça o seguinte (como root):

setsebool -P httpd_can_network_connect_db on
setsebool -P httpd_can_network_connect on

Agora o Apache/PHP já consegue se conectar aos bancos de dados!

Instalar Tcl no CentOS 7

Apesar de pouco freqüente, de vez em quando eu utilizo a Tcl para criar e rodar alguns scripts de linha de comando em servidores linux e também, de vez em quando, escrevo algumas funções para o PostgreSQL utilizando a linguagem procedural PL/Tcl.

A versão da Tcl que vem por padrão no CentOS 7.1 é a Tcl 8.5.13. Sou adepto de sempre usar os pacotes disponíveis nas distribuições linux, não instalando nada por conta própria, mas a Tcl (e o PostgreSQL) são exceções: eu sempre baixo os fontes e compilo as versões mais novas.

Assim, para instalar a última versão disponível da Tcl, a 8.6.4, faça o seguinte:

  1. No site da Tcl/Tk (http://www.tcl.tk) baixe o fonte da última versão (hoje em dia é a 8.6.4, procure pelo arquivo “tcl8.6.4-src.tar.gz”), e salve no diretório /usr/local/src.
  2. Descompacte o códio fonte e vá para o diretório /usr/local/src/tcl8.6.4/unix.
  3. Execute o seguinte comando configure:
    ./configure --prefix=/usr/local/lib/tcl8.6.4 --enable-threads --enable-64bit
  4. Se o comando configure não retornar nenhum erro, execute o comando make.
  5. Se o comando make não retornar nenhum erro, execute o comando make test. Se os testes de compilação foram concluídos com sucesso, você verá a seguinte mensagem:
    Tests ended at Wed Sep 23 22:28:32 BRT 2015
    all.tcl: Total 116     Passed 116     Skipped 0     Failed 0
  6. Agora execute o make install. A Tcl será instalada no diretório /usr/local/lib/tcl8.6.4.
  7. Crie os seguintes links simbólicos (digite cada comando em uma única linha!):
    ln -s /usr/local/lib/tcl8.6.4/bin/tclsh8.6 /usr/local/lib/tcl8.6.4/bin/tclsh
    
    ln -s /usr/local/lib/tcl8.6.4/bin/tclsh8.6 /usr/local/bin/tclsh
  8. Edite o arquivo .bashrc dos usuários que utilizarão a Tcl e altere a variável:
    export LD_LIBRARY_PATH=/usr/local/lib/tcl8.6.4/lib:$LD_LIBRARY_PATH
  9. Por fim, teste se a Tcl está instalada e se é thread-safe (tem que retornar 1):
    [usuario@servidor ~]$ tclsh
    % info exists tcl_platform(threaded)
    1
    % exit

Agora você já tem a versão mais nova da Tcl instalada, compilada para 64 bits e thread-safe.