sexta-feira, 16 de setembro de 2011

Servidor DNS

História do Sistema de Nomes de Domínio

Nos anos 70, a ARPAnet era muito pequena, um simples arquivo host.txt contendo todas as informações que se precisava conhecer sobre os hosts resolvia o problema.

Quando a rede começou a crescer e se mover para o protocolo TCP/IP, os administradores de rede tiveram várias dificuldades, e dentre elas podemos citar:

Colisão de nomes - duas máquinas com IPs diferentes poderiam ter o mesmo nome, pois a manutenção dos arquivos hosts.txt se tornava complicada. Não existia nada que prevenisse que alguém adicionasse um host com um nome idêntico a outro.
Consistência - quando necessário incluir um novo host, o procedimento precisava ser replicado para todos os outros arquivos. Caso um dos arquivos hosts.txt não fosse atualizado era gerado um problema na resolução de nomes na rede.
Os arquivos hosts.txt não eram escaláveis.

Em 1984 foram liberadas as RFCs 882 e 883 que descreviam o Sistema de Nomes de Domínio.
O Sistema de Nomes de Domínio
O Sistema de Nomes de Domínio é um banco de dados distribuído.

Desta maneira formou-se um sistema robusto com alto desempenho que pudesse ser replicado e armazenado em memória.

Abaixo vemos a estrutura de uma base de nomes que é semelhante ao sistema de arquivos do UNIX.

Cada domínio tem um nome único, como em um diretório. O nome do domínio identifica a posição na base de dados, mas ao contrário do sistema de arquivos do UNIX, o nome é uma a seqüência do nó para a raiz como mostrado a seguir.

Cada domínio pode ser administrado por uma entidade diferente.

Por exemplo, a InterNIC resolve o domínio edu (educational), mas o subdomínio berkley.edu quem resolve é a universidade U.C. Berkeley.

A primeira implementação do Sistema de Nomes de Domínio era chamada JEEVES, escrita por Paul Mockapetris. Posteriormente outra implementação chamada BIND, escrita para o sistema operacional Berkeley's 4.3BSD UNIX foi escrita por Kevin Dunlap. BIND atualmente é mantida pelo Internet Software Consortium.

Os nomes para os hosts no domínio podem ter até 63 caracteres sendo o “.” reservado para a raiz.

A seguir temos alguns domínios do topo da estrutura.

Para cada país é seguida a norma ISO3166 que define dois caracteres para representação do país. Abaixo alguns exemplos.

No Brasil temos alguns subdomínios tais como:

Para maiores informações entre no site registro.br.

Configuração

Este exemplo é baseado em um computador com sistema Linux pré-instalado.

Altere o nome da máquina para ns1.teste.com.br e o gateway padrão.

nano /etc/sysconfig/network

HOSTNAME=ns1.teste.com.br
GATEWAY=192.168.0.254

Ajuste o arquivo /etc/hosts para

127.0.0.1   localhost.localdomain   localhost
::1         localhost6.localdomain6 localhost6
192.168.0.1 ns1.teste.com.br        ns1
Altere o IP da máquina virtual para 192.168.0.1

nano /etc/sysconfig/network-scipts/ifcfg-eth0
DEVICE=eth0
ONBOOT=Yes
IPADDR=192.168.0.1
NETMASK=255.255.255.0
BROADCAST=192.168.0.255
NETWORK=192.168.0.0
Altere o endereço do servidor que irá resolver os nomes em /etc/resolv.conf, coloque inicialmente o endereço do seu provedor ou dns interno.

nameserver 10.2.0.1
Reinicie a máquina virtual para começarmos a configuração do nosso servidor de nomes.
Instalação dos pacotes
Instale os pacotes necessários para o servidor de nomes

yum install bind caching-nameserver bind-chroot

Definição do domínio teste.com.br
Vamos criar o domínio teste.com.br, edite o arquivo de configuração do servidor de nomes.

nano /etc/named.caching-nameserver.conf
Troque as linhas abaixo, que aparecem no arquivo de configuração,
listen-on port 53 { 127.0.0.1; };
view localhost_resolver {
     match-clients { localhost; };
     match-destinations { localhost; };
     recursion yes;
     include "/etc/named.rfc1912.zones";
};

Por

listen-on port 53 { 127.0.0.1; 192.168.0.1;};
view interno {
     match-clients { localhost; 192.168.0.0/24;};
     allow-query { localhost; 192.168.0.0/24;};
     recursion yes;
     include "/etc/named.rfc1912.zones";
     include "/etc/teste.com.br.zone";
};

Isto fará o servidor esperar por conexões no IP 192.168.0.1 vindas da rede 192.168.0.0/24, e indicará o arquivo onde será definido o domínio teste.com.br.

Como foi instalado o bind-chroot todos os arquivos referentes ao servidor de nomes se encontram no diretório /var/named/chroot. Vamos criar a zona teste.com.br.

nano /var/named/chroot/etc/teste.com.br.zone

Adicione neste arquivo as linhas abaixo.

zone "teste.com.br" IN {
     type master;
     file "teste.com.br.hosts";
     allow-update { none; };
};

zone "0.168.192.in-addr.arpa" IN {
     type master;
     file "teste.com.br.rev";
     allow-update { none; };
};

Altere as permissões deste arquivo para somente leitura e escrita pelo usuário root, e leitura para o grupo named.

O grupo proprietário deste arquivo deve ser o grupo named.
Criação da zona teste.com.br
Edite o arquivo da zona direta onde se cadastram as máquinas.

nano /var/named/chroot/var/named/teste.com.br.hosts
O arquivo deve conter as linhas abaixo.
$TTL 86400
@ IN SOA ns1.teste.com.br. root.ns1.teste.com.br. (
     2007082501 ; serial
     3H ; refresh
     15M ; retry
     1W ; expiry
     1D ) ; minimum
     IN NS ns1.teste.com.br.
     IN NS ns2.teste.com.br.
ns1 IN A 192.168.0.1
ns2 IN A 192.168.0.2
As permissões deste arquivo devem estar como no caso anterior.

Criação da zona teste.com.br reversa

Edite o arquivo da zona direta onde se cadastram as máquinas.

nano /var/named/chroot/var/named/teste.com.br.rev

O arquivo deve conter as linhas abaixo.

$TTL 86400
@ IN SOA ns1.teste.com.br. root.ns1.teste.com.br. (
     2007082501 ; Serial
     3H ; refresh
     15M ; retry
     1W ; expiry
     1D ) ; minimum
IN NS ns1.teste.com.br.
IN NS ns2.teste.com.br.
1.0.168.192.in-addr.arpa IN PTR ns1.teste.com.br.
2.0.168.192.in-addr.arpa. IN PTR ns2.teste.com.br.
As permissões deste arquivo devem estar como no caso anterior.

Testes
Inicie o serviço

/etc/init.d/named start

Resolução do nome

nslookup ns1.teste.com.br 127.0.0.1

A resposta deve ser

Server: 127.0.0.1
Address: 127.0.0.1#53

Name: ns1.teste.com.br
Address: 192.168.0.1

Resolução do nome reverso

nslookup 192.168.0.1 127.0.0.1

A resposta deve ser

Server: 127.0.0.1
Address: 127.0.0.1#53

1.0.168.192.in-addr.arpa name = ns1.teste.com.br.

Colocando para funcionar

Altere o arquivo /etc/resolv.conf para

search teste.com.br
nameserver 127.0.0.1

Faça os testes de resolução de nomes novamente.

Configuração do Servidor de Nomes Secundário

