Administração redes cliente servidor Gnu/Linux. Luís Machado 2013 Pag. 1

Transcrição

1 Administração redes cliente servidor Gnu/Linux Luís Machado 2013 Pag. 1

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

3 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 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 640x x x x x x (256) (32K) (65K) (16M) 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

4 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

5 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

6 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

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

8 $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

9 $more /etc/xinetd.d/telnet #default: on service telnet flags socket_type wait user server log_on_failure disable =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

10 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 (0x ) [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

11 ALL : Neste exemplo todos os serviços são aceites por parte de hosts da gama de IP 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: Neste exemplo são aceites todos os pedidos de serviços excepto o ftp e por parte dos IP da gama 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 /etc/host.conf /etc/hosts /etc/resolv.conf /etc/sysconfig/network /etc/sysconfig/network-scripts Propósito de utilização do ficheiro Ordem pela qual são efectuadas as resoluções de DNS Registo de nomes e endereços locais Endereços de servidores DNS na rede local Nome da máquina e endereço do router (default gateway) 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

12 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 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 nameserver 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

13 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= 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

14 IPADDR= NETMASK= 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= NETMASK= BROADCAST= 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 eth netmask 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

15 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 U eth U 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 form@formacao~$ route add -net /24 gw form@formacao~$ route add -net /26 gw Para se apagar uma rota faz-se o comando seguinte: form@formacao~$ route del -net /24 gw 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

16 Destination Gateway Genmask Flags Metric Ref Use Iface U eth U eth UG eth UG eth UG eth0 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 $tcpdump -i eth0 tcp.. No primeiro exemplo a captura de todos os pacotes é feita no servidor 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

17 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

18 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

19 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

20 #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

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

22 0 1-23/2 * * * /local/bin/daily.job * * /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 é emviado ao utilizador mrelvas com um conteúdo especificado. Este é 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

23 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 ) * * 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 "address@your .com" # address to receive reports netusage Kbps # Bandwidth limit, 10M dumpcycle 1 week # Backup cycle is 7 days runspercycle 7 # Run 7 times every 7 days tapecycle 15 tapes # Dump to 15 different tapes during the cycle Luís Machado 2013 Pag. 23

24 tpchanger "chg-disk" # 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" # Database directory logdir "/etc/amanda/servernetbackup/logs" # Log directory indexdir "/etc/amanda/servernetbackup/index" # Index directory define tapetype HARDDISK { # Define our tape behaviour length mbytes # 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 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

25 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

26 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

27 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

28 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 netmask { range ; option subnet-mask ; option broadcast-address ; option routers ; option domain-name "formacao.dom"; option domain-name-servers , ; # option netbios-name-servers ; # option ipforwarding off; default-lease-time 21600; max-lease-time 43200; # option time-offset ; host ns2 { Luís Machado 2013 Pag. 28

29 } option host-name ns2.formacao.dom next-server ns2.formacao.dom; hardware ethernet 00:02:c3:d0:e5:83; fixed-address ; } host laser-printer-laser1 { hardware ethernet 08:00:2b:4c:a3:82; fixed-address ; } 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 ; subnet netmask { parameters for subnet range ; } Luís Machado 2013 Pag. 29

30 } subnet netmask { parameters for subnet range ; } 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 ; option subnet-mask ; option domain-name "formacao.dom option domain-name-servers ; option time-offset ; # Eastern Standard Time host nabo { option host-name "nabo.formacao.dom"; hardware ethernet 00:A0:78:8E:9E:AA; fixed-address ; } } host mamute { option host-name "mamute.formacao.dom"; hardware ethernet 00:A1:DD:74:C3:F2; fixed-address ; } As leases atribuídas pelo dhcpd são armazenada no ficheiro /var/lib/dhcpd/dhcpd.leases. Não é Luís Machado 2013 Pag. 30