Revista Do Linux
 
EDIÇÃO DO MÊS
 CD do Mês

 Capa
 Estudo de Caso
 Entrevista
 Corporativo
 Software
 Desenvolvimento
 Iniciantes
 Hardware
 Distro
 Tutorial
 Segurança
 Sistema
 Banco de Dados
 
 
 
Histórias e Estórias do PostgreSQL
JC Waeny <waeny@firstlinux.net>
 
 
Atualmente, já na versão 7.1.x, o PostgreSQL continua evoluindo através do esforço conjunto de uma comunidade de desenvolvedores espalhados mundo afora. Este artigo dará ênfase para alguns utilitários que acompanham este SGBD, seus esquemas de segurança e rotinas de backup.
 
 
 
UTILITÁRIOS
 
O PostgreSQL possui alguns utilitários para controle e manutenção da base de dados que deverão ser executados apenas pelo administrador do banco, o DBA, ou os usuários por ele autorizados. Esses utilitários incluem a criação de novos usuários, execução de processos para remoção de espaços vazios na base de dados, critérios para verificação do custo de uma query, etc.
 
Embora diversos utilitários existam como programas externos ao SGBD, muitos poderão ser executados através de uma interface SQL remota. Isso simplifica a manutenção e o gerenciamento da base de dados, bem como a execução de determinadas rotinas tais como a realização de backups especiais ou não programados.
 
Existem mais de 7 utilitários que permitem o gerenciamento do servidor de banco de dados, todos necessitando de um logon como "dba". Os principais serão mencionados a seguir:
 
·createdb [dbnome] : cria uma nova base de dados;
 
·createuser [nome do usuario] : permite que um usuário com uma conta no servidor acesse o banco de dados;
 
·destroydb [dbnome] : remove uma base de dados do servidor;
 
·destroyuser [nome do usuário] : remove o acesso do usuário ao servidor de banco de dados;
 
·pg_dump [dbnome] : extrai a base de dados para um script;
 
·pg_dumpall : extrai todas as bases de dados do servidor, cada uma num script específico;
 
·psql [dbnome] : console SQL, orientada a caractere, do servidor da base de dados.
 
Sobre este último utilitário vale a pena ressaltar que, dependendo da sua configuração e dos seus critérios de segurança, será necessário utilizá-lo com algumas opções adicionais, isto é,
 
psql -U [userid] [dbnome]
 
ou
 
psql ­U [userid] ­c "[cláusula SQL]" [dbnome]
 
Esses utilitários, que são de simples compreensão e que estão bem documentados nos manuais on-line, podem ser encontrados no respectivo site
 
http://www.postgresql.org
 
 
 
SEGURANÇA
 
 
Restrição de acessos
 
Sempre que algum usuário inicia um processo de negociação para se conectar com o PostgreSQL, o backend verifica o arquivo
 
pg_hba.conf
 
localizado no diretório
 
/usr/local/pgsql/data
 
para obter a regras de acesso que a base de dados solicitada possui. Essas regras utilizam duas metodologias distintas, mas simultâneas, uma especificando o método de autenticação para o usuário e outra atribuindo uma sub-rede com a qual um usuário poderá acessá-la.
 
Os critérios mais usuais para a autenticação são:
 
·trust: nenhuma autenticação é feita. O PostgreSQL associa o nome informado pelo usuário com os seus direitos e permissões para a base de dados cuja solicitação esta sendo feita;
 
·reject: a conexão é rejeitada;
 
·password: a senha informada pelo usuário será autenticada pelo servidor e a conexão será concedida, conservando os direitos e as permissões que esse usuário possui.
 
A utilização da opção "trust" exige que um usuário do host seja cadastrado como um usuário do banco de dados, o que poderá ser feito através do utilitário "createuser". Já a execução do utilitário
 
shell% pg_passwd /usr/local/pgsql/data/
 
permite que o administrador do banco de dados crie grupos distintos ou categorizados, incluindo usuários com suas respectivas senhas de acesso. Deve-se notar que o resultado final desse comando é um arquivo texto, criado automaticamente caso o mesmo não exista, cuja localização é exatamente a mesma onde se encontra o arquivo "pg_hba.conf".
 
Um exemplo dessa estrutura de autenticação pode ser vista a seguir
 
host all 127.0.0.1 0.0.0.0 trust
 
onde deve ser observado que qualquer usuário do host, que seja cadastrado como usuário do banco de dados, poderá acessar localmente qualquer base de dados. Já a estrutura
 
host all 200.1.10.1 255.255.255.0 trust
 
permitirá que os usuários autorizados acessem remotamente qualquer base de dados, desde que estejam na sub-rede formada pelos IP's
 
200.1.10.1
200.1.10.2
200.1.10.3
( ... )
200.1.10.255
 
Uma outra estrutura poderia ser estudada para a base de dados "sample". Primeiro, entretanto, seria necessário usar o utilitário
 
shell% createdb sample
 
para criá-la e, depois disso, montar uma estrutura de autenticação
 
host sample 109.90.15.1 255.255.255.0 trust
 
ou
 
host sample 109.90.15.1 255.255.255.0 password admin
 
Repare que a segunda estrutura prevê a existência de usuários dentro do grupo "admin". Nesse caso será preciso utilizar
 
pg_passwd /usr/local/pgsql/data/admin
 