Em outro servidor instale os mesmos pacotes instalados no servidor de nomes primário.

Repita o passo 1 colocando em listen-on a linha abaixo

listen-on port 53 { 127.0.0.1; 192.168.0.1;};
No passo 2 quando for criar as zonas direta e reversa, coloque
zone "teste.com.br" IN {
     type slave;
     file "slaves/teste.com.br.zones";
     masters { 192.168.0.1; };
};

zone "0.168.192.in-addr.arpa" IN {
     type slave;
     file "slaves/teste.com.br.rev";
     masters { 192.168.0.1; };
};

Copie a chave que está no arquivo /etc/rndc.key do servidor primário para o secundário.

Altere no servidor primário, inclua a opção para o domínio na definição da zona direta e reversa, abaixo do allow-update;

allow-transfer { 192.168.0.2; };
Testes
Inicie o servidor DNS e veja se os arquivos do domínio foram transferidos.

ls /var/named/chroot/var/named/slaves/

quinta-feira, 15 de setembro de 2011

Serviço proxy: Squid

Disponibilizo no meu Scribd uma ótima aula sobre proxy Squid. Esta aula é do ex-professor do curso de Redes de Computadores do IFRN, Bruno Pontes.

Clique aqui para acessar

Servidor de correio eletrônico

Disponibilizo no meu Scribd uma ótima aula sobre Servidor de Correio Eletrônico, especificamente em ambiente de sistema de código aberto. Esta aula é do ex-professor do curso de Redes de Computadores do IFRN, Bruno Pontes.

Clique aqui para acessar

Redes de longa distância

1. Breve história das redes WAN

A história da WAN começa em 1965 quando Lawrence Roberts e Thomas Merril ligaram dois computadores, um TX-2 em Massachussets a um Q-32 na Califórnia, através de uma linha telefônica de baixa velocidade, criando a primeira rede de área alargada (WAN).

Em geral, as redes geograficamente distribuídas contém conjuntos de servidores, que formam sub-redes. Essas sub-redes têm a função de transportar os dados entre os computadores ou dispositivos de rede.

As WAN tornaram-se necessárias devido ao crescimento das empresas, onde as LAN não eram mais suficientes para atender a demanda de informações, pois era necessária uma forma de passar informação de uma empresa para outra de forma rápida e eficiente. Surgiram as WAN que conectam redes dentro de uma vasta área geográfica, permitindo comunicação de longa distância.

2. Rede de área alargada (WAN)

As redes de área alargada (Wide Area Network) tem a dimensão correspondente a países, continentes ou vários continentes. São na realidade constituidas por múltiplas redes interligadas, por exemplo LANs e MANs. O exemplo mais divulgado é a "internet". Dada a sua dimensão e uma vez que englobam LANs e WANs, as tecnologias usadas para a transmissão dos dados são as mais diversas, contudo para que as trocas de informação se processem é necessário um elo comum sobre essa tecnologia heterogénea. Esse elo comum é o protocolo de rede.

As WANs são redes usadas para a interconexão de redes menores (LANs ou MANs) e sistemas computacionais dentro de áreas geográficas grandes (cidades, países ou até continentes). Elas possuem um custo de comunicação bastante elevado devido aos circuitos para satélites e enlaces de microondas.

São, em geral, mantidas, gerenciadas e de propriedade de grandes operadoras (públicas ou privadas), e o seu acesso é público. São exemplos de tecnologias WAN as ATM e X.25.

Por questões de confiabilidade, caminhos alternativos são oferecidos entre alguns nós. Com isso, a topologia da rede é, virtualmente, ilimitada, isto é voz, dados e vídeo são comumente integrados.

A capacidade de chaveamento da rede permite a alteração dinâmica do fluxo de dados, ao contrário das LANs, que normalmente empregam o roteamento fixo.

A interligação ("internetworking") de redes de diferentes tecnologias é assegurada por dispositivos conhecidos por "roteadores". Um roteador possui tipicamente ligação física a duas ou mais redes, recebendo dados de uma rede para os colocar na outra rede. Um exemplo tipico é a ligação de uma rede "Ethernet" a uma rede ponto-a-ponto.

2.1. Características das redes WAN

– Cobertura de grandes áreas geográficas geridas por operadores de Telecomunicações;

– Os recursos de transmissão podem ser dedicados ou partilhados;

– Usa-se diversas tecnologias de transporte (modos de transferência)

     • Comutação de circuitos (rede telefônica, RDIS)

     • Comutação de pacotes (X.25, IP)

     • Comutação de tramas (Frame Relay)

     • Comutação de células (ATM – Asynchronous Transfer Mode)

     • Comutação de etiquetas (MPLS – Multiprotocol Label Switching)

– Deve conectar computadores entre longas distâncias;

– Deve permitir que muitos computadores possam se comunicar simultaneamente sem limitação de largura de banda;

– Escalabilidade.

– São construídas a partir de muitos switches, os quais os computadores individuais se conectam.

– Para aumentar a rede, basta inserir mais switches para acomodar mais computadores.

– O dispositivo switch utilizado para as WAN são os switches de pacotes;

Os switches são combinados para formar uma rede de longo alcance. Os switches podem ser interconectados através de grandes distâncias. As combinações podem ser realizadas para acomodar mais tráfego e oferecer redundâncias nos casos de falhas.

2.2. Protocolos WAN

Um protocolo tem algumas regras que os nós devem obedecer para se comunicarem uns com os outros. O que eles fazem é criar uma linguagem comum entre diferentes máquinas. De forma geral, ele é um conjunto de regras, especificações e procedimentos que devem governar entidades que se comunicam entre si.

Elementos de um protocolo
– Sintaxe (formato dos dados, níveis de sinal, etc.)

– Semântica (informação de controle, tratamento de erros) – procedimentos

– Temporizações (adaptação de velocidades, sincronização, ordenação dos dados).

2.2.1. Protocolo ponto-a-ponto [Point-to-Point Protocol ( PPP )]:

É o protocolo mais comum para dar acesso à internet tanto em conexões discadas como dedicadas.

2.2.1.1. Topologia do PPP na rede WAN

Chama-se “topologia” à disposição física dos computadores relativamente às cablagens e dispositivos que os unem. Entretanto, são várias as topologias existentes, nomeadamente:
Estrela/Star

Este tipo de topologia ganhou terreno relativamente à topologia bus, principalmente devido à maior flexibilidade na alteração da estrutura da rede, sendo aquela que se utiliza em praticamente todas as redes Ethernet.

Une os computadores através de um hub central, do qual sai um cabo para cada máquina, formando assim uma estrela, que lhe dá o nome.

Vantagens

• Facilidade de modificação do sistema, já que todos os cabos ligam ao mesmo local;

• Baixa de um computador não afeta o resto da rede;

• Fácil detecção e isolamento de falhas;
• Simplicidade de protocolo de comunicação;
• Pode utilizar múltiplos tipos de cabo;
Desvantagens
• Maior comprimento do cabo para efetuar as ligações;
• Dificuldade em expandir o número de nós;
• Dependência do nó central, se este falhar, a rede fica inoperacional.

Anel/Ring

Na topologia em anel cada computador está ligado a outros dois ao longo de um circuito fechado. A informação circula num determinado sentido já pré-definido. Cada computador inclui um dispositivo de recepção e transmissão, o que lhe permite receber o sinal e passá-lo ao computador seguinte no caso de a informação não ser para ele.

As redes que usam esta topologia são designadas por Redes Token Ring. Os dispositivos utilizados neste tipo de rede tem de possuir uma certa inteligência para que, em caso de corte do anel, o hub consiga fazer um novo anel.

