MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
FORMAÇÃO LINUX ADMINISTRATOR
MÓDULO LINUX NETWORK ADMINISTRATOR (V.2.1S - 2013)
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 1
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
Este manual está protegido por direitos autorais, sendo a versão averbada legalmente.
VOCÊ PODE realizar o seu download diretamente do site da M.Cury, imprimir e utilizar para estudo ou referência, mantendo a sua integridade e referências.
VOCÊ PODE disponibilizá-lo para download em seu site ou página social, mantendo a sua integridade e referências.
VOCÊ PODE utilizá-lo em outro local de treinamento, empresa, curso ou palestra, distribuindo-o gratuitamente, de forma impressa ou digital,
mantendo a sua integridade e referências.
.
VOCÊ NÃO PODE vendê-lo ou utilizar de forma comercial em nenhum local, ainda que de forma impressa ou digital.
Contribua com o Manual da M.Cury.
Envie sua contribuição ou correções para [email protected]
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 2
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
CARACTERÍSTICAS DO LINUX NETWORK ADMINISTRATOR:
O curso de Linux Network Administrator é uma preparação para as provas do Linux Professional Institute (LPI) de Nível 2. As provas 117-201 e 117-202 são provas voltadas para o Administrador de Linux Pleno com foco principalmente em serviços e na resolução de problemas (troubleshooting).
Além de ser voltado para as provas de Certificação o objetivo do curso é preparar Administradores capazes de:
• Instalar e configurar os principais serviços utilizados nas empresas; • Gerenciar contas e domínios híbridos; • Analisar Logs e informações do sistema a fim de resolver problemas e evitar possíveis falhas de funcionamento; • Melhorar a segurança de serviços a fim de garantir um melhor funcionamento; • Estar apto a entender o funcionamento dos serviços e desenvolver soluções para integração dos mesmos.
Alguns dos tópicos vistos neste curso são visões mais aprofundadas de serviços vistos no Curso de Linux System Administrator , fortalecendo assim conhecimentos adquiridos no curso anterior e ampliando a aplicação dos mesmos.
O Manual visa orientar o aluno em relação à matéria que será passada em sala de aula e permitir que o aluno adicione suas próprias impressões e comentários do Instrutor para complementar o conteúdo escrito.
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 3
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
Índice : Tópico Página
01- Processo de Inicialização do Linux 05 02- Kernel e Módulos 20 03- Manutenção e Reparo de Sistemas de Arquivos 39 04- Hardware e Arranjos 50 05- Backup 64 06- Gerenciamento de Rede 69 07- Gerenciamento de Domínios 89 08- DHCP 106 09- Compartilhamento de diretórios em Linux 111 10- Gerenciamento de Log 116 11- Agendamentos 125 12- Samba 132 13- LDAP 142 14- SuperDaemons 158 15- OpenSSH 164 16- Servidor FTP 172 17- Servidor HTTP 186 18- Servidor Proxy 196 19- Servidor de Email 205 20- Firewall 227 21- Autenticação PAM 237
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 4
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
1- PROCESSO DE INICIALIZAÇÃO DO LINUX
1.1 A inicialização do computador e o Init
O Processo Init é o mais importante de todo o sistema já que é ele que inicia todos os outros processos e permite que cada runlevel seja executado corretamente, fazendo assim o papel de processo “pai” de todos os processos e é o processo de número 1.
Desde o momento em que é ligado o computador executa várias tarefas e processos que vão desde verificação do hardware presente, execução de códigos obrigatórios até o carregamento do Sistema Operacional propriamente dito.
Abaixo segue um resumo de como é iniciado o computador:
• Ao ser ligado o computador executa o POST (Auto Teste de Ativação) (Power On Self-Test), onde ele verifica se todo hardware mapeado se encontra nos locais indicados;
• Após isso ele executa o BIOS que foi configurado via SETUP;
• Carrega o BOOTLOADER (GRUB/LILO) que está gravado na MBR (Registro Principal de Inicialização);
• O BOOTLOADER carrega o KERNEL que está mapeado, endereçado fisicamente no disco, em seu arquivo de configuração;
• Após carregar o KERNEL, ele carrega se existir o INITRD, que é um arquivo que geralmente contém módulos adicionais ao kernel e uma estrutura chamada ROOTFS que cria um pseudo / (raiz) na memória, após carregar o INITRD, o KERNEL o converte em um RAMDISK e libera a memória que o initrd ocupava;
• Após o carregamento do INITRD é executado o script LINUXRC, que monta o raiz no / (real) com o comando pivot_root;
• É iniciado o processo INIT que carrega o RUNLEVEL corretamente configurado no /etc/inittab;
• No final da execução do INIT, é carregado geralmente o primeiro comando interativo (GETTY/MINGETTY/AGETTY) que cria os terminais e disponibiliza o prompt de login.
O funcionamento do initrd e as características do kernel serão estudadas em capítulos adiante.
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 5
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
Resumindo o mapeamento de hardware é feito pelo kernel e o carregamento do sistema operacional e serviço é feito pelo init.
1.2 Tipos de Init
Existem, basicamente, dois tipos de init usado pelas distribuições Linux: A maioria usa o SysV Init e outras como o Slackware usam uma variante do BSD Init, e temos os novos candidatos a substituir o SysV Init que são o Upstart e o SystemD.
As principais características destes sistemas de inicialização são:
• O SysV é dividido em runlevels, configurado pelo arquivo /etc/inittab e possui diretórios próprios para os scripts e para os links simbólicos que os executam, ele é mais complexo e mais flexível em termos de configuração;
• O BSD init é configurado pelo arquivo /etc/rc, não possui runlevels e não tem diretórios específicos para scripts, ele é mais simples e mais enxuto termos de configuração.
1.3 A configuração do INIT
Estudaremos o SysV Init que é o padrão da maioria das distribuições Linux.
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 6
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
O processo init é configurado através do arquivo /etc/inittab. Onde são configurados o runlevel, os terminais, scripts principais de inicialização e algumas teclas de controle e funções de gerenciamento de energia. Cada linha do arquivo segue a seguinte estrutura:
id:runlevel:action:process
Onde: id = sigla de identificação da linha, geralmente está relacionada com a ação configurada, uma contração das palavras que definem a ação;
runlevel = em que nível o processo será executado;
action = ação do init para aquele processo;
process = qual comando/script será executado.
As principais ações do init são:
initdefault - define o nível padrão do sistema
sysinit - define o principal script do sistema, é executado antes das outras ações
boot - ação prioritária, é executada depois da sysinit e antes das outras
wait - define que cada script deve ser iniciado e terminado antes de executar o próximo
respawn - define que se o processo for morto ele deve ser reiniciado
ctrlaltdel - define a ação associada às teclas control + alt + del
kbrequest - define a ação associada às teclas alt + seta para cima
powerfailnow powerokwait - ações relativas a gerenciamento de energia powefail
Estas ações de gerenciamento de energia funcionam quando o computador está ligado a sistemas UPS de energia (no-break inteligente).
Os níveis de execução (RUNLEVEL) são:
0 – Desligamento (Halt) 1 – Monousuário (Single User) 2 – Multiusuário sem NFS 3 – Multiusuário com NFS 4 – Multiusuário 5 – Multiusuário com NFS e Servidor X 6 – Reinício (Reboot)
Existem outros níveis de execução que não são documentados pela maioria das distribuições Linux, como os níveis S ou s que na verdade são usados para entrar no nível de monousuário e não precisam do inittab.
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 7
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
Os Runlevels são definições de quais serviços o sistema deve ou não executar em uma determinada configuração. Assim determinados scripts tem ordem para iniciar em um runlevel e ordem para fechar em outro. Por exemplo:
• No runlevel 6 ele deve fechar todos os serviços que estiverem abertos, fechar todos os processos e no final reiniciar o computador;
• No runlevel 1 ele deve fechar quase todos os serviços, fechar os terminais e permitir apenas login de root no tty1;
• No runlevel 3 ele deve carregar todos os serviços, todos os compartilhamentos, permitir múltiplos logins de usuários e não executar o servidor gráfico;
Portanto o que diferencia um runlevel de outro é a decisão que é tomada (iniciar ou fechar) com os scripts de inicialização.
O init executa, sempre que é carregado, o script configurado com a ação sysinit (geralmente rc.sysinit), e após carregar os scripts do nível configurado na ação initdefault ele executa o script rc.local.
Em distribuições baseadas em Debian o script principal se chama rcS, geralmente pequeno e usado apenas em personalizações administrativas. Em distribuições baseadas em Red Hat o script principal é o rc.sysinit e geralmente carrega as principais funções do sistema, como RAID, LVM, serviços de boot, etc.
Exemplo de inittab padrão Red Hat para o runlevel 5:
1.3.1 Upstart
O upstart é um daemon baseado em evento e um substituto do /sbin/init (pai de todos os processos).
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 8
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
Ele assegura o começo e parada das tarefas e serviços durante o boot, bem como uma parada programada, além de supervisionar os sistemas em execução. Foi originalmente desenvolvida para a distribuição Ubuntu, mas é adequado para ser implantado em todas as distribuições Linux como um substituto para o venerável init System-V.
Destaques do upstart:
• As tarefas e os serviços são começados e parados por eventos (Signal); • Os eventos são gerados enquanto as tarefas e os serviços estão funcionando ou parados; • Os eventos podem também ser gerados em intervalos programados, ou quando os arquivos de configuração forem alterados; • Os eventos podem ser recebidos de qualquer um ou de processos do sistema; • Os serviços podem ser reiniciados se morrerem inesperadamente; • Comunicação bidirecional com o daemon do init, para descobrir se os serviços estão funcionando, porque falharam etc.
Você pode começar a utilizar o upstart através dos comandos de controle.
# stop portmap Para o portmap.
# initctl list Lista todos os serviços em execução e seu estado (start, stop, waiting). Se você executou o comando acima para o portmap, verá que ele irá aparecer como waiting.
# start portmap Inicia o portmap.
# status portmap Verifica o status do portmap.
Onde configurar as opções que tinham no inittab? Ao contrário do System V, que concentrava todas as configurações em um único arquivo (/etc/inittab), agindo na forma serial de inicialização, o upstart utiliza um arquivo para cada item, antes contido no inittab. Os arquivos ficam dentro do diretório /etc/init. Dentro deste diretório você irá encontrar os arquivos que habilitam as opções antes encontradas no inittab, como os terminais TTY, control-alt-delete, udev e etc.
Exemplo: Para habilitar o tty2 apenas no runlevel 3 edite o arquivo abaixo:
# vim /etc/init/tty2.conf
start on runlevel [2] stop on runlevel [!23]
respawn exec /sbin/getty -8 38400 tty2
Com o upstart as configurações ficaram bem mais flexíveis. Coloque start para inicializar ou stop para desligar um processo no runlevel desejado.
Alterando o seu runlevel default
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 9
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
Para alterar o initdefault é necessário alterar o arquivo rc-sysinit.conf. Altere a variável DEFAULT_RUNLEVEL=2 pelo runlevel que deseja inicializar. No antigo init (SysV init) qualquer alteração no arquivo /etc/inittab, para que as novas configurações fossem carregadas, é necessário rodar o comando “init q” sem a necessidade de reiniciar a máquina, e para o upstart o procedimento é o mesmo.
Finalizando
O conteúdo de um arquivo dentro do /etc/init tem as seguintes características:
• Os arquivos contidos em /etc/init executam um comando sempre após o "exec". • Outro ponto interessante é colocar o parâmetro "respawn". Esse parâmetro monitora o comando executado. Caso o mesmo termine inesperadamente, um novo programa é inicializado automaticamente. É empregado normalmente para os terminais virtuais (tty’s) • Nos arquivos, além das execuções acima é possível também executar um script.
1.3.2 Systemd
O sistema de supervisão e inicialização de serviços Systemd foi anunciado como o novo, revolucionário e totalmente inovador substituto do venerável SysVinit. De fato, na descrição teórica ele parece ser muito poderoso, embora menos flexível do que uma série de scripts de shell.
Distribuições que utilizam o systemd por padrão:
• Fedora 15 e superior; • Mageia 2 utiliza systemd por padrão; • Mandriva 2011 tem o systemd habilitado por padrão; • OpenSUSE usa systemd por padrão a partir da versão 12.1 e superior.
Distribuições onde o systemd está disponível:
• Arch Linux tem pacotes para o system; • Debian GNU/Linux tem pacotes para systemd no repositório "testing"; • Gentoo oferece pacotes com systemd.
Entre suas características especiais está o de garantir que determinado serviço foi parado e, com ele, todos os processos filhos que este havia gerado. O subsistema que permite esse recurso é conhecido como Cgroups (Control Groups, ou grupos de controle) e reside no kernel. Os Cgroups permitem atribuir rótulos (ou tags) a cada processo que for iniciado no sistema, além de registrar tais informações (processos e seus respectivos rótulos) num pseudo-sistema de arquivos, o que facilita imensamente sua consulta por qualquer programa ou usuário. Outra característica é em relação a montagem de sistemas de arquivos. O Systemd é dotado de inteligência onde necessário. Ele lê o arquivo /etc/fstab durante a inicialização do sistema, e cria as políticas de montagem automática dos sistemas de arquivos descritos no arquivo. O Systemd não faz uso do serviço autofs. Ele utiliza o suporte do kernel ao autofs, mas implementa internamente as montagens automáticas, de forma totalmente independente do serviço autofs.
Arquitetura do Systemd
O Systemd visa a agir nos dois principais pontos problemáticos do SysVinit: shell e paralelismo. Para eliminar o uso do shell, o Systemd realiza todas as chamadas redundantes — isto é, aquelas presentes na maioria dos scripts — de forma embutida no binário /sbin/systemd. E para permitir o paralelismo, o Systemd abre sockets para comunicação entre os serviços, de forma que todos os serviços marcados pelo
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 10
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR administrador como desejados possam iniciar em paralelo e, caso dependam de outros serviços, estes também sejam iniciados sob demanda.
Diretórios do Systemd
Instalar o Systemd, no momento, é uma tarefa restrita a algumas distribuições, como Fedora, openSUSE, Debian, Gentoo, Arch e Ubuntu (este utiliza upstart por padrão). Os arquivos responsáveis pelos serviços no Systemd se localizam em /lib/systemd/system/. No entanto, como cada administrador pode — e deve como no caso das montagens de sistemas de arquivos — criar os seus próprios serviços, há um diretório específico para esse tipo de personalização: /etc/systemd/system/. Ou seja: não mexa no /lib/systemd/system/. Mexa somente em /etc/systemd/system/. Não se espera que o diretório /lib/ tenha arquivos de configuração alterados pelo administrador. Uma listagem do diretório /lib/systemd/system/ logo após a instalação revela algo em torno de 140 arquivos e diretórios. Estes são serviços que o pacote já traz configurados e instalados para você. Você pode se basear neles para escrever os seus próprios serviços.
Arquivos de serviços
Um fato muito positivo sobre o Systemd é que a documentação já está muito bem feita. O pacote do Systemd já traz as páginas de manual de cada tipo de serviço. Experimente:
# man -k systemd systemd.automount (5) - systemd automount configuration files systemd.conf (5) - systemd manager configuration file systemd.device (5) - systemd device configuration files systemd.exec (5) - systemd execution environment configuration systemd.mount (5) - systemd mount configuration files systemd.path (5) - systemd path configuration files systemd.service (5) - systemd service configuration files systemd.snapshot (5) - systemd snapshot units systemd.socket (5) - systemd socket configuration files systemd.special (7) - special systemd units systemd.swap (5) - systemd swap configuration files systemd.target (5) - systemd target configuration files systemd.timer (5) - systemd timer configuration files systemd.unit (5) - systemd unit configuration files
Há uma página de manual para os arquivos de serviços (systemd.service), e é ela que devemos consultar para entender ou desenvolver arquivos de serviços.
Gerenciar serviços com o comando “systemctl”:
# systemctl status irqbalance.service Verifica o estado atual do serviço irqbalance.
# systemctl enable httpd.service Habilita o serviço httpd.
# systemctl restart httpd.service Reinicia o serviço httpd.
# systemctl stop httpd.service Para o serviço httpd.
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 11
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
# systemctl disable telnet.service Desativa o serviço telnet.
# systemctl list-units --type=service Lista todos os serviços ativos.
1.4 O gerenciamento dos scripts de inicialização
Os scripts de inicialização ficam no diretório /etc/init.d (Debian) ou /etc/rc.d/init.d (Red Hat), no Red Hat existe um link para redirecionamento do rc.d para init.d.
Para não ser preciso modificar o script em cada runlevel, existem diretórios onde são criados links simbólicos apontando para os scripts em /etc/init.d.
De /etc/rc0.d até /etc/rc6.d de acordo com o runlevel desejado. Os links simbólicos para os scripts são tratados da seguinte forma:
• Os scripts que começam com K recebem a instrução de fechar naquele nível ( stop );
• Os scripts que começam com S recebem a instrução de iniciar naquele nível ( start );
A ordem de execução é determinada pelos números de 00 a 99 que estão juntos da letra (K ou S) no nome do link simbólico. Os links simbólicos com a letra K são executados antes dos links com a letra S (ordem alfabética).
Como no exemplo abaixo:
K20nomedoscript – fechar o script na ordem 20 S35nomedoscript – iniciar o script na ordem 35
Para verificar é só listar os diretórios dos runlevels: debian:~# ls -l /etc/rc0.d
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 12
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
ou debian:~# ls -l /etc/rc2.d
Os scripts que são carregados na verdade estão em /etc/init.d e são utilizados da seguinte forma:
Em qualquer Linux:
/etc/init.d/nome_do_script
Onde o parâmetro pode ser no mínimo start ou stop, para iniciar e parar o script respectivamente. Alguns scripts possuem outras instruções de execução como: restart, reload, status, etc.
De acordo com a distribuição utilizada existem ferramentas para lidar com os scripts de inicialização:
Em distribuições baseadas em Red Hat: service
Em distribuições baseadas em Debian: invoke-rc.d
Segue abaixo um exemplo de script que acata as instruções de stop, start e restart para realizar funções diferentes: debian:~# vi /etc/init.d/teste.sh #!/bin/bash # Script de teste de inicialização # Função que escreve quando o script recebe a instrução de start inicia () { echo -e “\n ” “Iniciando script” “\n ” sleep 3 } # Função que escreve quando o script recebe a instrução de stop para () { echo -e “\n ” “Fechando script” “\n ” sleep 3 }
MANUAL DE TREINAMENTO M.CURY LINUX NETWORK ADMINISTRATOR PÁGINA 13
MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
# case para testar os parâmetros passados ao scripts case $1 in start) inicia ;; stop) para ;; restart) para ; inicia ;; *) echo “Use: /etc/init.d/teste.sh (start|stop|restart)” ;; esac ### FIM debian:~# chmod -v 755 /etc/init.d/teste.sh
O próximo passo seria criar os links simbólicos para todos os runlevels com o comando ln, da seguinte forma: debian:~# ln -s /etc/init.d/teste.sh /etc/rc0.d/K20teste.sh debian:~# ln -s /etc/init.d/teste.sh /etc/rc1.d/K20teste.sh debian:~# ln -s /etc/init.d/teste.sh /etc/rc6.d/K20teste.sh debian:~# ln -s /etc/init.d/teste.sh /etc/rc2.d/S80teste.sh debian:~# ln -s /etc/init.d/teste.sh /etc/rc3.d/S80teste.sh debian:~# ln -s /etc/init.d/teste.sh /etc/rc4.d/S80teste.sh debian:~# ln -s /etc/init.d/teste.sh /etc/rc5.d/S80teste.sh
Mas cada distribuição tem sua própria ferramenta de ativar scripts de inicialização:
Em Debian temos o update-rc.d que independente se o script tem a estrutura certa ou não ele cria os links, geralmente ele utiliza um cabeçalho para estar de acordo com os padrões LSB, apesar de que este cabeçalho não é obrigatório para o correto funcionamento do script ele complementa as informações do mesmo: update-rc.d