Como exportar um dump de uma base Oracle com o Data Pump

Um dump de um banco de dados Oracle é simplesmente uma cópia “lógica” do banco de dados, ou seja, da estrutura de objetos do banco e de comandos para a criação dessas estruturas e do insert dos dados.

Um dump não é, por si mesmo, a melhor e mais segura estratégia de backup mas é um importante complemento para suas rotinas de backup.

Para usar o Oracle Data Pump para exportar um dump do banco de dados, inicialmente é preciso definir um diretório onde o dump será salvo. Esse diretório é criado por um usuário com privilégias de SYSDBA. Posteriormente damos permissão de acesso ao diretório para que outru usuário, por exemplo o SYSTEM, possa gerar o dump.

Vamos criar o diretório, nomeando-o de diretorio_datapump, e vamos dar permissões para o usuário SYSTEM. Acesse o SQL*Plus e execute os seguintes comandos:

usuario@servidor:~> sqlplus / as sysdba

SQL> create or replace directory diretorio_datapump
  2  as '/u05/dpump';

Directory created.

SQL> grant read, write
  2  on directory diretorio_datapump
  3  to system;

Grant succeeded.

Para realizar o dump full do banco de dados, basta usar o comando expdb (export usando data pump). A sintaxe é um pouco esquisita (principalmente o flashback_time) e você deve digitar exatamente como está abaixo, incluindo as contra-barras, as aspas simples e aspas duplas:

usuario@servidor:~> expdp userid=system full=y directory=diretorio_datapump dumpfile=backup.dpump logfile=backup.dpump.log flashback_time=\"to_timestamp\(to_char\(sysdate,\'yyyy-mm-dd hh24:mi:ss\'\),\'yyyy-mm-dd hh24:mi:ss\'\)\"

A senha do usuário SYSTEM será solicitada e o processo se iniciará. O dump será gravado no diretório “diretorio_datapump” que configuramos anteriormente, juntamente com o arquivo de log.

Se tudo correu bem você verá uma mensagem parecida com a seguinte:

Dump file set for SYSTEM.SYS_EXPORT_FULL_01 is:
 /u05/dpump/backup.dpump
Job "SYSTEM"."SYS_EXPORT_FULL_01" successfully completed at Tue Dec 8 17:26:26 2015 elapsed 0 00:02:46

Se quiser, use esse comando em um script e automatize o dump diariamente. Tenha em mente que dependendo do tamanho do banco de dados, como um banco de muitos terabytes, um dump não é prático. Mas se seu banco for de tamanho razoável, o dump é um ótimo acompanhante para sua rotina de backup.

Autoridade Certificadora (Certificate Authority – CA) Pessoal/Empresarial com o OpenSSL: parte 1

Se você administra uma rede de servidores com acesso externo como por exemplo servidores web, servidores de bancos de dados, servidores de diretório, servidores de e-mail ou outros, com certeza lidará com certificados SSL/TLS para garantir a comunicação segura entre os servidores e os clientes (e, talvez, garantir a autenticação dos cientes também).

O modo oficial pelo qual você consegue um certificado válido na internet é um processo de 6 etapas:

  1. Gerar um par de chaves pública/privada (Private Key e Public Key) para seu servidor ou serviço;
  2. Usar essa chave para gerar um CSR (Certificate Signing Request) com as informações de seu servidor;
  3. Enviar esse CSR para uma Certificate Authority (CA) – autoridade de certificação – reconhecida, como a CertSign, Tawthe, Comodo ou outra.
  4. A CA validará o CSR para garantir que você é realmente o dono do servidor e que as informações estão corretas e, estando tudo certo, a CA utilizará as informações constantes em seu CSR para gerar um certificado SSL/TLS que garante a autenticidade de seu servidor, assinando esse certificado.
  5. A CA então enviará para você o certificado assinado do seu servidor, bem como o certificado da própria CA.
  6. Você instalará o seu certificado e o certificado da CA em seu servidor.

Entretanto, em algumas situações, um certificado válido assinado por uma CA reconhecido é caro e nem sempre necessário. Ambientes de testes, intranets, ou acessos administrativos à bancos de dados podem muito bem serem protegidos por certificados SSL/TLS gerados por você mesmo, ou seja: você pode criar sua própria CA para uso pessoal ou empresarial!

Uma vez criada, sua CA pessoal/empresarial pode ser utilizada para gerar e assinar certificados de servidor ou de usuários para uso imediato em seus servidores online.

Este texto mostrará como utilizar o OpenSSL e suas ferramentas de linha de comando para criar sua CA pessoal, gerar chaves, CSR e certificados, além de outras tarefas administrativas que uma CA realiza rotineiramente.

A vantagem de usar o OpenSSL é que ele é o padrão mundial para a implementação de uma infraestrutura de chaves (PKI: public key infrastructure) e fornece um conjunto de ferramentas para implementar e gerenciar certificados.

A desvantagem de usar o OpenSSL é que ele não tem uma interface gráfica, todos os seus comandos são feitos no shell do linux e assim temos que decorar ou lembrar de vários comandos, opções, alternativas e modificadores.

Essa desvantagem pode ser, na realidade, uma vantagem já que qualquer computador recente com linux já trará o OpenSSL instalado, mesmo que não tenha uma interface gráfica habilitada (como é o caso da maioria dos servidores).