Vantagens
• Pequeno comprimento de cabo;
• Não são necessários armários de distribuição dado que as ligações são efectuadas em cada um dos nós;

• Funciona bem com muito tráfego.

Desvantagens

• A falha de um nó pode causar a falha de toda a rede;
• Dificuldade em diagnosticar falhas;
• Dificuldade em reconfigurar a rede;
• Tipicamente mais cara do que a topologia estrela.

Malha/Mesh

Cada par de componentes liga-se e comunica diretamente a outros componentes da malha e cada componente é responsável por gerir sessões.

Vantagens

• Extremamente resistente a falhas;
• De fácil manutenção.
Desvantagens
• Topologia que requer mais cablagem;
• Tipicamente a topologia mais cara.
2.2.2.  Rede X.25

É uma arquitetura de comutação de pacotes (que correspondem dois tipos de serviços: Circuitos Virtuais e Datagramas) definida nas recomendações do ITU-T. A rede X.25 fornece uma arquitetura orientada à conexão para transmissão de dados sobre uma rede física sujeita a alta taxa de erros. A verificação desses erros é feita em cada nó da rede entre a origem e o destino (store and forward), o que acarreta alta latência e inviabiliza a rede X.25 para a transmissão de voz e vídeo. A rede pode dispor de mecanismos para:

• Manter a sequência (ordenação) de pacotes nó a nó;

• Reordenação de pacotes antes da entrega;
• Detecção (e eventual recuperação) de erros.

O uso da técnica de pacotes proporciona um elevado padrão de qualidade. A determinação do caminho mais adequado para transmissão de um conjunto de pacotes permite contornar situações adversas decorrentes de falhas no sistema ou de rotas congestionadas.
2.2.2.1. Níveis do Protocolo X.25
A recomendação X.25 do ITU-T define os protocolos na interface de acesso entre um equipamento terminal e uma rede pública de comutação de pacotes especifica três níveis que correspondem aos três níveis mais baixos do OSI:

     - Nível Físico - Interface física entre o equipamento terminal (DTE) e um equipamento de terminação de Rede (DCE).

     - Nível de ligação de dados (nível trama) - LAPB (Link Access Procedures Balanced) - Especifica os procedimentos para estabelecer, manter e terminar uma ligação de dados que permite o envio confiável de tramas, sujeito a mecanismos de controle de erros e de fluxo.

     - Nível de rede (nível pacote) - Oferece um Serviço de Circuitos Virtuais. Especifica os procedimentos para estabelecer, manter e terminar circuitos virtuais e transferir pacotes de dados nos circuitos virtuais.

2.2.3. Frame Relay

É uma arquitetura de rede de pacotes que adota o modelo de comutação de Circuitos Virtuais de alta velocidade e sucessor natural da rede X.25. Permite comutação mais rápida e mais eficiente que a comutação X.25 e ultrapassa algumas limitações dos serviços em modo pacote na RDIS.

O Serviço Frame Relay é orientado à conexão, oferecendo portanto uma interface do tipo Circuito Virtual. Os Circuitos Virtuais são identificados por um identificador de ligação de dados (DLCI) no campo de endereço das tramas.

Os Circuitos Virtuais podem ser de dois tipos: 

Comutados (SVC – Switched Virtual Circuits)

     - Os circuitos virtuais comutados (chamadas virtuais) são estabelecidos e terminados por meio de procedimentos de sinalização.
Permanentes (PVC – Permanent Virtual Circuits)
     - Os circuitos virtuais permanentes são estabelecidos por meio de procedimentos de gestão.

2.2.3.1. Caracteristicas do Frame Relay

– Procedimentos de sinalização de nível 3 em canais lógicos separados;

– Multiplexagem e comutação de circuitos virtuais no nível 2;
– Ausência de controle de erros e de fluxo nó-a-nó;
– Controle de erros e de fluxo extremo-a-extremo.
2.2.3.2. Parâmetros de tráfego 

AR – Access Rate
     
     - Capacidade do canal físico para acesso ao serviço;
     - O débito instantâneo do utilizador é limitado pela capacidade do canal de acesso.
CIR – Committed Information Rate

     - Débito médio na interface de acesso que a rede deve garantir em condições normais;
     - CIR é definido num intervalo T (tipicamente da ordem de 1 segundo) não diretamente especificado.
Bc – Committed Burst Size

     - Máxima quantidade de informação que a rede aceita transferir em condições normais durante um intervalo T, indiretamente definido pela relação Bc = CIR * T;
     - É possível transmitir um burst máximo Bc com débito instantâneo AR, desde que o valor médio do débito (em qualquer intervalo T) não exceda CIR;
     - O tráfego é sujeito a policiamento pela rede em janelas de observação contínuas de duração T;

     - A geração de tráfego conforme (shaping) e o respectivo policiamento podem ser realizados com um mecanismo de controle do tipo Token Bucket.
Be – Excess Burst Size

     - Máxima quantidade de informação (para além de Bc) que a rede transmite condicionalmente durante um intervalo T; Be = EIR * T, sendo EIR a Excess Information Rate;
     - Tráfego que num período T exceda Bc + Be é descartado incondicionalmente.
2.2.3.3. Vantagens e limitações do Frame Relay

- O serviço Frame Relay não garante total confiabilidade na transferência de dados, uma vez que tramas descartadas devido a erros de transmissão ou congestionamento não são recuperadas pela rede;

O impacto deste efeito é limitado pela elevada confiabilidade dos sistemas de transmissão digital e por mecanismos de prevenção de congestionamento.
- O aumento da capacidade de comutação resultante da redução de overheads protocolares e de processamento tem como consequências o aumento do débito (throughput) possível (total e por circuito virtual) e a redução do tempo de atraso (latência) na rede.
• O serviço Frame Relay combina assim as vantagens da comutação de circuitos dedicados com as vantagens da comutação de pacotes, podendo esta ser realizada a muito alta velocidade (tipicamente até cerca de 45 Mbit/s).

2.2.4. Rede ATM (Asynchronous Transfer Mode)

É uma tecnologia de rede (que adota também o modelo de comutação de Circuitos Virtuais) usada para WAN (e também para backbones de LAN), suporta a transmissão em tempo real de dados, de voz e vídeo. A unidade de transmissão e comutação designa-se por Célula. A topologia típica da rede ATM utiliza-se de switches que estabelecem um circuito lógico entre o computador de origem e destino, deste modo garantindo alta qualidade de serviço e baixa taxa de erros.

Diferentemente de uma central telefônica, a rede ATM permite que a banda excedente do circuito lógico estabelecido seja usada por outras aplicações. A tecnologia de transmissão e comutação de dados utiliza a comutação de células como método básico de transmissão, uma variação da comutação de pacotes onde o pacote possui um tamanho reduzido. Por isso, a rede ATM é altamente escalável, permitindo velocidades entre nós da rede como: 1.5Mbps, 25Mbps, 100Mbps, 155Mbps, 622Mbps, 2488Mbps (~2,5Gbps), 9953Mbps (10Gbps).

2.2.4.1. Camada ATM

As principais funções da camada ATM são a multiplexagem e a comutação de células de diferentes conexões virtuais.

Células de uma mesma conexão transportam um identificador comum, que tem significado local em cada interface e que, por essa razão, é normalmente alterado no processo de comutação.

O identificador de conexão é estruturado em duas partes:
• VPI – Virtual Path Identifier
• VCI – Virtual Channel Identifier
O conceito de Caminho Virtual (VP – Virtual Path) permite agrupar Canais Virtuais (VC – Virtual Channels), que podem ser comutados em conjunto.