para inserir esses usuários individualmente.
 
 
As Vantagens Inerentes
 
Imagine agora uma grande WAN, segmentada por redes Estaduais, onde cada Estado recebeu uma classe "B" de IP's virtuais para utilizar em sua rede local, cuja identificação foi feita através do DDD:
 
10.61.x.x Brasília (DF)
10.11.x.x São Paulo (SP)
10.21.x.x Rio de Janeiro (RJ)
10.1.x.x Brasil (BR)
 
e assim sucessivamente. A cada sub-rede corresponde a submáscara 255.255.0.0. Dessa forma, será possível criar uma base de dados para cada Estado e manter uma estratégia de restrição com acessos isolados, criando informações regionais que poderiam ser consolidadas num escopo global existente nos sistemas da União.
 
Analogamente a utilização do programa pg_passwd permitiria a criação de usuários especiais para cada Estado:
 
shell% pg_passwd /usr/local/pgsql/data/df
(...)
shell% pg_passwd /usr/local/pgsql/data/sp
(...)
shell% pg_passwd /usr/local/pgsql/data/rj
(...)
shell% pg_passwd /usr/local/pgsql/data/br
(...)
 
Finalmente o arquivo "pg_hba.conf" seria montado como esta:
 
host df 10.61.0.0 255.255.0.0 password df
host sp 10.11.0.0 255.255.0.0 password sp
host rj 10.21.0.0 255.255.0.0 password rj
host br 10.1.0.0 255.255.0.0 password br
( ... )
 
Com uma rápida observação, pode-se concluir que a utilização dos diversos arquivos de usuário/password, criados com o comando
 
shell% pg_passwd /usr/local/pgsql/data/"arq"
 
tornam-se desnecessários pois a base de dados tem o acesso associado ao IP que constrói sua rede local. Além disso, cada usuário é autenticado por um servidor "seguro" no Estado, tornando desnecessária a repetição de sua password para as diversas sub-redes. Portanto poderíamos ter uma situação como esta
 
host df 10.61.0.0 255.255.0.0 trust
host sp 10.11.0.0 255.255.0.0 trust
host rj 10.21.0.0 255.255.0.0 trust
host br 10.1.0.0 255.255.0.0 trust
 
mais simples e tão segura quanto o modelo delineado anteriormente. Obviamente que essa estrutura baseia-se na utilização de um backbone via Frame Relay. A inclusão do acesso via Internet modificaria algumas definições, mas não invalidaria uma modelagem semelhante.
 
 
 
Backup
 
É aconselhável, pelo menos teoricamente, que as bases de dados gerenciadas pelo PostgreSQL sejam copiadas de forma compactada diariamente. É possível a realização dessas rotinas on-line através do script "postgres.bkp":
 
1 #! /bin/sh
2
3 BACKUP_DIR=/usr/local/pgsql/backups
4 BACKUP_NUM=7
 
5 # Vaccum each database and make a backup of the databases
6 databases=`su -l dba -c 'psql -q -t -c "select datname from pg_database;" template1'`
 
7 for d in $databases; do
8 echo -n "Vacuuming $d... "
9 if su -l dba -c "psql -q -c 'VACUUM' $d"; then
10 echo "done."
11 else
12 echo ""
13 echo "oops"
14 fi
 
15 if [ ! -d $BACKUP_DIR/$d ]; then
16 echo -n "Creating backup directory $BACKUP_DIR/$d... "
17 su -l dba -c "mkdir $BACKUP_DIR/$d" ] || continue
18 echo "done."
19 fi
 
14 # Keep a maximum of $BACKUP_NUM number of backups
15 archive=$BACKUP_DIR/$d/$d.gz
16 if [ -f $archive.$BACKUP_NUM ]; then rm -f $archive.$BACKUP_NUM; fi
17 n=$(( $BACKUP_NUM - 1 ))
18 while [ $n -gt 0 ]; do
19 if [ -f $archive.$n ]; then
20 mv $archive.$n $archive.$(( $n + 1 ))
21 fi
22 n=$(( $n - 1 ))
23 done
24 if [ -f $archive ]; then mv $archive $archive.1; fi
 
25 echo -n "Dumping database $d... "
26 su -l dba -c "(pg_dump -D $d |gzip -9) > $archive"
27 echo "done."
28 done
 
Observe as linhas em negrito, pois nelas aparece o nome do administrador do banco de dados. Se você utilizou outro user id terá que alterar essas linhas. Este script gerará um erro, caso o diretório
 
/usr/local/pgsql/backups
 
não tenha sido criado ou caso o usuário dba não tenha permissão para escrever nele (linha 3). O arquivo do script também deve ter uma flag permitindo sua execução pelo administrador da base de dados.
 
Deve-se aproveitar o serviço "crond", existente no Linux, e automatizar as tarefas de backup, visto que o script, conforme pode ser visto na linha 4, mantém a cópia das 7 últimas versões das bases de dados quando executado diariamente. A distribuição do RedHat Linux, por exemplo, traz diversas facilidades embutidas, bastando copiar esse script para o diretório
 
/etc/cron.dialy/
 
que o sistema se encarregará de executar o backup das bases de dados que estiverem sendo gerenciadas pelo PostgreSQL.
 
 
 
 

A Revista do Linux é editada pela Conectiva S/A
Todos os Direitos Reservados.

Política de Privacidade
Anuncie na Revista do Linux