Obviamente você não utilizará a linha de comando do OpenSSL para criar uma CA real, que gerencia milhões de certificados de milhões de clientes. Isso é impossível e impraticável na linha de comando e para isso existem softwares comerciais que custam alguns milhares de dólares (também existem alternativas open source, como o EJBCA). Mas o OpenSSL e a linha de comando são mais do que adequados para nossas necessidades.

Um aviso antes de começar! Não sou especialista em OpenSSL: aprendi somente o básico para implantar uma CA pessoal/empresarial e poder administrar meus próprios certificados, e tudo o que aprendi foi baseado nas seguintes fontes (leia os originais se quiser maiores informações e explicações técnicas detalhadas):

1) O OpenSSL está instalado em meu sistema?

Se você usa linux, tenho certeza que sim. Para seguir este tutorial você precisa da versão 1.0.1 do OpenSSL. Para descobrir qual a versão instalada em seu sistema digite o comando:

$ openssl version
OpenSSL 1.0.1f 6 Jan 2014

Se, por um mistério qualquer seu linux não tiver o OpenSSL instalado, utilize o gerenciador de pacotes de sua distribuição para instalar a versão 1.0.1 (ou compile o código fonte).

2) Como funcionará nossa CA?

Nossa CA pessoal/empresarial será dividida, na realidade, em duas autoridades certificadoras:

  • Uma CA raiz, a Root CA, que é intrinsecamente válida e confiável; e
  • Uma CA filha, a Sub CA, que é válida pois foi validada pela Root CA.

A função da Root CA é somente validar e criar a Sub CA, sendo esta a responsável por realmente emitir os certificados finais para usuários e servidores.

Isso é assim por questões de segurança: a Root CA deve ficar protegida, off-line, sendo utilizada somente para gerar a Sub CA.

A Root CA não assina certificados de clientes ou servidores, só de outras Subs CA.

A Sub CA gerará e assinará os certificados de servidores e clientes, em nome da Root CA, e será tecnicamente restrita, ou seja, só poderá gerar e assinar certificados para domínios e hostnames permitidos.

O maior desafio em gerir sua própria CA não é gerar a CA em si, é manter a Root CA e a Sub CA protegidas, com chaves privadas em segurança, principalmente da Root CA. Se um hacker obtém a chave privada de sua Sub CA, a Root CA ainda pode ser utilizada para revogar todos os certificados emitidos pela Sub CA e gerar uma nova Sub CA para emissão de novos certificados. Já se o hacker conseguir a chave privada de sua Root CA, toda a cadeia de certificação torna-se comprometida!

Isto posto, iniciaremos a criação de nossa CA.

3) Preparação da estrutura de diretórios

Vamos iniciar criando um conjunto de diretórios para nossa CA, em nosso diretório HOME, incluindo 3 arquivos especiais (index, serial e crlnumber). Execute os comandos abaixo:

cd $HOME

mkdir CA
cd CA

mkdir root-ca
cd root-ca
mkdir certs crl csr db newcerts private
chmod 700 private

touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

cd ..

mkdir sub-ca
cd sub-ca
mkdir certs crl csr db newcerts private
chmod 700 private

touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

Os comandos acima criaram a seguinte árvore de diretórios:

$HOME/CA
       |> root-ca
       |        |> certs
       |        |> crl
       |        |> csr
       |        |> db
       |        |> newcerts
       |        |> private
       |> sub-ca
       |        |> certs
       |        |> crl
       |        |> csr
       |        |> db
       |        |> newcerts
       |        |> private

A função dos diretórios é a seguinte:

  • certs e newcerts: armazenar os certificados gerados
  • crl: armazenar a lista de certificados revogados
  • csr: armazenar as solicitações de assinatura de certificados (CSR)
  • db: armazenar o banco de dados de certificados (em formato texto)
  • private: armazenar as chaves privadas

Além disso, dentro do diretório db foram criados 3 arquivos especiais:

  • index: armazenará o banco de dados de certificados
  • serial: armazenará o número serial dos certificados
  • crlnumber: armazenará o número da lista de certificados revogados

Obviamente a estrutura acima NÃO É SEGURA pois estamos criando a Root CA no mesmo computador da Sub CA. Idealmente a Root CA deveria ficar em um computador offline, mas para nosso tutorial admitiremos essa falha em nome do aprendizado.

4) Criação da Root CA

Antes de realmente usar os comandos OpenSSL para criarmos a Root CA temos que criar um arquivo de configuração que dirá ao OpenSSL exatamente como a Root CA deve ser criada, que padrões utilizar, que extensões habilitar e etc.

Faça o download do arquivo root-ca.conf de modelo e salve dentro do diretório $HOME/CA/root-ca. Uma descrição detalhada das opções deste arquivo está fora do escopo deste texto mas a maioria das configurações é auto-explicativa e vários comentários indicam a utilidade de cada configuração.

LEIA e MODIFIQUE o arquivo $HOME/CA/root-ca/root-ca.conf conforme suas necessidades! Não prossiga sem antes modificar o arquivo e incluir suas informações pessoais ou de sua empresa. Basta ler o arquivo e os comentários e você saberá quais linhas alterar.

Depois que você modificou o arquivo de configuração, vamos à criação da Root CA.

Em primeiro lugar, temos que criar um chave privada para nossa CA, protegendo essa chave com uma senha forte:

cd $HOME/CA/root-ca