2.2.4.2. Multiplexagem e comutação em ATM

É inerente ao modo de operação do ATM que a ocupação de células de um circuito virtual seja irregular (assíncrona), não obedecendo a um padrão pré-definido.
A multiplexagem e comutação de células ATM origina variações de débito e atraso que dependem por um lado do próprio padrão de tráfego submetido em cada circuito virtual, mas também da disponibilidade de recursos.

A importância das variações instantâneas do débito e do atraso depende dos requisitos de Qualidade de Serviço (QoS). A existência de tráfego com débito variável possibilita a exploração de Multiplexagem Estatística.

• A multiplexagem estatística permite aumentar a eficiência na utilização de recursos;
• A multiplexagem estatística aumenta a probabilidade de conflitos no acesso a recursos, originando situações de sobrecarga que agravam os atrasos e podem mesmo originar perdas (overflow de buffers).

2.2.4.3. QoS em redes ATM

Parâmetros de Qualidade de Serviço

- Cell Loss Ratio (CLR) - Definido para cada conexão pela relação:
     
     Nº de células perdidas / Nº total de células transmitidas
- Maximum Cell Transfer Delay (maxCTD) - O valor especificado por conexão é o percentil (1 - α) de CTD, isto é p (CTD > maxCTD) < α.

     Para serviços de tempo real, células cujo atraso exceda um certo limite são consideradas como perdidas (inúteis).

- Peak-to-peak Cell Delay Variation (peak-to-peak CDV)
     Habitualmente designado por Delay Jitter - É a diferença entre o maxCTD e o valor das componentes fixas do atraso (que determinam o atraso mínimo).
2.2.4.4. Funções de Controle de tráfego
O ATM Forum identificou um conjunto de funções genéricas de Controle (Gestão) de Tráfego, que deverão ser suportadas em diferentes elementos de rede – equipamento terminal, nós de acesso e nós internos da rede.

- Connection Admission Control – CAC
- Feedback Control

- Usage Parameter Control – UPC

- Cell Loss Priority Control
- Traffic Shaping
- Network Resource Management
- Frame Discard
2.3. Outros protocolos usados nas WAN
DSL (Digital Subscriber Line)

Permite tráfego de alta capacidade usando o cabo telefônico normal entre a casa ou escritório do assinante e a central telefônica. Possui dois modos básicos: ADSL e HDSL.
ADSL (Asymmetric DSL)
O ADSL compartilha uma linha de telefone comum, usando um faixa de frequência de transmissão acima daquelas usadas para a transmissão de voz. É a variação do protocolo DSL onde a capacidade de transmissão é assimétrica, isto é, a banda do assinante é projetada para receber maior volume de dados do que este pode enviar. Serviço mais adequado ao usuário comum que recebe dados da internet.

HDSL (High-Bit-Rate DSL)
O HDSL fornece um enlace de alta taxa de transmissão de dados, tipicamente T1, sobre o par trançado comum, exigindo a instalação de pontes e repetidores. Esta variação do protocolo DSL onde a capacidade de transmissão, a banda do assinante, tem a mesma capacidade de envio e recebimento de dados. Serviço mais adequado ao usuário corporativo que disponibiliza dados para outros usuários comuns.

Tecnologias de redes locais

1. Introdução

Nas topologias de redes em barramento e anel, observamos que o meio de interligação é comum entre as estações. Desta forma, quando duas máquinas necessitam trocar informações é necessário que exista um protocolo de controle do meio de transmissão, a fim de que outras máquinas não tentem transmitir, interferindo, assim, na comunicação que está em andamento.

As primeiras tecnologias de redes foram desenvolvidas por grandes corporações com a Xerox, a GM e a IBM. Em seguida, a organização americana IEEE (Institute of Electrical and Electronics Engineers – Instituto dos Engenheiros Eletricistas e de Eletrônica) desenvolveu um conjunto de padrões de protocolos de acesso ao meio para LANs conhecido como IEEE 802.

Posterioremente, a ISO adotou estes padrões internacionalmente como ISO 8802.

2. Histórico

Na década de 70 as grandes corporações como a Xerox, a General Motors e a Boeing começaram a se interessar pela automação dos seus escritórios e linhas de montagem. A partir de então, houve um desenvolvimento acelerado dos padrões de redes locais. A Xerox Corporation implementou a LAN Ethernet, a qual foi rapidamente adotada por muitas empresas, e a Intel construiu posteriormente um controlador de Ethernet em um único chip. Não demorou muito para que a Ethernet se tornasse um padrão de fato para LANs.

Paralelamente, a GM necessitava de LANs que atendessem a automação de suas fábricas, onde os carros se movimentavam a uma taxa fixa na linha de montagem. Portanto, a GM considerou essencial ter uma LAN com tempos determinísticos de transmissão de informações. Como a Ethernet não possuía esta propriedade, a GM optou por uma LAN chamada Token Bus, na qual as máquinas se alternariam, uma de cada vez, dando assim, um desempenho no pior caso determinístico, em vez de estatístico. Enquanto tudo isto acontecia, a IBM anunciou que havia adotado uma terceira opção, a Token Ring como seu padrão de LANs. A IBM adotou este padrão devido à sua alta confiabilidade e facilidade de manutenção, assim como outras vantagens técnicas.

Quando foi pensado em criar um padrão oficial para LANs, sobre a coordenação do IEEE, verificou-se que existiam três padrões de fato adotados, e como não existia uma maioria para a aprovação de um único padrão, foram estabelecidos pelo IEEE os três padrões de LANs, conhecidos como IEEE 802.3 (CSMA/CD) baseado no Ethernet, IEEE 802.4 token bus, e IEEE 802.5 (token ring).

3. A arquitetura IEEE 802 e o modelo OSI

Apesar das diferenças nos padrões de redes locais, as empresas viram a necessidade de utilizarem protocolos específicos e uma arquitetura aberta para suas redes, a fim de evitar futuras incompatibilidades. Obviamente foi adotado o modelo OSI para a implementação das arquiteturas. O conjunto dos padrões 802.X foi adotado pela ISO internacionalmente como tecnologias de redes locais através da padronização ISO 8802. Portanto, as tecnologias de redes locais do IEEE foram adotadas nas arquiteturas abertas OSI e TCP/IP.

A arquitetura IEEE compreende duas camadas: a física e a de enlace de dados. A camada de enlace de dados é dividida em duas partes: uma sub-camada de controle de acesso ao meio denominada de CAM que corresponde aos protocolos de acesso ao meio IEEE 802.3 (CSMA/CD), IEEE 802.4 (token bus) e IEEE 802.5 (token ring) e uma sub-camada de controle de enlace de dados denominada de LC e padronizado através do IEEE 802.2. A sub-camada LLC é a responsável pelo interfaceamento dos diferentes protocolos de acesso ao meio às camadas superiores do OSI e do TCP/IP. Além de servir de interfaceamento, a LLC é responsável pelas funções de controle de erro e de fluxo dos dados. A figura abaixo mostra a arquitetura IEEE 802 e o seu mapeamento no modelo OSI.
Mapeamento da arquitetura IEEE 802 no modelo OCI

Padrão IEEE 802.3 (CSMA/CD)

O IEEE 802.3 (ISO 8802-3) é o padrão para redes locais em barramento cujo protocolo para acesso ao meio é denominado de CSMA/CD (Carrier Sense Multiple Access with Collision Detection), acesso múltiplo por detecção de portadora com detecção de colisão. As redes IEEE 802.3 operam a taxas de velocidades de 10 Mbps, 100 Mbps, 1 Gbps podendo chegar a 10 Gbps.

