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