openssl genrsa -aes256 -out private/root-ca.key 4096
Generating RSA private key, 4096 bit long modulus
........................................................................................++
..................................................................................++
e is 65537 (0x10001)
Enter pass phrase for private/root-ca.key: digite_a_senha
Verifying - Enter pass phrase for private/root-ca.key: digite_a_senha

chmod 400 private/root-ca.key

Com isso acabamos de criar nossa chave no arquivo $HOME/CA/root-ca/private/root-ca.key, com permissões de acesso restritas.

Agora vamos usar essa chave privada para gerar um CSR para nosso Root CA. Repare que informamos ao OpenSSL o arquivo de configuração que criamos, indicando qual chave usar e onde armazenar o CSR gerado; note também que os padrões de país, estado, cidade, etc., que o OpenSSL apresenta são configurados no aquivo root-ca.conf que você modificou:

cd $HOME/CA/root-ca

openssl req -new -config root-ca.conf -key private/root-ca.key -out csr/root-ca.csr
Enter pass phrase for private/root-ca.key: senha
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
País (codigo de 2 letras) [BR]:
Estado [Espirito Santo]:
Cidade [Vila Velha]:
Nome da Empresa [Empresa Exemplo Ltda]:
Unidade/Departamento da Empresa [Tecnologia da Informacao]:
Identificador único do certificado (Common Name) [Root CA]:
E-mail [admin@exemplo.com.br]:

Agora já temos a chave e o CSR e só falta usar o OpenSSL para gerar um certificado auto-assinado para a Root CA (claro, se esta é a CA raiz, não existe ninguém acima dela para assinar o certificado para nós, ele obrigatoriamente tem que ser auto-assinado).

Note que informamos ao OpenSSL o arquivo de configuração, dizendo explicitamente qual seção do arquivo será considerada para a geração do Root CA (root_ca):

cd $HOME/CA/root-ca

openssl ca -selfsign -config root-ca.conf -extensions root_ca -in csr/root-ca.csr -notext -out certs/root-ca.crt
Using configuration from root-ca.conf
Enter pass phrase for ./private/root-ca.key: senha
Check that the request matches the signature
Signature ok
Certificate Details:
   Serial Number:
      8a:23:e3:c9:5b:20:0c:4b:0e:c0:a8:83:91:e3:c9:c0
   Validity
      Not Before: Oct 27 01:33:33 2015 GMT
      Not After : Oct 22 01:33:33 2035 GMT
   Subject:
      countryName = BR
      stateOrProvinceName = Espirito Santo
      localityName = Vila Velha
      organizationName = Empresa Exemplo Ltda
      organizationalUnitName = Tecnologia da Informacao
      commonName = Root CA
      emailAddress = admin@exemplo.com.br
   X509v3 extensions:
      X509v3 Basic Constraints: critical
      CA:TRUE
   X509v3 Key Usage: critical
      Certificate Sign, CRL Sign
   X509v3 Subject Key Identifier:
      59:36:03:FD:9A:D2:7F:22:A9:1B:8E:D9:24:0A:1B:D2:3C:3A:BA:85
Certificate is to be certified until Oct 22 01:33:33 2035 GMT (7300 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated

Note que o certificado foi salvo no arquivo certs/root-ca.crt e uma cópia foi armazenada no diretório newcerts.

Para verificar as informações do novo certificado:

openssl x509 -noout -text -in certs/root-ca.crt
Certificate:
   Data:
      Version: 3 (0x2)
      Serial Number:
         8a:23:e3:c9:5b:20:0c:4b:0e:c0:a8:83:91:e3:c9:c0
   Signature Algorithm: sha384WithRSAEncryption
      Issuer: C=BR, ST=Espirito Santo, L=Vila Velha, O=Empresa Exemplo Ltda, OU=Tecnologia da Informacao, CN=Root CA/emailAddress=admin@exemplo.com.br
   Validity
      Not Before: Oct 27 01:33:33 2015 GMT
      Not After : Oct 22 01:33:33 2035 GMT
   Subject: C=BR, ST=Espirito Santo, L=Vila Velha, O=Empresa Exemplo Ltda, OU=Tecnologia da Informacao, CN=Root CA/emailAddress=admin@exemplo.com.br
   Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (4096 bit)
      Modulus:
      (várias linhas omitidas aqui)
   Exponent: 65537 (0x10001)
   X509v3 extensions:
      X509v3 Basic Constraints: critical
      CA:TRUE
   X509v3 Key Usage: critical
      Certificate Sign, CRL Sign
   X509v3 Subject Key Identifier:
59:36:03:FD:9A:D2:7F:22:A9:1B:8E:D9:24:0A:1B:D2:3C:3A:BA:85
Signature Algorithm: sha384WithRSAEncryption
      (várias linhas omitidas aqui)

Repare que o certificado foi criado conforme indicamos no arquivo de configuração: 20 anos de validade, com as informações da empresa, chave de 4096 bits, com extensões de CA e servindo apenas para assinar certificados e CRLs. Nesse momento já temos nossa Root CA pronta para o trabalho!

5) Criação da Sub CA

A nossa Sub CA é uma autoridade de certificação intermediária entre a Root CA e os nossos servidores, e serve para gerar e assinar certificados em nome da Root CA.