O padrão IEEE 802.3 converge para a especificação Ethernet da Xerox. Por isso, esta tecnologia é geralmente denominada de Ethernet.

4.1 Protocolo de acesso ao meio

Para entender a técnica CSMA/CD, a figura abaixo ilustra a topologia de uma rede ethernet onde o meio é comum e o acesso é compartilhado entre todos os computadores. A figura "a" mostra a topologia física de uma rede ethernet. Neste exemplo, se considerarmos um equipamento de convergência, onde o sinal que chega por uma porta é difundido por todas as outras portas, esta rede tem uma topologia lógica em barramento, conforme a figura "b".
Topologia de uma rede ethernet

Portanto, considerando uma rede em barramento da figura abaixo, o protocolo CSMA/CD que controla a política de ocupação do meio pode ser explicado da seguinte forma:
Topologia de uma rede em barramento ethernet

1°) Quando um computador necessita enviar dados pela rede, ele verifica primeiramente se o meio está livre, ou seja, ele “escuta” se na rede nenhum outro computador está transmitindo. Caso o meio esteja ocupado, ele aguarda um tempo aleatório e repete o processo;

2°) Caso o meio esteja livre, ou seja, nenhum computador da rede transmitindo, os dados são enviados;

3°) Entretanto, se no mesmo instante um outro computador transmitir dados pela rede, haverá colisão de informações. Esta colisão é detectada pelos dois computadores, através da técnica de “escuta” do meio durante a transmissão, assim, o envio de informações é abortado pelos dois computadores;

4°) Em seguida, cada computador aguarda um tempo aleatório e repete o processo de escuta do meio e transmissão em seguida.

A técnica CSMA/CD apesar de ser a mais popular e a mais difundida entre as redes locais, não é aplicada em redes que possuem computadores com aplicações que exigem tempos determinísticos para comunicação, como, por exemplo, controles de processos em tempo real. A popularidade da técnica CSMA/CD deve-se principalmente ao fato do padrão Ethernet ser implementado em praticamente todas as redes que atendem a automação dos escritórios das empresas e universidades.

4.2 Sintaxe do protocolo

A estrutura do quadro MAC do padrão IEEE 802.3 é mostrada na figura abaixo.
Sintaxe do quadro IEEE 802.3

A função de cada componente do quadro é a seguinte:

- Preâmbulo (7 bytes): Cada um dos 7 bytes contém o formato de bits 10101010. A codificação Manchester desse padrão produz uma onda quadrada de 10MHz por 5,6s para permitir que o relógio do receptor se sincronize com o do transmissor;

- Delimitador de início de quadro (1 byte): Contém os bits 10101011 para sinalizar o início do quadro propriamente dito;

- Endereço de destino e Endereço de origem (2 ou 6 bytes): É o endereço referenciado entre as estações de origem e de destino. Normalmente esses endereços são chamados de endereços MAC. O padrão Ethernet usa endereços de 6 bytes, entretanto o IEEE 802.3 suporta também endereços de 2 bytes;

- Comprimento do campo de dados (2 bytes): Informa quantos bytes estão presentes no campo de dados;

- Dados (0 a 1500 bytes): É a parte que contém as informações propriamente ditas, ou seja, é a PDU (unidade de dados de protocolo) para a camada LLC. Embora um quadro de dados com 0 bytes seja válido, ele causa um problema. Quando detecta uma colisão, um transceptor trunca o quadro em uso, o que significa que pedaços de quadros e bits perdidos aparecem no cabo a toda hora. Para diferenciar um quadro válido de lixo, o IEEE 802.3 diz que todos os quadros válidos devem ter ao menos 64 bytes, do endereço de destino até a soma de verificação. Também, o IEEE 802.3 diz que o quadro deve conter no máximo 1518 bytes;

- Pad (preenchimento): Consiste de bytes suficientes de preenchimento para assegurar ao quadro IEEE 802.3 o tamanho mínimo de 64 bytes. Se a parte de dados é grande o suficiente, o campo Pad não aparece no quadro (ele se transforma em um campo de comprimento zero);

- FCS (Frame Check Sequence - Checagem de Sequência de Bloco) (4 bytes): Monitora erros de transmissão. A estação de origem executa um teste de redundância cíclica (CRC) nos bits do bloco, e armazena o resultado destes cálculos no campo FCS. A estação de destino realiza a mesma operação e compara seu resultado com os valores do campo FCS. Se os valores forem diferentes, a estação de destino reporta uma mensagem de erro.

4.3 Classificação do IEEE 802.3

O rápido avanço tecnológico dos computadores e de suas aplicações exigiu uma melhoria no desempenho das redes. Desta forma, o padrão IEEE 802.3 (Ethernet) que inicialmente operava a uma taxa de 10 Mbps, evoluiu para outros padrões cuja característica está no aumento da taxa de velocidade obtida. Assim, surgiu uma série de padrões IEEE 802.3 cuja a evolução da tecnologia ocorreu basicamente na taxa de transmissão e no meio fisco (cabeamento metálico ou ótico) da rede. O protocolo MAC que é o CSMA/CD manteve-se inalterado.

O padrão IEEE 802.3 pode ser classificado conforme abaixo:

IEEE 802.3 (Ethernet) a 10 Mbps em par metálico e ótico;

IEEE 802.3u (Fast-Ethernet) a 100 Mbps em par metálico e ótico;

IEEE 802.3z (Gigabit Ethernet) a 1Gbps em cabo ótico;

IEEE 802.3ab (Gigabit Ethernet) a 1Gbps em par metálico;

IEEE 802.3ac (Gigabit Ethernet) a 10 Gbps em cabo ótico.

4.4 Nível físico do IEEE 802.3

As tecnologias de redes incluem as camadas físicas e enlaces de dados. Desse modo, os padrões do IEEE para tecnologias de redes compreendem além no protocolo MAC e da taxa de velocidade, o meio que suportará os sinais transmitidos.

A tabela a seguir apresenta os diferentes meios utilizados nas redes Ethernets. As especificações usam nomes que obedecem a uma convenção onde a primeira parte é a taxa de transmissão de bits/segundo (bps), a segunda, base, indica que a transmissão é realizada em banda de base (transmissão digital sem modulação). Por último, a terceira parte indica o tipo de cabeamento empregado.


4.5 Padrão IEEE 802.5 (token ring)

O IEEE 802.5 (ISO 8802.5) é o padrão para redes locais que operam em 4 e 16 Mbps utilizando a técnica token ring (passagem de fichas) para acesso ao meio.

O token ring foi desenvolvido pela IBM para conectar microcomputadores com seus meios ambientes de grande porte. Em razão da significativa base instalada pela IBM, criou-se um consenso no sentido de definir um padrão de LAN baseado nesta implementação.
Topologia de uma rede token ring

4.5.1 Protocolo de acesso ao meio

Para entender a técnica de passagem de fichas a figura acima ilustra a topologia em anel utilizada nas redes token ring. O acesso das estações ao anel é controlado por grupos especiais de bits chamados de token (ficha), os quais circulam através do anel de estação em estação. A técnica para o envio de informações pela rede é realizada da seguinte forma:

- Existe um token circulando pelo anel. Quando uma estação recebe o token, ela repete este token, se não tiver nada para transmitir;

- Por outro lado, se ela tiver algo para transmitir, o token recebido é substituído por um quadro de dados. Em seguida, o quadro é enviado para a estação subseqüente;

