servidores 0.7 2

IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Administração redes cliente–servidor
Gnu/Linux
Luís Machado 2013
Pag. 1
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Mudar as cores da consola em INIT3
Depois do arranque do sistema pode-se mudar as cores da consola de duas formas. Podem lembrarse os códigos ANSI depois de se fazer o respectivo “echo”, ou pode usar-se o comando setterm para
fazer essas alterações. Para se colocar fundo branco e fonte preta tem de usar-se o código seguinte:
setterm -background white -foreground white -store
A “man page” do setterm contém informações completas sobre as várias opções e os valores válidos
de cor. Pode executar-se este comando a partir de um script de inicialização, os caminhos dos
ficheiros sãodependentes da distribuição, mas /etc/rc.local é muitas vezes um bom ponto de partida.
Se se pretender mudar as cores desde o início, é necessário editar o código fonte do kernel para
alterar as cores padrão e recompilar posteriormente o kernel. O arquivo a ser editado é
drivers/char/vt.c (era drivers/char/console.c com kernels mais antigos); encontrar as linhas que
começam com
vc->vc_def_color
= 0x07; /* white */
Esta é a linha 2739 no código fonte do kernel 2.6.22. Os dois dígitos hexadecimais representam o
fundo e o primeiro plano, então 0x07 é o padrão branco no preto, enquanto que 0x70 seria o cenário
inverso, ou seja preto no branco. Alteram-se os valores para as cores desejadas e recompila-se o
kernel da maneira habitual. Os números para as várias cores são:
0 ................black
1 ................blue
2 ...............green
3 ...............cyan
4 ...............red
5 ...............purple
6 ...............brown/yellow
7 ...............white
Adicionar o algarismo 8 a estes números para obter as versões "brilhantes", mas o “rendering” de
cores “brilhantes” é dependente do hardware e pode piscar em alguns sistemas.
Luís Machado 2013
Pag. 2
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Para alterar a resolução da consola e consequentemente a resolução da fonte (maior ou menor)
introduzir no grub.conf a opção vga=*** no kernel. O grub.conf está em:
/boot/grub/grub.conf
e a entrada do kernel deverá ser como no exemplo seguinte:
kernel vmlinuz-2.6.32-358.e16.x86_64 ro root=/dev/mapper/vg_formacao-l vga=****
A tabela seguinte mostra os modos de vídeo que se podem utilizar (poderão variar ligeiramente com
as especificações) do hardware.
Colour depth
640x480
800x600
1024x768
1280x1024
8 (256)
769
771
773
775
15 (32K)
784
787
790
793
16 (65K)
785
788
791
794
24 (16M)
786
789
792
795
1400x1050
1600x1200
834
884
Alterar a fonte na consola em INIT3
Existem vária formas de alterar a fonte da consola como se pode comprovar pela documentação
digital ou tradicional (em papel).
Uma das formas é usar o comando setfont. A sintaxe do comando é a seguinte:
setfont /caminho _para_consolefonts/nome_da_fonte
Um exemplo para o CentOS é:
setfont /lib/kbd/consolefonts/lat2a-16.psfu.gz
Esta forma de mudança de fonte não é permanente para todos os utilizadores, apenas para o
utilizador corrente.
Luís Machado 2013
Pag. 3
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Para se modificar permanentemente a fonte da consola deve alterar-se o ficheiro em:
/etc/sysconfig/i18n
No ficheiro i18n deve-se procurar a entrada “SYSFONT” e alterá-la de acordo com a fonte
desejada. O seguinte exemplo mostra como deve ficar esta entrada com uma fonte diferente da que
é chamada por defeito.
…
SYSFONT=”iso06.14″
…
Vizualização da data e sua alteração
A visualização da data é feita com o comando “date”.
form@form:~$ date
Sun Apr 28 22:41:48 WEST 2013
Para se alterar a data basta usar as opções do comando como nos exemplo descritos a seguir:
$date -d mm/dd/yy
$date -s hh:mm:ss
Visualização do calendário
O comando “cal” permite a visualização do calendário do mês corrente. Para se visualizar o
calendário de um ano basta acrescentar o ano.
Visualização do espaço ou tamanho das directorias e discos
Para visualizar o tamanho de directórios utiliza-se o comando “du”.
Exemplo:
du -h ~/downloads
Luís Machado 2013
Pag. 4
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Para visualizar o tamanho de discos utiliza-se o comando “df”.
Exemplo:
df -h /dev/sda1
Runlevels (ou níveis de execução)
Em Gnu/Linux os “runlevels” são estados de configuração do sistema operativo nos quais apenas
determinados processos ou serviços estão activos.
Os “runlevels” permitem definir diversos estados de funcionamento do servidor, tendo cada estado
o seu conjunto específico de serviços e processos activos.
No arranque do sistema operativo o administrador definiu previamente o “runlevel” que deseja para
o servidor (ou desktop) definindo também os respectivos serviços a iniciar.
A tabela seguinte identifica os “runlevels” disponíveis assim como o propósito da utilização.
Runlevels
Propósito de utilização
0
Paragem “halt” do sistema
1
Modo “single user”
2
Modo reservado
3
Modo multi-utilizador (consola em modo de texto)
4
Modo reservado
5
Modo multi-utilizador (modo gráfico e consola em modo de texto)
6
“Reboot” do sistema
Os servidores arrancam normalmente em “init3” ou “init5”. Com o arranque em “init5” tem-se à
disposição o modo gráfico. Na generalidade os servidores são acedidos remotamente, quer estejam
em bastidores ou mesmo noutra localização mesmo que remota (outra cidade, outro edifício, etc).
No caso de estarem nesta situação os servidores não necessitam de ter o modo gráfico activo pelo
que o “runlevel 3” é o mais aconselhado já que poupa recursos. Os serviços disponibilizados são os
mesmos para os dois “runlevels” com excepção, claro está, da consola gráfica.
Os modos de execução (runlevels) 2 e 4 estão reservados para que o utilizador possa configurá-los à
sua medida. Somente em casos especiais é que se recorre a esta configuração já que com os
Luís Machado 2013
Pag. 5
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
“runlevels” 3 e 5 se podem activar e definir quais os serviços que estarão disponíveis no arranque
do sistema.
O “runlevel 0” corresponde à paragem do sistema com a terminação de todos os serviços, ou seja
desligar o servidor.
O “runlevel 6” corresponde ao “reboot” do sistema.
O “runlevel 1” corresponde ao modo “single-user” e é utilizado para realizar operações de
manutenção. Neste estado os serviços de rede não são activados pelo que comunicação com o
“exterior” está vedada. As operações críticas como a recuperação de cópias de segurança ou
recuperação do sistema após uma mal sucedida actualização do sistema devem ser feitas desta
forma. Claro está que estas operações de manutenção têm de ser feitas localmente.
O administrador pode entrar no modo “init1” através do GRUB. Esta situação é importante caso o
administrador se esqueça da palavra passe. O GRUB tem uma “shell” em que o administrador pode,
através de alguns comandos carregar o kernel e definiruma nova password através do comando
“password”.
O processo “init” é o primeiro a ser activado quando o sistema operativo arranca. Este vai carregar
o “runlevel” definido para o arranque.
O runlevel inicial é configurado no ficheiro /etc/inittab. Este ficheiro tem uma directiva de
configuração como o nome de initdefault que define o runlevel pretendido para o servidor.
#/etc/inittab – vista parcial do ficheiro
id:3:initdefault
Neste exemplo o “runlevel” de arranque será o 3.
O sistema operativo disponibiliza alguns comandos para monitorizar e controlar os runlevels.
A tabela seguinte mostra alguns destes comandos e a sua utilização ou funcionamento.
Comando
Funcionamento
Init [0...6]
Altera o nível de execução actual do sistema
runlevel
Determina os níveis de execução actual e anterior do sistema
halt
Pára o sistema (mesmo que init 0)
reboot
Reinicializa o sistema (mesmo que init 6)
poweroff
Pára o sistema e desliga o computador
shutdown
Pára o sistema de forma segura
Como se pode verificar alguns destes comandos realizam na prática a mesma função que a
utilização dos init. O comando reboot tem a mesma função que init 6.
Luís Machado 2013
Pag. 6
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Como já foi referido anteriormente o nível de execução ou runlevel tem como objectivo activar o
sistema operativo com os serviços necessários para aquela função específica. Os serviços a serem
activados estão presentes no ficheiro /etc/services. Neste ficheiro estão os serviços conhecidos pelo
sistema operativo identificados pelo nome, porto e protocolo(s) utilizado(s).
No arranque do sistema o init vai ler o conteúdo do ficheiro services e os ficheiros configurados no
respectivo runlevel são activados.
Os serviços podem ser reinicializados através de um sinal enviado ao init como por exemplo:
$service smbd restart
Os serviços podem ter dois modos de funcionamento: o modo standalone e o modo xinetd.
No modo standalone, que são a maioria dos serviços de um servidor, os serviços são suportados
por daemons (processos). Os serviços são controlados por scripts próprios que se encontram no
directório /etc/rc.d/init.d. Este directório é no CentOS o responsável por albergar estes mesmos
scripts mas noutras distribuições podem ter um directório diferente, mas sempre dentro de /etc.
Os serviços podem ser como foi dito anteriormente controlados pelo comando service no entanto
pode controlar-se através do caminho para /etc/rc.d/init.d/serviço função.
$/etc/rc.d/init.d/smbd restart
Para se conhecer todas as opções de funções de um serviço basta invocar esse mesmo serviço:
$service smbd
Usage: /etc/init.d/smbd {start|stop|restart|reload|condrestart|status}
Os serviços activos para um determinado runlevel estão referenciados por links simbólicos nos
directórios correspondentes de cada runlevel em /etc/rc(runlevel).d. Por exemplo para o runlevel 5
o directório correspondente será /etc/rc5.d. Os serviços que começam com o nome “S” são para
activar (start) e os que começam por “K” são para desactivar (kill).
O número que aparece após estas letras serve para indicar o número de ordem para activação ou
desactivação dos serviços. É necessário ter em conta este número de ordem já que alguns serviços
dependem de outros para funcionarem correctamente. O serviço de email só poderá ser activado
após o serviço de rede (placa de rede) estar activo. Estes links simbólicos apontam para o directório
/etc/rc.d/init.d.
A criação destes links simbólicos torna-se mais fácil utilizando os comandos chkconfig ou setup.
Luís Machado 2013
Pag. 7
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
$chkconfig --list
…
networking
0:nao 1:nao 2:nao 3:sim 4:nao 5:sim 6:nao
…
Neste caso o comando lista todos os serviços e aqui mostra-se o serviço “networking” como activo
nos runlevels 3 e 5 o desactivado para os restantes.
Os exemplos seguintes mostram como activar ou desactivar serviços para runlevels.
$chkconfig --level 35 httpd on
$chkconfig --level 35 nfs off
No modo XINETD são controlados serviços que apenas pontualmente precisam de ser chamados.
Como não estão permanentemente activos ou a serem necessários pelo sistema são controlados pelo
xinetd sendo ele próprio um serviço standalone.
Este mecanismo serve essencialmente para poupar recursos de memória e processamento.
O ficheiro de configuração principal do xinetd é o /etc/xinetd.conf. Neste ficheiro de configuração
estão definidas algumas opções globais assim como as configuração específicas dos serviços
disponibilizados via xinetd. Estas últimas configurações estão armazenadas no directório
/etc/xinetd.d.
A sintaxe e os parâmetros de configuração do ficheiro xinetd.conf e dos ficheiros individuais em
/etc/xinetd.d, são as mesmas.
Algumas das configurações do ficheiro xinetd.conf incluem a forma como os logs são tratados.
Uma opção possível tem a ver com o parâmetro log_type= syslog daemon info, que especifica que
os logs são efectuados recorrendo ao serviço syslog através do daemon e nível info. A opção
log_on_failure=HOST configura o xinetd para registar nos logs o IP das máquinas clientes cujas
ligações falharam ou foram recusadas. A opção log_on_success=PID HOST DURATION EXIT
permite registar as ligações com sucesso com o PID e o IP do cliente que pediu o acesso, a duração
e quando saiu.
Os ficheiros de configuração dos serviços do xinetd em /etc/xinetd.d são incluídos na sua
configuração através da inclusão da directiva includedir /etc/xinetd.d. Já foi referido que estes
ficheiros permitem o controlo dos serviços por parte do xinetd e cada um tem o seu ficheiro
individual com o seu nome.
Por exemplo o serviço telnet terá o seu ficheiro e poderá ser como o exemplo seguinte:
Luís Machado 2013
Pag. 8
IEFP – Centro Formação Profissional Braga
$more /etc/xinetd.d/telnet
#default: on
service telnet
flags
socket_type
wait
user
server
log_on_failure
disable
Técn. Inst. Gestão de Redes Informáticas
=REUSE
=stream
=no
=root
=/usr/sbin/in.telnetd
=USERID
=no
A informação detalhada pode encontrar-se no manual do xinetd.conf (man xinetd.conf) de como
configurar estes ficheiros.
Sempre que se façam alterações ao xinetd.conf ou aos ficheiros de configuração individuais em
xinetd.d deve-se fazer o reload do serviço xinetd.
$service xinetd reload
Relembra-se que assim deve ser já que o xinetd é um serviço standalone.
TCP Wrappers
Os TCPWrappers são serviços “invisíveis” que servem para adicionar segurança na comunicação do
cliente com os serviços requisitados ao servidor. Os tcpwrappers podem funcionar paralelamente
com outros serviços de segurança como firewalls.
Neste contexto, os tcpwrappers fornecem mais uma camada de protecção para acesso aos serviços
no servidor por parte dos clientes.
No pacote “tcp_wrappers” a libraria libwrap.a é chamada pelos serviços requisitados para fazer o
controlo de acesso aos serviços.
Quando um cliente tenta ligar-se a um serviço controlado com tcpwrapper os ficheiros
/etc/hosts.allow e /etc/hosts.deny são lidos. O primeiro a ser lido é o hosts.allow e só depois de
não ser encontrada nenhuma regra é que passa a ler o hosts.deny.
As mensagens de entre clientes e servidor são guardadas em /var/log/secure e /var/log/messages.
Após a aceitação da comunicação entre o cliente e o serviço o TCPWrapper não volta a ter
interferência na comunicação entre eles.
Alguns dos serviços/servidores têm ligação directa (link) com a libraria libwrap.a permitindo uma
administração mais eficiente por parte dos administradores.
Luís Machado 2013
Pag. 9
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Uma forma de verificar se o serviço está ligado ao tcpwrapper é através do comando:
ldd <nome_serviço> | grep libwrap
Se o serviço não está ligado ao tcpwrapper ocomando não irá dar nenhum resultado e a consola
volta para o “prompt”. Caso contrário o resultado será com o do exemplo seguinte.
[root@formacao ~]# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00655000)
[root@formacao ~]#
A sintaxe de configuração dos ficheiros hosts.allow e hosts.deny é da forma:
lista de daemons: lista de clientes [: opção: opção: ...]
A lista de daemons pode ser mesmo um conjunto de daemons ou apenas um mas deve colocar-se o
nome do daemon e não o nome do serviço (sshd e não ssh). Para vários daemons devem separar-se
por virgulas.
A lista de clientes pode pode ser um cliente, um host ou um domínio. A forma da configuração é
semelhante à da lista de daemons.
Na opção vai colocar-se se é allow ou é deny, autoriza ou nega a ligação ao serviço. Outras opções
são também aceites.
Nos exemplos seguintes mostra-se como se podem configurar os dois ficheiros de configuração.
vsftpd : .example.com
Se for no ficheiro hosts.allow, todos os computadores do domínio example.com serão autorizados,
se for a configuração do ficheiro hosts.deny o acesso será negado.
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
Neste exemplo os clientes de exemple.com quando tentam ligar ao serviço ssh, um “echo” é
executado com a mensagem de tentativa de acesso a ser colocada em sshd.log e o acesso é negado.
ALL : .example.com
Neste exemplo todos ao serviços são aceites para todos os hosts do domínio exemple.com.
Luís Machado 2013
Pag. 10
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
ALL : 192.168.
Neste exemplo todos os serviços são aceites por parte de hosts da gama de IP 192.168.X.X.
in.telnetd : /etc/telnet.hosts
Neste exemplo o telnet vai aceitar apenas os hosts que estão no ficheiro telnet.hosts.
ALL EXCEPT vsftpd: 192.168.0.
Neste exemplo são aceites todos os pedidos de serviços excepto o ftp e por parte dos IP da gama
192.168.0.X.
Outros serviços de rede
O(s) protocolo(s) de rede mais utilizado(s) nos dias que correm é o TCP/IP. As classes de rede, a
respectiva máscara e gama de IP's admissíveis por cada classe é conhecida.
Em Linux e nomeadamente no CentOS existem no entanto alguns ficheiros que são muito
importantes para a configuração de serviços de rede para que esta funcione sem problemas.
A tabela seguinte refere estes ficheiros e a sua utilização.
Ficheiro de configuração
Propósito de utilização do ficheiro
/etc/host.conf
Ordem pela qual são efectuadas as resoluções de DNS
/etc/hosts
Registo de nomes e endereços locais
/etc/resolv.conf
Endereços de servidores DNS na rede local
/etc/sysconfig/network
Nome da máquina e endereço do router (default gateway)
/etc/sysconfig/network-scripts Directório para os scripts de configuração das interfaces de rede
A visualização do ficheiro host.conf permite verificar como é feita a procura das resoluções de DNS
da máquina.
A configuração mais corrente neste ficheiro é da forma:
#Conteúdo do ficheiro /etc/host.conf
order hosts,bind
Significa isto que a procura de nomes vai ser feita pela ordem que está configurada no ficheiro hosts
Luís Machado 2013
Pag. 11
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
e que o serviço de DNS vais ser activado.
No caso do CentOs 6.4 vem com a configuração por defeito:
#Conteúdo do ficheiro /etc/host.conf
multi on
Nesta configuração o serviço de DNS vais fazer a procura do nome em todos os hosts do ficheiro
/etc/hosts e não apenas pela ordem que eles têm no dito ficheiro.
Outras opções de configuração podem facilmente ser consultadas no manual do ficheiro (man
host.conf).
O ficheiro /etc/hosts é utilizado para fazer a correspondência entre nomes de servidores e
respectivos IP's apenas no servidor local. Normalmente este ficheiro apenas serve para associar o
nome da máquina ao seu endereço de loopback que é o 127.0.0.0.
Este ficheiro é, no entanto, essencial para o funcionamento de serviços e programas que requeiram a
comunicação por TCP/IP. Assim estes serviços e programas comunicam desta forma dentro da
própria máquina. O formato deste ficheiro é IP (source); Domínio (domain); Nomes_da_máquina
(hostnames).
Um ficheiro que é também muito importante na configuração do serviço de rede já que contem os
parâmetros do cliente de DNS do sistema. O resolver é o programa ou componente do sistema
operativo que implementa a funcionalidade de cliente de DNS. Assim recorre a este ficheiro para
fazer a procura dos nomes dos hosts que necessita.
Um exemplo de configuração deste ficheiro é a que se mostra a seguir.
#Conteúdo do ficheiro hosts
search
domínio1 domínio2 …
domain
domínio_da_máquina
nameserver
10.0.0.1
nameserver
10.0.0.2
Como se pode ver pelo exemplo a directiva “search” permite procurar um nome em vários
domínios. A directiva “domain” indica o domínio em que a máquina se encontra. As directivas
“nameserver” têm a indicação dos servidores primário e secundário, de DNS, que devem ser
consultados. O servidor que aparece em primeiro lugar será o servidor primário.
O ficheiro /etc/sysconfig/network permite fazer uma configuração mais geral da rede em que está
Luís Machado 2013
Pag. 12
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
inserida a máquina. Pode aqui activar-se a rede, definir o gateway assim como o nome da máquina
na rede. O exemplo seguinte mostra isso mesmo.
#Conteúdo do ficheiro /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=formacao.dom
GATEWAY=192.168.0.1
Para que se possam configurar individualmente as interfaces de rede o directório
/etc/sysconfig/network_scripts contem um ficheiro individual para cada um dessas interfaces. Os
ficheiros têm o nome de ifcfg-nome_da_interface. No caso da primeira interface activada no
sistema ter-se-há o nome ifcfg_eth0, para a segunda ifcfg_eth1, para uma interface wireless
ifcfg_wlan0, etc.
Um exemplo da configuração destas interfaces é o seguinte:
#Configuração de ifcfg_eth0
DEVICE=eth0
HWADDR=00:0C:29:E4:EA:CD
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=dhcp
DHCP_HOSTNAME=dns_formacao.dom
Neste exemplo as configurações de comunicação de rede são obtidas por dhcp. Para o caso de se ter
IP's estáticos, a configuração seria como o exemplo seguinte:
#Configuração de ifcfg_eth0
DEVICE=eth0
HWADDR=00:0C:29:E4:EA:CD
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
Luís Machado 2013
Pag. 13
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
IPADDR=192.168.0.200
NETMASK=255.255.255.0
As interfaces de rede em Linux podem ter uma funcionalidade interessante que é a possibilidade de
terem endereços de rede alternativos. Estes IP's alternativos são designados por alias (diferentes dos
alias de comandos de consola). Os ficheiros dos alias têm o nome da forma ifcfg-interface:alias.
Assim para um alias de eth0 ficaria o seu ficheiro de configuração com o nome ifcfg-eth0:0. Esta
funcionalidade é importante quando se quer várias interfaces de rede virtuais e apenas se tem um
física. Uma firewall ou um router é um exemplo de aplicação, com limitações de tráfego mas
funcional.
Um exemplo de como se deve configurar apresenta-se de seguida. A configuração é idêntica à
anteriormente apresentada para eth0.
#Configuração de ifcfg_eth0
DEVICE=eth0:0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.210
NETMASK=255.255.255.0
BROADCAST=192.168.0.255
As interfaces de rede e os serviços de rede são configurados pelos seus respectivos ficheiros mas
para que esses serviços possam ser monitorizados e controlados de forma expedita o administrador
tem ao seu dispor comandos de consola para esse mesmo fim.
O comando ifconfig é um comando que permite verificar as configurações das interfaces (ou
placas) de rede. O comando ifconfig pode ser utilizado como “configurador” da interface
fornecendo-lhe IP e mascara de rede.
ifconfig eth0 10.0.2.2 netmask 255.255.255.0
O comando ifconfig permite também activar ou desactivar as interfaces de rede.
ifconfig eth1 up
ifconfig eth2 down
Luís Machado 2013
Pag. 14
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
O comando route é também bastante importante já que permite a monitorização e gestão das tabelas
encaminhamentos de rede (routing tables). De forma análoga que o ifconfig podem verificar-se as
rotas da tabela de encaminhamentos estão correctas, adicionar rotas ou suprimi-las.
A tabela de encaminhamentos é criada no arranque é criada pelos scripts de arranque do sistema
operativo após a activação das interfaces de rede.
Seguidamente mostram-se alguns exemplos da aplicação prática deste comando.
form@formacao ~$route -n
Kernel IP routing table
Destination
Gateway
Genmask
Flags Metric Ref
Use
Iface
192.168.75.0 0.0.0.0
255.255.255.0
U
0
0
0
eth0
192.168.204.0 0.0.0.0
255.255.255.0
U
0
0
0
eth1
Neste exemplo verificou-se quais as rotas presentes na tabela de encaminhamentos.
No exemplo seguinte adiciona-se o gateway, e mais duas rotas que têm o mesmo gateway definido
anteriormente.
form@formacao~$ route add default gw 192.161.100.1
form@formacao~$ route add -net 192.168.100.12/24 gw 192.161.100.1
form@formacao~$ route add -net 193.136.121.95/26 gw 192.161.100.1
Para se apagar uma rota faz-se o comando seguinte:
form@formacao~$ route del -net 192.168.100.12/24 gw 192.161.100.1
Fazendo a verificação à tabela de encaminhamentos previamente a ser aplicado o comando anterior,
obtém-se o seguinte:
form@formacao ~$route -n
Kernel IP routing table
Luís Machado 2013
Pag. 15
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Destination
Gateway
Genmask
Flags Metric Ref
Use
Iface
192.168.75.0
0.0.0.0
255.255.255.0
U
0
0
0
eth0
192.168.204.0
0.0.0.0
255.255.255.0
U
0
0
0
eth1
192.168.100.12
192.168.100.1 255.255.255.0
UG
0
0
0
eth0
193.136.121.95
192.168.100.1 255.255.255.192
UG
0
0
0
eth0
0.0.0.0
192.168.100.1
UG
0
0
0
eth0
0.0.0.0
Nestes exemplos as “FLAGS” U e G significam que a rota está activa e que a rota é efectuada por
gateways, respectivamente.
Na última linha indica-se que todos os pacotes que não estejam referenciados por qualquer das rotas
anteriores anteriores sejam direccionados para o default gateway.
Um dos programas mais utilizados para monotorizar as ligações de rede é o netstat. Com este
software pode-se saber quais os portos activos, nos respectivos sockets assim como serviços e PID,
etc. A sua utilização é muito vasta pelo que para se ter um conhecimento mais profundo deve
consultar-se “man netstat”.
Como exemplos podem referir-se as opções netstat -i que mostra uma estatística das comunicações
das interfaces de rede. A opção netstat -l lista os sockets activos e preparados para receberem
comunicações. A opção netstat -s mostra estatísticas sobre a utilização dos vários protocolos de
rede.
Outro pequeno software que pode ser útil para analisar o tráfego da rede é o tcpdump. O tcpdump
não é mais do que um “sniffer” clássico que captura os pacotes de comunicação na rede ou numa
determinada máquina.
$tcpdump host 10.0.1.2
…..
$tcpdump -i eth0 tcp
…..
No primeiro exemplo a captura de todos os pacotes é feita no servidor 10.0.1.2. No segundo
exemplo os pacotes tcp são capturados na interface de rede eth0. As opções deste comando são
Luís Machado 2013
Pag. 16
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
imensas e por essa razão a leitura de “man tcpdump” é imprescindível.
Caso se queira uma análise mais completa e respectiva reconstrução das comunicações feitas pelos
protocolos nas interfaces de rede pode utilizar-se o programa wireshark. O wireshark pode utilizarse em modo consola que é muito útil para ligações remotas ou em modo gráfico com o wiresharkgnome.
$tshark -i eth0
…....
Com este comando os pacotes são capturados em eth0. Este comando permite que os pacotes sejam
capturados mesmo aqueles que não se destinam ou não têm como origem a máquina local.
Backups
Os “backups” ou cópias de segurança em português são um aspecto muito importante dos sistemas
informáticos e de redes. Os backups têm algumas soluções disponíveis e que devem ter em conta
não só o tipo de informação mas também o suporte em que a informação é guardada.
Relativamente à informação a salvaguardar poder-se-há dividir em 3 grupos: o sistema operativo, os
restantes programas e os ficheiros dos utilizadores.
O sistema operativo e os seus ficheiros de configuração podem ser salvaguardados totalmente,
criando uma imagem da partição ou apenas parcialmente. Em sistemas como servidores de DHCP,
DNS ou outros apenas poderá ser necessário fazer o backup dos ficheiros de configuração já que
por vezes é mais rápido instalar o sistema operativo dos que repor a imagem do sistema operativo.
Relativamente aos programas e seus ficheiros de configuração pode ter-se duas opções: ou ter um
backup apenas com conteúdos (bases de dados ou páginas WWW) ou backup com todo o pacote do
programa, ficheiros de configuração e conteúdos dos programas. Esta última opção pode ser
considerada acertada quando a instalação do software, seus programas acessórios e configuração
forem complicados e muito morosos.
Os ficheiros dos dados dos utilizadores são muitas vezes os dados mais importantes a ter em conta
na altura de fazer backups. Para muitas instituições esta informação é mais vital do que o sistema
operativo ou os ficheiros de configuração. Os backups dos dados dos utilizadores deverão ser
efectuados mais frequentemente e de forma completa, na maioria dos casos.
Deve-se analizar agora o tipo de backups que se podem fazer. Dito assim pode podem fazer-se
Luís Machado 2013
Pag. 17
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
backups completos, incrementais e diferenciais.
Os backups completos envolvem o armazenamento dos dados de todos os ficheiros de uma partição
ou de um directório. Necessariamente a quantidade de dados a armazenar será muito grande e
envolve grandes espaços no dispositivo de armazenamento. Estes backups são realizados com
menor frequência.
Os backups incrementais fazem uma verificação para cada ficheiro se este foi alterado desde o
último backup. Desta forma um backup incremental apenas adiciona os ficheiros alterados desde o
último backup tornando o processo mais rápido e com um tamanho menor do que fazendo backups
completos. Uma desvantagem tem a ver com o facto de quando se quer encontrar um determinado
ficheiro ter de procurar em mais que um ficheiro incremental e por vezes em diferentes unidades de
suporte (por exemplo unidades de fita magnética).
Quando se fizer a reposição total de um backup tem de se ter em conta que deve em primeiro lugar
repor-se o backup total mais recente e depois ir repondo os incrementais pela ordem que foram
efectuados.
Os backups diferenciais são semelhantes aos incrementais uma vez que só os ficheiros modificados
são adicionados. A diferença está no facto de que uma vez que um ficheiro é adicionado a um
backup será sempre incluído em todos os backups diferenciais que se fizerem até ao próximo
backup completo.
Assim sendo, quando se repõe um backup apenas será necessário repor o último backup completo e
o último backup diferencial para o sistema ficar actualizado.
Dispositivos de backup
Os dispositivos de backups podem ser variados e vão desde as simples “pendrives”, passando pelo
cd's e dvd's, pelas tape's (fitas magnéticas), HDD ou discos rígidos e servidores de backups com os
seus discos rígidos em RAID.
As tapes podem ser do tipo DDS (Digital Data Storage), DAT (Digital Audio Storage), DLT (Digital
Line Tape) e LTO (Linear Tape-Open). Relativamente às DDS têm uma tecnologia semelhante às
DAT. O formato DDS-4 suporta 20Gb ou 40 Gb com compressão. O formato DAT 72 suporta 36Gb
e 72Gb em formato comprimido. O DAT 160 suporta 80 Gb e 160 em modo comprimido.
Os backups que não necessitem de espaço muito extenso podem ser arquivados em cd's ou dvd's.
Um exemplo poderá ser o backup dos ficheiros de configuração dos servidores de DNS.
Os servidores de backups podem ser utilizados para armazenarem os dados dos utilizadores visto
Luís Machado 2013
Pag. 18
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
que a sua capacidade vai depender da quantidade e tamanho dos discos rigídos utilizados. Estes
servidores podem ser utilizados como servidores intermédios. Os dados são arquivados, via rede,
em horas de baixo tráfego (de noite, por exemplo) e posteriormente podem ser copiados para tape
ficando assim um backup redundante para uma segurança de dados mais apertada.
Comandos de backup
Os backups vão ser realizados através de comandos na consola de forma manual ou podem ser
realizados através de software que os tornam automáticos.
Os comandos mais conhecidos e utilizados em ambiente texto são o tar, o cpio, o dump, o restore e
o mt.
O comando tar Tape Archive já foi abordado noutras alturas por isso não vais ser abordado neste
momento.
O comando cpio faz a gestão dos arquivos com a mesma extensão (.cpio). Este comando funciona
de forma bem diferente do tar. O cpio recebe os ficheiros para arquivar através de um comando
auxiliar para que o resultado deste comando seja a entrada do cpio. O comando find é muitas vezes
utilizado para este fim.
# find /home | cpio -o > /backup/home-backup.cpio
# find /home -atime 60 | cpio -o >> \ /backup/home-backup.cpio
No primeiro caso os ficheiros e directórios de /home são utilizados para a criação do ficheiro de
backup home-backup.cpio.
No segundo caso o ficheiro home-backup.cpio vai ser criado com os ficheiros que foram acedidos
nos últimos 60 dias.
O comando dump permite realizar a cópia integral dos dados de uma partição para o dispositivo de
backup. O comando dump permite realizar backups incrementais assim como os completos.
O comando restore tem a função de fazer a reposição de uma partição ou conjunto de ficheiros
criados a partir do comando dump.
#dump 0auf /dev/nst0 /
Neste exemplo o backup é completo (nível 0) e a partição da root / é armazenada na tape associada
a /dev/nst0
Luís Machado 2013
Pag. 19
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
#restore -f /dev/nst0 -i
Neste exemplo vão ser recuperados os ficheiros desejados pelo administrador através do modo
interactivo. Este modo permite fazer a escolha entre os ficheiros contidos no backup.
#restore -if backup.dump
Neste exemplo vão ser recuperados os ficheiros desejados pelo administrador através do modo
interactivo. Os ficheiros desejados estão armazenados no ficheiro backup.dump.
O comando mt é utilizado para controlar as unidades de fita magnética. Este comando permite
rebobinar e colocar na posição desejada a tape que se está a utilizar para fazer os backups.
#mt -f /dev/st0 rewind
#mt -f /dev/st0 fsf 1
#mt -f /dev/st0 bsf 1
No primeiro exemplo a tape irá ser rebobinada. No segundo exemplo a tape será posicionada no
primeiro bloco do arquivo seguinte (fsf – forward space count files). No terceiro exemplo a tape
será posicionada no último bloco do arquivo anterior (bsf – backward space count files). Os valores
de fsf e bsf podem ser diferentes de 1 mediante a posição que o administrador deseje.
Backups centralizados
Os backups centralizados podem ser importantes na política de criação de backups de uma
instituição. Os backups são centralizados num servidor especificamente destinado para o efeito.
Estes backups podem ser realizados através dos comandos referidos anteriormente ou através de
software desenhado para o efeito. Um exemplo para este caso é o AMANDA (Advanced Maryland
Automatic Network Disk Archiver).
Podem agendar-se também as tarefas de backup através dos mecanismos de programação de tarefas
como é o caso do cron.
O cron é o serviço utilizado para programar a execução de tarefas de forma repetitiva em
Gnu/Linux. As tarefas são configuradas para serem executadas repetitivamente e na data e hora
desejadas.
Luís Machado 2013
Pag. 20
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Este é um serviço essencial para o sistema por isso deve funcionar no modo standalone e estar
activado no runlevel em que vai funcionar o sistema. Uma característica interessante do serviço é
que não é necessário reinicializar o serviço após a alteração do ficheiro de configuração já que ele
verifica a cada minuto as tarefas que deve realizar.
O cron suporta tarefas de utilizador ou de sistema. O administrador, ou root, pode ele próprio
programar tarefas como utilizador.
Os ficheiros de configuração do cron são denominados de crontab e encontram-se em directórios
distintos quer se trate de ficheiros de utilizadores ou de sistema. Os ficheiros de utilizadores estão
armazenados do directório /var/spool/cron. Neste directório cada utilizador tem o seu próprio
crontab. Os crontab de sistema podem ser encontrados em /etc/contrab (ficheiro genérico de
configuração), /etc/cron.d (ficheiros mais específicos de tarefas), /etc/cron.hourly, /etc/cron.daily,
/etc/cron.weekly e /etc/cron.monthly. Além deste ficheiros e directorias são importantes os ficheiros
/etc/cron.allow e /etc/cron.deny que especificam quem pode realizar agendamento de tarefas ou
quem é interdito de usar o cron.
A sintaxe de configuração dos ficheiros crontab é como se apresenta de seguida:
#configuração genérica do crontab para utilizadores
SHELL=/bin/bash
MAILTO=form
#configuração da tarefa
Min H D M DS tarefa_ou_comando_a_executar
A configuração confere a possibilidade de agendar a tarefa para Min=minutos, H=hora, D=dia,
M=mês e DS=dia da semana. Para este último parâmetro consideramos de 0 (domingo) a 7
(sábado). Além das variáveis SHELL e MAILTO podem-se configurar a variável LOGNAME (é o
nome do utilizadorque é dono do crontab em execução) e HOME (directório de trabalho para
execução dos comandos do crontab). A variável MAILTO define o endereço de email para onde é
reportado o resultado da tarefa após conclusão.
Estas variáveis podem não constar no ficheiro do crontab, sendo assim o sistema adopta as varíaveis
por defeito.
Seguidamente exemplificam-se algumas tarefas no crontab:
5 0 * * * /local/bin/daily.job >> /tmp/out 2>&1
0 */2 * * * /local/bin/daily.job
Luís Machado 2013
Pag. 21
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
0 1-23/2 * * * /local/bin/daily.job
15 14 1 * * /local/bin/monthly
0 9,14 * * 1-5 mail -s “Aviso” mrelvas%Ola, %%vai trabalhar malandro!!!%
No primeiro exemplo 5 minutos depois da meia noite é executado o script daily.job e o resultado é
(stdout) enviado para o ficheiro /tmp/out, assim como os erros resultantes (stderr). O dispositivo 2
(stderr) é redireccionado para 1 (stdout).
No segundo exemplo o script daily.job é executado de duas em duas horas, diariamente, apartir das
00 horas.
O terceiro exemplo é semelhante ao anterior mas com a execução a começar à 1H e continuando de
2 em em 2 horas.
O quarto exemplo indica que o começo da tarefa é ás 14:15H do dia 1 de cada mês.
No último exemplo um email é emviado ao utilizador mrelvas com um conteúdo especificado. Este
email é enviado todos os dias úteis (1-5) ás 9H e ás 14H.
Deve notar-se que as tarefas são executadas sempre que estiver definido o parâmetro respectivo.
Assim se o contab estiver definido para '30 2 1,10 * 5', ás 2:30 dos dias 1 e 10 de cada mês e ás
sextas-feiras será executada a tarefa.
Já foi referido que para os utilizadores terem permissão para utilizar o cron têm de estar sinalizados
no ficheiro /etc/cron.allow ou em /etc/cron.deny para o caso de serem excluidos. O root tem sempre
acesso ao cron independentemente destes ficheiros existirem ou não. No CentOS apenas o
ficheiro /etc/cron.deny existe e está vazio, o que significa que todos estão autorizados a utilizar o
cron por defeito.
As tarefas de sistema têm diferenças relativamente ás tarefas de utilizadores, já que é necessário
indicar o utilizador da tarefa a seguir à data da mesma.
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
Luís Machado 2013
Pag. 22
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user
command
17 * * * *
root
cd / && run-parts --report /etc/cron.hourly
25 6 * * *
root
test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7
root
test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * *
root
test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
O exemplo anterior de um /etc/crontab exemplifica que o sistema realiza tarefas de verificação
todos os dias, todas as semanas, todos os meses.
Caso existam tarefas que não se enquadrem nos directórios existentes no /etc/crontab podem criarse ficheiros de”crontab” mas com o formato de sistema (com um username) no directório
/etc/cron.d.
AMANDA
Este software permite a criação de um servidor centralizado de backups. Assim sendo necessitamos
de dois programas, um para o servidor e outro para os clientes.
O Amanda utiliza os mesmos comandos que já vimos anteriormente como o dump e o tar para a
compressão dos ficheiros de backup.
O suporte de armazenamento pode ser tape ou discos rígidos que são “transformados” em tapes
virtuais.
A configuração do Amanda é um pouco trabalhosa e requer bastante atenção.
O exemplo seguinte mostra alguns dos parâmetros necessários para configurar o Amanda.
org "ServerNetBackup"
# Organization name for reports
mailto "[email protected]"
netusage 10000 Kbps
dumpcycle 1 week
runspercycle 7
tapecycle 15 tapes
Luís Machado 2013
# Email address to receive reports
# Bandwidth limit, 10M
# Backup cycle is 7 days
# Run 7 times every 7 days
# Dump to 15 different tapes during the cycle
Pag. 23
IEFP – Centro Formação Profissional Braga
tpchanger "chg-disk"
Técn. Inst. Gestão de Redes Informáticas
# The tape-changer glue script
changerfile "/etc/amanda/ServerNetBackup/changer"
# The tape-changer file
tapedev "file://central_backup/ServerNetBackup/slots" # The no-rewind tape device to be used
tapetype HARDDISK
# Define the type of tape
infofile "/etc/amanda/ServerNetBackup/curinfo"
logdir "/etc/amanda/ServerNetBackup/logs"
# Log directory
indexdir "/etc/amanda/ServerNetBackup/index"
define tapetype HARDDISK {
length 100000 mbytes
# Database directory
# Index directory
# Define our tape behaviour
# Every tape is 100GB in size
}
amrecover_changer "changer"
# Changer for amrecover
Pode ver-se que tem o nome do servidor ou organização, o email para onde enviar as comunicações
de estado dos processos. Configura-se também a periodicidade dos backups assim como a largura
de banda da rede a usar e a capacidade dos discos rígidos, etc.
Relativamente ao cliente a configuração é mais básica necessitando apenas de configurar o ficheiro
/var/lib/amanda/.amandahosts:
#ficheiro de configuração /var/lib/amanda/.amandahosts
formacao.dom amandabackup amdump
localhost amandabackup amdump
localhost.localdomain amandabackup amdump
Não se deve de esquecer de configurar devidamente o xinetd ou o ficheiro correspondente em
/etc/xinetd.d para aceitar os pedidos do Amanda.
O “KERNEL”
O kernel é como se sabe “o coração” do sistema operativo das distribuições GNU/Linux.
As próprias distribuições fazem actualizações automáticas do kernel quer para corrigir “bugs”,
quer para adicionar funcionalidades quer para actualizar para novas versões de hardware suportado.
Luís Machado 2013
Pag. 24
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Existem duas grandes correntes na criação de kernels: o kernel monolítico e kernel modular.
O kernel modular é o mais simples possível e encarrega-se de coordenar a troca de mensagens e
dados entre os diferentes componentes (drivers). Os componentes são compilados como módulos
que são carregados e descarregados dinamicamente à medida que vão sendo necessários.
No kernel monolítico todas as funções importantes do kernel fazem parte de um único processo em
que todos os elementos partilham o mesmo espaço de endereçamento de memória, poupando
recursos.
O kernel do Linux incorporou algumas características de um kernel modular, o que o torna
atualmente uma espécie de kernel "semi-monolítico". Todo o kernel, incluindo os drivers de
dispositivos e outros componentes ainda formam um único bloco de código (gigantesco, mais de 30
MB compactado) mas agora podem ser compilados separadamente na forma de módulos. Estes
módulos podem ser carregados e descarregados a qualquer altura, como seria possível num kernel
modular, porém sem a perda de desempenho ou aumento da complexidade que existiria ao utilizar
um kernel realmente modular.
A desvantagem é que os módulos compilados para uma determinada versão do kernel não podem
ser usados noutras máquinas com versões diferentes do kernel ou após haver uma actualização do
mesmo. Os módulos têm assim que ser novamente compilados.
Porquê personalizar a compilação do kernel? Ora bem, acima de tudo com uma compilação
personalisada para cada máquina conseguem-se ganhos de performance. Com uma personalisação
do kernel apenas se activam as funcionalidades pretendidas assim que os módulos compilados
apenas serão aqueles que efectivamente a máquina possui. Alguns estudos revelaram que este ganho
nem sempre é relevante e por vezes não compensa o tempo perdido para se ganhar 0.5% de
performance.
Para se realizar a actualização do kernel existem duas formas de o fazer. Como já foi referido pode
fazer-se uma compilação do kernel mais recente através do código fonte. O kernel pode ser
actualizado através do sistema de actualizações (updates) da distribuição.
#yum update kernel
O kernel será assim actualizado para a versão mais recente que a distribuição fornecer nos seus
repositórios de pacotes. Atenção que, dependendo da distribuição, a versão de kernel pode ser mais
ou menos recente. No CentOs (como no RHLE) previligia-se a estabilidade pelo que utilizam uma
versão menos recente mas mais testada a nível de estabilidade e “bugs”.
Luís Machado 2013
Pag. 25
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
A numeração das versões do kernel segue um padrão em que o segundo algarismo reflete se o
kernel é estável ou de teste. Assim quando terminar em par significa uma versão estável (3.4) se
terminar em ímpar significa uma versão com componentes em teste (3.9).
No caso de se querer fazer a actualização do kernel através do código fonte o primeiro passo é fazer
o download da versão que se pretende do site kernel.org.
Após o download efectuado copia-se ou move-se o ficheiro para /usr/src.
#mv linux-X.X.X.tar.gz /usr/src
No caso de já existir aqui um directório chamado “linux” devemos fazer alterá-lo para outro nome.
#mv linux linux_antigo
Faz-se a extracção do conteúdo do ficheiro tar
#tar zxvf linux-X.X.X.tar.gz
De seguinda altera-se o nome de linux-X.X.X para linux:
#mv linux-X.X.X linux
Dentro do directório linux vai-se aplicar o comando:
#make menuconfig
A partir daqui tem que se verificar todos os menus e submenus para escolher os componentes que se
adequam ao sistema. Após se ter feito a configuração, não se pode esquecer de guardar (save).
Com o comando anterior as configurações são feitas de raíz. Para se poder ter acesso ás
configurações actuais do kernel que está a ser usado pelo servidor pode-se usar o comando:
#make oldconfig
Assim pode poupar-se muito tempo em configurações já que a configuração anterior é carregada.
Pode depois alterar-se como desejar essa mesma configuração.
A partir daqui o computador vai fazer a compilação do kernel.
#make bzImage
A compilação pode demorar algumas horas no caso de configurações mais complexas.
De seguida vai-se compilar e instalar os módulos previamente seleccionados no processo de
Luís Machado 2013
Pag. 26
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
configuração do kernel.
#make modules
Mais uma vez tem que se esperar um pouco.
Após a compilação instalam-se os módulos:
#make modules-install
O comando acima indicado instala os módulos no directório /lib/modules/versão_do_kernel
(/lib/modules/3.9.4) para que possam ser chamados sempre que o mesmo os necessite.
Resta agora instalar o kernel compilado:
#make bzImage install
Com o comando anterior a instalação do kernel é feita colocando a imagem em /boot. Os ficheiros
que devem ser gerados são System.map-versão; vmlinuz-versão e initramfs-versão.img.
Após a verificação se os ficheiros estão no seu devido lugar verifica-se se a entrada no
/boot/grub.conf do novo kernel já está configurada. Caso contrário terá de se fazer manualmente.
DHCP
O Dynamic Host Configuration Protocol – DHCP é uma ferramenta de redes importante quando se
trata da configuração das mesmas. Como se sabe, o DHCP, permite que equipamentos que usam a
rede e o TCP/IP obtenham automaticamente as configurações à qual estão ligados. As vantagens e
desvantagens são já conhecidas.
O processo de obtenção de parâmetros de rede por DHCP baseia-se no seguinte: o equipamento que
se liga à rede emite um broadcast à rede e um DHCP Discover. Seguidamente o servidor, ou
servidores, de DHCP enviam como resposta um DHCP Offer. O equipamento escolhe o servidor (e
as configurações respectivas) e envia-lhe um pedido – DHCP Request (em broadcast). Assim avisa
todos os servidores qual o IP que vai ter. Os servidores que tinham reservados IP para aquela
máquina vão libertar estes IP para outros equipamentos. Por fim o servidor “escolhido” envia um
DHCP Acknowledge em que confirma o IP e autoriza completamente a ligação. O equipamento fica
então ligado à rede com o IP até à finalização do tempo de lease.
Luís Machado 2013
Pag. 27
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Em Gnu/Linux o DHCP tem a sua configuração em vários ficheiros. O cliente de DHCP é
denominado de dhclient. Este cliente é activado quando a placa de rede, ou melhor, a configuração
da placa de rede tem a opção BOOTPROTO=dhcp. Esta opção faz parte do ficheiro
/etc/sysconfig/network-scripts/ifcfg-eth0 (por exemplo). Quando a placa de rede é activada, o
cliente de DHCP é activado também e obtém os parâmetros necessários para a configuração.
No caso de o cliente e o servidor estarem em redes físicas diferentes um router ou um relay agent
fazem a ligação entre os dois. O relay agent está na maioria dos casos integrados no router. O relay
agent limita-se a copiar as mensagens com os pedidos entre os clientes e os servidores.
O dhclient tem um ficheiro em /var/lib/dhclient no sentido de guardar as configurações acerca da
lease que lhe foi atribuída. Com este ficheiro garante-se que, mesmo depois da reinicialização da
máquina, esta mantém o IP até ao final da lease.
O servidor de DHCP é o daemon dhcpd. O seu ficheiro de configuração é /etc/dhcpd.conf. O
ficheiro de exemplo de configuração pode ser encontrado em:
/usr/share/doc/dhcp-4.1.1/dhcpd.conf.sample.
O exemplo seguinte mostra como se compõe o ficheiro dhcpd.conf.
#Exemplo de configuração de dhcpd.conf
ddns-update-style interim;
#Dynamic DNS deve sempre conter esta directiva
ignore client-updates;
#Ignora os updates da linha anterior
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.128 192.168.0.254;
option subnet-mask
255.255.255.0;
option broadcast-address
192.168.0.255;
option routers
192.168.0.1;
option domain-name
option domain-name-servers
#
#
option netbios-name-servers
"formacao.dom";
192.168.0.16, 192.168.0.17;
192.168.1.100;
option ipforwarding off;
default-lease-time 21600;
max-lease-time 43200;
#
option time-offset
-18000;
host ns2 {
Luís Machado 2013
Pag. 28
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
option host-name “ns2.formacao.dom”
next-server ns2.formacao.dom;
hardware ethernet 00:02:c3:d0:e5:83;
fixed-address 192.168.0.16;
}
host laser-printer-laser1 {
hardware ethernet 08:00:2b:4c:a3:82;
fixed-address 192.168.0.120;
}
}
As directivas relacionadas com o DDNS têm de estar sempre presentes no dhcpd.conf. A razão é
que quando se quer compatibilidades com o Active Directory do MSWindows esta configuração
tem de estar presente.
A directiva subnet configura a rede com os parâmetros necessários: gama de IP (range), a máscara
de rede os IP do router, dos servidores de DNS, o nome do domínio, os tempos de leases, etc..
Na segunda parte do ficheiro definem-se dois IP's fixos para duas máquinas: um para o servidor
primário de DNS e outro para uma impressora. Sempre que haja necessidade de atribuir IP's fixos a
servidores ou máquinas individuais deve colocar-se o MAC address da respectiva interface de rede
e o seu IP.
No caso de se terem várias subnets dentro da mesma rede física pode configurar-se do seguinte
modo:
shared-network name {
option domain-name
"formacao.dom";
option domain-name-servers
ns1.formacao.dom, ns2.formacao.dom ;
option routers
192.168.0.254;
subnet 192.168.0.0 netmask 255.255.252.0 {
parameters for subnet
range 192.168.0.1 192.168.0.254;
}
Luís Machado 2013
Pag. 29
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
subnet 192.168.2.0 netmask 255.255.252.0 {
parameters for subnet
range 192.168.2.180 192.168.2.254;
}
}
Pode verificar-se que para cada uma das subnets a gama de IP vai se necessariamente diferente.
Este ficheiro de configuração tem a possibilidade de se poderem agrupar subnets, shared-networks,
hosts ou mesmo outros grupos na mesma configuração base.
O exemplo seguinte ilustra esta situação.
#Exemplo de configuração de group
group {
option routers
192.168.1.254;
option subnet-mask
255.255.255.0;
option domain-name
"formacao.dom
option domain-name-servers 192.168.1.1;
option time-offset
-18000;
# Eastern Standard Time
host nabo {
option host-name "nabo.formacao.dom";
hardware ethernet 00:A0:78:8E:9E:AA;
fixed-address 192.168.0.4;
}
host mamute {
option host-name "mamute.formacao.dom";
hardware ethernet 00:A1:DD:74:C3:F2;
fixed-address 192.168.0.6;
}
}
As leases atribuídas pelo dhcpd são armazenada no ficheiro /var/lib/dhcpd/dhcpd.leases. Não é
Luís Machado 2013
Pag. 30
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
aconselhavel que o administrador modifique este ficheiro uma vez que pode originar conflitos na
rede. O administrador deve guardar um cópia no caso de ser necessário repor este ficheiro.
DNS (Domain Name Server)
O serviço de DNS é um dos mais importantes nas redes actuais. Basta ver que na Internet tudo
passa por este serviço e a menos que se saibam qual os IP's das páginas que se querem visualizar, o
DNS é o que permite obter o contacto com os servidores que as alojam.
Como se deve saber o serviço DNS faz a tradução de um nome num IP seja esse nome de uma
máquina da rede local ou de um servidor da Internet.
O servidor utilizado no CentOS é o BIND (Berkeley Internet Name Domain) e o daemon
respectivo é o named.
No CentOS o serviço de DNS utiliza para os protocolos de comunicação TCP e UDP o porto 53. o
DNS é identificado no /etc/services por domain.
Um servidor de DNS pode funcionar da forma representada na tabela seguinte:
Modo de Funcionamento
Descrição geral do funcionamento
master
Armazena a informação das zonas DNS para as quais tem autoridade
slave
Copia a informação das zonas DNS a partir de servidores master
caching-only
Resolve endereços e armazena em cache os resultados
forwarding
Recorre a outros endereços para efectuar a resolução de endereços
O modo master (ou servidor primário) é o responsável pela configuração das zonas pelas quais tem
autoridade. Sempre que há necessidade de alterar os ficheiros com registo de nomes e endereços das
diversas zonas, este trabalho é feito no master e depois é copiado para o slave.
O modo slave (ou servidor secundário) funciona como backup do servidor primário ou master. Os
ficheiros de registo dos nomes e IP são copiados para este servidor a partir do master e de forma
automática.
O modo caching-only permite que se façam operações de resolução e manutenção em cache dos
resultados. Não é necessário ser master ou slave para isso. A cache é sempre mantida e se algum
domínio ou nome desaparecer, a sua informação estará no servidor mas depois não há destino a
atingir. Este é o seu inconveniente.
O modo forwarding faz o pedido a outros servidores DNS. Ele não faz a resolução de nomes,
Luís Machado 2013
Pag. 31
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
apenas faz o pedido a outros servidores pelo nome. Uma utilização deste modo é em redes privadas
em que os servidores não têm ligação directa à Internet.
Os nomes dos servidores devem ser sempre representados no formato FQDN (Fully Qualified
Domain Name). O endereço www.formacao.pt. (o ponto no final faz parte) indica que o servidor
www faz parte do domínio formacao.pt. Os DNS têm uma hierarquia e esta hierarquia permite que
cada domínio seja administrado de forma independente. Para que um domínio seja visível para
todos este deve ser delegado, ou seja, deve ser registado nos servidores de domínio imediatamente
superiores na hierarquia.
As zonas que constam no DNS podem ser várias mas terão que ser sempre pelo menos duas. Uma
zona de mapeamento directo e outra de mapeamento inverso. O mapeamento directo consiste em
resolver o nome obtendo o IP. O mapeamento inverso consiste em obter o nome a partir do IP.
As zonas de mapeamento directo terão o nome próprio do domínio (formacao.dom). As zonas de
mapeamento inverso será identificada usando os dígitos do IP invertidos com o sufixo in-addr.arpa.
O nome do mapeamento inverso ficaria, por exemplo: 111.0.168.in-addr.arpa. (atenção ao ponto no
final). Já se sabe que os browsers assumem o ponto no final do endereço e por isso não se põe
quando se digita o mesmo na barra de endereços.
Os ficheiros de zonas da configuração dos DNS contêm resource records que indicam entradas
para os nomes dos servidores ou para directivas de configuração.
A tabela seguinte mostra os resource records utilizados na configuração dos DNS.
Resource records
Nome
Propósito de utilização
SOA
Start of authority
Identificação do cabeçalho de zonas
NS
Name server
Definição de servidores de DNS (master ou slave)
PTR
Pointer to Name
Associação de um endereço a um nome (mapeamento
inverso)
MX
Mail exchanger
Definição de servidores de correio electrónico
A
Adress
Associação de um nome a um endereço (mapeamento
directo)
CNAME
Canonical name
Definição de nomes alternativos para servidores
TXT
Text information
Definição de informação textual sobre o domínio
HINFO
Host information
Definição de informação sobre um servidor.
No CentOS para se instalar o bind deve considerar-se instalar também os pacotes bind-utils e
caching-nameserver porque proporcionam ferramentas e ficheiros de configuração por defeito
Luís Machado 2013
Pag. 32
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
(default). Estes ficheiros podem ser uma boa base de partida para a configuração dos serviços.
O modo de caching-only permite fazer uma procura recursiva de nomes armazenando-os em cache.
Já se referiram anteriormente as características deste modo.
O exemplo seguinte é retirado do ficheiro caching-nameserver.conf. Este é o ficheiro default mas
que exemplifica a sintaxe de configuração do BIND.
#Exemplo de /etc/caching-nameserver.conf
options{
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
query-source port 53;
query-source-v6 port 53;
allow-query { localhost; };
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view localhost_resolver {
match-clients { localhost; };
match-destinations { localhost; };
recursion yes;
include "/etc/named.rfc1912.zones";
};
Neste ficheiro deve referir-se que no grupo “options” estão definidas os portos de comunicação, e o
directório raiz de ficheiros de configuração do named (daemon do bind).
O grupo “logging” define a forma como se vai fazer o trabalho de logs do named.
O grupo “view” permite configurar as vistas do bind, ou seja, o grupo de máquinas que poderão
efectuar pedidos de resolução de nomes.
O ficheiro referido como named.rfc1912.zones define requisitos operacionais de como o servidor
de DNS deve funcionar nomeadamente com o localhost e com o Top Level Domain (TLD –
domínio de topo).
# Exemplo de /etc/named.rfc1912.zones
zone "." IN {
type hint;
Luís Machado 2013
Pag. 33
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
file "named.ca";
};
zone "localdomain" IN {
type master;
file "localdomain.zone";
allow-update { none; };
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
...
Neste ficheiro a zona “.” tem a referência do ficheiro named.ca que identifica os servidores de topo
da hierarquia da internet.
#Ficheiro /var/named/named.ca
A.ROOT-SERVERS.NET.
3600000
IN
A
198.41.0.4
A.ROOT-SERVERS.NET.
3600000
NS
AAAA
2001:503:ba3e::2:30
B.ROOT-SERVERS.NET.
3600000
IN
A
128.9.0.107
C.ROOT-SERVERS.NET.
3600000
IN
A
192.33.4.12
D.ROOT-SERVERS.NET.
3600000
IN
A
128.8.10.90
E.ROOT-SERVERS.NET.
3600000
IN
A
192.203.230.10
F.ROOT-SERVERS.NET.
3600000
IN
A
192.5.5.241
G.ROOT-SERVERS.NET.
3600000
IN
A
192.112.36.4
H.ROOT-SERVERS.NET.
3600000
IN
A
128.63.2.53
I.ROOT-SERVERS.NET.
3600000
IN
A
192.36.148.17
Os seguintes ficheiros representam a forma como as zonas são configuradas no bind. Há algumas
diferenças entre os dois nomeadamente a seguir ao “resource record” SOA (start of authority), em
que no named.local se inscreve o hostname (localhost) e o email do responsável pelo serviço
Luís Machado 2013
Pag. 34
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
(root.localhost = root@localhost).
#Ficheiro /var/named/localhost.zone
$TTL
@
86400
IN
SOA @
root (
2002022401 ; serial
3H ; refresh
15M ; retry
1w ; expire
1D ) ; minimum
IN
NS
@
IN
A
127.0.0.1
IN
A
:1
#Ficheiro /var/named/named.local
$TTL
86400
@
IN
1
SOA
localhost.
root.localhost. (
2013060100
; Serial
28800
; Refresh
14400
; Retry
3600000
; Expire
86400 )
;Minimum
IN
NS
localhost.
IN
PTR
localhost.
De notar que o serial é o número de série do ficheiro. Este nº de série serve para que o servidor
secundário possa verificar se houve alterações na configuração do DNS. Ao questionar o servidor
primário vai verificar este nº de série e caso ele tenha variado o ficheiro é copiado para o
secundário.
É uma prática corrente colocar-se a data com o nº sequencial como o nº de série (2013061101, por
exemplo).
Após a configuração estar efectuada vai iniciar-se o serviço com o comando já conhecido:
#service named start
Luís Machado 2013
Pag. 35
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Após o início do serviço deve verificar-se se as zonas estão configuradas correctamente. Para isso
basta aceder aos logs gerados pelo named.
#tail -f /var/log/messages
Para configurar os clientes de DNS, o processo já é conhecido, bastando para isso aceder e alterar,
de acordo com o pretendido, os ficheiros /etc/resolv.conf, /etc/hosts e /etc/host.conf.
Seguidamente apresenta-se um exemplo prático da configuração de servidores DNS. A rede tem
acesso a um servidor WWW pelo exterior e no interior. Os clientes da WWW não poderão ver os
servidores dos domínios internos nem as máquinas da rede interna pelo que se criaram duas vistas
(views): uma de nome “trusted” para os internos e outra para os externos “external”.
#Ficheiro de /etc/named.conf
//Recebe pedidos na interface de ligação ao DMZ
options{
listen-on port 53 { 193.136.212.65;127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
query-source port 53;
query-source-v6 port 53;
// Qualquer máquina pode contactar o servidor
allow-query { any; };
// Por omissão não autoriza transferências completas de zonas
allow-transfer { none; };
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
// Vista trusted aplica-se a todos os IP internos com excepção do router e do servidor DNS
// secundário
view “trusted” {
// Os IP 193.136.212.66 e 193.136.212.126 são excluídos (sinal !)
match-clients { 10.60.0.0/24; !193.136.212.66; !193.136.212.126;
193.136.212.64/26; 10.50.0.0/24; 127.0.0.1; };
Luís Machado 2013
Pag. 36
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
recursion yes;
//Zona fca.pt da rede interna
zone "fca.pt" {
type master;
file "internal/fca.pt.db";
};
//Zona mapeamento inverso da DMZ do interior
zone "212.136.193.in-addr.arpa." {
type master;
file "internal/193.136.212.rev";
};
//Zona mapeamento inverso dos servidores internos, do interior
zone "0.50.10.in-addr.arpa." {
type master;
file "internal/10.50.0.rev";
};
//Zona mapeamento inverso dos utilizadores, do interior
zone "0.60.10.in-addr.arpa." {
type master;
file "internal/10.60.0.rev";
};
//Autorização para o secundário transferir as zonas definidas na vista
allow-transfer { 193.136.212.125; };
};
// Vista external para pedidos feitos fora da rede interna (Internet)
view “external” {
match-clients { “any”; };
recursion no;
//Zona fca.pt da rede interna
zone "fca.pt" {
type master;
file "external/fca.pt.db";
};
//Zona mapeamento inverso da DMZ do interior
zone "212.136.193.in-addr.arpa." {
type master;
file "external/193.136.212.rev";
};
//Autorização para o secundário transferir as zonas definidas na vista
allow-transfer { 193.136.212.66; };
};
As directorias /var/named/internal e /var/named/external devem ser criadas para a se colocarem os
ficheiros que a seguir se descrevem. Como recurso ao ficheiro named.local criam-se os ficheiros das
zonas assinaladas anteriormente.
#Ficheiro /var/named/internal/fca.pt.bd
Luís Machado 2013
Pag. 37
IEFP – Centro Formação Profissional Braga
$TTL
86400
@
IN
SOA
Técn. Inst. Gestão de Redes Informáticas
dns.fca.pt.
root.fca.pt. (
2013060101
; Serial
28800
; Refresh
14400
; Retry
3600000
; Expire
86400 )
;Minimum
IN
NS
dns.fca.pt.
IN
NS
dns2.fca.pt.
; Informação textual do domínio
IN
TXT
“Domínio Rede FCA”
; Servidores de email do domínio
IN
MX
100
users.fca.pt
; Redes do domínio
net-DMZ
IN
A
193.136.212.64
net-servers
IN
A
10.50.0.0
net-users
IN
A
10.60.0.0
; servidores DMZ
dns
IN
A
193.136.212.65
dns2
IN
A
193.136.212.66
smtp
IN
A
193.136.212.67
smtp2
IN
A
193.136.212.68
www
IN
A
193.136.212.69
webmail
IN
CNAME
www
gw-vpn
IN
A
193.136.212.70
; servidores internos
helpdesk
IN
A
10.50.0.1
auths
IN
A
10.50.0.2
users
IN
A
10.50.0.3
backups
IN
A
10.50.0.4
; clientes dhcp dos utilizadores
dhcp01
Luís Machado 2013
IN
A
10.60.0.1
Pag. 38
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
...
dhcp10
IN
A
10.60.0.10
; router e ligações internas
gw
IN
A
193.136.203.247
gw-dmz
IN
A
193.136.212.126
gw-servidores
IN
A
10.50.0.254
gw-utilizadores
IN
A
10.60.0.254
O ficheiro 193.136.212.rev ficará configurado do seguinte modo:
#Ficheiro /var/named/internal/193.136.212.rev
$TTL
86400
@
IN
SOA
dns.fca.pt.
root.fca.pt. (
2013060101
; Serial
28800
; Refresh
14400
; Retry
3600000
; Expire
86400 )
;Minimum
IN
NS
dns.fca.pt.
IN
NS
dns2.fca.pt.
; Informação textual do domínio
IN
TXT
“Domínio Rede FCA”
; registos inversos para servidores DMZ
65
IN
PTR
dns.fca.pt
66
IN
PTR
dns2.fca.pt
67
IN
PTR
smtp.fca.pt
68
IN
PTR
smtp2.fca.pt
69
IN
PTR
www.fca.pt
70
IN
PTR
gw-vpn.fca.pt
126
IN
PTR
gw-dmz.fca.pt
A construção dos ficheiros /var/named/internal/10.60.0.rev e /var/named/internal/10.50.0.rev é
análoga ao anterior. Não esquecer de colocar o gateway dos respectivos routers.
Luís Machado 2013
Pag. 39
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Relativamente ao external o fca.pt.db é mais pequeno porque diz respeito apenas aos pedidos
externos. Assim o ficheiro ficará:
#Ficheiro /var/named/external/fca.pt.bd
$TTL
86400
@
IN
SOA
dns.fca.pt.
root.fca.pt. (
2013060101
; Serial
28800
; Refresh
14400
; Retry
3600000
; Expire
86400 )
;Minimum
IN
NS
dns.fca.pt.
IN
NS
dns2.fca.pt.
; Informação textual do domínio
IN
TXT
“Domínio Rede FCA”
; Servidores de email do domínio
IN
MX
100
smtp.fca.pt
IN
MX
100
smtp2.fca.pt
; servidores DMZ
dns
IN
A
193.136.212.65
dns2
IN
A
193.136.212.66
smtp
IN
A
193.136.212.67
smtp2
IN
A
193.136.212.68
www
IN
A
193.136.212.69
webmail
IN
CNAME
www
gw-vpn
IN
A
193.136.212.70
; router e ligações a DMZ
gw
IN
A
193.136.203.247
gw-dmz
IN
A
193.136.212.126
O ficheiro external/193.136.212.rev ficará configurado do seguinte modo:
#Ficheiro /var/named/external/193.136.212.rev
$TTL
86400
Luís Machado 2013
Pag. 40
IEFP – Centro Formação Profissional Braga
@
IN
SOA
Técn. Inst. Gestão de Redes Informáticas
dns.fca.pt.
root.fca.pt. (
2013060101
; Serial
28800
; Refresh
14400
; Retry
3600000
; Expire
86400 )
;Minimum
IN
NS
dns.fca.pt.
IN
NS
dns2.fca.pt.
; Informação textual do domínio
IN
TXT
“Domínio Rede FCA”
; registos inversos para servidores DMZ
65
IN
PTR
dns.fca.pt
66
IN
PTR
dns2.fca.pt
67
IN
PTR
smtp.fca.pt
68
IN
PTR
smtp2.fca.pt
69
IN
PTR
www.fca.pt
70
IN
PTR
gw-vpn.fca.pt
126
IN
PTR
gw-dmz.fca.pt
Os ficheiros que se configuraram anteriormente têm de pertencer ao “user named” para poderem
funcionar correctamente no bind, por isso faz-se a mudança de “dono”:
#chown named:named /etc/named.conf
#chown -R named:named /var/named/internal
#chown -R named:named /var/named/external
Depois de se inicializar o serviço deve verificar-se as zonas foram carregadas como anteriormente
foi descrito.
O servidor secundário é configurado com o ficheiro /etc/named.conf com as alterações necessárias.
O ficheiro é copiado para o servidor secundário e alterado. Pode usar-se o comando scp (secure
copy) caso assim se considere.
#scp 193.136.212.65:/etc/named.conf /etc/named.conf
Luís Machado 2013
Pag. 41
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
O resultado das alterações é o seguinte:
#Ficheiro de /etc/named.conf do secundário
//deve associar-se aos IP
options{
listen-on port 53 { 193.136.212.66; 193.136.212.125; 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
query-source port 53;
query-source-v6 port 53;
// Qualquer máquina pode contactar o servidor
allow-query { any; };
// Por omissão não autoriza transferências completas de zonas
allow-transfer { none; };
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
// Vista trusted aplica-se a todos os IP internos com excepção do router e do servidor DNS
// secundário
view “trusted” {
// Os IP 193.136.212.66 e 193.136.212.126 são excluídos (sinal !)
match-clients { 10.60.0.0/24; !193.136.212.66; !193.136.212.126;
193.136.212.64/26; 10.50.0.0/24; 127.0.0.1; };
recursion yes;
//Zona fca.pt da rede interna
zone "fca.pt" {
type slave;
masters { 193.136.212.65; }
file "internal/fca.pt.db";
};
//Zona mapeamento inverso da DMZ do interior
zone "212.136.193.in-addr.arpa." {
type slave;
masters { 193.136.212.65; }
file "internal/193.136.212.rev";
};
//Zona mapeamento inverso dos servidores internos, do interior
zone "0.50.10.in-addr.arpa." {
type slave;
masters { 193.136.212.65; }
file "internal/10.50.0.rev";
Luís Machado 2013
Pag. 42
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
};
//Zona mapeamento inverso dos utilizadores, do interior
zone "0.60.10.in-addr.arpa." {
type slave;
masters { 193.136.212.65; }
file "internal/10.60.0.rev";
};
};
// Vista external para pedidos feitos fora da rede interna (Internet)
view “external” {
match-clients { “any”; };
recursion no;
//Zona fca.pt da rede interna
zone "fca.pt" {
type slave;
masters { 193.136.212.65; }
file "external/fca.pt.db";
};
//Zona mapeamento inverso da DMZ do interior
zone "212.136.193.in-addr.arpa." {
type slave;
masters { 193.136.212.65; }
file "external/193.136.212.rev";
};
};
Deve ter-se em atenção que a criação dos ficheiros /var/named/internal e external e a respectiva
mudança de “dono” para o “user named”.
Para testar o funcionamento dos dns podem usar-se os comando nslookup e dig:
#nslookup
>nabo.formacao.dom
#dig @192.168.0.111 formacao.dom AXFR
LOGS do sistema
O sistema operativo guarda as mensagens que os diversos serviços e programas emitem quando
estão a realizar as suas tarefas através do serviço de LOGS. Este serviço é um serviço standalone e
tem o nome de sysklogd. O sysklogd controla 2 serviços: o syslogd e o klogd. O primeiro serviço
controla os logs ao nível do sistema, locais e remotos e é o responsável de interpretar o ficheiro
Luís Machado 2013
Pag. 43
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
/etc/syslog.conf. O klog é o responsável dos logs produzidos pelo kernel. O klog é cliente do
syslogd e por isso, na prática, é configurado no mesmo ficheiro.
O CentOS 6 tem instalado como sistema de logs o rsyslog. Este serviço tem no rsyslogd o seu
daemon e os ficheiros de configuração semelhantes ao syslog. O seu funcionamento é idêntico e
melhorado no que diz respeito ao envio de logs para um servidor remoto. No entanto aborda-se aqui
o syslog por ser ainda utilizado por outras distribuições mais antigas e que ainda estão em
actividade. O principio de configuração é idêntico.
O syslog, como serviço integrado permite armazenar os ficheiros de logs localmente ou
remotamente num servidor de recolha de logs. Esta solução é importante quando se está na presença
de muitos servidores e muitos deles afastados espacialmente do administrador.
O funcionamento do syslog está normalizado pelo RFC 3164 do IETF (Internet Engineering Task
Force).
O processo de funcionamento do syslog é bastante simples em termos de princípio. As aplicações,
serviços ou o kernel têm uma implementação para enviar as mensagens para o syslog. Estas
mensagens estão configuradas de acordo com o seu tipo e a sua prioridade (facility, priority). O
klogd e o syslogd tratam as mensagens de acordo com o requisito e importância da mensagem e
enviam-na para um ficheiro local, para o email de um utilizador ou para um “servidor de logs”
(gestão centralizada de logs).
O envio de um log para um ficheiro “local” pode não ser um ficheiro de texto simples mas pode ser
um device file, ou seja, uma consola (tty*), uma impressora, ou qualquer outro dispositivo com
acesso a um device file.
A configuração do syslog.conf tem em atenção a sintaxe do tipo facility.priority → action. As
facilities especificam o tipo de log, as priorities a sua prioridade e a action o local onde guardar os
logs.
Código de facility
Subsistema da origem das mensagens de LOGS
auth
Segurança e autenticações
authpriv
Segurança e autenticações (privadas)
cron
Serviço escalonamento tarefas
daemon
Daemons do sistema
lpq
Aplicações do sistema de impressão
mail
Aplicações do sistema de emails
news
Sistema de network news (USENET)
syslog
Do próprio Syslog
Luís Machado 2013
Pag. 44
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
user
Aplicações do utilizador
uucp
Subsistema UUCP (usado para comunicação por modem não adsl)
ftp
Pelo ftp
Local0 a local7
Reservado para utilização futura
A tabela anterior mostra o tipo de serviços que pode ser configurado e a seguinte exemplifica o tipo
de prioridades.
Código de priority
Propósito de utilização
debug
Mensagem a nível de debug (para resolução de problemas)
info
Nível informativo, correspondentes a processamentos normais
notice
Mensagens de condições normais mas muito importantes
warning
Avisos de potenciais problemas
err
Avisos de erros
crit
Condições consideradas criticas
alert
Condições que requerem intervenção imediata
emerg
Condições em que o sistema é considerado inutilizável
A prioridade dos logs vai aumentando à medida que avançamos na tabela. Assim o debug é o menos
importante e o emerg é o mais importante.
Podem ainda considerar-se os caracteres * (para todas as facilities e priorities), none (para nenhuma
priority), = (considerar apenas uma priority mas nenhuma das superiores) e ! (ignora as priorities).
#Exemplo de /etc/syslog.conf
…
*.info; mail.none;news.none; authpriv.none;cron.none
/var/log/messges
#Acesso do authpriv
authpriv.*
/var/log/secure
#Acesso de email
mail.none
/var/log/maillog
#Cron
cron.*
/var/log/cron
#Emergência
*.emerg
*
#News e uucp
Luís Machado 2013
Pag. 45
IEFP – Centro Formação Profissional Braga
uucp, news.crit
Técn. Inst. Gestão de Redes Informáticas
/var/log/spooler
#Mensagens de boot
local7.*
/var/log/boot.log
#News
news.=crit
/var/log/news/news.crit
news.=err
/var/log/news/news.err
news.notice
/var/log/news/news.notice
De salientar que no caso da priority de emerg que o * pode ser substituído por usernames de
utilizadores do sistema separados por virgulas.
Quando se pretende ter um sistema centralizado de logs o ficheiro anterior tem de ter as entradas
para o destino do log, um IP ou um nome do servidor.
#Exemplo de /etc/syslog.conf com recurso a sistema remoto de logs
…
mail.*
/var/log/maillog
mail.*
@formacao
#Cron
cron.*
/var/log/cron
cron.*
@192.168.0.111
#Emergência
*.emerg
root, form
O servidor de logs tem de ser configurado para poder receber os logs remotos e para isso tem de se
alterar o ficheiro /etc/sysconfig/syslogd. Neste ficheiro vai-se alterar a variável:
SYSLOGD_OPTIONS=”-m 0 -r”
A opção -r permite receber remotamente os logs de outras máquinas. Por defeito está configurada
sem o -r.
O sistema de logs pode trazer alguns problemas com o tamanho dos ficheiros. Alguns dos ficheiros
Luís Machado 2013
Pag. 46
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
mais utilizados poderiam alcançar tamanhos desmesurados. Para evitar esse problema existe a
rotação de logs que não é mais do que a criação de backups dos ficheiros de logs. Com este sistema
pode-se fazer uma melhor gestão dos logs já que se pode fazer a rotação em termos de calendário
(diário, semanal, etc.) ou por tamanho do ficheiro. A aplicação responsávelpor esta implementação é
o logrotate.
A configuração do /etc/logrotate.conf pode ser a seguinte:
#Exemplo do /etc/logrotate.conf
#Periodo de rotação
weekly
#Período de duração dos backup em semanas
rotate 4
#Criar novos ficheiros depois da rotação dos antigos
create
#Comprimir os ficheiros de backup
#compress
#Ficheiros específicos de cada aplicação para os logs
include /etc/logrotate.d
#Aplicação sem responsável pelo seu log
/var/log/wtmp {
monthly
minsize 1M
create 0664 root utmp
rotate 1
}
De referir que a a directiva include /etc/logrotate.d permite que as aplicações quando instaladas
possam ter ficheiros específicos com a forma como fazem os seus logs.
No caso do rsyslog uma configuração possível (do computador cliente) de /etc/rsyslog.conf será:
#Exemplo /etc/rsyslog.conf do cliente
...
$WorkDirectory
/var/lib/rsyslog
$ActionQueueFileName
fwdRule1
$ActionQueueMaxDiskSpace
2g
$ActionQueueSaveOnShutdown
on
$ActionQueueType
LinkedList
$ActionResumeRetryCount
-1
*.* @@192.168.0.105:514
Luís Machado 2013
Pag. 47
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
No caso do server a configuração será a alteração ao /etc/rsyslog.conf:
#Exemplo /etc/rsyslog.conf do servidor
...
$ModLoad
imtcp
$InputTCPServerRun
514
:FROMHOST-IP, isequal, "192.168.0.101" /var/log/cliente.log
&~
Por último adicionar uma entrada ao IPTABLES para permitir a comunicação
-A INPUT -m state --state NEW -m tcp -p tcp --dport 514 -j ACCEPT
Não se pode esquecer que a cada alteração dos ficheiros se deve reiniciar o serviço.
NIS (Network Information Service)
O NIS é um serviço que proporciona a partilha de ficheiro de configuração de sistemas por vários
computadores. Um NIS permite a autenticação dos vários clientes de uma rede concentrando num
só servidor os ficheiros de configuração como o /etc/passwd, o /etc/shadow, etc.. Pode ainda servir
para partilhar outros ficheiros de configuração do sistema e de utilização comum a outras máquinas
como o /etc/services, por exemplo.
O NIS permite então que numa determinada rede os utilizadores utilizem qualquer computador para
se autenticarem e começarem a trabalhar. Este sistema tem a vantagem de possibilitar que, os
utilizadores que não estejam sempre no mesmo posto de trabalho, possam utilizar as plataformas de
rede e os seus ficheiros sem problemas. Neste caso o NIS utiliza-se em conjunto com o NSF
(Network File System).
O NIS é o percursor do LDAP ( Lightweight Directory Access Protocol) ou do Active Directory da
Microsoft no Windows Server.
O NIS é muito pouco utilizado presentemente devido à sua falta de segurança, uma vez que um
utilizador registado no domínio poderia ter acesso às bases de dados que o compõem sem ter
privilégios de administrador. O outro senão do NIS é o facto da comunicação do servidor com o
cliente, em cada login, não encriptar o username e a password.
Luís Machado 2013
Pag. 48
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
A sua utilização deve, por estes motivos de segurança, ser restringida a redes seguras que não
possam ser acedidas do exterior.
O NIS foi desenvolvido pela Sun Microsystems e foi referência durante muito tempo em sistemas
Unix. No início era conhecido por “yellow pages” mas o nome foi alterado devido ao mesmo nome
da publicação com o mesmo nome por parte da companhia dos telefones britânica.
O daemon que controla o servidor tem o nome de ypserv.
O NIS necessita outros daemons para funcionar perfeitamente. A tabela seguinte evidencia estes
quais os daemons necessários:
Nome do daemon
Fucionalidade
portmap
O daemon RPC sobreo qual o NIS funciona.
yppasswdd
Permite aos utilizadores alterarem a password a partir de clientes de NIS
ypserv
Servidor NIS
ypbind
Cliente NIS
ypxfrd
Utilizado para acelerar a transferência de grandes mapas de NIS
O ficheiro principal de configuração é /etc/yp.conf. Além deste ficheiro têm que se configurar os
seguintes ficheiros: /etc/sysconfig/network, /etc/nsswitch.conf, /var/yp/securenets e por vezes o
/etc/ypserv.conf.
Para configurar um NIS deve-se introduzir o domínio no ficheiro /etc/sysconfig/network:
# Introdução do domínio NIS em /etc/sysconfig/network
…
NETWORKING=yes
HOSTNAME=formacao
NISDOMAIN=nis_formacao
...
O servidor vai ser configurado para poder ele próprio se cliente do serviço através do ficheiro
/etc/yp.conf:
#Ficheiro /etc/yp.conf no servidor
domain nis_formacao server 127.0.0.1
#ou em alternativa
ypserver 127.0.0.1
Luís Machado 2013
Pag. 49
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Para fazer a activação do NIS é necessário que os serviços portmap, ypserv, yppasswdd e ypbind
estejam a correr e estejam configurados no runlevel para serem activados no arranque do sistema
para que assim o NIS arranque automaticamente.
Assim e para relembrar:
#activação dos serviços
service portmap start (ypserv start, etc)
# no runlevel
chkconfig portmap on (ypserv on, etc)
No sentido de verificar se os serviços estão a funcionar correctamente pode fazer-se o seguinte
comando:
#rpcinfo -p localhost
program
vers
proto
port
100000
2
tcp
111
portmapper
100000
2
udp
111
portmapper
100009
1
udp
681
yppasswdd
100004
2
udp
698
ypserv
100004
1
udp
698
ypserv
100004
2
tcp
701
ypserv
100004
1
tcp
701
ypserv
Os daemons ypbind e ypxfrd só podem ser iniciados após a configuração do domínio. Far-se-há
depois das próximas instruções de configuração.
Para inicializar o domínio NIS é então necessário correr o comando e fornecer o respectivo nome
quando é inquirido ao administrador.
# Inicialização do domínio NIS
#/usr/lib/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS servers. nis_formacao is in
the list of NIS server hosts. Please continue to add the names for the other hosts, one per line. When
you are done with the list, type a <control D>.
Luís Machado 2013
Pag. 50
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
next host to add: nis_formacao
next host to add:
The current list of NIS servers looks like this:
nis_formacao
Is this correct? [y/n: y] y
We need a few minutes to build the databases...
Building /var/yp/formacao/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/formacao'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating services.byservicename...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
gmake[1]: Leaving directory `/var/yp/formacao'
nis_formacao has been set up as a NIS master server.
Now you can run ypinit -s nis_formacao on all slave server.
Neste momento já se podem activar os serviços ypbind e ypxfrd da forma que se conhece. Não
esquecer de os activar para o runlevel de funcionamento da máquina.
O servidor já está inicializado e agora resta adicionar utilizadores as sistema e à base de dados do
NIS.
O processo de adição dos utilizadores é o mesmo de sempre. Para que a base de dados do NIS fique
actualizada deve fazer-se sempre, que se adiciona um utilizador, um make no directório /var/yp/.
#useradd -g users nisuser
#passwd nisuser
Changing password for user nisuser.
New password:
Retype new password:
Luís Machado 2013
Pag. 51
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
passwd: all authentication tokens updated successfully.
# cd /var/yp
[root@formacao yp]# make
gmake[1]: Entering directory `/var/yp/nis_formacao'
Updating passwd.byname...
Updating passwd.byuid...
Updating netid.byname...
gmake[1]: Leaving directory `/var/yp/nis_formacao'
Para verificar se o utilizador está devidamente criado pode utilizar-se o seguinte comando:
[root@formacao yp]# ypmatch nisuser passwd
nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/::504:100::/home/nisuser:/bin/bash
Ou então o getent:
[root@formacao yp]# getent passwd nisuser
nisuser:x:504:100::/home/nisuser:/bin/bash
No primeiro caso, com o ypmatch, pode-se verificar a password completa (hexadecimal). Já no
segundo não fornece essa informação.
Configuração do Cliente
A configuração dos clientes vai ser feita seguidamente tendo em consideração que deve conter o
nome do domínio NIS no ficheiro /etc/sysconfig/network como foi referido anteriormente.
Para a configuração dos clientes pode utilizar-se o comando authconfig-tui e fornecer a password de
root assim como o nome do domínio e o ip ou nome do servidor NIS. Os ficheiros de configuração
serão criados no cliente.
[root@cliente1 ]#authconfig-tui
No cliente é necessário colocar no /yp.conf a informação do domínio NIS.
# /etc/yp.conf - configuração do ypbind
domain nis_formacao server 192.168.0.100
Luís Machado 2013
Pag. 52
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
O ficheiro /etc/nsswitch.conf é actualizado pelo authconfig-tui e deve conter as seguintes entradas:
#/etc/nsswitch.conf
passwd:
files nis
shadow:
files nis
group:
files nis
O cliente deve ser então iniciado pelos serviços já conhecidos (ypbind e portmap) e colocados
runlevel desejado.
Para se verificar se o NIS está a funcionar pode fazer-se o ypmatch, getent ou ypcat como já foi
referido anteriormente.
[root@cliente1 tmp]# ypcat passwd
nisuser:$1$Cs2GMe6r$1hohkyG7ALrDLjH1:505:100::/home/nisuser:/bin/bash
quotauser:!!:503:100::/home/quotauser:/bin/bash
ftpinstall:$1$8WjAVtes$SnRh9S1w07sYkFNJwpRKa.:502:100::/:/bin/bash
www:$1$DDCi/OPI$hwiTQ.L0XqYJUk09Bw.pJ/:504:100::/home/www:/bin/bash
smallfry:$1$qHni9dnR$iKDs7gfyt..BS9Lry3DAq.:501:100::/:/bin/bash
Configuração de SLAVES
Os Slaves ou secundários são normalmente utilizados para fazer a comunicação entre várias subnets. Podem ser utilizados na mesma subnet como servidores redundantes no caso do Master ter
algum problema e não possa ser acedido.
A sua configuração no que diz respeito ao yp.conf é igual ao que já foi feito anteriormente para o
Master.
Pode haver necessidade de colocar no ficheiro /etc/hosts do Master e dos Slaves as entradas
respectivas.
#etc/hosts (nis_formacao)
192.168.1.254
nis_slave
#/etc/hosts (nis_slave)
192.168.1.100
Luís Machado 2013
nis_formacao
Pag. 53
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Não se pode esquecer de actualizar o ficheiro /etc/sysconfig/network com o domínio NIS.
Os serviços já referidos anteriormente (portmap, ypbind e o ypxfrd) devem ser configurados para
arrancar no runlevel desejado.
O ypxfrd deve também ser activado no master para permitir a sincronização optimizada das bases
de dados do Master.
Após estes passos faz-se um pedido ao Master para verificar as bases de dados disponíveis:
[root@nis_slave tmp]# ypwhich -m
mail.aliases nis_formacao
group.bygid nis_formacao
passwd.byuid nis_formacao
rpc.bynumber nis_formacao
...
...
[root@nis_slave tmp]#
(-m de Master)
Seguidamente faz-se um primeiro download das bases de dados do Master:
root@nisslave tmp]# /usr/lib/yp/ypinit -s nis_formacao
We will need a few minutes to copy the data from nis_formacao.
Transferring services.byservicename...
Trying ypxfrd ... success
(-s de Slave)
Transferring group.byname...
Trying ypxfrd ... success
...
...
Após este passo estar concluído iniciar o ypsev no Slave utilizando os comandos habituais.
No Master é necessário alterar o ficheiro /var/yp/ypservers adicionando o Slave:
#Ficheiro no Master /var/yp/ypservers
nis_formacao
nis_slave
O Master deve estar preparado para sincronizar com o Slave e assim faz-se uma cópia de segurança
do ficheiro /var/yp/Makefile e no mesmo alterara-se:
#Ficheiro no Master /var/yp/Makefile
#Allow the master to do database pushes to the slave
NOPUSH=false
Luís Machado 2013
Pag. 54
IEFP – Centro Formação Profissional Braga
Técn. Inst. Gestão de Redes Informáticas
Na mesma directoria valta a fazer-se o make para actualizar a base de dados:
[root@formacao yp]# make
gmake[1]: Entering directory `/var/yp/nis_formacao'
Updating ypservers...
YPPUSH: gethostbyname(): Success
YPPUSH: using not FQDN name
gmake[1]: Leaving directory `/var/yp/nis_formacao'
gmake[1]: Entering directory `/var/yp/nis_formacao'
Updating netid.byname...
YPPUSH: gethostbyname(): Success
YPPUSH: using not FQDN name
gmake[1]: Leaving directory `/var/yp/nis_formacao'
Resta configurar o Slave para fazer a sincronização com o Master das bases de dados utilizando o
crond:
# Ficheiro em Slave /etc/cron.d/nis_sync
20 * * * *
/usr/lib/yp/ypxfr_1perhour
40 6 * * *
/usr/lib/yp/ypxfr_1perday
55 6,18 * * * /usr/lib/yp/ypxfr_2perday
Após esta última configuração o sistema poderá ser utilizado.
Luís Machado 2013
Pag. 55