Como já visto usamos uma CA intermediária por segurança, para garantir que a Root CA seja mantida offline o maior tempo possível. Se a Sub CA é comprometida, a Root CA pode revogar os certificados emitidos pela Sub CA e criar um novo par criptográfico.

A CA intermediária pode ter qualquer nome, aqui escolhi Sub CA para indicar que está abaixo da Root CA. Se você não gostar do nome, pode alterar no arquivo de configuração.

Da mesma forma que na Root CA, antes de realmente usar os comandos OpenSSL para criarmos a Sub CA temos que criar um arquivo de configuração que dirá ao OpenSSL exatamente como a Sub CA deve ser criada, que padrões utilizar, que extensões habilitar e etc.

Faça o download do arquivo sub-ca.conf de modelo e salve dentro do diretório $HOME/CA/sub-ca. Uma descrição detalhada das opções deste arquivo está fora do escopo deste texto mas a maioria das configurações é auto-explicativa e vários comentários indicam a utilidade de cada configuração.

LEIA e MODIFIQUE o arquivo $HOME/CA/sub-ca/sub-ca.conf conforme suas necessidades! Não prossiga sem antes modificar o arquivo e incluir suas informações pessoais ou de sua empresa. Basta ler o arquivo e os comentários e você saberá quais linhas alterar.

Depois que você modificou o arquivo de configuração, vamos à criação da Sub CA.

Em primeiro lugar, temos que criar um chave privada para nossa Sub CA:

cd $HOME/CA/sub-ca

openssl genrsa -aes256 -out private/sub-ca.key 4096
Generating RSA private key, 4096 bit long modulus
..............................................................................................................................................................................++
........................................++
e is 65537 (0x10001)
Enter pass phrase for private/sub-ca.key: digite_a_senha
Verifying - Enter pass phrase for private/sub-ca.key: digite_a_senha

Agora vamos usar essa chave privada para gerar um CSR para nosso Sub CA. Repare que estamos informando ao OpenSSL o arquivo de configuração que criamos, indicando qual chave usar e onde armazenar o CSR gerado; note também que os padrões de país, estado, cidade, etc., que o OpenSSL apresenta são configurados no arquivo sub-ca.conf que você modificou:

cd $HOME/CA/sub-ca

openssl req -config sub-ca.conf -new -key private/sub-ca.key -out csr/sub-ca.csr
Enter pass phrase for private/sub-ca.key: senha
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
País (codigo de 2 letras) [BR]:
Estado [Espirito Santo]:
Cidade [Vila Velha]:
Nome da Empresa [Empresa Exemplo Ltda]:
Unidade/Departamento da Empresa [Tecnologia da Informacao]:
Identificador único do certificado (Common Name) [Sub CA]:
E-mail [admin@exemplo.com.br]:

Agora já temos a chave e o CSR, só falta gerarmos o certificado para a Sub CA. Mas cuidado, pois agora vem a parte da pegadinha, pois a Sub CA não pode gerar um certificado auto-assinado!

Nossa Sub CA gerou um CSR solicitando que alguém gere um certificado para ela. Só que ao contrário da Root CA, que como é a autoridade raiz é intrinsecamente confiável, a Sub CA não é intrinsicamente confiável: a Sub CA precisa que alguém diga que a Sub CA é confiável e que assine um certificado para ela.

Quem pode fazer isso? A Root CA que criamos!

Então nós vamos “enviar” o CSR da Sub CA para a Root CA e a Root CA vai assinar e gerar um certificado para a Sub CA, atestando que a Sub CA em questão é válida e confiável:

cd $HOME/CA/sub-ca
cp csr/sub-ca.csr ../root-ca/csr/

Agora que você já enviou o CSR para uma autoridade certificadora competente (a Root CA), a Root CA vai gerar e assinar o certificado da Sub CA. Note que os comandos a seguir devem ser executados pela Root CA. Repare também que usamos o arquivo de configuração da Root CA (root-ca.conf), mas especificamos explicitamente a extensão sub_ca, que indica a seção no arquivo root-ca.conf onde definimos os parâmetros para as Sub CA criados a partir da Root CA. Note também que a validade de um certificado gerado pela Root CA é de 20 anos, conforme configurado no arquivo root-ca.conf, mas vamos diminuir a validade do certificado da Sub CA para 10 anos:

cd $HOME/CA/root-ca

openssl ca -config root-ca.conf -extensions sub_ca -days 3650 -in csr/sub-ca.csr -notext -out certs/sub-ca.crt
Using configuration from root-ca.conf
Enter pass phrase for ./private/root-ca.key: senha
Check that the request matches the signature
Signature ok
Certificate Details:
   Serial Number:
      8a:23:e3:c9:5b:20:0c:4b:0e:c0:a8:83:91:e3:c9:c1
   Validity
      Not Before: Oct 27 02:26:58 2015 GMT
      Not After : Oct 24 02:26:58 2025 GMT
   Subject:
      countryName = BR
      stateOrProvinceName = Espirito Santo
      localityName = Vila Velha
      organizationName = Empresa Exemplo Ltda
      organizationalUnitName = Tecnologia da Informacao
      commonName = Sub CA
      emailAddress = admin@exemplo.com.br
   X509v3 extensions:
      Authority Information Access:
         CA Issuers - URI:http://root-ca.exemplo.com.br/root-ca.crt
         OCSP - URI:http://ocsp.root-ca.exemplo.com.br
   X509v3 Authority Key Identifier:
     keyid:59:36:03:FD:9A:D2:7F:22:A9:1B:8E:D9:24:0A:1B:D2:3C:3A:BA:85
   X509v3 Basic Constraints: critical
      CA:TRUE, pathlen:0
   X509v3 CRL Distribution Points:
   Full Name:
      URI:http://root-ca.exemplo.com.br/root-ca.crl
   X509v3 Extended Key Usage:
      TLS Web Client Authentication, TLS Web Server Authentication
   X509v3 Key Usage: critical
      Certificate Sign, CRL Sign
   X509v3 Name Constraints:
   Permitted:
      DNS:exemplo.com.br
      DNS:exemplo.org.br
   Excluded:
      IP:0.0.0.0/0.0.0.0
      IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
   X509v3 Subject Key Identifier:
      E9:1B:BC:B0:E8:C0:E6:37:0B:A9:AF:52:F5:EF:71:12:09:66:9C:B8
   Certificate is to be certified until Oct 24 02:26:58 2025 GMT (3650 days)