- Se a estação subseqüente não for a estação de destino do quadro, ela apenas o recebe e o reenvia a estação seguinte, ou seja, ela ignora o quadro;

- Se a estação subseqüente for a estação de destino dos dados, ela copia o quadro e em seguida, o reenvia a estação subseqüente;

- O quadro é reenviado por todas as estações subseqüentes, até alcançar a estação de origem, que, por sua vez, retira o quadro de dados e libera um token para a estação seguinte.

Ligue a vontade para qualquer celular ou fixo em todo o Brasil, EUA e Canadá, através do 99TelexFREE. Teste nosso serviço por 1 hora gratuitamente: http://www.telexfree.com/ad/marcelmesmo

terça-feira, 13 de setembro de 2011

Técnicas de transmissão

Segue link para slides com um trecho sobre técnicas de transmissão, retirado de aula do professor Volnys Bernal, da USP.

Clique aqui para acessar

segunda-feira, 12 de setembro de 2011

Meios de transmissão

Publico abaixo o link para uma excelente aula sobre Meios de Transmissão, da professora Íria Cosme, do IFRN Ipanguaçu.

Clique aqui para acessar

quinta-feira, 1 de setembro de 2011

Métodos de autenticação no PostgreSQL

Abaixo estão descritos com mais detalhes os métodos de autenticação.

1. Autenticação de confiança

Quando é especificada a autenticação trust, o PostgreSQL assume que qualquer um que possa se conectar ao servidor está autorizado a acessar o banco de dados como qualquer usuário que seja especificado (incluindo o superusuário do banco de dados). É claro que as restrições especificadas para o usuário e para o banco de dados ainda se aplicam. Este método deve ser utilizado somente quando existe uma proteção adequada no nível de sistema operacional para as conexões ao servidor.

A autenticação trust é apropriada e muito conveniente para conexões locais em estações de trabalho com um único usuário. Geralmente não é apropriada em um máquina multiusuária. Entretanto, é possível utilizar trust mesmo em uma máquina multiusuária, se for restringido o acesso ao arquivo de soquete do domínio Unix do servidor utilizando permissões do sistema de arquivos. Para fazer isto, deve ser definido o parâmetro de configuração unix_socket_permissions (e, possivelmente, unix_socket_group). Também pode ser definido o parâmetro de configuração unix_socket_directory para colocar o arquivo de soquete em um diretório com restrição adequada.

Definir as permissões do sistema de arquivos somente serve para as conexões através dos soquetes do Unix. As conexões locais TCP/IP não são restringidas desta maneira; portanto, se for desejado utilizar permissões do sistema de arquivos para segurança local, deve ser removida a linha host ... 127.0.0.1 ... do arquivo pg_hba.conf, ou mudá-la para que use um método de autenticação diferente de trust.

A autenticação trust somente é adequada para as conexões TCP/IP quando se confia em todos os usuários de todas as máquinas que podem se conectar ao servidor de banco de dados pelas linhas do arquivo pg_hba.conf que especificam trust. Raramente faz sentido utilizar trust para conexões TCP/IP, a não ser as oriundas de localhost (127.0.0.1).

2. Autenticação por senha

Os métodos de autenticação baseados em senha são md5, crypt e password. Estes métodos operam de forma semelhante, exceto com relação à forma como a senha é enviada através da conexão, mas somente o método md5 suporta senhas criptografadas armazenadas no catálogo do sistema pg_shadow; os outros dois métodos requerem que sejam armazenadas senhas não criptografadas neste catálogo.

Se houver preocupação com relação aos ataques de "farejamento" (sniffing) de senhas, então md5 é o método preferido, com crypt como a segunda opção se for necessário suportar clientes pré-7.2. O método password deve ser evitado, especialmente em conexões pela Internet aberta (a menos que seja utilizado SSL, SSH ou outro método de segurança para proteger a conexão).

As senhas de banco de dados do PostgreSQL são distintas das senhas de usuário do sistema operacional. As senhas de todos os usuários do banco de dados são armazenadas na tabela do catálogo do sistema pg_shadow. As senhas podem ser gerenciadas através dos comandos SQL CREATE USER e ALTER USER; por exemplo, CREATE USER foo WITH PASSWORD 'segredo';. Por padrão, ou seja, se nenhuma senha for definida, é armazenado o valor nulo para a senha e a autenticação da senha é sempre mal-sucedida para este usuário.

Para restringir o conjunto de usuários que podem se conectar a um determinado banco de dados, os usuários devem ser relacionados na coluna usuário do arquivo pg_hba.conf, conforme explicado na seção anterior.

3. Autenticação Kerberos

Kerberos é um sistema de autenticação seguro, padrão da indústria, adequado para computação distribuída em redes públicas. A descrição do sistema Kerberos está muito acima do escopo deste texto; de forma geral pode ser bastante complexo (porém poderoso). Existem diversas fontes de distribuição do Kerberos.

Embora o PostgreSQL suporte tanto o Kerberos 4 quanto o Kerberos 5, somente o Kerberos 5 é recomendado. O Kerberos 4 é considerado inseguro, não sendo mais recomendado para uso geral.

Para o Kerberos poder ser utilizado, o seu suporte deve ser habilitado em tempo de construção. São suportados tanto o Kerberos 4 quanto o 5, mas pode ser suportada apenas uma versão por uma construção.

O PostgreSQL opera como um serviço Kerberos normal. O nome do serviço principal é nome_do_serviço/nome_do_hospedeiro@domínio, onde nome_do_serviço é postgres (a menos que seja selecionado um nome de serviço diferente em tempo de configuração utilizando ./configure --with-krb-srvnam=qualquer_coisa). O nome_do_hospedeiro é o nome de hospedeiro da máquina servidora totalmente qualificado. O domínio (realm) do serviço principal é o domínio preferido da máquina servidora.

Os principais dos clientes devem ter seu nome de usuário do PostgreSQL como primeiro componente como, por exemplo, pgusername/outras_coisas@dominio. Atualmente o domínio do cliente não é verificado pelo PostgreSQL; portanto, estando habilitada a autenticação entre domínios, então todo principal de qualquer domínio que puder se comunicar com o que está sendo utilizado será aceito.

Certifique-se de que o arquivo de chaves do servidor seja legível (e preferencialmente somente legível) pela conta do servidor PostgreSQL. O local do arquivo de chaves é especificado pelo parâmetro de configuração em tempo de execução krb_server_keyfile. O padrão é /etc/srvtab se estiver sendo utilizado o Kerberos 4, e /usr/local/pgsql/etc/krb5.keytab (o ou diretório especificado como sysconfdir em tempo de construção) no Kerberos 5.

Para gerar o arquivo keytab deve ser utilizado, por exemplo (com a versão 5):

kadmin% ank -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

Para obter detalhes deve ser lida a documentação do Kerberos.

Ao se conectar ao banco de dados tenha certeza de possuir um tíquete para o principal correspondendo ao nome de usuário do banco de dados. Como exemplo: Para o nome de usuário do banco de dados cecilia, podem ser utilizados tanto o principal cecilia@EXAMPLE.COM quanto cecilia/users.example.com@EXAMPLE.COM para se autenticar no servidor de banco de dados.

Se for utilizado no servidor Web Apache o módulo mod_auth_kerb de Kerberos Module for Apache e o mod_perl, pode ser utilizado AuthType KerberosV5SaveCredentials com um script mod_perl, proporcionando um acesso seguro ao banco de dados através da Web, sem necessidade de senhas extras.

4. Autenticação baseada no Ident

O método de autenticação ident funciona obtendo o nome de usuário do sistema operacional do cliente, e determinando os nomes de usuário do banco de dados permitidos utilizando um arquivo de mapa que lista os pares de nomes de usuários correspondentes permitidos. A determinação do nome de usuário do cliente é o ponto crítico da segurança, funcionando de forma diferente dependendo do tipo de conexão.

4.1. Autenticação Ident através de TCP/IP

O "Protocolo de Identificação" está descrito no RFC 1413. Virtualmente todo sistema operacional da família Unix é distribuído com um servidor ident que escuta a porta TCP 113 por padrão. A funcionalidade básica do servidor ident é responder a perguntas como "Que usuário inicializou a conexão que sai pela sua porta X e se conecta à minha porta Y?". Uma vez que o PostgreSQL conhece tanto X quanto Y quando a conexão física é estabelecida, pode fazer a pergunta ao servidor ident no hospedeiro do cliente se conectando e pode, teoricamente, determinar o usuário do sistema operacional para uma determinada conexão desta maneira.

O problema deste procedimento é que depende da integridade do cliente: se a máquina cliente não for confiável ou estiver comprometida, alguém querendo fazer um ataque pode executar algum programa na porta 113 e retornar qualquer nome de usuário desejado. Este método de autenticação é, portanto, apropriado apenas para redes fechadas onde toda máquina cliente está sob controle rígido, e onde os administradores do sistema e do banco de dados trabalham de forma integrada. Em outras palavras, é necessário confiar na máquina executando o servidor ident. Deve ser observada a advertência: O Protocolo de Identificação não tem por objetivo ser um protocolo de autorização ou de controle de acesso.

4.2. Autenticação Ident através de soquetes locais

Nos sistemas que possuem a opção SO_PEERCRED para os soquetes do domínio Unix (atualmente Linux, FreeBSD, NetBSD, OpenBSD e BSD/OS), a autenticação ident também pode ser aplicada para as conexões locais. Neste caso nenhum risco à segurança é introduzido pela utilização da autenticação ident; na verdade, esta é a escolha preferida para as conexões locais nestes sistemas.

Em sistemas que não possuem a opção SO_PEERCRED, a autenticação ident está disponível somente através das conexões TCP/IP. Para superar este problema, é possível especificar o endereço 127.0.0.1 do localhost, e se conectar a este endereço. Este método é tão confiável quanto o servidor ident local.

4.3. Mapas de Ident

Ao utilizar a autenticação baseada no ident, após determinar o nome de usuário do sistema operacional que iniciou a conexão o PostgreSQL verifica se este usuário pode se conectar como o usuário de banco de dados que está sendo solicitado na conexão. Isto é controlado pelo argumento do mapa de ident que segue a palavra chave ident no arquivo pg_hba.conf. Existe um mapa de ident pré-definido chamado sameuser, que permite todo usuário do sistema operacional se conectar como o usuário de banco de dados com o mesmo nome (se este existir). Os outros mapas devem ser criados manualmente.

Fora o sameuser, os mapas de ident são definidos no arquivo de mapa de ident que, por padrão, se chama pg_ident.conf e é armazenado no diretório de dados do agrupamento. A forma geral das linhas do mapa de ident é:

nome_do_mapa nome_de_usuário_do_ident nome_de_usuário_do_banco_de_dados

Os comentários e os espaços em branco são tratados da mesma maneira que no arquivo pg_hba.conf. O nome_do_mapa é um nome arbitrário a ser utilizado para fazer referência ao mapa em pg_hba.conf. Os outros dois campos especificam qual usuário do sistema operacional pode se conectar como qual usuário do banco de dados. O mesmo nome_do_mapa pode ser utilizado várias vezes para especificar mais mapeamentos de usuários dentro de um único mapa. Não existe restrição com relação a quantos usuários do banco de dados um determinado usuário do sistema operacional pode corresponder, nem o contrário.

O arquivo pg_ident.conf é lido na inicialização e quando o processo servidor principal (postmaster) recebe um sinal SIGHUP. Se o arquivo for editado com o sistema ativo, será necessário enviar este sinal para o postmaster (utilizando pg_ctl reload ou kill -HUP) para fazer o arquivo ser lido novamente.

Um arquivo pg_ident.conf está mostrado no exemplo seguinte. Nesta configuração de exemplo, qualquer usuário autenticado em uma máquina da rede 192.168 que não possua o nome de usuário Unix oliveira, lia ou andre não vai ter o acesso permitido. O usuário Unix andre somente poderá acessar quando tentar se conectar como o usuário do PostgreSQL pacheco, e não como andre ou algum outro. A usuária lia somente poderá se conectar como lia. O usuário oliveira poderá se conectar como o próprio oliveira ou como guest1.

Exemplo: Arquivo pg_ident.conf de exemplo

# MAPNAME IDENT-USERNAME PG-USERNAME
omicron   oliveira       oliveira
omicron   lia            lia
# pacheco possui o nome de usuário andre nestas máquinas
omicron   andre          pacheco
# oliveira também pode se conectar como guest1
omicron   oliveira       guest1

5. Autenticação PAM

Este método de autenticação opera de forma semelhante ao método password, exceto por utilizar o mecanismo de autenticação PAM (Pluggable Authentication Modules). O nome padrão do serviço PAM é postgresql. É possível, opcionalmente, fornecer um outro nome de serviço após a palavra chave pam no arquivo pg_hba.conf.

Criação e restauração de cópias de segurança no PostgreSQL

Como tudo que contém dados importantes, devem ser feitas cópias de segurança dos bancos de dados do PostgreSQL regularmente. Embora o procedimento seja essencialmente simples, é importante possuir uma compreensão básica das técnicas e princípios subjacentes.

Existem duas abordagens fundamentalmente diferentes para fazer cópia de segurança dos dados do PostgreSQL:
· Método SQL-dump;
· Cópia de segurança no nível de sistema operacional.

1. Método SQL-dump

A idéia por trás do Método SQL-dump é gerar um arquivo texto contendo comandos SQL que, ao serem processados pelo servidor, recriam o banco de dados no mesmo estado em que este se encontrava quando o arquivo foi gerado. O PostgreSQL disponibiliza o programa utilitário pg_dump para esta finalidade. A forma básica de utilização deste programa é:

pg_dump nome_do_banco_de_dados > arquivo_de_saída

Conforme pode ser visto, o programa pg_dump escreve o seu resultado na saída padrão. Será visto abaixo como isto pode ser útil.

O pg_dump é uma aplicação cliente normal do PostgreSQL (embora seja particularmente astuta). Isto significa que o procedimento de cópia de segurança pode ser realizado a partir de qualquer hospedeiro remoto que possua acesso ao banco de dados. Porém, deve ser lembrado que o pg_dump não opera com permissão especial. Em particular, é necessário possuir acesso de leitura a todas as tabelas que se deseja fazer cópia de segurança. Portanto, na prática, quase sempre é necessário ser um superusuário do banco de dados.

Para especificar qual servidor de banco de dados o pg_dump deve se conectar, devem ser utilizadas as opções de linha de comando -h hospedeiro e -p porta. O hospedeiro padrão é o hospedeiro local, ou o que estiver especificado na variável de ambiente PGHOST. De maneira semelhante, a porta padrão é indicada pela variável de ambiente PGPORT ou, na falta desta, pelo padrão de compilação (Por conveniência, o servidor normalmente é compilado usando o mesmo padrão).