Sign the certificate? [y/n]: y

1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated

Note que o certificado foi salvo no arquivo certs/sub-ca.crt e uma cópia foi armazenada no diretório newcerts.

Para verificar as informações do novo certificado:

openssl x509 -noout -text -in certs/sub-ca.crt
Certificate:
  Data:
    Version: 3 (0x2)
    Serial Number:
      8a:23:e3:c9:5b:20:0c:4b:0e:c0:a8:83:91:e3:c9:c1
  Signature Algorithm: sha384WithRSAEncryption
    Issuer: C=BR, ST=Espirito Santo, L=Vila Velha, O=Empresa Exemplo Ltda, OU=Tecnologia da Informacao, CN=Root CA/emailAddress=admin@exemplo.com.br
  Validity
    Not Before: Oct 27 02:26:58 2015 GMT
    Not After : Oct 24 02:26:58 2025 GMT
  Subject: C=BR, ST=Espirito Santo, L=Vila Velha, O=Empresa Exemplo Ltda, OU=Tecnologia da Informacao, CN=Sub CA/emailAddress=admin@exemplo.com.br
  Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    Public-Key: (4096 bit)
  Modulus:
    (várias linhas omitidas aqui)
  Exponent: 65537 (0x10001)
  X509v3 extensions:
    Authority Information Access:
      CA Issuers - URI:http://root-ca.exemplo.com.br/root-ca.crt
      OCSP - URI:http://ocsp.root-ca.exemplo.com.br
  X509v3 Authority Key Identifier:
    keyid:59:36:03:FD:9A:D2:7F:22:A9:1B:8E:D9:24:0A:1B:D2:3C:3A:BA:85
  X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0
  X509v3 CRL Distribution Points:
    Full Name:
      URI:http://root-ca.exemplo.com.br/root-ca.crl
  X509v3 Extended Key Usage:
    TLS Web Client Authentication, TLS Web Server Authentication
  X509v3 Key Usage: critical
    Certificate Sign, CRL Sign
  X509v3 Name Constraints:
  Permitted:
    DNS:exemplo.com.br
    DNS:exemplo.org.br
  Excluded:
    IP:0.0.0.0/0.0.0.0
    IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
  X509v3 Subject Key Identifier:
    E9:1B:BC:B0:E8:C0:E6:37:0B:A9:AF:52:F5:EF:71:12:09:66:9C:B8
  Signature Algorithm: sha384WithRSAEncryption
    (várias linhas omitidas aqui)

Repare que o certificado foi criado conforme indicamos no arquivo de configuração e nos parâmetros do comando openssl: 10 anos de validade, com as informações da empresa, chave de 4096 bits, com extensões de CA e servindo apenas para assinar certificados e CRLs.

Agora a Root CA precisa “enviar” o certificado assinado para a Sub CA, incluindo o próprio certificado da Root CA para que a Sub CA possa validar o seu certificado:

cd $HOME/CA/root-ca

cp certs/sub-ca.crt ../sub-ca/certs/

cp certs/root-ca.crt ../sub-ca/certs/

Nesse momento a Sub CA acabou de receber de volta seu certificado assinado pela Root CA, bem como o certificado da própria Root CA (que servirá para validar os certificados assinados por essa Root CA).

Como a Sub CA pode checar se seu certificado é válido, ou seja, se realmente está assinado e validado por uma autoridade certificadora confiável (nossa Root CA)? Checando o certificado da Sub CA contra o certificado da Root CA:

cd $HOME/CA/sub-ca

openssl verify -CAfile certs/root-ca.crt certs/sub-ca.crt
certs/sub-ca.crt: OK

O “OK” acima indica que o certificado da Sub CA foi corretamente validado utilizando-se o certificado da Root CA, ou seja, o certificado da Sub CA é válido e assinado pela Root CA.

A Sub CA precisa ainda realizar uma última tarefa antes de poder emitir certificados para servidores e clientes: gerar um certificado com a cadeia de certificação, ou seja, gerar um arquivo que contenha o certificado da própria Sub CA, juntamente com o certificado da Root CA.

Essa cadeia de certificação é enviada aos clientes (servidores ou usuários) que tenham certificados gerados pela Sub CA, de modo que os próprios clientes (servidores ou usuários) também possam validar seus próprios certificados e ter certeza de que a SubCA e a Root CA são válidas.

Quando os clientes (servidores ou usuários) receberem seus certificados gerados pela Sub CA eles podem validá-los de modo semelhante ao que foi feito quando a Root CA enviou seu certificado para a Sub CA, só que nesse caso a Sub CA também deve enviar seu certificado para os clientes agregando, além do próprio certificado, o certificado da Root CA em uma “cadeia de certificação”. Para fazer isso:

cd $HOME/CA/sub-ca/certs

cat sub-ca.crt root-ca.crt > ca-chain.crt

6) Criação de certificados para servidores

Certificados para servidores são utilizados para garantir a conexão segura, criptografada, entre aplicações clientes e seus servidores como, por exemplo, um servidor web, um servidor de e-mails, um servidor de banco de dados, etc.

Os certificados para os servidores geralmente têm validade de 1 ano e tamanho de chaves de 2048 bits.

Além disso, as chaves privadas dos certificados para servidores são geradas sem senha para evitar que o reinício de algum serviço obrigue a presença física de um administrador de sistemas para informar a senha do certificado. Por exemplo: se seu servidor web utiliza uma chave privada com senha, toda vez que você reiniciar o servidor, alguém precisará informar, manualmente, a senha da chave privada do certificado caso contrário o servidor web não será inicializado. Assim, por comodidade, as chaves privadas dos certificados de servidores são geralmente criadas sem senha e salvas em um diretório restrito com permissões mais restritas ainda (400).

Uma CA real não cria as chaves nem o CSR para o servidor. O terceiro interessado em proteger a comunicação com seu servidor é que tem que gerar as chaves e o CSR, enviar esse CSR para a CA oficial e, somente então, a CA oficial gera e assina um certificado para o servidor.

Como nós somos nossa própria CA, usaremos a Sub CA para gerar as chaves, o CSR e o certificado para o servidor web02.exemplo.com.br. Inicialmente, vamos gerar a chave privada para o servidor, sem senha, com tamanho de 2048 bits:

cd $HOME/CA/sub-ca

openssl genrsa -out private/web02.exemplo.com.br.key 2048
Generating RSA private key, 2048 bit long modulus
...............+++
................+++
e is 65537 (0x10001)

chmod 400 private/web02.exemplo.com.br.key

Agora vamos gerar um CSR com as informações corretas para nosso servidor.

A configuração mais importante é o Common Name, que deve apontar para o hostname totalmente qualificado, válido na internet, de seu servidor ou serviço (pode ser um registro do tipo A, MX ou CNAME, mas deve obrigatoriamente ser resolvido para um IP). Repare que usamos o arquivo de configuração do nosso próprio Sub CA e a chave privada gerada anteriormente, e que os padrões para o país, estado, cidade, etc. foram configurados no arquivo sub-ca.conf (ATENÇÃO: altere o common name para o hostname completo do servidor!):

cd $HOME/CA/sub-ca

openssl req -new -config sub-ca.conf -key private/web02.exemplo.com.br.key -out csr/web02.exemplo.com.br.csr
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
País (codigo de 2 letras) [BR]:
Estado [Espirito Santo]:
Cidade [Vila Velha]:
Nome da Empresa [Empresa Exemplo Ltda]:
Unidade/Departamento da Empresa [Tecnologia da Informacao]:
Identificador único do certificado (Common Name) [Sub CA]:web02.exemplo.com.br
E-mail [admin@exemplo.com.br]:

Agora usaremos a Sub CA para gerar e assinar o certificado do servidor. Note que o arquivo de configuração utilizado é o da Sub CA, mas especificamente informamos a extensão server_cert que diz para o OpenSSL gerar um certificado de servidor:

cd $HOME/CA/sub-ca

openssl ca -config sub-ca.conf -extensions server_cert -in csr/web02.exemplo.com.br.csr -notext -out certs/web02.exemplo.com.br.crt
Using configuration from sub-ca.conf
Enter pass phrase for ./private/sub-ca.key: senha
Check that the request matches the signature
Signature ok
Certificate Details:
   Serial Number:
      a1:4f:42:f2:19:75:e5:bb:fc:eb:b8:b4:9c:76:ed:ac
   Validity
      Not Before: Oct 27 18:03:16 2015 GMT
      Not After : Oct 26 18:03:16 2016 GMT
   Subject:
      countryName = BR
      stateOrProvinceName = Espirito Santo
      localityName = Vila Velha
      organizationName = Empresa Exemplo Ltda
      organizationalUnitName = Tecnologia da Informacao
      commonName = web02.exemplo.com.br
      emailAddress = admin@exemplo.com.br
   X509v3 extensions:
      X509v3 Basic Constraints: critical
         CA:FALSE
   Netscape Cert Type:
      SSL Server
   Netscape Comment:
      Certificado Servidor gerado pelo OpenSSL
   X509v3 Subject Key Identifier:
      1A:1A:21:F1:63:79:88:80:EC:28:0E:92:78:C5:EF:60:31:CE:48:EC
   X509v3 Authority Key Identifier:
     keyid:E9:1B:BC:B0:E8:C0:E6:37:0B:A9:AF:52:F5:EF:71:12:09:66:9C:B8
   DirName:/C=BR/ST=Espirito Santo/L=Vila Velha/O=Empresa Exemplo Ltda/OU=Tecnologia da Informacao/CN=Root CA/emailAddress=admin@exemplo.com.br
   serial:8A:23:E3:C9:5B:20:0C:4B:0E:C0:A8:83:91:E3:C9:C1
   Authority Information Access:
      CA Issuers - URI:http://sub-ca.exemplo.com.br/sub-ca.crt
      OCSP - URI:http://ocsp.sub-ca.exemplo.com.br
   X509v3 Key Usage: critical
      Digital Signature, Key Encipherment
   X509v3 Extended Key Usage:
      TLS Web Client Authentication, TLS Web Server Authentication
   X509v3 CRL Distribution Points:
      Full Name:
         URI:http://sub-ca.exemplo.com.br/sub-ca.crl