Assim como qualquer outra aplicação cliente do PostgreSQL, o pg_dump se conecta por padrão ao banco de dados com o usuário cujo nome é igual ao nome do usuário corrente do sistema operacional. Para que seja outro, deve ser especificada a opção -U, ou definida a variável de ambiente PGUSER. Não deve ser esquecido que as conexões do pg_dump estão sujeitas aos mecanismos normais de autenticação de cliente.

As cópias de segurança criadas pelo pg_dump são consistentes internamente, ou seja, as atualizações feitas no banco de dados enquanto o pg_dump está executando não estão resentes na cópia de segurança. O pg_dump não bloqueia outras operações no banco de dados enquanto está executando (Exceto as operações que necessitam operar com modo de bloqueio exclusivo, como o VACUUM FULL).

Importante: Quando o esquema do banco de dados é dependente dos OIDs (como chaves estrangeiras, por exemplo) deve-se instruir o pg_dump para que também inclua os OIDs. Para que isto seja feito, deve ser utilizada a opção de linha de comando -o. Também, não são feitas cópias de segurança dos "objetos grandes" por padrão. Se forem utilizados objetos grandes, deve ser vista a página de referência do programa pg_dump.

1.1. Restauração da cópia de segurança

Os arquivos texto criados pelo programa pg_dump são feitos para serem lidos pelo programa psql. A forma geral do comando para restaurar uma cópia de segurança é:

psql nome_do_banco_de_dados < arquivo_de_entrada

onde o arquivo_de_entrada é o que foi utilizado como arquivo_de_saída pelo programa pg_dump. O banco de dados nome_do_banco_de_dados não será criado por este comando, devendo ser criado a partir de template0 antes de executar o psql (por exemplo, usando createdb -T template0 nome_do_banco_de_dados). O psql possui opções semelhantes às do pg_dump para controlar a identificação do servidor de banco de dados e o nome do usuário. Para obter mais informações deve ser vista a página de referência do programa psql.

Se no banco de dados original os objetos pertencem a usuários diferentes, então a cópia de segurança instrui o psql a se conectar como cada usuário afetado por vez, e depois criar os objetos relevantes. Desta forma o dono original é preservado. Entretanto, isto também significa que todos estes usuários devem existir, e que é possível se conectar como cada um deles. Portanto, pode ser necessário fazer um relaxamento temporário das definições de autenticação de clientes.

Uma vez feita a restauração, é sensato executar o comando ANALYZE em cada um dos bancos de dados, para que o otimizador possua estatísticas úteis. Uma forma fácil de se fazer é executando vacuumdb -a -z para efetuar o VACUUM ANALYZE de todos os bancos de dados; equivale a executar VACUUM ANALYZE manualmente.

A capacidade do pg_dump e do psql de escrever e ler de pipes torna possível replicar um banco de dados de um servidor para outro diretamente; por exemplo:

pg_dump -h hospedeiro1 nome_do_banco_de_dados | psql -h hospedeiro2 nome_do_banco_de_dados

Importante: As cópias de segurança produzidas pelo pg_dump são relativas a template0. Isto significa que todas as linguagens, procedimentos, etc. adicionados a template1 também serão incluídos na cópia de segurança feita pelo pg_dump. Como resultado, se estiver sendo utilizado um banco de dados template1 personalizado, ao ser feita a restauração deve ser criado um banco de dados vazio a partir de template0, conforme mostrado no exemplo acima.

Dica: O desempenho da restauração pode ser melhorado pelo aumento do parâmetro de configuração sort_mem.

1.2. Utilização do pg_dumpall

O mecanismo mostrado acima não é cômodo nem apropriado para fazer a cópia de segurança de um agrupamento de bancos de dados. Por este motivo é fornecido o programa pg_dumpall. O pg_dumpall faz a cópia de segurança de todos os bancos de dados de um agrupamento, e também salva dados de todo o agrupamento, como os usuários e grupos. A forma básica de utilização deste programa é:

pg_dumpall > arquivo_de_saída

A cópia de segurança gerada pode ser restaurada pelo psql usando:

psql template1 < arquivo_de_entrada

(Na verdade, pode ser especificado qualquer nome de banco de dados existente para começar, mas se estiver sendo feita a restauração em um agrupamento vazio, então template1 é a única escolha disponível). É sempre necessário possuir acesso de superusuário do banco de dados para fazer a restauração de uma cópia de segurança gerada pelo pg_dumpall, para poder restaurar as informações de usuário e de grupo.

1.3. Tratamento de bancos de dados grandes

Uma vez que o PostgreSQL permite a existência de tabelas maiores do que o tamanho máximo de arquivo do sistema operacional, pode ser problemático fazer a cópia de segurança de uma tabela como esta em um arquivo, uma vez que o arquivo resultante provavelmente será maior do que o tamanho máximo permitido pelo sistema operacional. Como o pg_dump pode escrever na saída padrão, podem ser utilizadas as ferramentas padrão do Unix para superar este possível problema.

Utilização de cópias de segurança comprimidas: Pode ser utilizado o programa de compressão favorito como, por exemplo, o gzip.

pg_dump nome_do_banco_de_dados | gzip > nome_do_arquivo.gz

Restaurar com

createdb nome_do_banco_de_dados
gunzip -c nome_do_arquivo.gz | psql nome_do_banco_de_dados

ou

cat nome_do_arquivo.gz | gunzip | psql nome_do_banco_de_dados

Utilização do comando split: O comando split permite dividir a saída em blocos de tamanho aceitável para o sistema de arquivos subjacente. Por exemplo, para fazer blocos de 1 megabyte:

pg_dump nome_do_banco_de_dados | split -b 1m - nome_do_arquivo

Restaurar com

createdb nome_do_banco_de_dados
cat nome_do_arquivo | psql nome_do_banco_de_dados

Utilização de formatos de cópia de segurança personalizados. Se o PostgreSQL foi construído em um sistema com a biblioteca de compressão zlib instalada, o formato de cópia de segurança personalizado comprime os dados ao escrever o arquivo de saída. Produz cópias de segurança com tamanhos semelhantes às produzidas utilizando o gzip, mas tem a vantagem adicional de permitir a restauração seletiva das tabelas. O comando abaixo gera a cópia de segurança do banco de dados utilizando o formato de cópia de segurança personalizado (custom dump format):

pg_dump -Fc nome_do_banco_de_dados > nome_do_arquivo

O formato de cópia de segurança personalizado não é um script para o psql, devendo ser restaurado pelo pg_restore. Para obter detalhes devem ser vistas as referências do pg_dump e do pg_restore.

1.4. Precauções

O pg_dump (e consequentemente o pg_dumpall) possui algumas poucas limitações causadas pela dificuldade de reconstruir certas informações a partir dos catálogos do sistema.

Especificamente, a ordem utilizada pelo pg_dump para escrever os objetos não é muito sofisticada. Isto pode causar problemas como, por exemplo, quando são utilizadas funções como valor padrão de colunas. A única solução é reorganizar manualmente a cópia de segurança. Se forem criadas dependências circulares no esquema, então haverá mais trabalho a ser feito.

Por motivo de compatibilidade com as versões anteriores, o pg_dump não faz cópia de segurança dos objetos grandes por padrão. Para fazer cópia de segurança dos objetos grandes deve ser utilizado o formato de saída personalizado ou o formato tar, e utilizada a opção -b do pg_dump. Para obter detalhes deve ser vista a referência do pg_dump. O diretório contrib/pg_dumplo, da árvore do código fonte do PostgreSQL, também contém um programa que pode ser utilizado para fazer cópias de segurança dos objetos grandes.

Por favor, se familiarize com a referência do pg_dump.