Certificate is to be certified until Oct 26 18:03:16 2016 GMT (365 days)

Sign the certificate? [y/n]: y

1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated

O certificado foi salvo no arquivo certs/web02.exemplo.com.br.crt e uma cópia foi armazenada no diretório newcerts.

Para verificar as informações do novo certificado (output omitido aqui, é semelhando aos outros já apresentados; estudo o output e repare que o certificado não é um CA, tem validade de 1 ano e é do tipo servidor):

openssl x509 -noout -text -in certs/web02.exemplo.com.br.crt

Para verificar se o certificado está válido, vamos verificá-lo contra a cadeia de certificação:

openssl verify -CAfile certs/ca-chain.crt certs/web02.exemplo.com.br.crt
certs/web02.exemplo.com.br.crt: OK

Como tudo está pronto, só precisamos instalar o certificado no servidor. Para fazer isso você precisará colocar os 3 arquivos abaixo no servidor e ajustar a configuração específica do seu aplicativo (consulte a documentação específica do aplicativo em questão – Apache, PostgreSQL, Zimbra, etc. –, para saber exatamente como configurar o aplicativo para utilizar os arquivos abaixo):

  • certificado do servidor (com a extensão crt)
  • chave privada do certificado (com a extensão key)
  • a cadeia de certificação que inclui os certificados da Root CA e da Sub CA (arquivo ca-chain.crt)

7) Criação de certificados para usuários/clientes

Um outro tipo de certificado que podemos criar é o certificado de usuário/cliente, que é um certificado com objetivo diferente do certificado para servidores.

Enquanto o certificado de servidor tem como objetivo principal criptografar a comunicação entre o software cliente e o software servidor, o certificado cliente tem como objetivo principal confirmar a identidade do usuário para o servidor.

Por exemplo: você já instalou um certificado servidor em um banco de dados e comunicação está segura mas, mesmo assim, o banco de dados só permitirá acesso se o usuário apresentar um certificado de usuário/cliente, assinado por uma CA válida e reconhecida pelo servidor (nossa Sub CA!), que autentique o cliente, ou seja, que garanta que o cliente é quem ele diz que é. Se o cliente não apresentar um certificado válido, o banco de dados não pode autenticar o cliente e assim não permitirá o acesso. Um outro uso comum deste tipo de certificado é a assinatura de mensagens de e-mails dos usuários, garantindo que o remetente do e-mail é quem ele diz ser.

Os certificados de usuários/clientes também têm, geralmente, validade de 1 ano e tamanho de chaves de 2048 bits.

As chaves privadas dos certificados de usuários/clientes podem ser geradas com senha ou sem senha, dependendo da política da empresa ou de sua política pessoal.

Se você tem como garantir que seu certificado de usuário/cliente será sempre mantido em segurança, pode gerar a chave sem senha. Se você não confia nisso, gere a chave com senha mas lembre-se que toda vez que precisar do certificado terá que digitar a senha (o que teoricamente não é problema, visto que esses certificados são utilizados geralmente de forma manual pelo usuário).

De qualquer forma as chaves privadas dos certificados de usuários/clientes são geralmente criadas (com ou sem senha) e salvas em um diretório restrito com permissões mais restritas ainda (400).

Como nós somos nossa própria CA, usaremos nossa Sub CA para gerar as chaves, o CSR e o certificado. É interessante estabelecer um padrão de nome para as chaves/certificados dos usuários, por exemplo o endereço de e-mail corporativo.

Inicialmente, vamos gerar a chave privada para o usuário, COM senha, com tamanho de 2048 bits (se quiser gerar uma chave SEM senha, basta retirar a opção “-aes256” do comando abaixo):

cd $HOME/CA/sub-ca

openssl genrsa -aes256 -out private/abrantes.filho.at.exemplo.com.br.key 2048
Generating RSA private key, 2048 bit long modulus
.................................................+++
.....................+++
e is 65537 (0x10001)
Enter pass phrase for private/abrantes.filho.at.exemplo.com.br.key:
Verifying - Enter pass phrase for private/abrantes.filho.at.exemplo.com.br.key:

chmod 400 private/abrantes.filho.at.exemplo.com.br.key

Agora vamos gerar um CSR com as informações corretas para o certificado de usuário. A configuração mais importante é o Common Name, que tem que ser um identificador único, por exemplo o endereço de e-mail do usuário, ou o nome do usuário. Repare que usamos o arquivo de configuração do nosso próprio Sub CA e a chave privada gerada anteriormente (e novamente os padrões foram configurados no arquivo sub-ca.conf):

cd $HOME/CA/sub-ca

openssl req -new -config sub-ca.conf -key private/abrantes.filho.at.exemplo.com.br.key -out csr/abrantes.filho.at.exemplo.com.br.csr
Enter pass phrase for private/abrantes.filho.at.exemplo.com.br.key: senha
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
País (codigo de 2 letras) [BR]:
Estado [Espirito Santo]:
Cidade [Vila Velha]:
Nome da Empresa [Empresa Exemplo Ltda]:
Unidade/Departamento da Empresa [Tecnologia da Informacao]:
Identificador único do certificado (Common Name) [Sub CA]:abrantes.filho@exemplo.com.br
E-mail [admin@exemplo.com.br]:

Agora usaremos a Sub CA para gerar e assinar o certificado do usuário. Note que o arquivo de configuração utilizado é o da Sub CA, mas especificamente informamos a extensão usr_cert que diz para o OpenSSL gerar um certificado de usuário/cliente:

cd $HOME/CA/sub-ca

openssl ca -config sub-ca.conf -extensions usr_cert -in csr/abrantes.filho.at.exemplo.com.br.csr -notext -out certs/abrantes.filho.at.exemplo.com.br.crt
Using configuration from sub-ca.conf
Enter pass phrase for ./private/sub-ca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
   Serial Number:
      a1:4f:42:f2:19:75:e5:bb:fc:eb:b8:b4:9c:76:ed:ad
   Validity
      Not Before: Oct 27 18:51:13 2015 GMT
      Not After : Oct 26 18:51:13 2016 GMT
   Subject:
      countryName = BR
      stateOrProvinceName = Espirito Santo
      localityName = Vila Velha
      organizationName = Empresa Exemplo Ltda
      organizationalUnitName = Tecnologia da Informacao
      commonName = abrantes.filho@exemplo.com.br
      emailAddress = admin@exemplo.com.br
   X509v3 extensions:
      X509v3 Basic Constraints: critical
         CA:FALSE
   Netscape Cert Type:
      SSL Client, S/MIME
   Netscape Comment:
      Certificado Cliente gerado pelo OpenSSL
   X509v3 Subject Key Identifier:
      E8:DE:CC:E8:17:E0:1A:CD:AB:F5:67:6F:BD:13:98:7B:2D:73:07:D3
   X509v3 Authority Key Identifier:
     keyid:E9:1B:BC:B0:E8:C0:E6:37:0B:A9:AF:52:F5:EF:71:12:09:66:9C:B8
DirName:/C=BR/ST=Espirito Santo/L=Vila Velha/O=Empresa Exemplo Ltda/OU=Tecnologia da Informacao/CN=Root CA/emailAddress=admin@exemplo.com.br
serial:8A:23:E3:C9:5B:20:0C:4B:0E:C0:A8:83:91:E3:C9:C1
   Authority Information Access:
      CA Issuers - URI:http://sub-ca.exemplo.com.br/sub-ca.crt
      OCSP - URI:http://ocsp.sub-ca.exemplo.com.br
   X509v3 Key Usage: critical
      Digital Signature, Non Repudiation, Key Encipherment
   X509v3 Extended Key Usage:
      TLS Web Client Authentication, E-mail Protection
   X509v3 CRL Distribution Points:
      Full Name:
         URI:http://sub-ca.exemplo.com.br/sub-ca.crl
Certificate is to be certified until Oct 26 18:51:13 2016 GMT (365 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

O certificado foi salvo no arquivo certs/abrantes.filho.at.exemplo.com.br.crt e uma cópia foi armazenada no diretório newcerts.

Para verificar as informações do novo certificado (output omitido):

openssl x509 -noout -text -in certs/abrantes.filho.at.exemplo.com.br.crt

Para verificar se o certificado está válido, vamos verificá-lo contra a cadeia de certificação:

openssl verify -CAfile certs/ca-chain.crt certs/abrantes.filho.at.exemplo.com.br.crt
certs/abrantes.filho.at.exemplo.com.br.crt: OK

Como tudo está pronto, precisamos enviar a chave, o certificado e a cadeia de certificação para o usuário, e a cadeia de certificação para o servidor.

Você terá também que configurar sua aplicação/servidor para utilizar a cadeia de certificação para validar os certificados que os usuários apresentam ao tentar acessar o serviço/servidor. Para isso consulte a documentação específica de seu software. Em geral você sempre fará o seguinte:

  • enviar o certificado do usuário para o usuário (com a extensão crt)
  • enviar a chave privada do certificado para o usuário (com a extensão key)
  • enviar a a cadeia de certificação (arquivo ca-chain.crt) para o usuário
  • enviar a cadeia de certificação para o sevidor

8) Finalizando:

Lembre-se que o maior desafio de manter sua própria CA é manter a segurança da Root CA e da Sub CA. Idealmente a Root CA deve ficar em um computador totalmente offline, sendo usada somente para gerar a Sub CA e as listas de revogação de certificados das Sub CA, quando necessário.

Nossa CA já está pronta e configurada para emitir certificados de servidor e de usuários/clientes para nosso uso pessoal ou empresarial, de maneira simples e rápida. Comece a gerar os certificados de que necessita e mão à obra!

Só um último aviso: à medida que você gera e emite certificados, alguns serão perdidos, senhas serão esquecidas ou o prazo de validade expirará. Nesses casos você precisa revogar o certificado e emitir um novo. O processo de revogação de certificados, bem como a geração da CRL (Lista de Certificados Revogados) será mostrado na parte 2 deste texto. Até lá!

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!