Livro Formatado e Organizado Final LPG260-Pag182

1

Guia Linux Professional – Clayton Lobato

2


3

Depois de escrever, reescrever, escrever mais uma vez e ficar nesse ciclo vicioso por mais de um ano, creio ter conseguido chegar a um formato de material que pode ajudar no entendimento do sistema GNU/Linux. Umas de minhas maiores preocupações foi em buscar os conceitos do “como funciona” e focar um pouco menos o “como fazer”, pois esses estão disponíveis na internet.

Outro fato que me chamou a atenção era ter um grande número de meus alunos sempre me questionando como os serviços realmente funcionavam. Por exemplo, um dia um aluno me fez parar uma aula para explicar como e de onde o comando useradd saberia qual seria o primeiro ID que seria usado para criação dos usuários e grupos, onde seriam criados o diretório home do usuário e se seria ou não criado o mesmo. Uma pergunta ficou nesse tempo todo... “o que realmente eu deveria focar em minhas aulas ?”. A resposta foi simples, imediata e intrigante... buscar o entendimento de como funciona. Mas como faria isso para pessoas que nunca tiveram contato com o sistema de uma forma clara e simples e de fácil entendimento possível ?

Encontrei essas respostas em sala de aula testando alguns métodos “alternativos” com os alunos. O primeiro passo foi organizar algumas pequenas apostilas complementares para usar com eles.

Após alguns anos, um grande volume de materiais e pedidos de alunos, resolvi organizar todo esse material, detalhando ao máximo as informações focando os objetivos propostos.. Entendimento claro e direto do funcionamento do sistema e como usar os comandos de forma simples.

A proposta do material é trazer ao estudante de GNU/Linux, os principais conceitos e desafios de uso do sistema, em um mundo mais Corporativo. Para isso, alinhamos todo o nosso conteúdo com o processo de administração do sistema.

Mas nada se faz sozinho. Apresentei o material a Diretoria da X25 Treinamento e Consultoria que apoiou a idéia e adotou o livro em seus treinamentos GNU/Linux além de ajudar a divulgá-lo entre a comunidade adepta ao Software Livre, na qual VOCÊ também deve estar inserido... ao contrário não estaria lendo a apresentação do livro.

Um grande abraço, Paz, Liberdade e Sonhos.

Clayton Lobato


4


5

A Deus e a todos que colaboraram de forma direta e indireta para a realização deste trabalho.

À Diana Nunes e Marcelo Burato pelo apoio e paciência por todas as vezes que adiei a entrega deste material.

A Adriana Heinen pelo apoio incondicional e pela elaboração da capa deste material, além de todo o apoio em todas as fases do processo de criação do mesmo.

Aos meus alunos e ex-alunos que estiveram comigo durante todos os anos em que o projeto nasceu até o estado atual de editoração.

À Dona Dica, Seu Eduardo, Seu Mário, Dona Moroza, Telma e Jorge, Karine, Beatriz, Tainá, Simone, Fernanda, Luiz Gaudêncio, Luis Eduardo, Alice Caroline, Akemi e Fernanda. Muito obrigado por serem minha família.


6


7

SumárioCapítulo 1 – Um pouco de História.......................................................................................13

Um pouco de história.......................................................................................................15História dos sistemas operacionais..............................................................................15Estrutura......................................................................................................................15Classificações...............................................................................................................15A história do Linux.......................................................................................................16Qual a diferença entre Linux e Unix?...........................................................................16O que é GPL?................................................................................................................17O que são as tais distribuições?...................................................................................17Vantagens do Código-Aberto.......................................................................................18

Capítulo 2 - Dispositivos de armazenamento e estrutura de diretórios...............................21Estrutura de diretórios.....................................................................................................23Estudo dos dispositivos de armazenamento....................................................................24Tipos de File – System e Particionamento de Discos. ......................................................26Particionamento de discos – Comando fdisk....................................................................27Formatação do disco – Comando mkfs.............................................................................30Instalação do GNU/LINUX.................................................................................................31

Capítulo 3 - Processo de inicialização, Boot Loader e Run Level..........................................41Bootstrapping – Inicialização do Computador..................................................................43Gerenciadores de boot (bootloaders)...............................................................................44

GRUB ( GRand Unified Bootloader)..............................................................................44LILO ( LInux LOader )...................................................................................................46

Níveis de execução do Sistema........................................................................................46Capítulo 4 - Administração do GNU/Linux............................................................................49

Usuários, Grupos, Senhas e NPA......................................................................................511. useradd ...................................................................................................................512. userdel ....................................................................................................................524. chsh.........................................................................................................................535. chage ......................................................................................................................536. usermod ..................................................................................................................547. chfn .........................................................................................................................548. groupadd..................................................................................................................559. groupdel...................................................................................................................5510. gpasswd ................................................................................................................5511. groupmod...............................................................................................................5612. chpasswd...............................................................................................................5613. id............................................................................................................................5614. chgrp .....................................................................................................................5715. finger......................................................................................................................5716. chmod ...................................................................................................................6117. chown.....................................................................................................................62

Capítulo 5 – Comandos GNU/Linux.......................................................................................651. cat............................................................................................................................672. tac ...........................................................................................................................673. cut ...........................................................................................................................684. expand ....................................................................................................................685. fmt ..........................................................................................................................696. head ........................................................................................................................697. tail ...........................................................................................................................70


8

8. hexdump .................................................................................................................709. join ..........................................................................................................................7010. split .......................................................................................................................7111. tr ...........................................................................................................................7112. nl ...........................................................................................................................7213. paste .....................................................................................................................7214. pr ..........................................................................................................................7315. sort ........................................................................................................................7316. wc .........................................................................................................................7418. uniq .......................................................................................................................7419. sed ........................................................................................................................7520. cp ..........................................................................................................................7521. find ........................................................................................................................7622. mv..........................................................................................................................7723. ls............................................................................................................................7724. rm..........................................................................................................................8225. mkdir ....................................................................................................................8226. rmdir......................................................................................................................8327. man ......................................................................................................................8328 info .........................................................................................................................8429 tar ..........................................................................................................................8530 gzip ........................................................................................................................8531 bzip2 ......................................................................................................................8632 crontab....................................................................................................................8633 ps............................................................................................................................8734 kill ..........................................................................................................................8835 killall .......................................................................................................................8836 nice ........................................................................................................................8937 renice .....................................................................................................................8938 mount / umount......................................................................................................90

Capítulo 6 - Instalação e compilação de programas e compilação do Kernel......................95Processo de compilação de programas............................................................................97Pacotes RPM...................................................................................................................101

RPM............................................................................................................................102Pacotes DEB...................................................................................................................104

DPKG..........................................................................................................................104Kernel do Linux...............................................................................................................106

Capítulo 7 - Sistema X Window...........................................................................................111Instalação do Servidor X11............................................................................................113

Capítulo 8 – Conceitos Básicos de Protocolos TCP/IP..........................................................119Histórico.........................................................................................................................121Modelo de Referência ISO/OSI........................................................................................121Modelo TCP/IP.................................................................................................................123Endereçamento IP e Classes..........................................................................................125Subredes........................................................................................................................127

Netmask - Máscara de Subredes...............................................................................127Protocolos e Aplicações..................................................................................................134

Protocolo Internet - IP................................................................................................134Address Resolution Protocol - ARP.............................................................................135Internet Control Message Protocol - ICMP..................................................................136Transmission Control Protocol - TCP...........................................................................137User Datagram Protocol - UDP...................................................................................137Protocolos da Camada de Aplicação..........................................................................138Outros Protocolos e Aplicações..................................................................................139


9

Capítulo 9 - Comandos e arquivos básicos de configuração e administração de interfaces ethernet..............................................................................................................................141

Linux e interface ethernet..............................................................................................143Comandos de redes GNU/Linux......................................................................................146

ifconfig.......................................................................................................................146arp..............................................................................................................................147dig..............................................................................................................................148ifup.............................................................................................................................148ifdown........................................................................................................................148route..........................................................................................................................148dhclient......................................................................................................................149hostname...................................................................................................................150netstat........................................................................................................................150ping............................................................................................................................151traceroute2................................................................................................................151

Comandos de redes GNU/Linux......................................................................................152Eliminando rotas .......................................................................................................152Negando pacotes ......................................................................................................152Alguns serviços de redes...........................................................................................152

Capítulo 10 - Servidor DNS ( Domain Name Server ).......................................................155O Serviço de Resolução de Nomes – DNS......................................................................157

Fundamentos do DNS................................................................................................157Requisitos de sistema................................................................................................157Instalação do BIND.....................................................................................................158

Capítulo 11 - O SAMBA – Servidor Compartilhamento GNU/Linux Windows......................161Instalação.......................................................................................................................163Configuração..................................................................................................................163

Capítulo 12 - SQUID – Proxy Firewall em Layer 7 ?.............................................................171Instalação do Squid........................................................................................................173

Capítulo 13 - Servidor DHCP...............................................................................................1791. DHCP simples.............................................................................................................181 2. IP fixo usando DHCP..................................................................................................182

Capítulo 14 - Servidor Postfix / Dovecot.............................................................................185Capítulo 15 . Servidor WWW..............................................................................................239

Instalação.......................................................................................................................241Capítulo 16 - Compartilhando arquivos no GNU/Linux.......................................................259Capítulo 17 - Serviço OpenSSH..........................................................................................263Capítulo 18 - Referências Bibliográficas.............................................................................269


10


11

Para quem se destina esse livro ?Este livro se destina aos profissionais de tecnologia, estudantes universitários e todos

que tenham vontade de conhecer o mundo GNU/Linux, indo dos mecanismos mais simples às estruturas mais internas e complexas do sistema.

Se você é um usuário experiente ou está conhecendo o GNU/Linux, este livro lhe servirá.

O que é abordado nesse Livro.Neste livro serão vistos aspectos importantes para a instalação do sistema, uso de

comandos e conceitos necessários para a administração do sistema, arquivos importantes para o processo de administração do sistema. Buscaremos o entendimento do processo de integração ao hardware, integração com o usuário e comandos internos do sistema.


12


13

Capítulo 1 – Um pouco de HistóriaComo todo início, conhecermos um pouco da história e filosofia do mundo GNU/Linux

nos fará entender alguns conceitos, lendas e mitos deste fascinante e relativamente novo universo.

Durante algum tempo, achava-se que o GNU/Linux era uma cópia exata ou um clone do unix. Depois veio a fase do “Foi apenas uma melhoria no minix, o código é o mesmo” mas na verdade existe uma história bem mais interessante e desafiadora no processo de criação do sistema. Na primeira parte deste Livro, conheceremos alguns aspectos interessantes sobre a história do sistema, suas licenças e o modelo de implementação conhecido como colaborativa.

De antemão posso garantir que em nenhum momento o sistema foi desenvolvido para derrubar ou competir com nenhuma outra plataforma existente, só queriam rodar um sistema baseado em unix em um micro com arquitetura X86.

Então vamos conhecer um pouco de história GNU/Linux.


14


15

Um pouco de história

História dos sistemas operacionais

No início da computação os primeiros "sistemas operacionais" eram únicos, pois cada mainframe vendido necessitava de um sistema operacional específico. Esse problema era resultado de arquiteturas diferentes e da linguagem utilizada — no caso, assembly (linguagem de baixo nível). Após essa fase, iniciou-se a pesquisa de sistemas operacionais que automatizassem a troca de tarefas (jobs), pois os sistemas eram mono-usuário e tinham cartões perfurados como entrada (eliminando, assim, o trabalho de pessoas que eram contratadas apenas para trocar os cartões perfurados).

Um dos primeiros sistemas operacionais de propósito geral foi o CTSS, desenvolvido no MIT. Após o CTSS, o MIT, os laboratórios Bell da AT&T e a General Eletric desenvolveram o Multics, cujo objetivo era suportar centenas de usuários. Apesar do fracasso comercial, o Multics serviu como base para o estudo e desenvolvimento de sistemas operacionais. Um dos desenvolvedores do Multics, que trabalhava para a Bell, Ken Thompson, começou a rescrever o Multics num conceito menos ambicioso, criando o Unics (em 1969), que mais tarde passou a chamar-se Unix. Os sistemas operacionais eram geralmente programados em assembly, até mesmo o Unix em seu início. Então, Dennis Ritchie (também da Bell) criou a linguagem C a partir da linguagem B, que havia sido criada por Thompson. Finalmente, Thompson e Ritchie reescreveram o Unix em C. O Unix criou um ecossistema de versões, onde destacam-se: System V e derivados (HP-UX, AIX); família BSD (FreeBSD, NetBSD, OpenBSD, etc.), Linux e até o Mac OS X (que deriva do Mach e FreeBSD).

Na década de 1970, quando começaram a aparecer os computadores pessoais, houve a necessidade de um sistema operacional de utilização mais fácil. Em 1980, William (Bill) Gates e seu colega de faculdade, Paul Allen, fundadores da Microsoft, compram o sistema QDOS ("Quick and Dirty Operating System") de Tim Paterson por $50.000, batizam-no de DOS (Disk Operating System) e vendem licenças à IBM. O DOS vendeu muitas cópias, como o sistema operacional padrão para os computadores pessoais desenvolvidos pela IBM.

No começo da década de 1990, um estudante de computação finlandês postou um comentário numa lista de discussão da Usenet dizendo que estava desenvolvendo um kernel de sistema operacional e perguntou se alguém gostaria de auxiliá-lo na tarefa. Este estudante chamava-se Linus Torvalds e o primeiro passo em direção ao tão conhecido Linux foi dado naquele momento.

Estrutura

Um sistema operacional (ou seu kernel), possui as seguintes funções:

1. Agendamento de processos;

2. Gerenciamento de memória;

3. Sistema de arquivos;

4. Disponibilização de entrada e saída de dados.

Classificações

Em relação ao seu projeto (arquitetura), segundo Tanenbaum:

• Sistema monolítico: o kernel consiste em um único processo executando


16

numa memória protegida (espaço do kernel). Ex.: Windows, Linux, FreeBSD.

• Sistema em camada: funções do kernel irão executar em camadas distintas, de acordo com seu nível de privilégio. Ex.: Multics.

• Modelo cliente-servidor ou micro-kernel: o kernel consiste apenas no essencial (comunicação e gerenciamento de processos), e funções como sistemas de arquivos e gerenciamento de memória são executadas no espaço do usuário como serviços; as aplicações (programas) são os clientes. Ex.: GNU Hurd, Mach.

• Monitor de máquinas virtuais: fornece uma abstração do hardware para vários sistemas operacionais. Ex.: VM/370, VMware, Xen.

Quanto à capacidade de processamento, pode-se usar a seguinte classificação:

• Monotarefa: pode-se executar apenas um processo de cada vez Ex.: DOS.

• Multitarefa: além do próprio SO, vários processos estão carregados em memória, sendo que um pode estar ocupando o processador e outros ficam enfileirados, aguardando a sua vez. O compartilhamento de tempo no processador é distribuído de modo que o usuário tenha a impressão que vários processos estão sendo executados simultaneamente.

• Multiprocessamento ou multi programação: o SO pode distribuir as tarefas entre vários processadores.

A história do Linux

Inspirado em um sistema desenvolvido por Andrew Tanembaum, Linus trabalhou duro desenvolver o GNU/Linux. Um pouco antes de lançar a primeira versão oficial do kernel, Linus mandou a seguinte mensagem para o grupo de notícias comp.os.minix:

“Você suspira por melhores dias do Minix-1.1, quando homens serão homens e escreverão seus próprios drivers de dispositivos? Você está sem um bom projeto e está morrendo por colocar as mãos em um sistema operacional o qual você possa modificar de acordo com suas necessidades? Você está achando frustrante quando tudo trabalha em Minix? Chega de atravessar noites para obter programas que trabalhem corretamente? Então esta mensagem pode ser exatamente para você.”

“Como eu mencionei há um mês atrás, estou trabalhando em uma versão independente de um sistema operacional similar ao Minix para computadores AT-386. Ele está, finalmente, próximo do estágio em que poderá ser utilizado (embora possa não ser o que você esteja esperando) e eu estou disposto a colocar os fontes para ampla distribuição. Ele está na versão 0.02... contudo eu tive sucesso rodando o bash, gcc, gnu-make, gnu-sed, compressão e etc nele.”

No dia 5 de Outubro de 1991, Linus Torvalds anunciou a primeira versão oficial do Linux, versão 0.02. Desde então, muitos programadores têm respondido ao seu chamado e têm ajudado a fazer do Linux o sistema operacional que é hoje uma grande maravilha. Um sistema criado inteiramente por programadores espalhados pela Internet, os hackers!

Qual a diferença entre Linux e Unix?Linus Torvalds, quando criou o Linux, criou ele nos padrões POSIX, que é o mesmo

padrão que os UNIX usam. É por esse mesmo uso do padrão POSIX que o Linux é parecido com o UNIX. Além do mais, existem vários tipos de UNIX, que têm seu código-fonte


17

fechado e pago. Uma resposta mais completa para esta pergunta foi feita pelo Fernando M. Roxo:

“Limpo, claro e definitivo: O Linux não é UNIX. O Linux é um UNIX. O UNIX foi um sistema criado e registrado pela Unix Lab. Todos os sistemas baseados naqueles códigos são chamados de uma forma geral de UNIX.”

“Linux foi escrito desde o início pelo Linus Torvalds e não contém nenhuma linha de código do UNIX. Mas o Linux foi escrito conforme o padrão POSIX, que deve ser o padrão da API (Application Programming Interface) Unix, que em última análise pode ser resumido (forçando um pouco a barra) como sendo as chamadas do sistema. Por isto se diz que o Linux é um Unix (não UNIX). Tem uma diferença sutil aí.”

“Por causa da API POSIX, do conjunto de utilitários (FSF/GNU em sua maioria) e do uso do X-Window (XFree) o Linux é tão parecido com o UNIX que existem empresas que usam o Linux para desenvolver para os UNIX que não sejam os delas mesmas (por exemplo a IBM).”

O que é GPL?Se você já ouviu falar bem de Linux, com certeza já deve ter ouvido falar nesta sigla.

GPL significa General Public License (ou traduzindo grosseiramente: Licença Pública Geral) e foi criada pela Free Software Foundation. A grande maioria dos programas que vêm nas distribuições Linux são de código-fonte aberto e usam esta licença. Uma licença serve para proteger o seu código quando ele for lançado para o público.

A licença GPL permite que o autor do código distribua livremente o seu código... Outras pessoas podem simplesmente pegar este código, modificar à suas próprias necessidades e usar à vontade. O único requerimento é que a pessoa que modificou deve lançar o código modificado em GPL e manter também o seu código aberto (e não apenas distribuir os binários). Isso tudo cria uma comunidade de desenvolvedores onde toda a ajuda é mútua e você pode pegar várias idéias de outros desenvolvedores simplesmente olhando o código deles. Além disso, você pode aproveitar e poder ajudar o desenvolvedor, criando correções e mandando-as para o autor.

É com essa licença que o kernel do Linux é liberado. É assim que o kernel tem seu desenvolvimento feito por várias e várias pessoas em todo o mundo. Estas pessoas pegam livremente o código-fonte do kernel, analisam-no e procuram por erros. Se encontrarem erros, escrevem correções e mandam para o Linus Torvalds. E não só correções, mas desenvolvedores também fazem novas implementações ao kernel e mandam para o Linus Torvalds organizar tudo. E é assim que temos hoje em dia este grande e bem feito e organizado kernel do Linux! É assim que a filosofia GPL funciona e funciona muito bem para criar uma comunidade de desenvolvedores justa! Eu pessoalmente apóio e muito a licença GPL, que para mim é simplesmente perfeita. Vivas à Free Software Foundation por criar esta licença! E vivas para os desenvolvedores que a utilizam para seus códigos! :)

O que são as tais distribuições?Distribuições: uma palavra que você vai ouvir muito no mundo Linux. A liberdade de

escolha e a diversidade são vantagens que o software livre nos traz e as distribuições são um resultado disso. O papel de uma distribuição Linux é juntar todos os programas de código-fonte, empacotá-los, otimizá-los e deixar pronto para que o usuário final possa instalar e usar.

São facilitadores. Qualquer um pode simplesmente sair buscando todos os programas na Internet, juntá-los, compilá-los e formar seu sistema Linux. Mas será que


18

todos querem fazer isso toda hora? É aí que entra o trabalho de facilitador: as distribuições.

Existem centenas (sem exagero) de distribuições Linux disponíveis para todos os tipos de usuários. Cabe a cada usuário escolher qual distribuição usar (cada um com seus méritos e gostos).

As maiores distribuições (com exceções, claro), são feitas por empresas que investem muito no Linux. Estas empresas coletam e produzem programas livres (e às vezes até mesmo proprietários), empacotam, deixam tudo facilitado com um instalador e disponibilizam de graça na Internet e à venda com CDs.

Estas empresas geralmente não ganham dinheiro vendendo caixinhas, licenças, ou coisas do tipo. Isso é uma prática do software proprietário. Estas empresas ganham através de serviço: quando você compra um pacote de uma distribuição, você recebe algo como 6 CDs, um livro, serviço de suporte e outras coisas confortáveis para o usuário. Você está pagando pelo serviço! Se por acaso você não quiser pagar por essas coisas, você mesmo pode baixar a distribuição, comprar mídias de CDs à 80 centavos cada e gravar para usar à vontade. Você só não vai ganhar a caixinha bonitinha, os CDs, o livro e o suporte.

Empresas geralmente precisam de garantias, suporte, gente para fazer a personalização, entre outros. E é aí que ela pode optar por comprar uma distribuição oficial com suporte e serviços vinculados. Ou quem sabe, montar uma equipe competente para trabalhar internamente e se comprometer a dar um serviço de qualidade.

Mais à frente, vou analisar algumas distribuições e dar uma visão geral sobre elas, a fim de ajudar na escolha inicial de cada usuário. Mas lembre-se: gosto é gosto e cada um tem suas necessidades. No fim, tudo é Linux.

Vantagens do Código-AbertoDepois de conhecer um pouco sobre o Linux, seu desenvolvimento aberto e as

licenças livres, que tal agora conhecermos algumas vantagens do código-aberto? :)

Resposta rápida para falhas

Nada é perfeito, certo? É claro que isso é uma verdade e por isso não podemos esperar que o Linux nunca tenha defeitos (sim, no Linux aparecem falhas também). Mas o que diferencia o Linux de sistemas proprietários é sua capacidade de correção rápida para essas falhas.

O que eu quero dizer com isso? Bem, primeiro temos que ver que com o código aberto, a possibilidade de se achar uma falha aumenta bastante, pois várias cabeças podem auditar o código e procurar por falhas de implementação nele a qualquer momento e parte do mundo. Em um curto período de tempo, o sistema fica bem mais seguro e estável. E é justamente isso que acontece na época em que o kernel está em desenvolvimento: lança-se versões instáveis do código e várias pessoas vão auditando e testando, até se chegar a um kernel estável, pronto para ser lançado para o público em geral usar em produção.

Segundo, no mundo do software livre (e isso inclui principalmente o Linux) as falhas que são encontradas são rapidamente consertadas e lançadas ao público. Para se ter uma idéia, geralmente as falhas que se encontram são corrigidas e empacotadas (prontas pra atualização) pelas distribuições num período de 24 horas (ou muito menos). Isso se chama eficiência!


19

Tudo isto é resultado do modelo de código-fonte aberto, porque as pessoas sentem a necessidade de retribuir com correções aquele conhecimento que lhes foi passado.

Mais pessoas disponíveis a observar e cuidar do código

Está bem... Entendemos que com o modelo de código-fonte aberto, qualquer pessoa pode pegar o código em algum lugar, olhar e mexer. Agora imagine que você seja um desenvolvedor e quer colocar as mãos na massa, programando algum utilitário ou coisa parecida. Você tem algumas opções:

1. Começar seu programa a partir do zero, fechar o código e continuar desenvolvendo.

2. Se juntar a uma empresa que faz programas de código-fechado e trabalhar para ela desenvolvendo.

3. Desenvolver o código-livre e disponibilizar para a comunidade.

4. Juntar-se a um grupo que desenvolve programas de código-fonte aberto, desenvolvendo melhorias e correções.

No item 1, você vai ter muito trabalho e vai ter que dedicar muito tempo para uma coisa que não pode valer tanto a pena (fazer coisas do zero hoje em dia são bem mais difíceis). Ingressar um produto novo no mercado prostituído que é a informática é muito difícil. Vai ser preciso também ótimos conceitos de marketing!

Já no item 2, você tem uma possibilidade de sucesso maior que a do item 1, mas sempre terá restrições. Você não terá muita liberdade sobre o que vai fazer, pois estará sempre submetido à política restrita da empresa proprietária. Além disso, a tarefa de ingressar em uma boa empresa desenvolvedora de software é difícil, pois você provavelmente vai precisar de um bom currículo, experiências e por aí vai.

Já os itens 3 e 4, as coisas ficam mais fáceis. No mundo do software livre, tudo funciona como uma seleção natural. A pessoa que se esforça em seus estudos e práticas e desenvolve algo bom para a comunidade, obtém seu status nela e rapidamente ganha confiança e é chamado para vários projetos grandes.

Por exemplo: imagine que você é um Zé Ninguém, que mal entrou na universidade, não tem muita experiência em empresas e passa o dia todo fuçando na Internet. Será que você tem muitas chances de ingressar numa empresa?

Agora imagine que você resolveu estudar uma linguagem de programação e começou a praticar verificando e fazendo mudanças em códigos de programas livres? Você estará recebendo conhecimento do mundo todo gratuitamente, no conforto de sua casa e seu computador. Com o tempo, se suas contribuições forem boas e importantes, a comunidade em si se encarregará de deixá-lo mais importante e esperto no mundo da computação. Em pouco tempo, seu nome poderá estar entre muitos outros nomes importantes na comunidade e isso chama e muito a atenção de grandes empresas (tanto proprietárias quanto de software livres).

Além disso, você não fica restrito a apenas uma linha. Você pode desenvolver o que quiser, o quanto puder e quando quiser. Dependendo do seu esforço, você receberá recompensas pessoais.

Então o fator mais importante é esse: muito mais oportunidades. E isso não se restringe apenas quem está começando não. Já vi muita gente que passou anos em softwares proprietários e que depois conheceu o modelo de código-aberto, abraçou e hoje se sente muito melhor com isso do que antes. Experiência é tudo, viva para você ver como é! Contagiante! :)


20

São essas oportunidades que fazem mais e mais desenvolvedores aparecerem no mundo do software livre e do Linux. Hoje em dia o kernel do Linux é mantido por centenas de pessoas, de diversas partes do mundo (e de empresas também) livremente. E dá muito certo! Depois de ler este texto, agora mesmo você pode baixar os fontes do kernel e contribuir com alguma coisa. Imagine o mundo todo fazendo isso!

Todos podem contribuir sem se preocupar tanto

Como dito anteriormente, qualquer pessoa pode contribuir. Para isso acontecer num modelo de desenvolvimento proprietário, o desenvolvedor teria que falar com a empresa, pedir o código-fonte, pedir autorização, entre outras burocracias (com o risco de não aceitarem) para fazer isso legalmente. E ainda por cima poderá (provavelmente) acontecer de você ter que pagar para fazer essas coisas.

No desenvolvimento aberto, você pode pegar e modificar a qualquer momento, de qualquer lugar e como quiser, sem ter que dar satisfação a ninguém. Adeus preocupações... A única preocupação que você teria seria na hora de distribuir o programa junto com as coisas que você modificou. Para isso você teria que respeitar a licença.

Uso Livre

Da mesma forma que qualquer pessoa pode pegar o código-fonte, modificar livremente à sua maneira, qualquer pessoa pode também pegar o programa e usar sem precisar dar satisfação à ninguém. Se por exemplo eu quiser usar um WebMail (e uso ;P), eu pego na Internet e uso livremente.

No software livre você nunca vai precisar pagar licenças de uso para os programas. Só o que você precisará pagar é pelo serviço. Imagine assim: Você tem todas as peças de um carro de graça e só é preciso montá-lo. Se você não quer ter o trabalho de montar o carro, pague para alguma outra pessoa fazer pra você. Mas se você souber como fazer e quiser fazer, faça à vontade. O único preço que você irá pagar é tempo e esforço.

Incentivo ao Mercado Local (Pequenas e médias empresas)

Assistindo a uma palestra de John "Maddog" Hall, aprendi que o software livre incentiva o mercado local. Quando falamos em software proprietário, apenas uma empresa detém o direito do software. Outras empresas podem surgir como "parceiras" ou "filiais", mas sempre pagando alguma coisa pra matriz e criando dependência.

No software livre a coisa é diferente, qualquer pessoa pode lançar uma empresa de serviços (por exemplo, em software) e começar a trabalhar com produtos livres com total liberdade. Essa mesma empresa vai estar criando uma cultura para aquele programa e isso influencia positivamente quem criou o programa. Sem ter que dar satisfação e pagar para uma matriz, a empresa local pode ganhar mais dinheiro, investir em si mesma e quem sabe começar a desenvolver junto com a empresa criadora. Tudo isso em uma relação saudável.

E de acordo com a demanda, o cliente vai escolher sempre o mais ao seu nível. Se por exemplo o Sr. João, que possui um escritório de contabilidade, com 3 pessoas, quiser montar uma rede baseada em software livre, ele pode escolher uma empresa local para fazer isso. Se uma empresa gigante (exemplo: Casas Bahia) quiser fazer o mesmo, ela contrata uma corporação (tipo a IBM). Como eu disse anteriormente: seleção natural.


21

Capítulo 2 - Dispositivos de armazenamento e estrutura de diretórios.

Antes de pensarmos em fazer qualquer tipo de interação junto ao sistema, precisamos nos localizar. Duas informações são imprescindíveis:

1. Onde ficam armazenados os arquivos do sistema e para que serve cada diretório do sistema;

2. Como podemos usar os dispositivos de armazenamento.

É muito comum que já se comece um material sobre sistema, instalando o mesmo. Porém, vamos primeiro abordar a organização dos dados e dispositivos de armazenamentos, haja vista que para instalarmos precisamos saber onde e como colocar as informações no sistema.

Analisando de outra forma, como poderemos projetar nosso sistema para que os serviços nele instalado sejam estáveis e confiáveis se não soubermos onde e como organizar os arquivos ?

Imagine instalar um servidor DHCP, um servidor SAMBA e uma estação de trabalho. Você seria capaz de descrever como seria organizado o sistema para que todas as instalações fossem bem sucedidas ?

Não podemos pensar em ter a mesma organização para os três exemplos citados anteriormente, haja visto que cada perfil terá características próprias.

Em grande parte dos materiais, encontraremos descrito que precisamos apenas de duas partições para instalarmos o sistema. Uma seria descrita como swap e outra como /. Não deixa de ser verdade. Para instalações menos criteriosas termos apenas duas partições bastam. Mas se pensarmos em sistemas de produção, realmente teremos problemas com essa estrutura.

Para cada instalação, o que determinará toda a estrutura do sistema será o conjunto de aplicações que serão instalados. Não podemos pensar, por exemplo, em estruturas iguais para uma instalação voltada de uma estação de trabalho e uma máquina que iremos usar como servidor SAMBA. Cada perfil irá requerer uma organização própria dos dispositivos de armazenamento.

Nesse capítulo, abordaremos aspectos relacionados a estrutura de diretórios, organização dos dispositivos de armazenamento, suas limitações e como projetar a instalação do GNU/Linux.

Então.. café e uma boa poltrona e bom estudo...


22


23

Estrutura de diretórios.Algo que intriga a muitos iniciantes no GNU/Linux é a organização dos arquivos. O

fato de todo e qualquer arquivo estar submetido a um único ponto, o diretório / (root), torna o entendimento da organização de arquivos um tanto confusa para muitos. Em primeiro lugar, não devemos confundir o diretório / (root) com o diretório do usuário root, o qual está localizado em /root (observe que ele é um sub-diretório do diretório principal /), é comum esse tipo de confusão.

Outro detalhe que devemos observar aqui, é que cada diretório do sistema GNU/Linux tem um papel específico. Conhecer a função de cada diretório é fundamental para as tarefas administrativas.

É comum ouvirmos iniciantes reclamando que não sabem para onde foram as aplicações instaladas no sistema e perderem um bom tempo para achar e identificar qual o arquivo deverá ser usado. O primeiro passo para se ter uma vida mais tranqüila no sistema é conhecer a estrutura a estrutura de diretórios. Dado o primeiro passo, os outros serão bem mais simples.

Vamos ver um pouco da organização dos diretórios, veja o Mapa 3.1

Mapa 3.1 – Detalhamento da estrutura de diretórios.


24

Outro fato que chama a atenção e provoca sérios transtornos de entendimento para novos administradores é a ausência de estruturas independentes de diretórios. Todos os discos estarão “montados” em um diretório, abaixo do /. Em sistemas como o Windows, cada partição terá uma estrutura de diretórios própria e será apresentada de forma independente. No GNU/Linux isso não acontece.

Estudo dos dispositivos de armazenamentoNas páginas anteriores vimos que toda a estrutura de arquivos do sistema estaria

submetida ao diretório /, o que nos faz crer que todo e qualquer dispositivo de armazenamento estará ligado a um ponto, um sub-diretório do /, chamado de ponto de montagem.

No GNU/Linux, todas as informações contidas em dispositivos de armazenamento serão dispostas em diretórios. Esse processo é descrito como montagem de dispositivos, ou seja, dispor das informações de um volume em um sub-diretório do /, para que o usuário possa ter acesso. Todo o processo será detalhado mais adianta quando estudarmos o comando mount e o arquivo /etc/fstab.

Mas uma pergunta permanece... Como posso organizar meus dispositivos de armazenamento, quais suas limitações e como serão identificados no GNU/Linux ?

Encontraremos uma forma muito peculiar de identificação dos discos rígidos. Cada dispositivo terá um nome próprio de acordo com a “porta” à qual está instalada. Em um padrão IDE, todos os discos estarão identificados pelo prefixo hd, seguido do endereço da porta (a, b, c , d) e o número da partição. Em discos SATA e SCSI teremos a identificação com o prefixo sd. Trocando em miúdos...

Se um disco estiver conectado a uma porta IDE 0, sendo o mesmo um primeiro master, teremos o disco identificado como hda. Se este mesmo disco for dividido em 4 partições, teremos então hda1, hda2, hda3, hda4. Se tivermos a mesma configuração em um disco SCSI ou SATA, teremos sda1, sda2, sda3, sda4.

Para cada dispositivo, teremos no máximo 4 partições primárias e 12 partições lógicas. Não é necessário que sejam esgotadas as partições primárias para termos as partições lógicas, porém, independente de como esteja a configuração do disco, sempre que uma partição for identificada com os valores numéricos de 5 – 16, essas serão partições lógicas e de 1 – 4, primárias.

Os limites descritos acima são para cada disco instalado no sistema, independente da razão de sua existência. Não devemos confundir com as limitações impostas para o tipo de partição SWAP, a qual veremos mais adiante.

No mapa abaixo, coloquei algumas situações bem comuns para discos instalados no GNU/Linux, observe os detalhes da organização dos discos.


25

Mapa 3.2 – Detalhamento das partições de discos no GNU/Linux.

No exemplo acima, temos um sistema IDE padrão sendo usado. Os dispositivos hda e hdb têm partições primárias e lógicas, sendo que no primeiro, esgotamos as possibilidades de partições primárias para iniciarmos as lógicas. No segundo, temos 3 partições primárias e cinco partições lógicas.

Importante notar a nomenclatura das partições, observe que as partições lógicas sempre iniciam com o identificador numérico 5. Os demais discos tem apenas partições primárias.

Falamos em partes de discos, em organização “física” dos dispositivos. Além de definir em quantas partes estará dividido o dispositivo é importante entender os tipos de file-system, afinal é ele quem organizará os dados para que possamos acessar.


26

Tipos de File – System e Particionamento de Discos.

Após dividirmos um disco em pedaços, o que chamamos de particionamento, é necessário definirmos um sistema de arquivo que será responsável pelo controle das informações. Isso é feito pelo processo de formatação das partições.

O sistema de arquivos irá dividir o espaço da partição em:

1. Uma parte para armazenar os dados relativos ao sistema de arquivos em si;

2. Com o espaço restante, segmentará em pequenos espaços de tamanhos bem definidos, conhecidos como inodes.

Não existem regras que definam um sistema de arquivos como o universal. Podemos ter um disco, dividido em 5 partições e mais de um sistema de arquivos, um para cada partição, porém, sistemas de arquivos podem ser incompatíveis entre si. Por isso, cuidado ao manuseá-los.

Um sistema operacional pode ser totalmente compatível com um determinado sistema de arquivo, mesmo não sendo o sistema de arquivo padrão. Esse é um aspecto bem positivo de se trabalhar com o GNU/Linux, temos “suporte” para quase todas os sistemas de arquivos existentes hoje, para não falarmos todos. Na abaixo, encontraremos os sistemas de arquivos suportados pelo GNU/Linux.

Fig. 3.3 – Detalhamento de File - System.


27

Dentre todos os sistemas de arquivos, um que devemos ter o cuidado em entender é o SWAP. No processo de instalação do sistema, precisamos apenas de duas partições, uma partição que será usada para o / (local onde o sistema será estruturado) e outra para ser usada como SWAP, onde serão colocados processos que não estejam em estado de processando, liberando espaço em memória para processos “ativos”.

Existem limitações que devemos respeitar. Por sistema, note que não falei disco e sim sistema, podemos ter no máximo 16 gigas de SWAP total e 2 gigas por partição. Em uma visão mais prática...

Limitação por partição 2 Gigas

Número máximo de partições SWAP 8

Limitação por sistema 8 Partições x 2Gigas = 16 Gigas

De uma forma geral, o tamanho da partição SWAP estava relacionado com a quantidade de RAM existente no computador. Definíamos a quantidade de SWAP da seguinte maneira.

SWAP = 2 x RAM (SWAP será 2 vezes a quantidade de RAM)

Considerando que memória RAM era mais valiosa que ouro, esse cálculo foi meio abandonado quando o volume de memória RAM chegou aos patamares de 512 Megas.

Em sistemas normais, mais que 512 Megas de Swap é realmente desnecessário. Hoje em dia, algumas literaturas indicam valores entre 256 a 512 MB, para sistemas com mais de 512 de RAM, porém, na prática, o que determinará o quanto de SWAP deverá ser instalado no sistema são as aplicações e necessidades impostas pelo cenário a ser desenvolvido. Por isso, entendermos os motivos que nos levará a instalação de uma máquina com o sistema GNU/Linux é fundamental.

Particionamento de discos – Comando fdiskAntes mesmo de instalarmos, vamos verificar como preparar os disco através do

comando fdisk. Considerado um comando com certa dificuldade, faremos um exercício prático para tentar facilitar o entendimento.

Nunca devemos esquecer que o comando fdisk é um particionador destrutivo, ou seja, uma vez usado, todos os dados contidos no dispositivo serão perdidos.

O primeiro passo aqui seria a chamada para o fdisk. Para isso digite o comando abaixo.

# fdisk /dev/sda

Com uma sintaxe simples, o fdisk requer que seja informado qual disco será usado no processo. Em nosso caso, teremos o sda como alvo do processo de particionamento. A tela inicial do fdisk será apresentada como na Fig. 3.4.


28

Fig. 3.4 – Tela incial do fdisk

Observe que no topo da tela exibida teremos informações da volumetria do dispositivo. Com a comando “p“, listaremos a tabela de partições do disco. O mesmo podemos obter sem a necessidade de entrarmos no prompt de execução do fdisk digitando na shell do sistema o comando #fdisk -l. Veja a Fig. 3.5

Fig. 3.5 – Listagem da organização do disco.

Observe na figura acima que a partição estendida aparece destacada, veja ao lado direito a descrição Extended e logo abaixo dela está a partição lógica.

Com a comando “m” teremos o help do fdisk, aqui encontraremos as opções para uso do fdisk. Algumas opção serão apresentadas apenas no menu de uso avançado do fdisk. Para acesso aos recursos avançados digite o comando “x” e em seguida o comando “m”.

Muito cuidado ao usar o fdisk, para garantias de que o que foi feito realmente era a ação desejada, sempre use o comando “p”, assim você acompanhará todo o processo. Caso tenha dúvidas do que fazer, o comando “q” sempre será bem-vindo. Com ele sairemos do prompt do fdisk sem salvar as alterações. Veja um exemplo na Fig 3.6


29

Fig. 3.6 – Detalhamento da opção m do fdisk.

Antes de criarmos novas partições, vamos apagar todas as existentes no sistema, use o comando “d“. O número da partição será solicitado. Informe-o de acordo com a partição que deseja apagar. Farei com uma partição para demonstrar, veja abaixo.

Fig. 3.7 – Detalhamento da opção d do fdisk.

Faça o mesmo com as outras partições que deseja apagar, uma a uma.

Criaremos agora a nova partição. Para isso, usaremos o comando “n“. Algumas informações serão solicitadas. Veja que no exemplo abaixo. O primeiro passo é definirmos se a partição será ou não primária.

Em seguida, informamos o número da partição, defina o bloco inicial da partição. Caso não saiba qual será o bloco inicial, use o valor definido pelo sistema. Por fim, informe o tamanho da partição, exatamente como demonstrado no exemplo. Note que existe um sinal + antes do tamanho e a letra M para determinarmos que o tamanho será em Megas.

Fig. 3.8 – Detalhamento da opção n.

Repita esta etapa para criar as outras partições do sistema.

Após definirmos o tamanho, definiremos o tipo de file system da partição, usando


30

comando “t “.

Será solicitado o número de uma partição, e em seguida o código do tipo do file system. Com a opção “L“ teremos a lista de todos os file system suportados. Identifique o file system que irá usar na partição e digite o código hexadecimal que está descrito ao lado esquerdo da descrição na tabela apresentada.

Tendo uma visão geral do processo teremos. . .

Fig. 3.10 – Detalhamento de todo o processo de escolha do File System.

Repita essa etapa para cada partição criada, assim, não teremos surpresas desagradáveis nas próximas etapas do processo. Usando o comando “w“, salve e saia do fdisk.

Para que todas as alterações sejam válidas, é interessante reiniciar o sistema.

Sistema reiniciado, vamos ao processo de formatação das partições criadas.

Formatação do disco – Comando mkfsO fato de se criar uma partição e definir um file system não nos dá a condição de uso

da partição. Para que possamos usá-la precisamos formatá – la de forma que o sistema possa entender a organização dos dados.

Não esqueça que o fdisk é apenas um particionador, para formatarmos um partição no GNU/Linux, usaremos o comando mkfs.

Imagine que seja necessário formatar uma partição, usando o ext3 como file system. Veja como é simples...

#mkfs.ext3 /dev/sda5

Interessante nesse momento buscarmos por blocos defeituosos. Para isso, use o


31

comando fsck, como no exemplo abaixo

#fsck.ext3 -pc /dev/sda5

No comando acima, duas ações foram efetuadas. O -p define que será feito a reparação do sistema automaticamente. Já o -c busca por bad blocks e os adiciona a uma lista.

Para partições SWAP, o conceito é basicamente o mesmo, o que muda são os comandos que usaremos. Veja como a mesma ação seria feita para a SWAP.

#mkswap -c /dev/sda6

Formatação feita, vamos ativar a partição SWAP com o comando swapon

#swapon -a

Podemos verificar as partições SWAP lendo o conteúdo do arquivo /proc/swaps.

#cat /proc/swaps

Muito bem, partições criadas, formatadas e checadas. Podemos seguir com nosso processo.

Instalação do GNU/LINUXPartiremos agora para instalação do GNU/Linux. Usaremos o padrão de instalação

gráfica, por questões didáticas. Não usarei aqui nenhuma instrução avançada para a instalação apesar de criar as partições e formatar os discos usando o fdisk para dar uma base de como seria o preparo para instalação no slackware, por exemplo.

Detalhar cada processo de forma muito minuciosa, seria realmente complicado haja vista que venho dizendo desde o início que para determinarmos uma organização para a instalação precisamos entender as necessidades do ambiente a ser configurado. Por isso, resolvi usar minhas aulas para discutirmos um pouco mais sobre o assunto, e acredite, falamos muito sobre isso.

Para demonstrar a instalação, usaremos o Fedora como modelo. Respeitando as características de cada distribuição, o processo é basicamente o mesmo. Vamos ao processo de instalação.

Creio que seja interessante conhecer o equipamento que será usado, para poder determinar características mais específicas ao sistema.


32

O primeiro passo é iniciar o sistema pelo cd de instalação.

Após o boot do sistema pelo dispositivo de cd, será apresentada uma tela de boas vindas, como na figura 3.11

Fig. 3.11 – Tela Inicial de Instalação.

Na tela apresentada observe nas possibilidades de uso do menu. Caso queira instalação em modo console, reduzindo o consumo de recursos com o ambiente gráfico, digite linux text e em seguida pressione enter.

Para iniciar a instalação em modo gráfico apenas pressione a tecla enter.

Na etapa seguinte será apresentada uma solicitação de testes dos discos de instalação. Caso queira ter certeza que nenhum dos discos trarão problemas durante a instalação, selecione OK. Caso queira passar esta fase sem testes de discos, selecione SKIP. Veja a figura 3.12.

Fig. 3.12 – Testes de discos de Instalação

É importante verificar os discos, ao menos durante a primeira instalação com mídias novas, isso nos garante que não seremos pego de surpresa lá pelos 99 % da instalação.


33

Após selecionar se iremos ou não executar os testes nos discos, passaremos para as etapas seguintes. Selecione o idioma para a instalação do sistema. Veja o exemplo na figura 3.13.

Fig. 3.13 – Seleção de Idioma

Idioma selecionado, definiremos agora o tipo do teclado. Caso seu teclado tenha o ç, selecione o layout Português Brasileiro, caso não tenha, identifique o teclado e selecione na lista apresentada, como na figura 3.14 e vamos adiante.

Fig. 3.14 – Configuração do teclado

Na etapa seguinte, defina se será feito uma nova instalação ou uma atualização do sistema . Caso o sistema já esteja instalado, e queira atualizar o mesmo e tenha o cd de uma nova versão, apenas solicite uma atualização do sistema.

Caso queira instalar a instalação do zero, escolha Instalar Fedora Core. Escolhido a ação, passo adiante. Agora defina qual processo será executado, se instalação ou atualização. Veja a figura 3.15.


34

Fig. 3.15 – Seleção do Processo Atualização ou Instalação

Será questionado qual o procedimento para organização do disco. Eu uso sempre o processo manual, assim posso determinar exatamente como os meus discos serão usados pelo sistema, além de poder determinar que, em caso de termos uma instalação do windows, não corro riscos de perder as informações do mesmo. Veja a Figura 3.16


35

Fig. 3.16 – Definição do processo de configuração do Disco


36

Agora chegamos ao Disk Druid, um formatador em ambiente gráfico que nos auxiliará na organização do disco. Precisamos escolher no mínimo de duas partições, uma para ser usada pelo / e outra para ser a swap. Lembre-se que os discos podem ser particionados pelo fdisk, mas as relações entre os discos e o ponto de montagem não foi feito até o momento. Aqui é que realmente definiremos qual partição será disposta em qual ponto de montagem. Defina de acordo com suas necessidades e boa sorte. Veja um exemplo na Figura 3.17

Fig. 3.17 – Disk-Druid

Após organizarmos o file system, definirmos o tipo de file system, passamos a configuração do Boot Loader do sistema, veremos mais detalhes nos próximos capítulos. No caso do Fedora, trabalharemos com o GRUB, como demonstrado na figura 3.18

Fig. 3.18 – Configuração do Boot-Loader


37

Configurar uma interface ethernet não é necessário nesse momento, porém pode ser feito como na figura 3.19

Fig. 3.19 – Configuração da interface de rede

Defina o fuso horário que será adotado pelo sistema, seguindo o exemplo da figura 3.20

Fig. 3.20 – Seleção de Fuso


38

Nesse ponto da instalação definiremos uma senha para o administrador do sistema, o usuário root. Veja a figura 3.21

Fig. 3.21 – Definição de senha de root

No GNU/Linux, temos dois caminhos a seguir a partir deste ponto. O primeiro é escolhermos um dos perfis sugeridos pelo próprio sistema com alguns pacotes pré estabelecidos de acordo com cada perfil e um segundo caminho que é o de escolhermos os pacote que desejamos instalar. Em caso de servidores, aconselha-se escolher os pacotes manualmente, definindo somente o que é necessário para o funcionamento da máquina. Veja a tela dessa etapa na figura 3.22

Fig. 3.22 – Seleção de pacotes

Uma tela descrevendo o que será feito será apresentada, confirma a instalação para


39

continuarmos o processo. Veja a figura 3.23

Fig. 3.23 – Aviso de início de instalação

Agora só nos resta esperar a conclusão da instalação . Nessa etapa serão apresentados os pacotes que estão sendo instalados. Como falei, basta aguardar. Veja um exemplo na figura 3.24

Fig. 3.24 – Detalhes do processo de instalação


40

Como demonstrado na figura 3.25, reinicie a máquina e pronto ...GNU/Linux pronto para o combate...

Fig. 3.25 – Finalização da instalação, aviso de reboot

Como vimos acima, não há grandes segredos para instalar o sistema, desde que se saiba o que e onde queremos instalar.


41

Capítulo 3 - Processo de inicialização, Boot Loader e Run Level

Instalação feita, inicia agora a nossa vida de estudos e administração do GNU/Linux.

Nesse capítulo, abordaremos como se dá o processo de bootstrap, arquivos lidos, explosão do kernel em memória, o processo init, arquivos relacionados ao init, níveis de execução até chegarmos no ponto de um usuário logado e pronto para interagir junto ao sistema.

Importante observar as relações entre os processos e os arquivos lidos e gravados, isso nos dará a possibilidade de definirmos exatamente o comportamento do sistema.


42


43

Bootstrapping – Inicialização do Computador.Muitas pessoas me questionam se o mais importante é saber o maior número de

comandos possíveis e imagináveis ou saber como colocar um super servidor no ar. Para mim, é o entendimento do sistema e conhecer as relações entre os processos e os arquivos.

Saber como se comporta o sistema durante o processo de inicialização é o foco deste capítulo. Estudaremos as etapas de bootstrapping desde os testes da bios ao processo de login do usuário. Vamos direto ao ponto então.

Veja a seqüência de boot no diagrama 4.1

Diagrama 4.1 – Detalhamento do Processo de inicialização do Sistema.

Durante o processo de inicialização, nada está em funcionamento e o sistema tem que se virar para criar o ambiente necessário para que possamos interagir com o mesmo. Durante o processo de bootstrapping, o kernel é carregado em memória e inicia um conjunto de execuções para tornar o sistema disponível.

No gráfico acima, tentei resumir todo o processo para tornar mais simples a visualização do mesmo, porém, acho importante detalhar um pouco demonstrando os arquivos que serão lidos durante esta etapa.

Iniciado o sistema, a primeira etapa do processo é iniciado pelo código de boot encontrado em memória ROM. Durante essa etapa, o sistema faz um reconhecimento do hardware, em seguida, tenta localizar uma chamada para carga do kernel em memória. Essa etapa eu chamo de boot de bios.

Em seguida o kernel é chamado, carregado em memória e entra em ação. Vamos


44

estudar essa etapa do boot, que chamo de boot de kernel.

Durante o processo de bootstrapping, sua primeira tarefa é garantir o kernel em execução em memória. Para isso, é feito uma chamada ao arquivo /boot/vmlinuz.

Após carregar e garantir a execução do kernel em memória, este executa testes de memória para tentar descobrir quanto poderá ser usado. Algumas informações são dimensionadas de forma estatística, assim, pode-se determinar quanto de memória será usada para si e quanto poderá ser inicializada. Esta memória é reservada para o kernel, o que impede o uso para aplicações em camadas de usuário.

Uma das primeiras etapas aqui é a checagem do hardware, para poder determinar que dispositivos estão presentes. As informações dos dispositivos nem sempre são fornecidas completamente. Para resolver isso, o kernel sonda o barramento em busca dos dispositivos para determinar informações nos drivers apropriados. Para os dispositivos com drivers que estão faltando ou que não respondem a sondagem serão desabilitados. Em compensação, dispositivos conectados posteriormente podem ter seus drivers carregados ou habilitados durante a execução.

Terminado o processo do kernel, vários processos são criados. O primeiro processo a ser criado é o init, considerado o processo pai de todos os outros processos. Sua identificação será sempre com o PID 1 (Identificador do processo).

Junto ao processo init vários outros processos são carregados. Todos esses processos estão ligados ao nível de execução do sistema, o que veremos em mais detalhes em capítulos posteriores.

Mas uma pergunta ainda permanece. Quem é responsável pela chamada do kernel ?

Bem, o responsável por essa chamada é o BOOT LOADER. No GNU/Linux temos dois BOOT LOADERS padrão, o GRUB e o LILO.

Vamos ver em detalhes ambos na etapa seguinte.

Gerenciadores de boot (bootloaders)

Após a etapa de boot da máquina, que é iniciado pela BIOS, o primeiro mecanismo de interação que teremos junto ao sistema é o Boot Loader. No GNU/Linux temos dois Boot Loaders, o GRUB ( GRand Unifying Bootloader ) e o LILO ( LInux LOader ). É de responsabilidade dele fazer a chamada do kernel do sistema, por isso, se faz necessário o entendimento do Boot Loader para um administrador de sistema.

Partiremos do GRUB.

GRUB ( GRand Unified Bootloader)

A primeira informação que devemos ter do GRUB é sobre a localização do seu arquivo de configuração e como personalizá-lo.

Os arquivos de configuração do grub estão em /boot/grub. Alguns livros informam–no como sendo o arquivo menu.lst, porém, vejam que menu.lst é um link do arquivo grub.conf, como demonstrado abaixo.

#ls /boot/grub

lrwxrwxrwx 1 root root 11 Ago 31 11:45 menu.lst -> ./grub.conf


45

Vamos entender o arquivo grub.conf.

#vim /boot/grub/grub.conf

# grub.conf generated by anaconda

#

# Note that you do not have to rerun grub after making changes to this file

# NOTICE: You do not have a /boot partition. This means that

# all kernel and initrd paths are relative to /, eg.

# root (hd0,5)

# kernel /boot/vmlinuz-version ro root=/dev/hda6

# initrd /boot/initrd-version.img

#boot=/dev/hda

default=1 (Indicação de qual sistema operacional será inicializado por padrão)

timeout=15 (Indicação do tempo de espera, em segundos, para carregar o sistema operacional, caso não haja interação de teclado)

splashimage=(hd0,5)/boot/grub/splash.xpm.gz (Arquivo que será usado como papel de parede do GRUB)

hiddenmenu (Inibe a exibição de opções no menu do grub, durante o boot. Garante que a imagem especificada pela linha default seja carregada)

title Fedora Core (2.6.15-1.2054_FC5) (Nome do Sistema. Apenas em caráter informativo. Podemos colocar qualquer nome nessa área)

root (hd0,5) (Indica a partição onde o sistema foi instalado. Um detalhe importante é observar a forma como os endereços do disco são informados, hd0 corresponde à hda e 5 à sexta partição do disco. Trocando em miúdos, hd0,5 é correspondente à hda6)

kernel /boot/vmlinuz-2.6.15-1.2054_FC5 ro root=LABEL=/ rhgb quiet(Imagem do kernel que será chamada para o Boot)

initrd /boot/initrd-2.6.15-1.2054_FC5.img (Aqui teremos a chamada do arquivo que contém informações dos módulos que serão carregados. Cada compilação do kernel terá seu arquivo de imagens)

title Other

rootnoverify (hd0,0) (Essa opção tem a mesma função de root, porém, não tenta montar a partição raiz. É muito usada para chamadas de sistemas como MS-DOS e Windows)

chainloader +1 (Alguns sistemas operacionais armazenam seus bootloaders no início da partição onde estão instalados. O chainloader informa o local onde o Bootloader foi instalado)

Além de entendermos as configurações do GRUB, precisamos conhecer ainda o utilitário grub-install. O grub-install instala o GRUB na MBR do primeiro disco, criando o


46

diretório /boot/grub.

As opções mais usadas com o grub-install são :

--root-directory=DIR (Instala a imagem do GRUB em diretório que não seja o raiz)

--recheck (Checa o arquivo /boot/grub/device.map. Útil quando retiramos ou acrescentamos um novo disco no sistema)

LILO ( LInux LOader )

O LILO foi o primeiro Bootloader usado pelas distribuições GNU/Linux. Por ser grande para caber no setor de boot ou na MBR, o LILO foi dividido em duas partes.

A primeira é o motor de arranque e está na MBR ou setor de boot, sendo que a segunda é a responsável pela interação com o usuário. Um dos aspectos mais importantes do lilo é a configuração do mesmo. Vamos analisar o arquivo /etc/lilo.conf

boot=/dev/hda (Aqui definimos de qual disco será usado o setor de boot do sistema)

map=/boot/map (Arquivos de mapas. Por padrão /boot/map)

install=/boot/boot.b (Arquivo de setor de boot)

prompt (Disponibiliza ao usuário um prompt de interação com o LILO)

timeout=50 (Define o tempo de espera antes de iniciar o sistema)

image=/boot/vmlinuz (Caminho completo para a imagem que será carregada)

label=Linux (Nome de identificação da imagem)

root=/dev/hdb1 (Partição que deverá ser montada como root)

read−only (Apenas Leitura)

Para que possamos ter as alterações disponíveis no próximo boot do sistema, é necessário usar a aplicação /sbin/lilo.

Níveis de execução do Sistema.Durante o processo de boot do sistema, init é ativado dando início ao que chamo de

explosão dos processos filhos do init, ou seja, todo e qualquer processo startado no sistema.

Esses processos estão ligados diretamente ao nível de execução do sistema, o qual está referenciado no arquivo /etc/inittab. É necessário entendermos algumas informações desse arquivo, então vamos a elas.

No processo de carga do init, o arquivo /etc/inittab será lido para que o sistema saiba qual nível de execução padrão. Através do nível de execução, o sistema saberá quais serviços deverão ser carregados sempre que a máquina for ligada. Em um sistema padrão, temos 7 níveis de execução para o Linux, indo do nível 0 ao nível 6, cada um com uma característica. Veja o padrão de funcionamento dessas características, analisando Mapa 4.2.1. Importante ressaltar que algumas distribuições alteram o comportamento de alguns níveis.


47

Mapa 4.2.1 – Detalhamento dos níveis de execução.

Para determinarmos o nível padrão de execução, edite a linha id:NE:initdefault:, onde NE é o nível de execução do sistema. Por exemplo, id:3:initdefault: determina que o nível de execução será o nível 3.

Para cada nível de execução existirá um diretório /etc/rc.d/rcNE.d, onde encontraremos os scripts de start e stop dos serviços relacionados com este nível. Os arquivos estão descritos de duas formas S45autofs e K85autofs, vamos entendê-los.

O S indica que o serviço relacionado ao arquivo será inicializado durante o start do nível, o número 45 indica a ordem de prioridade desse serviço em relação aos outros que também serão carregados o nome é apenas uma descrição, aqui colocamos o nome de serviço para facilitar a identificação do mesmo.

No outro arquivo teremos o K indicando que o serviço será “morto”, desligado, o número como no primeiro caso indica a ordem em relação aos outros serviços que serão mortos e o nome.

Para cada nível existirá um conjunto de aplicações que serão mortos e outras que serão carregadas. Para saber mais sobre esses serviços, veja o conteúdo dos diretórios /etc/rc.d/rcNE.d.

Após os processos terem sido inicializado, a próxima etapa é a execução do getty, aguardando o login do usuário. Essa etapa é descrita como boot de usuário.

Durante o processo de login do usuários, alguns arquivos são lidos para que seja criado o ambiente de interação do mesmo, junto ao sistema. Seria quase impossível criar um ambiente para cada usuário, tendo que copiar cada arquivo necessário para os homes, manualmente. Para isso, o sistema lerá a “variável” skel no arquivo /etc/default/useradd, ele informará onde estão os arquivos necessários para a criação do ambiente do usuário (.bashrc, .bash_profile e .bash_logout), no nosso caso em /etc/skel.

O arquivo .bash_profile é responsável pelos programas que devem ser executados na abertura da sessão do usuário, pela configuração do ambiente e pelos caminhos (PATH). Nele também há uma chamada para o .bashrc.

O arquivo .bashrc é executado por uma chamada do .bash_profile. Podemos editar o arquivo para personalizar o ambiente. Nele é muito comum que sejam criados alias para


48

comando, facilitando a vida do usuário. Importante lembrar que estamos falando de um arquivo que estará no diretório home do usuário, assim, tudo o que for alterado nele, será valido apenas para o usuário. Veja como poderíamos editar este arquivo.

$vim .bashrc

# .bashrc

# Source global definitions

if [ -f /etc/bashrc ]; then

. /etc/bashrc

fi

alias l='ls -aF --color=auto'

alias montacd='eject; sleep 5; eject -t; mount /media/cdrom; cd /media/cdrom; ls'

Ainda existem dois arquivos que fazem parte do processo de criação de ambiente do usuário com o sistema, sendo estes o /etc/bashrc (responsável por variáveis globais, lido sempre que o uma nova sessão da bash for executada) e o /etc/profile (executado sempre que um usuário logar. Responsáveis pelas variáveis do sistema dentre outras informações usadas pelo usuário junto as consoles). Para determinar comportamentos “globais”, comuns a todos os usuários, podemos editar o arquivo /etc/profile. Para criarmos aliases globais, podemos usar o /etc/bashrc.

Algumas variáveis devem ser conhecidas, para que possamos ajustar o sistema para necessidades mais específicas.

Variável Definição

BASH shell usada pelo usuário

PS1 Formato de apresentação do prompt

PATH Caminhos de localização de comandos e aplicações do sistema.

HOSTNAME Nome da máquina

HOME Diretório home do usuário logado

LOGNAME Login do usuário

UID Identificador numérico do usuário

Alterar qualquer valor das variáveis do sistema pode acarretar no funcionamento pouco eficiente do mesmo, por isso, cuidado ao tratar dessas informações. Veremos mais sobre shell, variáveis de sistemas e customização de ambiente mais adiante.


49

Capítulo 4 - Administração do GNU/Linux

Após instalado, nossa próxima etapa é entendermos os comandos e como usá-los em conjunto, para darmos mais dinamismo à nossas ações. Todos os comandos aqui fazem parte do conteúdo exigido pela prova de certificação da LPI – Linux Professional Institute e do processo de certificação da Red Hat RHCE, por isso tentei colocar o maior número de informações possíveis além de alguns manuais completos e traduzidos. Usaremos os mapas mentais, buscando melhor visualização das opções dos comandos, facilitando o entendimento.

Vamos lá então...


50


51

Usuários, Grupos, Senhas e NPA.Em sistemas como o GNU/Linux, entender os mecanismos de administração de

usuários, senhas, grupos e as relações entre usuários, grupos e arquivo é fundamental. Nada se faz no sistema sem um usuário e muito menos se não soubermos como criar um ambiente onde muitos usuários podem interagir.

Por definição, cada usuário no sistema terá seu próprio ambiente onde poderá armazenar seus dados, o que chamamos de diretório home, criado normalmente no /home, o qual leva o mesmo nome definido como o login do usuário, além de possuir um grupo principal e um UID ( User ID – Identificador de usuário ). Mas isso não é o bastante para um usuário interagir com o sistema. Além de todas as informações descritas acima, para que o usuário possa interagir com o sistema é preciso que ao mesmo seja relacionado um shell, um interpretador de comandos. No GNU/Linux temos várias possibilidades de shell, sendo o padrão o bash (Bourne-Again Shell).

Nas próximas páginas deste capítulo, veremos alguns comandos usados para administrar usuários, grupos e senhas e mais adiante veremos ainda onde todas as informações ficam armazenadas e como podemos alterar o comportamento padrão do sistema.

Para vermos a chamada do comando em execuções configuraremos o ambiente executando o comando abaixo.

$set -x

Para desligar a exibição do comando, use o comando

$set +x

Podemos ainda usar o comando strace, este é realmente um comando interessante de ser usado para conhecermos os detalhes de ação de cada comando do GNU/Linux.

1. useradd

Descrição: Cria usuário no sistema

Mapa 1 – Detalhamento de Opções do comando useradd

Exemplos:

#useradd clayton


52

#useradd -d /users/clayton clayton

#useradd -d -m /users/clayton clayton

#useradd -c “Clayton Lobato” clayton

2. userdel

Descrição: “Apaga” um usuário do sistema.

Mapa 2. – Detalhamento de Opções do comando userdel

Exemplos:

#userdel -f clayton

#userdel -r clayton

#useradd clayton

3. passwd

Descrição: Define ou altera a senha de um usuário.

Mapa 3. – Detalhamento de Opções do comando passwd

Exemplos:

#passwd -x 5 clayton

#passwd -w 3 clayton

#passwd -n 4 clayton

#passwd -d clayton


53

4. chshDescrição: Altera o shell do usuário.

Mapa 4 – Detalhamento de Opções do comando chsh.

Exemplos:

#chsh -s /bin/sh clayton

#chsh -l

5. chage

Descrição: Muda informações de expiração de senha do usuário.

Mapa 5 – Detalhamento de Opções do comando chage.

Exemplos:

#chage -l clayton

#chage -M 20 clayton

#chage -m 10 clayton


54

6. usermod

Descrição: Altera informações da conta do usuário.

Mapa 6 – Detalhamento de Opções do comando usermod.

Exemplos:

#usermod -g desenvolv clayton

#usermod -c “Clayton Lobato” clayton

#usermod -l c1141478 -c “clayton lobato” clayton

#usermod -L clayton

#usermod -U clayton

7. chfn

Descrição: Altera informações de identificação do usuário.

Mapa 7 – Detalhamento de Opções do comando chfn.

Exemplos:#chfn -f “Clayton Lobato” clayton


55

8. groupaddDescrição: Cria grupo no sistema

Mapa 8. – Detalhamento de Opções do comando groupadd.

Exemplos:

#groupadd layer

#groupadd -f layer

#groupadd -g 525 bases

#groupadd -r master

9. groupdelDescrição: Apaga grupo no sistema

Exemplos:

#groupdel layer

10. gpasswd Descrição: Administra o arquivo /etc/group.

Mapa 10 – Detalhamento de Opções do comando gpasswd.

Exemplos:

#gpasswd -a clayton suporte

#gpasswd -d clayton suporte

#gpasswd -M alice,eduardo suporte

Existe uma diferença enorme, muito mais em execução que conceitual das opções -M e -a.


56

11. groupmodDescrição: Modifica informações de um grupo.

Tabela 11 – Detalhamento de Opções do comando groupmod.

Exemplos:

#groupmod -g 536 suporte

#groupmod -n suporte redes

12. chpasswd

Descrição: Atualiza a senha de usuários cadastrados no sistema a partir de um arquivo com o formato usuário:senha.

Opções Descrição

-e Aguarda que as senhas sejam criptografadas.

Mapa 12 – Detalhamento de Opções do comando chpasswd.

13. idDescrição: Exibe os ids dos usuários.

Mapa 13 – Detalhamento de Opções do comando id

Exemplos:

#id -g clayton

#id -u clayton

#id -n clayton

#id -G clayton


57

14. chgrp Descrição: Define um novo grupo a um arquivo.

Mapa 14 – Detalhamento de Opções do comando chgrp

Exemplos:

#chgrp root teste

#chgrp root:teste base_dados

#chgrp -hR root /base/postgres

15. finger

Descrição: Exibe informações de usuários.

Mapa 15 – Detalhamento de Opções do comando finger

Exemplos:

#finger clayton

#finger -p clayton

#finger -m clayton

Para que um usuário seja válido no sistema, este precisa obrigatoriamente de um login, uid, gid, home, shell e senha.

As senhas no GNU/Linux são definidas pelo comando passwd e armazenada em /etc/shadow. No arquivo /etc/passwd, ao contrário do que se pensa, serão armazenadas apenas as informações da conta do usuário. Veja na Figura 1.

Fig 1. – Informações da conta do usuário


58

Observe que temos 7 colunas divididas por : ( dois pontos ). Da esquerda para a direita, temos...

clayton login do usuário;

:x Indicação de senha;

:500 UID – User ID;

:500 gID – Group ID (nesse caso teremos o grupo principal do usuário);

:Clayton Lobato Comment – Comentário, descrição do usuário;

:/home/clayton Diretório home do usuário;

:/bin/bash Shell do usuário.

Note que as senhas não estão presente no arquivo /etc/passwd. Para visualizarmos as senhas encriptadas, exibiremos o arquivo /etc/shadow. Veja a figura 2.

Fig. 2. – Visualização de senhas encriptadas

Mas de onde saem todas essas informações ?

Existem alguns arquivos que são fundamentais para administração do sistema. Em se tratando de usuários, vamos estudar os 4 que acho mais importante.

Começaremos pelo /etc/login.defs. Este é um dos primeiros a ser lido no processo de criação do usuário. Nele, informações como controles de senhas, UID inicial e final e criação ou não do diretório home são gerenciados. Veja algumas opções importantes desse arquivo.

Mapa 16 - Detalhamento do arquivo /etc/login.defs


59

Outro arquivo que devemos conhecer é o /etc/default/useradd. Vamos ao conteúdo deste...

Mapa 17 - Detalhamento do arquivo /etc/default/useradd

Fechando o conjunto de informações, para todo usuário criado, será criado um diretório home e nele teremos os arquivos responsáveis pelo ambiente de interação dos usuários.

Durante o processo de criação do usuário foi dito que um grupo principal para o usuário foi criado. Mas... Como funciona essa relação ?

Bem, no mundo GNU/Linux cada usuário, arquivo, processo tem relação com um grupo. Digite o comando ls -l em sua console, veja o que aparece. . .

drwxr-xr-x 2 root root 4096 Jan 1 2000 bindrwxr-xr-x 3 root root 4096 Jan 1 2000 bootdrwxr-xr-x 9 root root 4920 Jan 1 00:02 devdrwxr-xr-x 78 root root 12288 Jan 1 00:01 etcdrwxr-xr-x 3 root root 4096 Jan 1 2000 homedrwxr-xr-x 11 root root 4096 Jan 1 2000 libdrwx------ 2 root root 16384 Dez 31 22:53 lost+founddrwxr-xr-x 4 root root 4096 Jan 1 2000 mediadrwxr-xr-x 2 root root 4096 Abr 25 2005 miscdrwxr-xr-x 2 root root 4096 Mai 23 2005 mntdr-xr-xr-x 2 root root 4096 Jan 1 00:01 netdrwxr-xr-x 2 root root 4096 Mai 23 2005 optdr-xr-xr-x 53 root root 0 Dez 31 22:01 procdrwxr-x--- 5 root root 4096 Jan 1 2000 rootdrwxr-xr-x 2 root root 4096 Jan 1 2000 sbindrwxr-xr-x 2 root root 4096 Jan 1 2000 selinuxdrwxr-xr-x 2 root root 4096 Mai 23 2005 srvdrwxr-xr-x 10 root root 0 Dez 31 22:01 sysdrwxrwxrwt 3 root root 4096 Jan 1 00:01 tmpdrwxr-xr-x 14 root root 4096 Jan 1 2000 usrdrwxr-xr-x 26 root root 4096 Jan 1 2000 vardrwxr-xr-x 3 root root 4096 Dez 31 22:55 x25

Para cada arquivo apresentado existe uma relação com um usuário e um grupo.

Para que se tenha acesso a um arquivo, é necessário ter permissão. Vamos entender essa relação analisando umas das linhas exibidas acima.


60

drwxr-xr-x 2 root root 4096 Jan 1 2000 bin

d Indicação de que o arquivo é um diretório;

rwx Indica o nível de permissão de acesso do DONO do arquivo;

r-x Indica o nível de permissão de acesso do GRUPO do arquivo;

r-x Indica o nível de permissão de acesso para usuários que não se enquadram nos parâmetros anteriores, ou seja, não é o dono e nem faz parte do grupo do arquivo;

root Indica o usuário DONO do arquivo;

root Indica o GRUPO do arquivo;

4096 Tamanho do arquivo, em bytes.;

Jan 1 2000 14:01 Data e hora do ultimo acesso ao arquivo;

bin Nome do arquivo.

Mas onde ficam armazenadas as informações dos grupos, membros dos grupos e como gerenciar os grupos no GNU/Linux ?

Vamos por partes!

O arquivo no qual as informações de grupos são armazenados é o /etc/group. Como acontece com os usuários, os grupos também possuem uma senha, só que no caso dos grupos o uso é opcional. As senhas dos grupos ficam armazenadas no arquivo /etc/gshadow.

Veja o conteúdo do arquivo /etc/group. Nele encontraremos informações dos grupos como o nome, group id e membros. Para entendermos, vamos olhar o conteúdo do arquivo citado.

mailnull:x:47:

smmsp:x:51:

rpcuser:x:29:

nfsnobody:x:65534:

apache:x:48:

squid:x:23:

webalizer:x:67:

tomcat:x:91:

xfs:x:43:

ntp:x:38:

mysql:x:27:

screen:x:84:

postdrop:x:90:

postfix:x:89:


61

eduardo:x:501:

notifiles:x:502:

qmail:x:503:clayton

Observe o grupo eduardo. Nele temos a descrição do grupo e o gid do mesmo, neste caso o número 501. Já o grupo qmail, possui um membro chamado clayton, este um usuário. Trocando em miúdos...

A estrutura base do arquivo /etc/group é

grupo:x:gid:membros

Entendido como gerenciar usuários e grupos, o próximo passo será o gerenciamento de permissões de acesso aos arquivos.

Tudo no GNU/Linux é um arquivo, e para cada arquivo definimos um nível de acesso, nível esse dividido em leitura (read), escrita (write) e execução (execute), além das informações de dono e grupo. Alguns comandos são usados para determinar um nível de permissão de acesso, o que chamo de NPA, além de determinar o dono e o grupo do arquivo. Quando novos arquivos são criados no sistema, entra em ação o umask, o qual garante que que determinados NPAs sejam usados como padrão, no processo de criação desses arquivos. No GNU/Linux teremos dois padrões, 755 será usado como padrão para criação de diretórios e 644 para criação de arquivos.

Para alterarmos o valor do umask, usamos o seguinte mecanismo.

777 - 027 = 750 ( estes serão os níveis de permissão )

Detalhando a informação....

777 é o valor total permitido para os níveis de permissão de acesso. 027 será o decremento umask. O resultado desse cálculo será o valor do NPA usado pelo sistema, nesse caso, 750 (Dono com permissão total, grupo podendo ler e executar e outros sem nenhum tipo de acesso). Vejamos os comandos que nos permitem definir os níveis de acesso, dono e grupo dos arquivos. Não usaremos os mapas aqui por conta da quantidade de informações dos comandos.

16. chmod Descrição: Gerencia os níveis de permissão de acesso dos arquivos.


-c Modo verbose, mostrando apenas as alterações feitas.

-R Aplica a recursividade na execução do comando.

u Usuário.

g Grupo.

o Outros.


62


a Todas as camadas.

Tabela 16 – Detalhamento de Opções do comando chmod

Modo Decimal Descrição

4 Leitura

2 Escrita

1 Execução

6 Leitura e Escrita

5 Leitura e Execução

3 Escrita e Execução

7 Leitura, Escrita e Execução

Tabela 16. – Comando chmod, níveis de permissão modo decimal

Modo Simbólico Descrição

r Leitura

w Escrita

x Execução

rw Leitura e Escrita

rx Leitura e Execução

wx Escrita e Execução

rwx Leitura, Escrita e Execução

Tabela 16 – Comando chmod, níveis de permissão modo simbólico

Modos Especiais Descrição

1 Stick Bit

2 Set group ID

4 Set User ID

Tabela 16 – Comando chmod, níveis de permissão modos especiais

Exemplos:

#chmod 777 texto.txt

#chmod u+x texto.txt

#chmod u=rw,g-x texto.txt

#chmod 2777 texto.txt

17. chown

Descrição: Define dono e grupo do arquivo.


-c Modo verbose, mostrando apenas as alterações feitas.

-R Aplica a recursividade na execução do comando.


63


-f Não exibe mensagem caso haja erro na execução do comando.

--preserve-root Não aplica a recursividade no diretório /

-v Exibe detalhes da execução do comando. Modo verbose.

Tabela 17 – Detalhamento de Opções do comando chown

Exemplos:

#chown root teste

#chown root:teste base_dados

#chown -R root /base/postgres


64


65

Capítulo 5 – Comandos GNU/Linux

Interagir com um sistema é a capacidade que teremos de efetuar certas ações junto ao mesmo. Para isso, precisamos conhecer os comandos que possibilitam esta interação, o que faremos nesse capítulo.

Sem mais delongas, vamos aos comandos....


66


67

1. catDescrição: Imprime em saída padrão o conteúdo de um arquivo.

Mapa 1. – Detalhamento de Opções do comando cat

Exemplos:

$cat teste

$cat -n teste

$cat -b teste

$cat >> arquivo.txt

2. tac

Descrição: Imprime em saída padrão o conteúdo de um arquivo em ordem inversa.

Mapa 2 – Detalhamento de Opções do comando tac

Exemplos:

$tac teste


68

3. cut

Descrição: Remove seções de um arquivo.

Mapa 3 – Detalhamento de Opções do comando cut

Exemplos:

$cut -c-4 teste (exibe do primeiro ao quarto caractere)

$cut -c4 teste (exibe o quarto caractere do arquivo)

$cut -c4- teste (exibe do quarto caractere em diante)

$cut -b4-9 teste (exibe do quarto ao nono bytes)

4. expand

Descrição: Converte TABs para espaços.

Mapa 4 – Detalhamento de Opções do comando expand

Exemplos:

$expand teste

$expand -i teste

$expand -t 6 teste


69

5. fmt

Descrição: Opções simples de formatação de textos.

Mapa 5 – Detalhamento de Opções do comando fmt

Exemplos:

$fmt teste

$fmt -c teste

$fmt -p/ teste

$fmt -w150 -p/ teste

6. head

Descrição: Exibe as 10 primeiras linhas do arquivo.

Mapa 6 – Detalhamento de Opções do comando head


70

Exemplos:

$head teste

$head -c20 teste

$head -n20 teste

$head -20 teste

$head -v teste

7. tail

Descrição: Exibe as 10 ultimas linhas do arquivo.


-c, --bytes=[-]N Exibe os últimos N bytes do arquivo..

-n, --lines=[-]N Exibe as ultimas N linhas do arquivo.

-f, --follow[={name|descriptor}] Exibe continuamente o arquivo, exibindo novas linhas inseridas no arquivo.

-q, --quiet, --silent Não imprime cabeçalhos com o nome do arquivo.

-v, --verbose Exibe cabeçalho do arquivo contendo nome.

Tabela 7 – Detalhamento de Opções do comando tail

Exemplos:

$tail teste

$tail -c20 teste

$tail -n20 teste

$tail -20 teste

$tail -v teste

8. hexdump

Descrição: Exibe arquivos em ascii, decimal, hexadecimal, octal dump.

Exemplo:

$hexdump teste

9. join

Descrição: Une as linhas de arquivos com índices comuns.


-j1 Define o campo índice para o arquivo 1.

-j2 Define o campo índice para o arquivo 2.

-j número Define o campo índice para ambos os arquivos.

Tabela 9 – Detalhamento de Opções do comando join

Exemplos:

$join -j1 2 teste teste1


71

$join teste teste1

$join -j2 1 teste1 teste

10. split Descrição: Divide um arquivo em pedaços.


-a, --suffix-length=N Define o tamanho do sufixo do nome dos arquivos gerados.

-b, --bytes=SIZE Define o tamanho de cada arquivo que será gerado, em bytes.

-C, --line-bytes=SIZE Define o tamanho de cada linha do arquivo.

-d, --numeric-suffixes Uso de sufixos numéricos.

-l, --lines=NUMBER Define o número de linhas de cada arquivo.

--verbose Imprime o detalhamento da execução do comando.

Tabela 10. – Detalhamento de Opções do comando split

Exemplos:

$split -b 2k base.txt bas

$split -l 1000 base.txt bas

11. tr

Descrição: Substitui ou Apaga caracteres.

Parâmetros Descrição

-d, --delete Apaga caractere do na exibição do arquivo.

-s, --squeeze-repeats Suprime as ocorrências da variável de busca.


\NNN Valor octal do caractere NNN

\\ Barra invertida

\a Sinal sonoro

\b Backspace

\f Formulário

\n Nova linha

\r Retorno (enter)

\t Tab horizontal

\v Tab vertical

CHAR1-CHAR2 Todos os caracteres de CHAR1 a CHAR2 em ordem ascendente

[CHAR*] no SET2, cópias de CHAR até o tamanho do SET1

[CHAR*REPEAT] REPETE cópias de CHAR, REPETE octal se começar com 0

[:alnum:] Todas as letras e dígitos

[:alpha:] Todas as letras

[:blank:] Todos espaços em branco na horizontal


72


[:cntrl:] Todos caracteres de controle

[:digit:] Todos dígitos

[:graph:] Todos caracteres imprimíveis, não incluindo espaço.

[:lower:] Todas letras em caixa baixa

[:print:] Todos os caracteres imprimíveis, incluindo espaço

[:punct:] Todos caracteres de pontuação

[:space:] Todos os espaços em branco na horizontal ou vertical

[:upper:] Todas letras em caixa alta

[:xdigit:] Todos os dígitos hexadecimais

[=CHAR=] Todos os caracteres que são equivalentes ao CHAR

Tabela 11. – Detalhamento de Opções do comando tr

Exemplos:

$cat base.txt | tr [a-c] [A-C]

$cat base.txt | tr -d a

12. nl

Descrição: Numera linhas de um arquivo.


-b,--body-numbering=STYLE Seleciona um estilo (`a`, `t`, `n`) para numeração das linhas.

-f,--footer-numbering=STYLE Numera o rodapé da página.

-h,--header-numbering=STYLE Numera o cabeçalho da página.

-s,--number-separator=STRING Insere um separador STRING após a numeração da página.

-v, --first-page=NUMBER Define o primeiro número da contagem.

-w, --number-width=NUMBER Define o número de colunas que antecede o número da linha.

Tabela 12– Detalhamento de Opções do comando nl

Exemplos:

$nl teste

$nl -bt teste

$nl -s@ teste

$nl -v1000 teste

$nl -w20 teste

13. paste

Descrição: Exibe as linhas de arquivos lateralmente.


73


-d, --delimiters=LIST Define um delimitador.

-s, --serial Mostra de forma contínua os conteúdos, apresentando-o linearmente.

Tabela 13 – Detalhamento de Opções do comando paste

Exemplos:

$paste teste teste1

$paste -d@ teste teste1

$paste -s teste teste1

14. pr Descrição: Formata um arquivo texto para impressão.


-a, --across Dimensiona o número de colunas. Caso a linha seja muito grande, esta será truncada.

-d, --double-space Define um espaço duplo para saída do arquivo.

-h HEADER, --header=HEADER Usa o cabeçalho centralizado.

-o MARGIN, --indent=MARGIN Define a margem esquerda da página.

-l PAGE_LENGTH,--length=PAGE_LENGTH Define a margem direita da página.

-w PAGE_WIDTH, --width=PAGE_WIDTH Define a largura da página.

-W PAGE_WIDTH, --page-width=PAGE_WIDTH Define o tamanho da página, truncando linhas.

Tabela 14 – Detalhamento de Opções do comando pr

Exemplos:

$pr -a teste

$pr -d teste

$pr -h “Linux Professional Administrator” teste

$pr -o20 -l20 teste

15. sort

Descrição: Ordena o arquivo em ordem crescente ou decrescente.


-r, --reverse Ordena de forma reversa o arquivo

-n, --numeric-sort Ordena pela definição numérica, com um limite de precisão de 16 valores decimais.

-m Usa o cabeçalho centralizado.

-o MARGIN, --indent=MARGIN Define a margem esquerda da página.


74


-l PAGE_LENGTH,--length=PAGE_LENGTH Define a margem direita da página.

-w PAGE_WIDTH, --width=PAGE_WIDTH Define a largura da página.

-W PAGE_WIDTH, --page-width=PAGE_WIDTH Define o tamanho da página, truncando linhas.

Tabela 15 – Detalhamento de Opções do comando sort

Exemplos:

$sort teste

$sort -r teste

16. wc

Descrição: Conta as linhas, palavras e caracteres de um arquivo.


-c, --bytes Retorna o número de bytes.

-m, --chars Retorna o número de caracteres.

-l, --lines Retorna o número de linhas.

-L, --max-line-length Retorna o tamanho da maior linha.

-w, --words Retorna o número de palavras.

Tabela 16 – Detalhamento de Opções do comando wc

Exemplos:

$wc -l base.txt

$wc -L base.txt

$wc -l base.txt

18. uniq

Descrição: Reporta ou omite linhas repetidas.


-c, --count Exibe o número de ocorrências da linha.

-d, --repeated Exibe apenas as linhas duplicadas.

-D, --all-repeated[=delimit-method] Exibe todas as linhas duplicadas.

-f, --skip-fields=N Ignora a comparação de N campos de cada linha.

-u, --unique Exibe apenas linhas únicas.

-w, --check-chars=N Compara não mais que N caracteres por linha.

Tabela 18– Detalhamento de Opções do comando uniq

Exemplos:

$uniq -D arquivo.txt


75

19. sed Descrição: Editor para filtrar ou alterar textos.

Por ser um pouco complexo, veremos o sed baseado em alguns exemplos. O abaixo.

Substituindo palavras em um arquivo.

#sed ‘s/clayton/alice/g’ /etc/registro.txt

Substituindo palavras em determinadas linhas de um arquivo

$sed ‘10,20s/luis/eduardo/’ registro.txt

Inserindo linhas em um arquivo.

$sed ‘7a\

Insere texto após a linha de número 15 do arquivo.

$sed ‘15i

Agora vamos inserir antes da linha de número 15.

$sed ‘15c

Apagamos as linhas 15, 16, 17 e 18 do arquivo.

$sed ‘15,18d’ registros.txt

Para apagarmos todas as linhas de um arquivo exceto as 13, 14, 15 e 16 usaremos

$sed ‘13,16!d’

Para apagarmos todas as linhas que contém uma determinada palavra usaremos

$sed ‘/clayton/d’ registros.txt

Para apagarmos as linhas que estão entre a primeira ocorrência de clayton até alice, use

$sed ‘/clayton/,/alice/d’ registros.txt

20. cp

Descrição: Copia arquivos e diretórios.


-a, --archive Ação similar ao uso de dpR.

--backup[=CONTROL] Cria cópia de backup, caso o arquivo exista no destino.

-b O mesmo que --backup, porém não aceita argumento.

-d Mesmo que --no-dereference –preserve=link

-f, --force Força a cópia mesmo que o destino, sendo um arquivo existente não possua permissão para ser sobrescrito.

-i, --interactive Modo interativo. Antes de sobrescrever um arquivo é perguntado se confirma a ação.

-p Preserva o nível de permissão de acesso dos arquivos copiados.

--preserve[=ATTR_LIST] Preserva os valores especificados como (default:


76


mode,ownership,timestamps).

--no-preserve=ATTR_LIST Não preserva os valores especificados.

-R, -r, --recursive Copia diretórios recursivamente.

Tabela 20– Detalhamento de Opções do comando cp

Exemplos:

$cp -rp /etc/ ~./

21. find Descrição: Localiza arquivos na estrutura de diretório.

O comando find para mim é um dos coringas do sistema. Com ele podemos simplesmente desenvolver quase tudo, inclusive a chamada de execução de um comando. Como o manual é grande demais ( cerca de umas 20 páginas ) resolvi colocar aqui algumas situações que acho bem interessantes para analisarmos o comportamento deste comando. Para mais detalhes, use o manual do comando $man find.

Exemplos:

$find / -type f -name x* -exec rm -f ’{}’ \;

$find / -user clayton -size 20 k

$find / -user clayton -size +20k -perm /u=w,g+x

$find / -perm 446 ! -perm a+w

$find / -size +20 K

$find / -size -20 k

$find / -type d -name docs -group administracao

$find / -group suporte -type f -atime +1 (aceso - horas)

$find / -group suporte -type f -mtime +1 (modificação – horas)

$find / -uid 1002 -amin 30 (acessado – minutos)

$find / -gid 1003 -mmin 45 (modificado - minutos)

Acima usei alguns exemplos que demonstram o poder de busca e execuções do comando find. Usei exemplos com execuções de comandos, com busca por tipo de arquivo, por nomes, tamanhos, datas de acesse e criação. Existem outros comandos para localizar arquivos no GNU/Linux. Veremos alguns em exemplos bem práticos.

Apesar de uma resposta um pouco mais rápido, nada muito significativo na grande maioria das vezes, usar o comando locate pode ser um tanto limitador.

Para que seja eficiente, o comando locate precisa que sempre seja atualizado o arquivo /var/lib/mlocate/mlocate.db, que é tratado pelo comando updatedb.

Assim, teremos..

#updatedb

#locate teste.conf

O grande problema é nos depararmos com a seguinte situação

#updatedb


77

#touch teste.conf

#locate teste.conf

O resultado aqui não será satisfatório. O locate em sua pesquisa pelo arquivo mlocate.db, não será encontrada nenhuma referência do arquivo teste.conf.

Para isso, precisaríamos executar novamente o updatedb para atualizar a base de pesquisas.

Temos ainda duas possibilidades específicas. A de buscarmos por arquivos binários, fontes e páginas de manuais de comandos do sistema e obtermos o caminho absoluto de um comando.

Veja os exemplos abaixo.

$whereis bash

Teremos como resultado..

bash: /bin/bash /usr/share/man/man1/bash.1.gz

Para o comando which, teríamos...

$which bash

Teremos o resultado...

/bin/bash

22. mv

Descrição: Move ou renomeia arquivo.


--backup[=CONTROL] Gera um backup caso exista um arquivo destino.

-b Mesma ação do –backup, porém não aceita argumentos.

-f, --force Força a ação para sobrescrever um arquivo sem questionamentos.

-i, --interactive Aguarda uma confirmação do usuário antes da execução do comando.

Tabela 22 – Detalhamento de Opções do comando mv.

Exemplos:

#mv arquivo.txt novo_nome.txt

23. ls

Descrição: Exibe o conteúdo de um arquivo.

Seguindo o modelo que usei para o find, o comando ls possui muitas opções de execução. Usarei exemplos para verificarmos as suas possibilidades.

Exemplos:

$ls -li

$ls -lh /

$ls -a


78

$ls -A

$ls --color=auto

$ls -ld /home

$ls -lG /home

$ls -lR /

Existem alguns coringas que poderão ser usados para auxiliar os comandos em algumas tarefas. Dentre vários deles, destacaremos a ação dos redirecionadores de saída. Na execução normal da maior parte dos comandos existentes no GNU/Linux, existirá duas possibilidades de saída STDOUT e STDERR, ambos exibindo em tela o resultado do processamento. Para alterar o comportamento de saída desses comandos usamos os redirecionadores > (grava em um arquivo, substituindo-o caso o mesmo exista) >> (grava um arquivo, concatenando o resultado da saída ao arquivo existente, caso o mesmo exista). Veja os exemplos abaixo.

$ls / > arquivo.txt

$ls /etc >> arquivo.txt

Nos exemplos acima, fizemos redirecionamentos da porta stdout. Para redirecionarmos a porta sdterr, usaremos comando como no exemplo abaixo.

$ls -l / 2 > erros.txt

Redirecionamos as mensagens de erro para o arquivo erros.txt. No exemplo seguinte, iremos tratar tanto das mensagens em stdout quanto as mensagens em stderr

$ls -lR / > arquivo.txt 2>&1

Algo importante para se perceber é zerar os arquivos sem que sejam apagados. Para isso usaremos o /dev/null, veja o exemplo.

$cat /dev/null > arquivo.txt

Uma forma de usarmos os comandos e os coringas do sistema seria por meio de shell scripts.

Vejamos alguns exemplos.

$vim teste.sh

#! /bin/bash

echo "Temos os seguintes browsers no sistema:"

cat << navegadores

mozilla

links

lynx

konqueror

opera

netscape

navegadores

echo -n "Qual o seu navegador favorito? "

read navegador


79

echo "Iniciando $navegador, aguarde..."

$navegador

No exemplo acima, usamos comandos comuns para escrever um script-shell. Observe o uso dos comandos cat, echo, read, e $ para chamar uma execução. O comando echo exibirá uma mensagem em tela e o read aguardará a digitação de algo pelo usuário.

Não somente uma forma de se usar os comandos do sistema, podemos desenvolver outras atividades envolvendo operadores aritméticos e lógicos. Vamos verificar o comportamento desses elementos.

Operadores Descrição

var++, var-- Pós-Incremento e Pós-decremento.

++var, --var Pré-Incremento, Pré-decremento

! ~ Negação

** Exponencial

* / % Multiplicação, Divisão e Resto

+ - Adição, Subtração

<< >> Deslocamento de bit para a esquerda e direita.

<= >= < > Menor igual, Maior igual, menor, maior

!= == Diferente, igual

& Operador and

^ Operador or exclusivo

| Operador or

&& and lógico

|| or lógico

Outros operadores Descrições

-eq igual a

-ne diferente de

-gt maior que

-ge maior ou igual a

-lt menor que

[ -a arquivo ] Verdade se o arquivo existir.

[ -d arquivo ] Verdade se o arquivo existe e é um diretório.

[ -f arquivo ] Verdade se o arquivo existe e é um arquivo regular.

[ -h arquivo ] Verdade se o arquivo existe e é um link-simbólico.

[ -k arquivo ] Verdade se o arquivo existe e está com o stick-bit ativo.

[ -s arquivo ] Verdade se o arquivo existe e se o tamanho é maior que zero.

[ -u arquivo ] Verdade se o arquivo existe e está com o Set User ID ativo.


80

[ -w arquivo ] Verdade se o arquivo existe e tem nível acesso de escrita.

[ -S arquivo ] Verdade se o arquivo existir e for um socket.

[ arquivo1 -nt arquivo2 ] Verdade se o arquivo1 for mais recente que o arquivo2 ou se o arquivo1 existir e o arquivo2 não.

[ arquivo1 -ot arquivo2 ] Verdade se o arquivo1 for mais antigo que o arquivo2 ou se o arquivo2 existir e arquivo1 não.

Antes de vermos exemplos práticos, vamos estudar os modelos de condicionadores e loops if, for, while e case.

O primeiro que veremos será o if. A estrutura dele é bem simples, nada de muito complexo.

if [ condição ]; then

comandos;

fi

observe no detalhe do encerramento da estrutura, temos o fi fechando-na.

Já o while se apresenta da seguinte maneira.

while [ condição ]; do

comandos;

done

O padrão do for seguiria o seguinte modelo.

for i in <instrução>; do

comandos;

done

Finalizando, teremos o modelo de instrução do case, veja como também é simples.

case $var in

$var)

comandos

;;

$var)

comandos

;;

$var)

comandos


81

;;

esac

Note que o grau de dificuldade das estruturas é baixo. Veremos agora como desenvolver shell-scripts de uma forma simples, objetiva e tentando usar o maior relacionamento entre os comandos e os controles de loop.

Importante lembrar que a maior parte da utilização e desenvolvimento de shell é para auxiliar na administração do sistema. Por isso, tentarmos desenvolver “sistemas” comerciais nesse ambiente seria realmente complicado e pouso produtivo.

Vamos aos exemplos de script-shell

#!/bin/bash

LIMIT=19

echo

echo "exibindo ate 20, retirando os numeros 3 e 11."

a=0

while [ $a -le "$LIMIT" ]; do

a=$(($a+1))

if [ "$a" -eq 3 ] || [ "$a" -eq 11 ]; then

continue

fi

echo "$a "

done

No exemplo acima foram usados o while e o if para exibir os valores de 1 à 20, exceto os números 3 e 11. Note que basicamente o comando echo foi usado.

Vejamos outro exemplo um pouco mais interessante.

$vim teste_case.sh

#!/bin/bash

echo; echo "Digite algo:"

read entrada

case "$entrada" in

[[:lower:]] ) echo "Letra Minuscula";;

[[:upper:]] ) echo "Letra Maiuscula";;

[0-9] ) echo "Entrada em forma de Valor Numerico";;

* ) echo "Valor desconhecido";;

esac


82

exit 0

Novamente, foi usado o comando echo para exibição de informações na tela, em seguida, o read aguarda a digitação de algo pelo usuário e o case, faz a verificação do valor digitado pelo usuário.

Os valores [[:lower:]] e [[:upper:]] verificam se a entrada digitada é uma letra maiúscula ou minúscula, da mesma forma que o comando tr.

24. rmDescrição: Remove arquivos ou diretórios.


-d, --directory Remove diretórios com unlink(2) no lugar de rmdir(2), e não exige que um diretório esteja vazio antes de tentar um unlink. Somente funciona se você tiver privilégios apropriados. Porque ao desvincular um diretório faz qualquer arquivo no diretório apagado se tornar inacessível, é recomendado passar o fsck(8) no sistema de arquivos depois de fazer isto.

-f, --force Força a remoção de um arquivo. Apaga o arquivo sem questionar.

-i, --interactive Questiona sobre a ação tomada para a remoção de um arquivo.

-r, -R, --recursive Remove diretórios e todos o conteúdo recursivamente.

-v, --verbose Demonstra a execução do comando.

Tabela 24 – Detalhamento de Opções do comando rm.

Exemplos:

#rm -R teste/

$rm -fr base/

$rm -ir base/

$rm -fr base/

25. mkdir

Descrição: Cria novos diretórios


-Z, --context=CONTEXT (SELinux) Indica o contexto de segurança.

-m, --mode=MODE Indica o nível de permissão de acesso.

-p, --parents Cria uma cadeia de dependências de diretórios quando necessário.

-v, --verbose Imprime detalhes de execução do comando.

Tabela 25 – Detalhamento de Opções do comando mkdir.


83

Exemplos:

#mkdir -p {work/{rh,financeiro,suporte/{virus,compacta}},\

colaboradores/{clayton,eduardo}}

$mkdir -p work/{rh,financeiro,suporte/{virus,compacta},\

colaboradores/{clayton,eduardo}}

26. rmdir

Descrição: Remove diretórios vazios.


-p, --parents Remove diretórios e sub-diretórios.

-v, --verbose Mostra a execução do comando.

Tabela 26 – Detalhamento de Opções do comando rmdir.

Exemplos:

#rmdir base/

$rmdir -p base/testes/sistema

27. man Descrição: Exibe o manual de comandos e serviços.


-C fich_config Indica o ficheiro de configuração a usar; por omissão será usado /etc/man.config. (Veja man.conf(5).)

-M path Indica a lista de directórios onde procurar manuais. Sem esta opção, será consultada a variável MANPATH. Se também esta variável estiver definida, uma lista será obtida por consulta de /etc/man.config. Um directório vazio em MANPATH representa a lista anterior.

-P paginador Indica qual o paginador/visualisador a usar. Sem esta opção tentará consultar a variável PAGER. Normalmente, man usará /usr/bin/less -is.

-S lista_sec Fornece a lista de secções (separadas por ,) onde procurar e por que ordem. Esta opção substitui o que é indicado pela variável MANSECT quando esta está definida

-a Normalmente man mostra o primeiro manual que encontrar. Esta opção faz com que mostre todas as páginas de manuais encontradas para a entrada nome.

-d Não mostra o manual, imprimindo vária informação para ‘debug’.


84

-f Equivalente a whatis.

-k Equivalente a apropos.Tabela 27 – Detalhamento de Opções do comando man.

Exemplos:

#man -f samba

#man -k samba

Existem mais dois comandos que podemos usar para verificar manuais. Vamos verificar os comandos apropos e whatis

#whatis bash

#apropos bash

Tanto apropos quanto whatis precisam que seja sempre atualizado o banco de pesquisa, podendo ser feito com o comando #makewhatis.

28 info

Descrição: Exibe o manual de comandos e serviços.

O info é outro comando usado para exibir ajuda para determinados comandos. Dois exemplos abaixo são suficientes para fazermos comparações.

Exemplos:


85

#info --show-options samba

#info samba

29 tar

Descrição: Empacota arquivos em um arquivo tarball.


-A, --catenate, --concatenate Insere novo arquivo em um pacote.

-c, --create Cria um novo pacote.

-d, --diff, --compare Verifica diferenças entre arquivos.

-r, --append Insere arquivo ao final de um arquivo tarball.

-t, --list Lista o conteúdo de um arquivo tarball.

-u, --update Apenda arquivos que foram alterados e fazem parte do pacote tarball.

-x, --extract, --get Extrai arquivos do um pacote tarball.

--delete Deleta um arquivo de um pacote tarball.

COMMON OPTIONS

-C, --directory DIR Muda o diretório.

-f, --file [HOSTNAME:]F Define o arquivo de saído do comando.

-j, --bzip2 Usa o bzip2 para compactar um arquivo tarball e o bunzip2 para descompactá-lo.

-p, --preserve-permissions Preserva os níveis de permissão de acesso.

-v, --verbose Executa em modo verbose. Detalhes de execução do sistema.

-z, --gzip, --ungzip Usa o gzip para compactar um arquivo tarball e o gunzip para descompactá-lo.

ALL OPTIONS

--owner USER Define o usuário na extração do arquivo.

-p, --same-permissions, --preserve-permissions Mantém os níveis de acesso dos arquivos

Tabela 29 – Detalhamento de Opções do comando tar

Exemplos:

#tar -xzf cadastro.tar.gz nomes.txt

30 gzip

Descrição: Comprime ou expande arquivos.


86


-d --decompress --uncompress Descompacta o arquivo.

-r --recursive Preserva a estrutura de diretório, usando a recursividade.

-t --test Verifica a integridade do arquivo compactado.

-v –verbose Detalha a execução do comando

-# --fast –best Determina o nível de compressão. -1 ou - - fast executa com uma taxa de compressão menor, determinando uma ação mais rápida do comando e -9 ou - - best determina ação mais demorada, com taxa de compressão maior.

Tabela 30 – Detalhamento do comando gzip

Exemplos:

#gzip -c teste > base.gz

Para descomprimir um arquivo gz, usamos o comando gunzip.

31 bzip2 Descrição: a block-sorting file compressor, v1.0.3.


-c --stdout Comprime e descomprime para saída padrão.

-d --decompress Força a descompressão de arquivos bz2.

-t --test Checa a integridade dos arquivos bz2.

-f --force Força a gravação de arquivos caso existam. Normalmente, se um arquivo bz2 existir, não poderá ser reescrito.

-1 (or --fast) to -9 (or --best) Determina a taxa de compressão para a execução do comando. -1 ou - -fast com uma taxa de compressão menor e ação mais rápida e -9 ou - -best com ação mais lenta e taxa mais alta.

Tabela 31 – Detalhamento de Opções do comando crontab

Exemplos:

#bzip2 base.tar

Para descomprimir um arquivo bz2, usamos o comando bunzip2.

32 crontab

Descrição: Agendamento de execuções no sistema.


-l Lista os agendamentos dos usuários

-r Remove agendamentos do crontab.


87


-e Edita base de agendamentos do crontab. Cada usuário terá um arquivo com seu nome de login no diretório /var/spool/cron. Sempre que usado, essa opção abrirá esse arquivo.

-u Administra o crontab do usuário especificado, ao invés do usuário que o invocou.

Tabela 32 – Detalhamento de Opções do comando crontab

Para que um usuário tenha acesso ao crontab, o mesmo deverá ser inserido no arquivo /etc/cron.allow, caso este exista. Caso contrário, existindo o arquivo /etc/cron.deny, todos os usuários que não devem ter acesso ao serviço devem ser incluídos no mesmo. No arquivo /etc/crontab, podemos incluir alguns agendamentos de sistema. Todos os usuários não cadastrados no arquivo /etc/cron.deny poderá agendar uma tarefa no crond. Os agendamentos serão armazenados no diretório /var/spool/cron, em arquivos com o nome do usuário. Cada usuário terá um arquivo registrado no diretório, desde que use o comando $crontab -e.

Exemplos:

#crontab -e -u clayton

33 psDescrição: Exibe os processos em execução no sistema.

Seleção Simples de Processo.


-A Seleção simples de processos.

-N Seleciona todos os processos exceto aqueles especificados na condição.

T Seleciona todos os processos associados a um terminal.

-a Seleciona todos os processos associados, a não ser líderes de processos e processos não relacionados com um terminal.

-d Seleciona todos os processos exceto líderes de seções.

-e Seleciona todos os processos, idêntico ao -A.

r Restringi a seleção apenas para processos que estão em execução.

x Exibe os processos em execução.

-C cmdlist Seleciona por linha de comando.

-G grplist Exibe processos por grupo.

U userlist Seleciona os processos por usuário. Aqui você notará a linha completa de execução do processo.

-U userlist Seleciona os processos por usuário. Aqui teremos uma forma mais resumida de exibição.

-g grplist Seleciona os processos por grupo.

p pidlist Seleciona o processo por PID. Ação idêntica ao -p and - -pid.


88

Seleção Simples de Processo.

t ttylist Seleciona o processo por terminal. Ação idêntica ao -t and –tty.

D Processo aguardando para continuar a execução

R Processo em execução.

S Processo em sleep, aguardando para continuar a execução.

T Processo parado.

W Paginação

X Processo morto.

Z Processo zumbi.

Tabela 33 – Detalhamento de Opções do comando ps

Exemplos:#ps -eLf

#ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm

34 kill Descrição: Mata um processo.


n Informa o valor do PID do processo.

-1 Todos os processos maiores que 1 serão sinalizados.

-n Todos os processos do grupo de -n serão sinalizados.

commandname Todos os processos chamados pela linha de comando serão sinalizados.

-s signal Especifica a ação da sinalização.

-l Imprime a lista de ações do kill. Podemos encontrar a lista completa em /usr/include/linux/signal.h

-a Sinaliza todos os processos de um determinado UID.

Tabela 34 – Detalhamento de Opções do comando kill

Exemplos:

#kill -9 2134 2543

35 killall Descrição: Mata um processo pelo nome.


-e, --exact Requer o nome exato para examinar nomes de comandos maiores que 15 caracteres.

-I, --ignore-case Não diferencia letras em maiúsculo e minúsculo.


89


-i, --interactive Modo interativo. Questiona se o processo será morto.

-l, --list Exibe todos os sinais conhecidos.

-q, --quiet Não exibe se o processo foi morto.

-r, --regexp Interpreta processos com meta caracteres no nome.

-s, --signal Envia um sinal para o processo.

-u, --user Mata somente os processos de um determinado usuário.

-v, --verbose Mostra detalhamentos da execução do processo.

Tabela 35 – Detalhamento de Opções do comando killall

Exemplos:

#killall -u clayton

36 nice Descrição: Define um nível de prioridade de execução para um processo .


-n, --adjustment=N Adiciona o n inteiro como prioridade. Como padrão teremos o 10.

--help Exibe o help

--version Exibe a versão do sistema

Tabela 36 – Detalhamento de Opções do comando nice

Exemplos:

#nice -n -6 script.sh

37 renice Descrição: Altera a prioridade de um processo em execução.


-g Determina o gid do processo.

-u Determina o nome do usuário.

Tabela 37 – Detalhamento de Opções do comando renice

Exemplos:

#renice +1 987 -u daemon root -p 32

De uma forma geral, gerenciar processos está relacionado com a capacidade de determinar o que estará rodando em seu sistema. Os comando visto acima, são os mais comuns para gerenciamento de processos, porém não únicos. Imagine o seguinte.

Acabamos de escrever um script, que chamaremos de base.sh. Precisamos colocar este em ação para garantir o funcionamento de uma aplicação maior que aguarda o resultado do processamento do base.sh. Primeira ação que vem em mente.. Rodar o base.sh, o que faremos com a linha abaixo.

#./base.sh


90

Parabéns, script em execução e sua console está “locada” pelo processamento do mesmo. Para liberarmos a tela da console, precisamos colocar o script rodando em background, o que faremos de uma forma diferente apenas para adiantar um pouco alguns novos comandos.

Em primeiro lugar, iremos gerar um processo em segundo plano, em estado de stop. Para isso use as teclas <ctrl> z. Observe que sua tela não está mais locada com o processo.

Com o auxílio do comando jobs, podemos visualizar os processos que estão em segundo plano, como demonstro abaixo.

#jobs

Colocaremos o processo rodando em segundo plano. Para isso, use o comando bg.

A sintaxe do comando bg está relacionada com o número de identificação do processo em relação ao job, a fila de processamento em segundo plano.

Então, para definirmos a execução do processo que está identificado no jobs com o número 3, use o comando abaixo.

#bg 3

Startamos o processo em segundo plano. Para colocá-lo em primeiro plano, basta se seja usado a linha abaixo, com o comando fg.

#fg 3

Para resumirmos um pouco. Vamos rodar um processo em segundo plano, permitindo que o mesmo continue rodando mesmo que seja efetuado logout na console.

#nohup teste.sh &

Trocando em miúdos...

nohup ----- > libera o processo da console.

&-----> coloca o processo em segundo plano.

38 mount / umountDescrição: Monta / desmonta um dispositivo.

Antes de descrevermos o comando mount, precisamos entender o conceito de ponto de montagem e sua relação com os dispositivos.

Na busca por definir um ponto de montagem, ler vários livros a respeito de file system além de conversar com muitos técnicos, chego a seguinte conclusão. Ponto de montagem é qualquer diretório do sistema.

Isso mesmo. Podemos usar qualquer diretório como ponto de montagem. Claro que alguns darão um pouco de trabalho usar, por serem de uso do próprio sistema. Porém, qualquer diretório criado por um usuário ou que não possuam informações necessárias para o funcionamento do sistema é um ponto de montagem.

Os pontos de montagem servem para nos dar acesso aos dados armazenados em um volume, seja um cd, seja um disco SCSI.

Todo e qualquer dado armazenado em disco será disposto ao usuário pelo ponto de montagem, porém, alguns volumes só poderão ser retirados do sistema após serem


91

desmontados.

Vejamos um exemplo para ficar mais fácil o entendimento.

Sempre que colocado um cd no driver, o sistema irá reconhecer o montar o volume para dar acesso aos dados armazenados nele. Para retirá-lo, do driver, desmonte-o antes, até porque a gaveta não abrirá se o dispositivo estiver montado.

Hoje em dia, não nos preocupamos mais com as montagens e desmontagens do cd, pen drivers, e afins... Antigamente as coisas funcionavam mais ou menos assim.

#mount /dev/cdrom /mnt/cdrom

#umount /mnt/cdrom

Observe que montei o dispositivo de cd no /mnt ( o /mnt sempre foi colocado como o ponto onde estariam todas montagens secundárias do sistema, como os dispositivos de cd, disquetes, outros hds com dados como músicas por exemplo ) e para retirar o disco da gaveta, precisarei desmontar, o segundo comando demonstra essa ação.

Observe ainda que para “montar o cd”, foi necessário especificar a origem (ou seja, o dispositivo - /dev/cdrom) e o ponto de montagem ( aqui o /mnt/cdrom ) .

Para otimizar essa ação, podemos configurar as relações de montagem no arquivo /etc/fstab. O seu formato padrão demonstro abaixo.

/dev/sda1 / ext3 defaults 1 1

devpts /dev/pts devpts gid=5,mode=620 0 0

tmpfs /dev/shm tmpfs defaults 0 0

/dev/sda2 /home ext3 defaults 1 2

proc /proc proc defaults 0 0

sysfs /sys sysfs defaults 0 0

Vamos ordena-lo da esquerda para a direita.

Na primeira coluna, teremos os dispositivos que iremos montar. Na segunda o ponto de montagem no sistema. A terceira coluna informa o tipo de file system usado, a quarta o comportamento da ação desmontar, a quinta nos dará a prioridade de montagem dos dispositivos.

Durante o processo de boot do sistema, o fstab será lido para informar quais partições serão montadas durante esse processo. Todos os que possuírem defaults serão montados automaticamente ou com o comando mount -a.

Para sabermos o que está montado no sistema, basta usarmos o comando mount ou exibir o conteúdo do arquivo /proc/mounts.

Aproveitando que estamos falando de volumes, veremos os comando df e du e os mecanismos de quota em discos.

Muitos alunos questionam como verificar a volumetria dos discos no GNU/Linux e como determinar uma cota de armazenamento para grupos e usuários.

Podemos acompanhar o consumo de disco usando o comando df, como demonstrado abaixo.

#df -h

Sist. Arq. Tam Usada Disp Uso% Montado em

/dev/sda1 6,7G 4,2G 2,2G 66% /


92

tmpfs 501M 0 501M 0% /dev/shm

/dev/sda2 48G 277M 45G 1% /home

/dev/sdb1 244M 52M 192M 22% /media/Pen

Teremos um pequeno “relatório” com o sistema de arquivo (volume), o tamanho total do disco, o que está sendo realmente usado, o que está disponível, o percentual usado do disco e o ponto de montagem.

O comando du, nos dará o tamanho de um arquivo ou diretório. Veja o exemplo.

#du -sh /etc

Será exibido apenas o total, ação conhecida como summarize.

#du -h /etc/samba/smb.conf

Será exibido o tamanho do arquivo smb.conf.

Mas tem algo que realmente deixa meus alunos muito estranhos... O poder das quotas em discos

Determinar as quotas é informar ao kernel do sistema que determinado usuário ou um determinado grupo terá uma capacidade limitada de armazenamento em disco .

As quotas estão relacionadas ao volume. Cada disco ou partição de disco poderá ter uma quota diferente para cada usuário.

Vamos determinar algumas quotas para o disco hda3.

O primeiro passo é alterar o arquivo fstab e informar ao sistema que a partição em questão terá o mecanismo de quota ativo.

Veja como ficaria no exemplo abaixo.

/dev/hda3 /dados ext3 defaults,usrquota,grpquota 1 1

Para o disco hda3 que está montado em /dados, serão configuradas quotas para usuários e grupos.

Seguindo o processo, é necessário carregar as novas informações. Para isso, vamos reiniciar o computador ou podemos simplesmente desmontar e montar novamente o volume.

O passo seguinte é criarmos os arquivos onde estarão as informações de quotas dos usuários e grupos. Para isso, execute o comando abaixo.

#quotacheck -mcug /dados

Observe que no diretório /dados serão criados dois arquivos, aquota.user e aquota.group, neles encontraremos as quotas configuradas no sistema.

Feito isso, precisamos ativar o sistema de quotas.

#quotaon -a

Agora, o que nos resta é configurar as quotas para usuários e grupos. Usaremos o comando edquota, veja

#edquota -u clayton

#edquota -g suporte

Para ambos encontraremos a seguinte situação.


93

Edite os parâmetros soft e hard para definir uma taxa lógica e um limitador físico. Aqui vale ressaltar que é saudável que se coloque o soft sempre menor que o hard. Sempre que atingir o limite soft, o sistema de quotas ativa o grace period, uma espécie de contador de tolerância para usuários e grupos. Assim que atingido o limite soft, o tempo é contado e caso haja necessidade de apagar alguns arquivos para retornar a um estado tolerável de uso de disco, abaixo do soft, o sistema o fará.

O parâmetro hard é o ponto limite do espaço em disco. Assim que atingido, nenhum arquivo poderá ser gravado pelo usuário.

Para alterarmos o grace period, use o comando #edquota -ut para grace de usuários e #edquota -gt para grupos e altere os parâmetros como demonstrado abaixo.

Mude os valores do grace period para reduzir o tempo de tolerância.

Para obter informações sobre as quotas de usuários e grupos execute os comandos

#quota -u <usuário>

#quota -g <grupo>

#repquota -a


94


95

Capítulo 6 - Instalação e compilação de programas e compilação do Kernel.

Algo que certamente diferenciar um bom administrador de sistema de um administrador mediano é o conhecimento de mecanismos de instalação dos programas. No universo GNU/Linux, precisamos conhecer os dois padrões mais usados ( .deb e .rpm) e os processos para instalar um programa a partir do seu código fonte, método esse muito usado para personalizar o funcionamento de programa.


96


97

Processo de compilação de programas.Dentre todas as formas de instalação, a compilação é a que mais trás transtornos

para grande parte dos usuários do sistema. Pensando em facilitar o entendimento desse processo, seguiremos os passos demonstrados abaixo.

Para compilarmos um programa, é necessário termos algumas ferramentas instaladas no GNU/Linux, preparando assim o ambiente de trabalho. O primeiro passo para pensarmos em compilar um programa no GNU/Linux é termos os fontes do kernel no diretório /usr/src. Feito isso, certifique-se que todos os tópicos da listagem abaixo estejam cumpridos.

1. gcc

2. glibc

3. make

4. tar

5. bzip2

6. bunzip2

7. kernel-source

Após termos criado o ambiente necessário para a compilação, passamos então para o tratamento do arquivo fonte. Aqui demonstraremos a instalação do SQUID com algumas particularidades.

Primeiro vamos desempacotar e descompactar o código fonte.

[root@clayton ~]# ls squid-2.6.STABLE3-20060916.tar.gz

squid-2.6.STABLE3-20060916.tar.gz

Observe o que o nosso pacote é do tipo tar.gz o que nos obriga a utilizar a linha de comando abaixo.

[root@clayton ~]# tar -zxvf squid-2.6.STABLE3-20060916.tar.gz

É importante observarmos esses detalhes para que não façamos confusão no hora de trabalhar. Existe a possibilidade de termos códigos fonte do tipo tar.bz2, nesse caso usaríamos os parâmetros -jxvf junto ao comando tar.

Após desempacotar e descompactar o arquivo fonte, precisamos compilar o programa. Veja abaixo:

[root@clayton squid-2.6.STABLE3-20060916]#./configure –prefix=/usr --sysconfdir=/etc/squid --libexecdir=/usr/lib/squid --infodir=/usr/share/info --mandir=/usr/share/man –enable-delay-pools --enable-useragent-log --enable-cachemgr-hostname=clayton –enable-arp-acl --enable-default-err-language="Portuguese" --enable-underscores --disable-htcp –disable-internal-dns --enable-cache-digests

checking for a BSD-compatible install... /usr/bin/install -c

checking whether build environment is sane... yes

checking for gawk... gawk

checking whether make sets $(MAKE)... yes


mailto:root@clayton

98

checking whether to enable maintainer-specific portions of Makefiles... no

checking for gcc... gcc

checking for C compiler default output file name... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables...

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking for gcc option to accept ANSI C... none needed

checking for style of include used by make... GNU

checking dependency style of gcc... gcc3

checking whether gcc and cc understand -c and -o together... yes

checking build system type... i686-pc-linux-gnu

checking host system type... i686-pc-linux-gnu

checking for pkg-config... /usr/bin/pkg-config

Store modules built: ufs

Removal policies built: lru

Delay pools enabled

User-Agent logging enabled

Cachemgr default hostname set to clayton

.

.

.

config.status: creating helpers/ntlm_auth/fakeauth/Makefile

config.status: creating helpers/ntlm_auth/mswin_sspi/Makefile10

config.status: creating helpers/ntlm_auth/no_check/Makefile

config.status: creating helpers/ntlm_auth/SMB/Makefile

config.status: creating helpers/ntlm_auth/SMB/smbval/Makefile

config.status: creating helpers/negotiate_auth/Makefile

config.status: creating helpers/negotiate_auth/mswin_sspi/Makefile

config.status: creating helpers/external_acl/Makefile

config.status: creating helpers/external_acl/ip_user/Makefile

config.status: creating helpers/external_acl/ldap_group/Makefile

config.status: creating helpers/external_acl/mswin_lm_group/Makefile

config.status: creating helpers/external_acl/session/Makefile


99

config.status: creating helpers/external_acl/unix_group/Makefile

config.status: creating helpers/external_acl/wbinfo_group/Makefile

config.status: creating tools/Makefile

config.status: creating include/autoconf.h

config.status: executing depfiles commands

[root@clayton squid-2.6.STABLE3-20060916]# make

Making all in lib

make[1]: Entering directory `/root/squid-2.6.STABLE3-20060916/lib'

if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT Array.o -MD -MP -MF ".deps/Array.Tpo" -c -o Array.o Array.c; \

then mv -f ".deps/Array.Tpo" ".deps/Array.Po"; else rm -f ".deps/Array.Tpo"; exit 1; fi

if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT base64.o -MD -MP -MF ".deps/base64.Tpo" -c -o base64.o base64.c; \

then mv -f ".deps/base64.Tpo" ".deps/base64.Po"; else rm -f ".deps/base64.Tpo"; exit 1; fi

if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT getfullhostname.o -MD -MP -MF ".deps/getfullhostname.Tpo" -c -o getfullhostname.o getfullhostname.c; \

then mv -f ".deps/getfullhostname.Tpo" ".deps/getfullhostname.Po"; else rm -f ".deps/getfullhostname.Tpo"; exit 1; fi

if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT hash.o -MD -MP -MF ".deps/hash.Tpo" -c -o hash.o hash.c; \

then mv -f ".deps/hash.Tpo" ".deps/hash.Po"; else rm -f ".deps/hash.Tpo"; exit 1; fi

if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT heap.o -MD -MP -MF ".deps/heap.Tpo" -c -o heap.o heap.c; \

then mv -f ".deps/heap.Tpo" ".deps/heap.Po"; else rm -f ".deps/heap.Tpo"; exit 1; fi

if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT html_quote.o -MD -MP -MF ".deps/html_quote.Tpo" -c -o html_quote.o html_quote.c; \

then mv -f ".deps/html_quote.Tpo" ".deps/html_quote.Po"; else rm -f ".deps/html_quote.Tpo"; exit 1; fi

if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT iso3307.o -MD -MP -MF ".deps/iso3307.Tpo" -c -o iso3307.o iso3307.c; \

then mv -f ".deps/iso3307.Tpo" ".deps/iso3307.Po"; else rm -f ".deps/iso3307.Tpo"; exit 1; fi

if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT md5.o -MD -MP -MF ".deps/md5.Tpo" -c -o md5.o md5.c; \

.

.

.


100

gcc -Wall -g -O2 -g -o cachemgr.cgi cachemgr__CGIEXT_-cachemgr.o -L../lib -lmiscutil -lm -lbsd -lnsl

make[2]: Leaving directory `/root/squid-2.6.STABLE3-20060916/tools'


make[1]: Entering directory `/root/squid-2.6.STABLE3-20060916'

make[1]: Nada a ser feito para àll-am'.

make[1]: Leaving directory `/root/squid-2.6.STABLE3-20060916'

[root@clayton squid-2.6.STABLE3-20060916]# make install

/usr/bin/install -c 'cachemgr.cgi' '/usr/lib/squid/cachemgr.cgi'

/usr/bin/install -c -m 644 ./cachemgr.conf /etc/squid/cachemgr.conf






make[2]: Nada a ser feito para ìnstall-exec-am'.

make[2]: Nada a ser feito para ìnstall-data-am'.



[root@clayton squid-2.6.STABLE3-20060916]#

Caso todos os passos acima tenham sido executados com sucesso, parabéns, você acaba de compilar o squid. Agora basta configurar o serviço e colocá-lo em ação!

Basicamente o processo de compilação se faz em três etapas. O ./configure, caso haja junto ao fonte, o make e o make install. Nunca devemos esquecer das bibliotecas e requisitos necessários, a ausência delas te tomará um bom tempo de trabalho e alguns erros.

Algo importante é lembrar da necessidade de informar ao ./configure o local onde serão colocados os arquivos, caso contrário, será criada uma estrutura no /usr/local com o nome do pacote em uso. No caso de nosso exemplo o squid.


101

Pacotes RPMCriado pela Red Hat, o Red Hat Package Manager (rpm) é o mais popular de todos os

gerenciadores de pacotes. Usá-lo é bem simples e um grande número de distribuições adotou – o como sendo o gerenciador de pacotes. Dentre outras informações, temos nos pacotes rpm:

1. Arquivos da aplicação compactados

2. Nome e versão do pacote

3. Data de criação

4. Descrição do pacote e da aplicação

5. Informações de quem criou o pacote

6. MD5 checksum para verificação de integridade do pacote

7. Outros pacotes requeridos (dependências)

Entendendo o nome de pacote rpm, termos

ethereal-0.8.9-1.i386.rpm

ethereal = Nome do pacote

-0.8.9 = Versão

-1 = Patch

.i386 = Arquitetura

.rpm = Extensão rpm

Trocando em miúdos ... O pacote acima está na versão 0.8.9 e este é a primeira compilação do mesmo, sendo que foi compilado para a arquitetura i386, padrão intel.

Vantagens e desvantagens do formato

As vantagens de utilizar os pacotes RPM em com relação a outro métodos de adquirir e instalar software são:

• Um método uniforme para o usuário instalar programas.

• Maior simplicidade para desinstalar os programas.

• Popularidade: muitos pacotes disponíveis, mesmo que eles comumente precisem de uma recompilação para funcionarem em uma outra distribuição.

• Instalação não-interativa: facilita uma instalação automática.

• Código-fonte original incluído (.tar.gz, .tar.bz2): fácil de verificar.

• Verificação criptográfica com o GPG e o md5.

As desvantagens citadas incluem:

• Comumente tem mudanças no formato de pacote incompatíveis com versões anteriores.

• Documentação incomplete e desatualizada.

• Pouca aprendizagem sobre os pacotes.


102

O RPM também vem sendo criticado pela falta de consistência no nome e conteúdo dos pacotes, o que pode dificultar o manejo automático de dependências. Entretanto, este problema não ocorre apenas no formato RPM, mas é um problema na maioria das distribuições que usam os pacotes RPM tais como o Red Hat, SuSE e Mandrake (Mandriva) Linux.

Base de dados RPM

Atrás do gerenciador de pacotes está o banco de dados rpm. Ele consiste de uma lista duplamente ligada que contêm todas as informações de todos os rpm instalados. O banco da dados lista todos os arquivos que são criados ou modificados quando um usuário instala um programa e facilita a remoção destes mesmos arquivos. Se o banco de dados fica corrompido (o que acontece facilmente se o cliente de rpm é fechado subitamente), as ligações duplas garantem que eles possa ser reconstruído sem nenhum problema. No computadores com o sistema operacional RedHat instalado, este banco da dados se encontra em /var/lib/rpm.

Agora que fomos apresentados aos pacotes rpm, vamos entender o comando rpm.

RPM

Descrição: RPM Gerenciador de Pacotes .rpm


Opções Gerais

--quiet Normalmente somente as mensagens de erro serão apresentadas.

-v Mostra o detalhamento da execução do comando.

-vv Imprime informações de debug da execução do comando.

--rcfile FILELIST Informações de configuração de instalação do pacote RPM. O padrão é ter as informações separadas por dois pontos como no exemplo. /usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc.

--dbpath DIRECTORY Informa o caminho para a base RPM, normalmente em /var/lib/rpm

--root DIRECTORY Informa o diretório usado, no qual encontraremos a base para verificação de dependências dos pacotes.

Opções de Instalação e upgrade

--aid Adiciona pacotes ajustando as necessidades de operação.

--allfiles Instala ou atualiza todos os arquivos do pacote mesmo que existam.

--excludedocs Não instala arquivo de manuais.

--force O mesmo que --replacepkgs, --replacefiles, e –oldpackage.


103


-h, --hash Imprime o hash durante o processo de instalação. Usado pelo modo verbose para acompanhamento do processo.

--ignoresize Não checa se há espaços para instalação do pacote.

--ignorearch Permite a instalação de pacotes mesmo se a arquitetura dos binários e da máquina não sejam combinantes.

--ignoreos Permite a instalação ou atualização de pacotes mesmo que o sistema operacional dos binários e do pacote não forem combinantes.

--includedocs Instala a documentação do pacote.

--justdb Atualiza o banco de pacotes mas não o sistema.

--nodigest Não verifica cabeçalhos do pacote ao ler.

--nosignature Não verifica assinaturas de cabeçalhos de pacotes.

--nodeps Não verifica dependências após instalação ou atualização de pacotes.

--noorder Não reordena os pacotes para a instalação. A lista de pacotes normalmente será reordenada para satisfazer dependências.

--prefix NEWPATH Redefine o caminho caminha dos pacotes no processo de instalação.

--test Não instala os pacotes, apenas checa o nível de conflito do mesmo.

ERASE OPTIONS

--allmatches Remove todas as versões de um pacote. Em caso de múltiplos pacotes, uma mensagem de erro é exibida.

--nodeps Não checa dependências na desinstalação de um pacote.

QUERY OPTIONS

--qf|--queryformat QUERYFMT

-a, --all Pesquisa por todos os pacotes instalados.

-f, --file FILE Pesquisa pelos arquivos de um pacote instalado.

PACKAGE QUERY OPTIONS:

-c, --configfiles Lista somente os arquivos de configuração de um pacote.

-d, --docfiles Lista somente os arquivo de manuais de um pacote.

--filesbypkg Lista todos os arquivos relacionados a um pacote.

-i, --info Lista informações do pacote.


104


--last Ordena a exibição dos pacotes, mostrando quais foram os últimos instalados aos primeiros.

-l, --list Lista todos os arquivo de um pacote.

-R, --requires Lista as dependências de um pacote.

--scripts Lista os scripts usados na instalação e desinstalação de um pacote.

-s, --state Mostra informações dos arquivos de um pacote, informando se o mesmo está instalado, desinstalado ou reinstalado.

Tabela 1– Detalhamento de Opções do comando rpm

Exemplos:

#rpm -qial samba

#rpm -ivh samba-3.0.9-1.i386.rpm

#rpm -e samba*.rpm

Pacotes DEBUm outro padrão de pacotes existente no mundo linux é o desenvolvido pela

distribuição DEBIAN, os famosos pacotes .deb. Estudaremos nesse capítulo o comando dpkg .

O primeiro passo que daremos será a localização das informações dos pacotes. O dpkg mantém as informações basicamente em dois arquivos, /var/lib/dpkg/avliable e /usr/lib/dpkg/status. O primeiro possui a lista de pacotes disponíveis e o segundo o status dos pacotes.

DPKGDescrição: Debian Gerenciador de Pacotes .deb


-E Não substitui um pacote de mesma versão.

-G Sobrescreve um pacote existente, mesmo de versões antigas.

-R Processa um conjunto de pacotes dentro de um diretório.

-i Instala um pacote

-l Usa a chave de busca para lista os pacotes que contenham referência a essa chave.

-L Lista os arquivos instalados por um pacote

--print-avail nomepacote Lista um conjunto de informações relacionadas ao pacote


105


--purge Remove todo o pacote

-r Remove todos os arquivos do pacote menos os de configuração

-s Mostra o status do pacote

-S Procura por um arquivo nos pacotes instalados.

--unpack Desempacota um pacote, porém não instala

--configure Configura um pacote não instalado.

Tabela 5.1 – Detalhamento de Opções do comando dpkg

Exemplos:

#dpkg -s samba

#dpkg -i samba*.deb

#dpkg –purge samba

#dpkg -r samba


106

Kernel do LinuxNão é novidade para ninguém que sou um apaixonado pelo kernel. Estudar as

possibilidades de tunning do kernel é realmente desafiador. Aqui terei que ser realmente bem objetivos senão nunca terminarei esse material, o que realmente está acontecendo.

Nessa etapa, vamos avaliar os mecanismos básicos para compilar o kernel, gerenciamento dos módulos, e atualização de um path do kernel.

O primeiro passo será efetuar o download da última versão estável do kernel no site www.kernel.org.

Feito isso .. Vamos ao que realmente interessa.

Algumas regras devem ser seguidas. Em primeiro lugar, devemos colocar o fonte do kernel no diretório /usr/src/linux, isso pode ser feito seguindo os passos abaixo.

#mv linux-2.6.21.5.tar.bz2 /usr/src/

#tar -jxvf linux-2.6.21.5.tar.bz2

#ln -s linux-2.6.21.5 linux

Verifique se o pacote ncurses está instalado, ele será usado quando solicitarmos ao make que execute o menuconfig o qual será usado para configurarmos de uma forma mais amigável o kernel.

Precisamos definir como será o comportamento do kernel. É de extrema importância determinarmos o que será colocado na “parte monolítica” e o que será colocado na “parte modular”. Não existe uma receita de bolo que irá ensinar o que deve ser feito nessa etapa, para cada sistema, cada hardware usado existirá um estudo de como preparar o kernel para atender de forma satisfatória a suas necessidades.

Usando uma o comando make podemos fazer chamada por um dos 4 configuradores. Vejamos mais sobre eles.

1. config – Menu de configuração basicamente texto. Será exibido linha a linha as opções do kernel.

2. menuconfig – Ambiente mais amigável de configuração. Aqui existirá uma tela simples, em ambiente console, que nos dará a possibilidade de escolhas de cada opção do kernel.

3. xconfig – Aqui, necessitamos do ambiente gráfico. Será criado uma tela bem amigável de configuração, com o uso do mouse.

4. oldconfig – Esse é um dos coringas do sistema. Com ele podemos aproveitar as configurações feitas em versões anteriores do kernel, evitando assim a perda de otimizações e simplificando a utilização de novas versões do kernel.

Usaremos o menuconfig para prepararmos o sistema para compilação. Veja os passos abaixo para configuração do sistema.

Configurado, tudo o que fizermos nessa etapa será gravado no arquivo .config, o qual será lido pelo processo de compilação para poder determinar o que será feito com o código.

Vamos a configuração do kernel então. Use os passos descritos abaixo.

#cd /usr/src/linux


http://www.kernel.org/

107

#make menuconfig

A tela abaixo é a tela de configuração do kernel. Entre nas categorias e defina o comportamento de cada uma das opções.

Super importante determinar com exatidão o que será realmente usado. Sua escolha poderá onerar o sistema inteiro, torná-lo lento ou mesmo inutilizado. Entenda como monolítico tudo aquilo que será compilado junto ao núcleo do kernel e modular o que será compilado em separado e chamado quando necessário.

Veja a tela de configuração do kernel.

Tela inicial de configuração do kernel.

Não existem receitas de bolo para desenvolver um processo de compilação do kernel do sistema. Sempre coloco apenas duas regras para um kernel mais interessante. Se o sistema estiver sendo usado para um servidor em produção, retire o kernel hacking – este conjunto do kernel é usado para debugar o sistema, muito usado por desenvolvedores do kernel. Retire ainda os pacotes que possuem descrição como experimental, eles não oferecem muitas garantias. Se o sistema estiver sendo usado para usarmos como base de estudos, é interessante que sejam colocados todo e qualquer recurso que se queira testar. Fica ao critério de cada administrador.


108

Interessante também habilitarmos em General Setup a opção Kernel .config support.

Após configurar o kernel, salve o que foi feito e vamos adiante.

Execute os comandos abaixo para compilar o kernel.

#make clean

Essa etapa limpará as ligações desnecessárias.

#make bzImage

Aqui realmente será a compilação do nosso kernel. Ao final da compilação será criado o arquivo /usr/src/linux/arch/i386/boot/bzImage, este é a imagem do kernel compilada,


109

a parte monolítica. Mais adiante retornaremos a este arquivo para colocá-lo me ação junto ao grub.

#make modules

Compilaremos aqui os módulos do sistema. Tudo o que foi marcado para ser modular será tratado de forma mais específica nessa etapa do processo. Todos os binários dos módulos serão criados nessa etapa.

#make modules_install

Com modules_install será criado um diretório referente aos módulos compilados para essa versão do kernel, em /lib/modules. Os módulos serão copiados para o diretório criado, mantendo a ordem do sistema.

Se tudo deu certo execute o comando mkinitrd para gerar um arquivo em /boot com as informações dos módulos que serão usados para a carga do sistema. Veja abaixo

#mkinitrd /boot/initrd-2.6.21.5.img 2.6.21.5

É importante sabermos exatamente o nome do diretório criado durante o processo de instalação dos módulos no passo #make modules_install, ele será usado aqui para passar a fonte de pesquisa para o mkinitrd.

Agora basta copiar o arquivo gerado pelo make bzImage para dentro do /boot com o nome vmlinuz-<versão_kernel>.

Todos os passos acima feitos, configure seu boot loader e boa sorte.

Precisamos conhecer como gerenciar os módulos do kernel, haja vista que precisamos deles para podermos colocar nosso sistema em funcionamento.

Conceitualmente podemos “ligar” e “desligar” os módulos a qualquer momento, mas para isso, precisamos conhecer o que está sendo ou não usado e como determinar a ação sobre os módulos. Vermos abaixo um conjunto de comandos usados para a administração específica dos módulos do sistema, usados pelos dispositivos, por aplicações e o próprio kernel. Se usarmos o comando lspci, veremos os dispositivos identificados pelo kernel durante o boot do sistema, na etapa de explosão em memória.

Mais uma vez chamo a atenção para o fato de um dispositivo ter sido identificado, não significa que o kernel terá interação com o mesmo, isso se dará com o uso dos módulos do sistema.

Não podemos nos esquecer ainda que podemos onerar o sistema com o uso indevido de módulos. As discussões a cerca deste assunto nos levará a dias e dias de filosofia livresca versos necessidades cotidianas, por isso, só você poderá determinar como usar as informações contidas.

Como primeira etapa, vamos conhecer os módulos que estão “carregados” no sistema neste momento. Use o comando lsmod, como demonstrado abaixo.

#lsmod

Será exibida uma tela como a abaixo. Observe que a grande maioria dos módulos estão relacionados aos dispositivos instalados.


110

Para carregarmos um módulo, fazendo as ligações necessárias entre o núcleo do kernel e o módulo, usaremos o comando insmod.

#insmod fat

Caso o caminho absoluto não seja passado, insmod lerá o arquivo /etc/modules para buscar suas referências.

Para descarregarmos um módulo, use a linha abaixo

#rmmod ieee1394

Se precisarmos saber informações sobre um módulo, usar o comando modinfo é uma boa opção.

#modinfo fat


111

Capítulo 7 - Sistema X WindowAté aqui, nosso ambiente de trabalho foi a console e linhas de comando, porém , no

processo de administração do sistema GNU/Linux, é importante sabermos interagir com o processo de instalação e configuração do servidor X, o ambiente gráfico. Veremos nessa etapa os mecanismos de instalação e configuração do Servidor X window, configuração do teclado dentre outros parâmetros relacionados com o assunto. Vamos ao conteúdo ...


112


113

Trabalhar com o servidor X é realmente bem complicado a primeira vista pelo volume de informações divergentes para cada distribuição.

O primeiro passo é saber que sem o servidor X nenhum gerenciador de janelas como o KDE e GNOME, por exemplo, poderá ser usado. O servidor X é responsável por prover o ambiente responsável para o ambiente gráfico. O Xorg é o responsável por todo o ambiente gráfico do sistema. Vamos instalar o sistema e X e configurá-lo.

Instalação do Servidor X11.Antes de instalarmos o Servidor X, é interessante que se conheça o hardware

instalado para podemos configurar o servidor. Para cada versão do Xfree, podemos nos deparar com um modo de instalação. O pacote do Xfree86 pode ser baixo do site em pacote tarball, e em pacotes .rpm e .deb, além de podermos baixar os pacotes no ftp oficial do projeto e buscarmos os fontes necessários ftp://ftp.xfree86.org/pub/XFree86/4.7.0/binaries.

Para a instalação usaremos o script Xinstall.sh, o qual nos ajudará muito durante essa etapa. Baixe o pacote do site ftp usando o comando

#wget ftp://ftp.xfree86.org/pub/XFree86/4.7.0/binaries/Common/Xinstall.sh /root

Em seguida, execute o script como na linha abaixo

#sh Xinstall.sh

Devemos declarar no PATH do sistema o diretório /usr/X11R6, para que possamos trabalhar com o servidor X. Após instalação, o processo de configuração deverá ser feito através de uma das ferramentas:

1. XFree86

2. cf86cfg

3. xf86config

4. X -config

5. xorgcfg

6. xorgconfig

Existe ainda a possibilidade de usarmos o arquivo de configuração /etc/X11/XF86config .

Abaixo coloco dois modelos do arquivo. Um no padrão Fedora e outro do Debian. Vamos compará-los.

# Xorg configuration created by pyxf86config

Section "ServerLayout"

Identifier "Default Layout"

Screen 0 "Screen0" 0 0

InputDevice "Keyboard0" "CoreKeyboard"

InputDevice "Synaptics" "CorePointer"

EndSection


ftp://ftp.xfree86.org/pub/XFree86/4.7.0/binaries/Common/Xinstall.sh

ftp://ftp.xfree86.org/pub/XFree86/4.7.0/binaries

114

Section "InputDevice"

Identifier "Keyboard0"

Driver "kbd"

Option "XkbModel" "pc105"

Option "XkbLayout" "us"

Option "XkbVariant" "intl"

EndSection


Identifier "Synaptics"

Driver "synaptics"

Option "Device" "/dev/input/mice"

Option "Protocol" "auto-dev"

Option "Emulate3Buttons" "yes"

EndSection

Section "Device"

Identifier "Videocard0"

Driver "intel"

EndSection

Section "Screen"

Identifier "Screen0"

Device "Videocard0"

DefaultDepth 24

SubSection "Display"

Viewport 0 0

Depth 24

EndSubSection

EndSection

Observe que o arquivo está dividido em Section. Nelas configuraremos os dispositivos como monitor, teclado, interface de vídeo. Note também que no padrão fedora não é tão claro as informamos de layout de teclado e resolução de vídeo.


115

No sistema debian, teremos um modelo de arquivo como o seguinte.

# /etc/X11/xorg.conf (xorg X Window System server configuration file)

#

# This file was generated by dexconf, the Debian X Configuration tool, using

# values from the debconf database.

#

# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.

# (Type "man /etc/X11/xorg.conf" at the shell prompt.)

#

# This file is automatically updated on xserver-xorg package upgrades *only*

# if it has not been modified since the last upgrade of the xserver-xorg

# package.

#

# If you have edited this file but would like it to be automatically updated

# again, run the following command:

# sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"

FontPath "/usr/share/fonts/X11/misc"

FontPath "/usr/X11R6/lib/X11/fonts/misc"

FontPath "/usr/share/fonts/X11/cyrillic"

FontPath "/usr/X11R6/lib/X11/fonts/cyrillic"

FontPath "/usr/share/fonts/X11/100dpi/:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"

FontPath "/usr/share/fonts/X11/75dpi/:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"

FontPath "/usr/share/fonts/X11/Type1"

FontPath "/usr/X11R6/lib/X11/fonts/Type1"

FontPath "/usr/share/fonts/X11/100dpi"

FontPath "/usr/X11R6/lib/X11/fonts/100dpi"

FontPath "/usr/share/fonts/X11/75dpi"

FontPath "/usr/X11R6/lib/X11/fonts/75dpi"

# path to defoma fonts

FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"

EndSection

Section "Module"

Load "i2c"


116

Load "bitmap"

Load "ddc"

Load "dri"

Load "extmod"

Load "freetype"

Load "glx"

Load "int10"

Load "vbe"

EndSection


Identifier "Generic Keyboard"

Driver "kbd"

Option "CoreKeyboard"

Option "XkbRules" "xorg"

Option "XkbModel""pc104"

Option "XkbLayout" "us"

EndSection


Identifier "Configured Mouse"

Driver "mouse"

Option "CorePointer"

Option "Device" "/dev/input/mice"

Option "Protocol" "ImPS/2"

Option "Emulate3Buttons" "true"

EndSection

Section "Device"

Identifier "Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller"

Driver "i810"

BusID "PCI:0:2:0"

EndSection

Section "Monitor"

Identifier "Monitor Genérico"


117

Option "DPMS"

HorizSync 28-64

VertRefresh 43-60

EndSection

Section "Screen"

Identifier "Default Screen"

Device "Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller"

Monitor "Monitor Genérico"

DefaultDepth 24


Depth 1

Modes "1280x800"

EndSubSection


Depth 4

Modes "1280x800"

EndSubSection


Depth 8

Modes "1280x800"

EndSubSection


Depth 15

Modes "1280x800"

EndSubSection


Depth 16

Modes "1280x800"

EndSubSection


Depth 24

Modes "1280x800"

EndSubSection

EndSection


118

Section "ServerLayout"

Identifier "Default Layout"

Screen "Default Screen"

InputDevice "Generic Keyboard"

InputDevice "Configured Mouse"

EndSection

Section "DRI"

Mode 0666

EndSection

Já o arquivo do debian, temos de forma clara as informações de teclado, freqüência do monitor, resolução do vídeo. Isso torna mais simples a configuração do sistema.

Para finalizarmos a instalação instalaremos da fontes. Para isso copie os arquivos para o diretório /usr/share/fonts, ou para /usr/X11R6/lib/X11/lib/fonts/* ou .fonts no home do usuário.


119

Capítulo 8 – Conceitos Básicos de Protocolos TCP/IP

Entender redes de computadores é entender os conceitos e funcionalidades dos protocolos usados para prover a comunicação entre os dispositivos. Não existe comunicação entre hosts em uma rede, sem que todos os hosts estejam usando o mesmo protocolo de comunicação.

Nessa etapa, abordaremos alguns dos protocolos mais importantes para prover a comunicação e a troca de informações entre hosts. Estudaremos os protocolos TCP/IP, protocolos associados e novas formas desenvolvidas por mim de uso dos mecanismos de endereçamentos IP.

Não veremos nenhum tipo de aplicação servidor aqui, isso ficará para outro momentos.


120


121

HistóricoNos anos 60, o principal setor estratégico americano, Department of Defense – DoD

se interessou em um protocolo que estava sendo desenvolvido/utilizado pelas universidades para interligação dos seus sistemas computacionais e que utilizava a tecnologia de chaveamento de pacotes. O interesse do DoD estava no desejo de manter a comunicação entre os diversos sistemas espalhados pelo mundo, no caso de um desastre nuclear. O problema maior estava na compatibilidade entre os sistemas computacionais de diferentes fabricantes que possuíam diferentes sistemas operacionais, topologias e protocolos. A integração e compartilhamento dos dados passou a ser um problema de difícil resolução.

Foi atribuído assim à Advanced Research Projects Agency – ARPA a tarefa de encontrar uma solução para este problema de tratar com diferentes equipamentos e diferentes características computacionais. Foi feita então uma aliança entre universidades e fabricantes para o desenvolvimento de padrões de comunicação. Esta aliança especificou e construiu uma rede de teste de quatro nós, chamada ARPANET, e que acabou sendo a origem da Internet hoje.

No final dos anos 70, esta rede inicial evoluiu, teve seu protocolo principal desenvolvido e transformado na base para o TCP/IP (Transmition Control Protocol / Internet Protocol). A aceitação mundial do conjunto de protocolos TCP/IP deveu-se principalmente a versão UNIX da Berkeley que além de incluir estes protocolos, colocava-os em uma situação de domínio público, onde qualquer organização, através de sua equipe técnica poderia modificá-los e assim garantir seu desenvolvimento.

Dentre as várias organizações e comitês que participaram deste desenvolvimento e divulgação, podemos destacar Internet Engineering Task Force – IETF (http://www.ietf.org) cuja principal função atual é a manutenção e apoio aos padrões da Internet e TCP/IP principalmente através da série de documentos Request for Comments - RFC. Estes documentos descrevem as diversas tecnologias envolvidas e servem de base para as novas tecnologias que deverão manter a compatibilidade com as anteriores dentro do possível.

Em resumo, o maior trunfo do TCP/IP é o fato destes protocolos apresentarem a interoperabilidade de comunicação entre todos os tipos de hardware e todos os tipos de sistemas operacionais. Sendo assim, o impacto positivo da comunicação computacional aumenta com o número de tipos computadores que participam da grande rede Internet.

Modelo de Referência ISO/OSIDentro deste cenário de grande variedade de sistemas operacionais, CPUs, interfaces

de rede, tecnologias e várias outras variáveis, e a necessidade de interconexão entre os diversos sistemas computacionais, em 1977, a International Organization for Standardization – ISO, criou um sub-comitê para o desenvolvimento de padrões de comunicação para promover a interoperabilidade entre as diversas plataformas. Foi então desenvolvido o modelo de referência Open Systems Interconnection – OSI.

É importante observar que o modelo OSI é simplesmente um modelo que especifica as funções a serem implementadas pelos diversos fabricantes em suas redes. Este modelo não detalha como estas funções devem ser implementadas, deixando isto para que cada empresa/organização tenha liberdade para desenvolver.

O comitê ISO assumiu o método “dividir para conquistar”, dividindo o processo complexo de comunicação em pequenas sub-tarefas (camadas), de maneira que os


122

problemas passem a ser mais fáceis de tratar e as sub-tarefas melhor otimizadas. O modelo ISO/OSI é constituído por sete camadas, descritas sucintamente a seguir da camada mais superior a mais inferior:

7

Aplicação Esta camada funciona como uma interface de ligação entre os processos de comunicação de rede e as aplicações utilizadas pelo usuário.

6

Apresentação Aqui os dados são convertidos e garantidos em um formato universal.

5

Sessão Estabelece e encerra os enlaces de comunicação.

4

Transporte Efetua os processos de sequenciamento e, em alguns casos, confirmação de recebimento dos pacotes de dados.

3

Rede O roteamento dos dados através da rede é implementado aqui.

2

Enlace Aqui a informação é formatada em quadros (frames). Um quadro representa a exata estrutura dos dados fisicamente transmitidos através do fio ou outro meio.

1

Física Define a conexão física entre o sistema computacional e a rede. Especifica o conector, a pinagem, níveis de tensão, dimensões físicas,características mecânicas e elétricas, etc.

Cada camada se comunica com sua semelhante em outro computador. Quando a informação é passada de uma camada para outra inferior, um cabeçalho é adicionado aos dados para indicar de onde a informação vem e para onde vai. O bloco de cabeçalho+dados de uma camada é o dado da próxima camada. Observe a figura abaixo que esquematiza isto.

A unidade de informação muda de nome ao longo das camadas de maneira que podemos saber sobre qual camada se está referindo pelo nome destas unidades.

Antes do desenvolvimento do modelo de camadas ISO/OSI, o DoD definiu seu próprio modelo de rede conhecido como modelo DoD de rede ou também modelo Internet de rede. Posteriormente este modelo passou a ser conhecido como modelo de camadas TCP/IP, que será descrito a seguir.


123

Modelo TCP/IPO modelo de camadas ISO/OSI acabou se tornando apenas uma base para

praticamente todos os protocolos desenvolvidos pela indústria. Cada desenvolvedor tem uma arquitetura que difere em detalhes as vezes fundamentais no seu desenvolvimento. Sendo assim, é de se esperar uma variação nas descrições do conjunto de protocolos TCP/IP.

Organizado em 4 camadas, a implementação sobre o protocolo TCP/IP se torna mais simples e eficiente. Vejamos como estão organizadas as camadas do TCP/IP em relação ao modelo OSI

Observe que as 3 primeiras camada do modelo OSI, tornaram-se a primeira do TCP/IP e que as 2 últimas do OSI, é a última camada do TCP/IP. Para entendermos melhor o comportamento do protocolo TCP/IP, veja a função de cada camada.

Camada Network

Oferece interface com a rede física;

Formata os dados para o meio de transmissão e os endereça para a sub-rede com base no endereço de hardware físico;

Verifica erros para os dados entregues na rede física;

Camada Internet

Endereçamento Lógico;

Roteamento;

Redução de tráfego;

Suporte para interligação de redes;

Relacionamento de endereços físicos com endereços lógicos;

Camada Transport


Camada Aplicação

Camada Apresentação

Camada Sessão

Camada Transporte

Camada Network

Camada Data Link

Camada Física

Camada Aplicação

Camada Transporte

Camada Internet

Camada Network

124

Controle de fluxo;

Verificação de erros;

Confirmação para a interligação de redes;

Interface para as aplicações de rede;

Camada Application

Diagnóstico de rede

Transferência de Arquivos

Controle remoto e atividades da Internet

Suporte para APIs da rede

O TCP/IP não faz distinção entre as camadas superiores. As três camadas superiores são estritamente equivalentes aos protocolos de processos da Internet. Os processos possuem o nome do próprio protocolo utilizado, porém é importante não confundir o protocolo em si com a aplicação que geralmente apresenta uma interface com usuário amigável para utilização do protocolo.

No modelo ISO/OSI, a camada de transporte (4) é responsável pela liberação dos dados para o destino. No TCP/IP isto é feito pelos protocolos “ponto a ponto” TCP e UDP que serão descritos posteriormente.

Por fim, o protocolo IP é o responsável pela conexão entre os sistemas que estão se comunicando. Basicamente este protocolo se relaciona com a camada de rede (3) do modelo ISO/OSI. Este protocolo é o responsável principal do movimento da informação na rede. É nesta camada/protocolo que a informação é fragmentada no sistema fonte e reagrupada no sistema alvo. Cada um destes fragmentos podem ter caminhos diferentes pela rede de forma que os fragmentos podem chegar fora de ordem. Se, por exemplo, o fragmento posterior chegar antes do anterior, o protocolo IP no sistema destino reagrupa os pacotes na seqüência correta.

A camada superior, camada de aplicação é responsável por permitir que aplicações possam se comunicar através de hardware e software de diferentes sistemas operacionais e plataformas. Muitas vezes este processo é chamado de cliente-servidor. A aplicação cliente em geral está em um equipamento mais simples e com uma boa interface com usuário. Esta aplicação envia requisições à aplicação servidor que normalmente está em uma plataforma mais robusta e que tem capacidade para atender várias requisições diferentes de clientes diferentes.

A camada de Transporte tem a função principal de começar e terminar uma conexão e ainda controlar o fluxo de dados e de efetuar processos de correção e verificação de erros. A camada de rede é a responsável pelo roteamento.

Comparativamente ela corresponde no modelo ISO/OSI a camada de Rede (3) e parte da camada Enlace (2). Esta camada é usada para atribuir endereço de rede (IP) ao sistema e rotear a informação para a rede correta. Tem ainda a função de ligação entre as camadas superiores e os protocolos de hardware.

Em essência podemos afirmar que sem esta camada, as aplicações teriam que ser desenvolvidas para cada tipo de arquitetura de rede como por exemplo Ethernet ou Token Ring.

A primeira camada, camada Física, não é definida pelo TCP/IP, porém é nítida sua importância em relação à parte física da mídia de comunicação, de bits, de quadros, de


125

endereços MAC, etc.

Endereçamento IP e ClassesIdentificador único, através do qual os hosts executam serviços de roteamento que

basicamente definem o caminho disponível naquele momento para comunicação entre a fonte e o destino.

O endereço IP está descrito em 4 octetos (bytes), separados por pontos, que definirão um único endereço dividido em uma parte que representa a rede a qual pertence, o endereço da subrede e por fim o identificador do host.

Antes de detalharmos como funcionam os endereçamentos IP, importante observarmos que alguns endereços tem função especial. Vamos aos detalhes de alguns deles.

Endereço 0: Significa a própria rede ou sistema. O endereço 0.0.0.35 referencia a estação 35 da rede local. O endereço 127.0.0.0 referencia a estação em análise. O endereço 152.84.40.0 referencia a subrede 40 inteira da rede local.

Endereço 127: É conhecido como loopback e é utilizado em processos de diagnose. O endereço 127.0.0.1 é o próprio loopback da estação em análise.

Endereço 255: Este endereço é muito utilizado em mensagens broadcast e serviços de anúncio generalizados. Uma mensagem enviada para o endereço 152.84.255.255 irá atingir todos os 255 sistemas de cada uma das 255 subredes da rede local do CBPF.

Organizado em classes, os endereços IP podem assumir valores diversos e o que determinará a que classe pertence, e a ordenação dos endereços são os bits de mais alta ordem. Para entendermos melhor, vamos observar as relações entre os endereços, bits de mais alta ordem e número de subredes e hosts para cada classe.

Classe A

Bit de alta ordem

0xxxxxxx

Intervalo de Endereços

1.0.0.0 – 126.0.0.0

Bits de redes/hosts

7/24

Máximo de Hosts

16.777.214

Classe B

Bit de alta ordem

10xxxxxx


128.1.0.0.0 – 191.254.0.0

Bits de redes/hosts


126

14/16

Máximo de Hosts

65.534

Classe C

Bit de alta ordem

110xxxxx


192.0.1.0 – 223.255.254.0

Bits de redes/hosts

22/8

Máximo de Hosts

254

Não existe nenhuma regra prática que o proíba de usar os endereços de qualquer classe a qualquer momento em sua rede ethernet, porém, como tudo que nos cerca, existem regras para uso dos endereços em redes globais, vejamos as regras.

Os endereços Classe A são usados para redes muito grandes normalmente ligada a funções educacionais e científicas. Os endereços Classe B são usados em redes muito grandes, normalmente atribuídas a instituições que possuíam um perfil disseminador de tecnologia e assim pudessem de alguma forma distribuir suas redes entre instituições e empresas contribuindo assim para o desenvolvimento de uma grande rede mundial. Os endereços Classe C são os mais difundidos pois permitem redes de 256 IP’s o que parece ser um número conveniente para gerenciamento e implantação de sistemas de informação. Os de Classe D são reservados para Multicast utilizado nas aplicações de Videoconferência, Multimídia, dentre outras, e por fim, os endereços Classe E são reservados para experimentação e desenvolvimento.

Graficamente, os endereços IP estão organizados da seguinte forma.

Mas definir um endereço IP nada significa para o processo de comunicação entre máquinas. Quem determinará em qual das subredes o host estará, será a netmask,


“netid”0 “hostid”

“netid”1 “hostid”0

“netid”1 “hostid”01

127

máscara de subrede.

SubredesA criação de subredes a partir de uma rede primária é um procedimento típico na

área de redes. O objetivo desta segmentação é permitir uma melhor performance da rede em termos organizacionais, estruturais e funcionais.

A idéia básica é acrescentar alguns bits à identificador de rede do endereço IP. Os endereços permitidos são aqueles formados pelos bits restantes do octeto, isso se dará com o uso da netmask.

Netmask - Máscara de SubredesConforme descrito na figura anterior, o identificador de redes e subredes, a máscara

de subrede, também é composta por 4 octetos. A máscara é formada por bits 1 nos campos que caracterizam o endereço de rede, e bits 0 nos campos relativos ao host. Veremos mais tarde que o conceito inicial nos fará entender como funciona todo o mecanismo de endereçamento mas pode ser alterado.

Considere uma Classe C com cada posição representada por um único bit de um endereço de 32bits:

N-> Rede H -> Máquina (Hot) NNNNNNNN.NNNNNNNN.NNNNNNNN.HHHHHHHHSe esta Classe C for dividida em 8 subredes com 32 endereços teremos então 2

endereços especiais que determinam o início e o final da subrede. Estes endereços são o endereço da rede, normalmente o primeiro do range e o endereço de broadcast, o último do range. Nossa rede estaria então definida da seguinte maneira.

32 - 2(rede e broadcast)=30 hosts em cada uma delas, a máscara de subrede será 255.255.255.224 ou ainda /27 e sua representação fica:

NNNNNNNN.NNNNNNNN.NNNNNNNN.NNNHHHHH 11111111.11111111.11111111.11100000

Em um outro exemplo queremos fazer 64 subredes com 4-2=2 hosts permitidos por subrede. Neste caso a máscara seria 255.255.255.252 ou ainda /30 com a seguinte representação:

NNNNNNNN.NNNNNNNN.NNNNNNNN.NNNNNNHH 11111111.11111111.11111111.11111100

O mesmo raciocínio pode ser empregado em uma Classe B ou Classe A, mudando somente a relação entre bits 1 e bits 0, ou em outras palavras muda o octeto em análise. No caso de 2 subredes na Classe B teremos 255.255.128.0 ou /17 representadas por:

NNNNNNNN.NNNNNNNN.NHHHHHHH.HHHHHHHH 11111111.11111111.10000000.00000000


128

Vale ressaltar aqui uma operação simples implementada por todos algoritmos de roteamento que é o AND lógico entre a máscara de subrede e o endereço do host. Se o endereço tiver os mesmos bits 1 da máscara então este endereço pertence a subrede em análise e portanto o pacote pode ser enviado através de broadcast na subrede. Se diferir, então o pacote deve ser enviado ao gateway, pois certamente pertence a outra subrede. veja no exemplo abaixo.

Aplicamos uma máscara de sub-rede padrão classe B para realizar a subdivisão da rede por um endereço IP.

IP : 140.179.240.200 (10001100.10110011.11110000.11001000)

Aplicaremos a máscara de sub-rede default da classe B

255.255.0.0 (11111111.11111111.00000000.00000000)

Em virtude disto, teremos

10001100.10110011.11110000.11001000(Endereço IP)

11111111.11111111.00000000.00000000(Netmask default)

--------------------------------- AND LÓGICO ----------------------------------------------

10001100.10110011.00000000.00000000 (Endereço de rede)

Observe que aplico um operação lógica AND entre os endereços IP e máscara de sub-rede para determinarmos o endereço da rede.

De uma forma geral, o endereço IP foi dividido em 2 partes, como vimos anteriormente, uma seria o netid e a outra o hostid. Com a aplicação da netmask, a parte do hostid foi dividida em mais duas partes. Uma sendo a identificação de subrede e outra a identificação do host. Graficamente representada como na figura abaixo.

Existe uma relação entre as classes de endereços IP e as descrições de classes das máscaras de subrede. Veja na figura abaixo como se comportam essas relações.

Note que temos um netmask para cada classe de endereços IP. Usando o and lógico podemos agora definir o comportamento padrão para cada endereço ip em cada classe. Analise as tabelas abaixo, elas descrevem os endereços de cada classe com sua respectiva netmask.


11111111 11111111 11111111 00000000

“netid”1 0 Número da sub-rede

Númerodo host

255.255.255.0FF.FF.FF.0Classe C

255.255.0.0FF.FF.0.0Classe B

255.0.0.0FF.0.0.0Classe A

Máscara de sub-rede (decimal)

Máscara de sub-rede(hexa)

Classe de endereço IP

129

Na tabela acima, iniciamos a observação do comportamento de cada classe com suas netmask, número de subredes possíveis e hosts para cada subrede em classe A .


130

Vejamos a classe B como se comporta.

Para finalizarmos, vamos à classe C.


131

Note que em todas as tabelas chegamos ao ponto de termos os endereços de subrede iguais. Isso nos mostra que podemos ter endereços tipicamente de classe C, sendo usados com máscaras de subrede classe C. O que determinará todo o comportamento dos endereços em sua rede é sua necessidade. Nada o impede de adequar seus endereços para satisfazer as necessidades de sua empresa.

Se observarmos as tabelas, veremos que em algum momento teremos endereços de classe A, por exemplo, com netmask tipicamente em classe C ou classe B. Isso demonstra que o simples fato de vermos um endereço não significará nada a nível prático, teremos que analisar o contexto em que este endereço está inserido.

Um outro detalhe que deve ser observado é o fato de em uma estrutura padrão de endereços, toda indicação de endereço de rede é par e os endereços de broadcast serão ímpares. Isso se dá pela forma como os endereços são determinados, vamos lembrar isso.

A fórmula base para o cálculo de um endereço ip é 2^n -2, onde n é o número de bits 0 encontrados na descrição binária do endereço. Veja o exemplo, tomando como base os endereços descritos anteriormente.

IP : 140.179.240.200 (10001100.10110011.11110000.11001000)

Aplicaremos a máscara de sub-rede default da classe B

255.255.255.0 (11111111.11111111.11111111.00000000)

Faremos o and lógico para determinarmos a qual subrede o endereço ip informado faz parte e podermos determinar também quantos hosts teremos na subrede.

10001100.10110011.11110000.11001000(Endereço IP)

11111111.11111111.11111111.00000000(Netmask default)

--------------------------------- AND LÓGICO ----------------------------------------------


132

10001100.10110011.11110000.00000000 (Endereço de rede)

Quem determinará todo o comportamento para estas relações será a netmask. No exemplo acima observamos um típico endereçamento usando classe C em sua netmask, teremos então 8 bits do endereço ip livres, justamente os 8 bits do último octeto que estão relacionados com o último octeto da netmask. Como temos 8 bits 0 na netmask, teremos 8 bits livres para endereços ip. Levando em conta que dois endereços serão usados para endereço de subrede e broadcast, teremos 254 hosts. Veja o como calcular abaixo.

2^n – 2 = hosts, logo, 2^8 -2 = 254 hosts

Os endereço 0 e 255 serão reservados para endereço da subrede e broadcast, respectivamente.

Se mantivermos o mesmo endereço ip e mudarmos a netmask, toda a relação será alterada. Veja o exemplo.

10001100.10110011.11110000.11001000(Endereço IP)

11111111.11111111.11111111.11111100(Netmask default)

--------------------------------- AND LÓGICO ----------------------------------------------

10001100.10110011.11110000.11001000 (Endereço de rede)

Assim, teremos

2^n -2 = hosts, logo, 2^2 -2 = 2 hosts

Por esse motivo, um endereço 255.255.255.248 nos dará um total de 6 hosts, um endereço 255.255.255.240 nos dará 30 hosts e assim por diante. Veja nas tabelas de relações de endereços apresentada anteriormente o número de hosts para cada possibilidade padrão de uso de endereços IP.

Colocando em prática...

Se precisarmos então de uma subrede com 10 máquinas, usaremos a netmask 255.255.255.240, o que possibilita 14 hosts. Teremos 10 usados e 4 sobrando. Assim vamos ajustando as possibilidades de uso dos endereços para nossas necessidades. A verdade é que na maior parte das vezes que pensarmos em usar subredes, algum tipo de sobra de ip acontecerá.

Pensando nisso, desenvolvi uma nova maneira de endereçamento e cálculo de hosts para subredes. Vamos a esta maneira alternativa.

Tudo começou quando resolvi desenvolver um mecanismo que fosse mais rápido e prático para determinar o número de hosts de uma subrede.

Se pensarmos em um endereço com uma netmask 255.255.255.252, teremos 2 hosts, ok? Vimos este exemplo anteriormente. Bom se pegarmos o último octeto do endereço de netmask (252) e subtrairmos de 254 (que é o último endereços de hosts, teremos 2, exatamente o número de hosts calculado pela fórmula tradicional. Se fizermos para todos os endereços descritos nos padrões tcp/ip teremos os mesmos resultados. Vamos aos exemplos, tomando como base a classe C.

Netmask Hosts pelo método Clássico (2^n-2)

Hosts pelo método alternativo desenvolvido por mim (254-netmask)

255.255.255.192 62 62

255.255.255.224 30 30


133

255.255.255.240 14 14

255.255.255.248 6 6

255.255.255.252 2 2

Intrigado com essa base de cálculos para o número de hosts de uma subrede, me perguntei se não poderia então determinar com exatidão uma netmask que evitasse sobras de Ips.

Tive a necessidade de determinar em uma rede, subredes com 15 máquinas. Pelo padrão usaria o netmask 255.255.255.224 e sobrariam 15 Ips para esta subrede. Consequência disso. Qualquer usuário poderia colocar uma nova máquina sem que eu soubesse, usando tentativa e erro até conseguir determinar um dos endereços livros em sua estação.

O meu problema era evitar isso, mas não existe, ao menos não consegui nada nem com professores, nem livros que me dessem condições para fazê-lo. Desenvolvi então um método alternativo de endereçamento.

A base de todo o método é determinar o número de hosts para a sua subrede e a partir dele, determinar a netmask da sua rede.

Vamos a prática...

254 - 15 hosts = 239, com isso teremos a netmask em classe C 255.255.255.239. O primeiro problema está resolvido. Porém tenho mais um ... Como determinar esse endereço para os hosts de minha rede, haja vista que nenhuma ferramenta de configuração me permitirá fazê-lo.

O segundo passo foi alterar o comportamento do DHCP para poder informar aos clientes seus novos endereços.

Não demonstrarei como fiz as alterações por questões lógicas, estou desenvolvendo um artigo que será publicado com todos os detalhes sobre o assunto. mas na figura abaixo mostro uma estação windows XP com o endereço alternativo provando sua funcionalidade.


134

Endereçamento entendido, vamos entender os protocolos que promovem a integração entre sistemas.

Protocolos e AplicaçõesAgora abordaremos os principais protocolos que compõem o conjunto TCP/IP de

protocolos. Alguns destes protocolos são confundidos pela própria aplicação que os utiliza. Sendo assim, adiante haverá uma seção de Protocolos de Aplicação.

Protocolo Internet - IPO protocolo Internet é definido na camada 3 do modelo ISO/OSI.

Esta camada é responsável pelo endereçamento dos pacotes de informação dos dispositivos origem e destino e possível roteamento entre as respectivas redes, se diferentes. Este roteamento é executado através do IP.

Como visto anteriormente, o endereço IP é composto de 4 octetos, que são divididos em parte rede e parte dispositivo, chamados de identificadores de rede e de host, de acordo com o tipo de classe definido pelos primeiros bytes do primeiro octeto, e/ou subrede, definida pelo número de máscara.

Este protocolo, usando a parte rede do endereço ou identificador de rede, pode definir a melhor rota através de uma tabela de roteamento mantida e atualizada pelos roteadores.

Este protocolo recebe os dados da camada superior (transporte) na forma de segmentos. Ocorre então o processo de fragmentação e os conjuntos de dados passam a se chamar datagramas. Estes datagramas são então codificados para envio à camada inferior (física) para encaminhamento no meio físico.

Na tabela abaixo relacionamos as diversas partes (9) constituintes de um data grama, o número de bits e função ou descrição.

O primeiro campo, Cabeçalho, contém informação sobre a versão do número IP (ipv4 ou ipv6) e o tipo de serviço (ToS), muito usado em aplicações que necessitem de Qualidade de Serviço (QoS).

O segundo campo, Comprimento, informa o comprimento do data grama incluindo dados e cabeçalho.

O terceiro campo, Fragmentação, instrui ao protocolo, como reagrupar datagramas quando chegam após um processo de fragmentação muito comum em interfaces defeituosas e tráfego intenso.

O quarto campo, Time to Live – TTL, informa o número de roteadores que podem redirecionar o data grama. O valor é decrementado até zero a cada roteador quando então o data grama é descartado, impedindo a criação de loops e assim garantindo estabilidade ao processo de roteamento.

O quinto campo, informa qual protocolo deverá receber o data grama na próxima

camada. Se o valor deste campo for 6, TCP, se 7, UDP. Estes protocolos serão descritos posteriormente.


135

O sexto campo, Verificação de Erro, seleciona que processo será utilizado na detecção de erros: Cyclical Redundance Check – CRC ou Frame Check Sequence – FCS.

Os próximos campos, sétimo e oitavo, Endereço Fonte e Endereço Destino, 32 bits cada, caracterizam por completo toda informação sobre endereçamento necessária ao processo de roteamento.

O último campo contém os dados, a informação na realidade, e tem tamanho livre porém definido pelo tipo de rede sendo o MTU igual a 1500kbytes.

Todas as informações necessárias para que o IP possa se comunicar com o resto da rede estão distribuídas nestes campos, principalmente naqueles relativos ao endereçamento. É importante observar que a camada de rede utiliza estes endereços lógicos de 4x8bits, para definir as redes existentes e como conseguir obter informação delas. Entretanto, para que os dados cheguem aos hosts é necessário um outro tipo de endereço: endereço Media Access Control - MAC ou Ethernet.

O TCP/IP define um protocolo, ARP, que caracteriza e relação entre o endereço IP e o endereço MAC. Falaremos a seguir sobre este protocolo.

Address Resolution Protocol - ARP

Na realidade, a troca de dados entre dispositivos IP é efetuada através do endereço MAC - Media Access Control, ou endereço Ethernet ou ainda endereço Físico. De maneira bem simplificada, podemos considerar o protocolo ARP como sendo um broadcast no segmento de rede perguntando qual é o endereço MAC do dispositivo que tem um certo IP.

Vamos considerar a figura abaixo através de dois exemplos típicos:

1. comunicação no mesmo segmento de rede e em redes distintas.

Vamos considerar primeiramente uma aplicação no computador A enviando dados para o computador B, considere por simplicidade um serviço PING de A para B. O primeiro passo é determinar se A e B pertencem ao mesmo segmento de rede. Isto é feito através do simples algoritmo que compara o resultado de uma operação AND lógico entre os IP e a sua respectiva máscara: mesmo resultado mesma rede, resultados diferentes redes diferentes. No caso A e B são vizinhos de um mesmo segmento.


136

Na construção do data grama, a aplicação sabe os endereços MAC e IP da fonte A e somente o endereço IP do destino B. Para descobrir o endereço MAC de B o protocolo ARP envia um broadcast a todos os dispositivos do segmento perguntando ao dono do IP B o seu endereço MAC. Por sua vez, o dispositivo dono do IP, envia também por broadcast, ou seja, para todos, o seu endereço MAC. Todos os dispositivos do segmento acrescentam na sua tabela ARP (IPxMAC), também chamada de proxycache ARP, este registro relativo ao B, que permanece durante um certo tempo. Finalmente, o dispositivo A envia o quadro (frame) destinado ao dispositivo B. Neste exemplo mesmo quadro é enviado para B e a interface do roteador deste segmento, porém somente o dispositivo B irá abrir o quadro até a última camada pois somente ele tem o endereço MAC destino. Observe que se houvesse outros dispositivos no segmento, eles passariam a conhecer também o endereço MAC de B de maneira que se quiserem enviar algo à B posteriormente, não seria mais necessário um broadcast ARP.

Vamos agora considerar que a comunicação seja entre os dispositivos A e C. Primeiramente o dispositivo A determina que C pertence a outro segmento através do algoritmo comparativo de operações AND. O dispositivo A então envia os dados para o gateway que é a interface do roteador. Para isto o protocolo ARP é utilizado para descobrir o endereço MAC da interface da mesma maneira que no caso anterior. Observe que o endereço MAC destino é do roteador porém o IP destino continua sendo do dispositivo C. Quando o roteador recebe os dados, ele procura pela rede à qual pertence o IP destino na sua tabela de roteamento e assim roteia para interface deste segmento. O roteador irá utilizar o protocolo ARP para determinar o endereço MAC do dispositivo C que será anexado ao cabeçalho da camada de enlace, como MAC destino e o seu próprio como MAC origem. É importante observar que os Ips origem (A) e destino (C) permanecem inalterados durante todo o processo. Quando o dispositivo C finalmente recebe a mensagem oriunda de A, o processo de volta é simplificado pois os diversos endereços MAC continuam nas tabelas dos dispositivos envolvidos (C, roteador e A).

Estes dois exemplos simples mostram o funcionamento e importância do protocolo ARP que na realidade só é usado para manter a tabela IP/MAC de cada dispositivo atualizada.

Internet Control Message Protocol - ICMPO ICMP é um protocolo de mensagens de controle usado para informar outros

dispositivos de importantes situações das quais podemos citar como exemplo: fluxo de mensagens maior que a capacidade de processamento de um dispositivo; parâmetro Time To Live – TTL; e mensagens de redirecionamento. Abordaremos rápida e separadamente cada um destes três exemplos.

Eventualmente um roteador pode estar recebendo mais informação do que pode processar, sendo assim ele passa a contar com controle de fluxo, enviando uma mensagem source quench para o dispositivo origem para que ele pare ou diminua o fluxo de dados. Esta mensagem é enviada pelo protocolo ICMP.

O segundo caso evolve o parâmetro TTL que basicamente é o número de hops


137

(roteadores) total que uma informação pode percorrer. Ele é decrementado a cada hop e quando chega a zero, o roteador descarta o data grama e envia uma mensagem à fonte informando que a informação não chegou ao seu destino, utilizando o ICMP.

O terceiro caso é a mensagem de redirecionamento ICMP, que é utilizada quando o roteador determina que um caminho melhor existe para o pacote que acabou de ser enviado assim mesmo. Neste caso a implementação do protocolo de roteamento pode definir um novo caminho de acordo com este melhor caminho. Alguns sistemas operacionais de roteamento não consideram esta mensagem e continuam enviando dados pelo pior caminho.

Uma aplicação típica deste protocolo é o PING, muito utilizado para determinar se um determinado dispositivo está ativo em uma rede, já que esta aplicação testa o sistema de transporte do TCP/IP.

Transmission Control Protocol - TCPO protocolo IP, camada de rede (3), envia dados para rede sem a preocupação de

verificar a chegada dos respectivos datagramas. Os protocolos da camada acima, host-host ou transporte (4), especificamente TCP, definem a maneira para tratar datagramas perdidos ou corruptos. Além disto, TCP é responsável pela segurança na transmissão/chegada dos dados ao destino e também define todo o processo de início de conexão e multiplexação de múltiplos protocolos da camada de aplicação (7) em uma única conexão, otimizando assim a conexão múltipla de aplicações com o mesmo destino.

O protocolo TCP é orientado a conexão sendo isto claramente observado no processo de inicialização da conexão. O TCP aplica o algoritmo three-way handshake ou three-fold nesta inicialização. Este algoritmo pode ser comparado com o ato de telefonar onde em um primeiro momento um número é discado, posteriormente alguém atende dizendo “alô” e por fim a pessoa que ligou começa a falar, enviando dados.

Na realidade, o dispositivo fonte envia uma seqüência de números que iniciará o envio de segmentos (vide final da seção 2), início de uma conexão SYN. Sendo assim o dispositivo destino passa a conhecer esta seqüência. O dispositivo destino responde com sua própria segundai de números e portanto o dispositivo fonte passa por sua vez, a conhecer a seqüência do destino, viabilizando assim a conexão pois os dispositivos envolvidos, fonte e destino, sabem as respectivas seqüências numéricas. Esta segunda etapa é conhecida como acknowledgment ou ACK. Na terceira e última etapa, o dispositivo fonte emite o seu sinal ACK informando que começará a enviar dados.

Assim como o IP, o TCP precisa saber qual o protocolo de aplicação da última camada que receberá os dados. Isto é feito através da codificação das portas. Ao todo são 65.535 (64k) portas, sendo que de 0 à 1024 são portas definidas e portanto só podem ser usadas por aplicações que utilizem os respectivos protocolos. As portas de 1024 à 65535 são atribuídas dinamicamente. Existem exceções que podem ser ignoradas nesta discussão.

User Datagram Protocol - UDPExistem situações em que o dispositivo origem não precisa da garantia de chegada

dos dados no dispositivo destino, como exemplo podemos citar alguns tipos de Videoconferência. Nestes casos, o TCP é substituído pelo UDP que é um protocolo que não é orientado a conexão, ou seja, não necessita estabelecer uma conexão entre origem e destino antes de enviar os dados. Este protocolo não verifica nem se o dispositivo destino está on line.

Na realidade o protocolo UDP empacota os dados e os envia para camada inferior


138

(rede 3) para que o protocolo IP dê prosseguimento ao envio dos dados. Estes pacotes, segmentos, apesar de serem numerados antes de serem enviados, não sofrem nenhuma verificação de chegada ao destino.

Assim como fizemos um paralelo entre TCP e o telefone, podemos comparar o UDP com o correio regular. Preparamos uma carta, envelopamos, selamos e colocamos no correio na esperança de que chegue ao seu destino.

Assim como o TCP, o UDP também é um protocolo da camada de transporte (4), porém diferentemente não gera mensagens ICMP.

Protocolos da Camada de AplicaçãoComo foi visto anteriormente, o conjunto de protocolos TCP/IP estão distribuídos ao

longo das camadas superiores se comparados com o modelo ISO/OSI. Dentre estes, existem muitos protocolos que atuam na última camada (Aplicação). Abordaremos a seguir os mais utilizados pela comunidade.

File Transfer Protocol - FTP

A aplicação FTP foi uma das primeiras aplicações na hoje chamada Internet. A base é o protocolo FTP que tem como principal função a transferência de arquivos entre dispositivos nos formatos ASCII e Binário. É uma aplicação do tipo cliente/servidor e em uma situação típica a aplicação cliente FTP utiliza o protocolo TCP para estabelecer uma conexão com o servidor remoto. Os servidores podem disponibilizar áreas só de leitura para download de arquivos compartilháveis ou leitura/escrita para áreas públicas sem restrição.

Normalmente estes servidores permitem conexão autenticada, login/senha, com usuários cadastrados para acesso em áreas do servidor restritas ou ainda usuário anonymous ou mesmo ftp, com senha livre, normalmente o e-mail, para posterior contato. É importante observar que neste processo de autenticação o login/senha trafegam pela rede sem criptografia facilitando assim eventuais infortúnios como a utilização de analisadores de tráfego. Normalmente nos casos onde a autenticação é necessária se emprega servidores de FTP criptografados, sendo o Security Shell - SSH um dos mais populares.

Quando um cliente começa a negociar uma conexão com um servidor FTP, uma porta é escolhida e enviada para posterior conexão. O servidor, por sua vez, recebe a requisição pela porta padrão 20. A resposta do servidor é enviada pela porta 21 endereçada pela porta escolhida pelo cliente. A utilização do conceito de portas permite desta forma, que um mesmo servidor receba várias requisições pois a resposta é endereçada à diferentes portas escolhidas por cada cliente.

Trivial File Transfer Protocol - TFTP

Este protocolo é utilizado principalmente para transferir arquivos de configuração ou mesmo do sistema operacional entre um computador e um equipamento, roteadores, comutadores, bridges, impressoras, etc. A aplicação também é do tipo cliente/servidor sendo normalmente o equipamento o cliente e o computador o servidor. Ao invés de TCP, este protocolo utiliza UDP pois apresenta a possibilidade de acesso, normalmente para configuração, à equipamentos importantes em situações críticas como por exemplo quando um roteador fica inacessível por não suportar mais conexões TCP no caso de um ataque externo.

Servidores de TFTP não possuem autenticação sendo normalmente utilizados através


139

de uma conexão direta na porta serial ou auxiliar do equipamento para garantir confiabilidade e segurança na transferência dos arquivos. Existem várias aplicações TFTP disponibilizadas de maneira compartilhada na Internet.

Telnet

Esta aplicação também do tipo cliente/servidor utiliza o protocolo TCP. É utilizada para conexão remota em computadores para execução de aplicações específicas muitas das vezes desenvolvidas pelo próprio usuário. Também usada para configuração e monitoramento remoto de equipamentos, como roteadores por exemplo. Como não transfere arquivos, é comum a utilização de aplicações FTP ou TFTP em conjunto.

Da mesma forma que o FTP, existe a necessidade de autenticação e portanto todos os problemas relativos a segurança também estão presentes. Da mesma forma, existem aplicações Telnet criptografadas compartilhadas na Internet.

Simple Network Management Protocol - SNMP

Este protocolo utiliza UDP para fazer gerência de equipamentos, sendo o protocolo base de todas as principais plataformas de gerenciamento, CiscoWorks - CISCO, HPOpenView - HP, SunNetManager - SUN, Transcend – 3COM, SCOTTY – TU Braunschweig, MRTG, dentre outras. Sua primeira versão possuía muitas falhas relativas a segurança e portanto era alvo certo dos hackers para invasão às redes. Apesar disto, sua utilização cresceu a ponto de se tornar o protocolo padrão das principais plataformas.

O funcionamento das aplicações está vinculado ao envio/recebimento periódico de mensagens, equipamentos/computadores respectivamente, que contém valores de parâmetros relevantes para monitoramento, análise e posterior configuração por parte dos equipamentos. Estas informações são armazenadas em forma de base de dados chamada Management Information Base – MIB.

É possível configurar as aplicações para que enviem avisos através de e-mails, de sinais visuais e sonoros, Tc, aos gerentes de rede quando situações críticas ocorrerem, como por exemplo a mudança de estado de uma porta de um roteador, nível de tráfego fora dos limites, percentagem de processamento perto do limite, dentre outras.

Outros Protocolos e AplicaçõesExistem vários outros protocolos que pertencem ao grupo TCP/IP dos quais podemos

citar: SMTP, DNS, NFS, HTTP, RIP, Rlogin, X Windows, Packet Internet Groper – PING, Traceroute. Abordaremos rapidamente alguns deles.

Domain Name Server – DNS: também chamada de Name Service, esta aplicação relaciona endereços IP com os seus respectivos nomes atribuídos a dispositivos da rede.

Simple Mail Transfer Protocol – SMTP: este protocolo é utilizado nos serviços básicos de envio de mensagens.

Network File System – NFS: este sistema foi desenvolvido pela Sun Microsystems e permite que computadores possam “montar” discos ou parte deles (diretórios) de dispositivos remotos e operá-los como se fossem locais.

HyperText Transfer Protocol – HTTP: este protocolo é a base do ambiente World Wide Web que basicamente permite a leitura dinâmica e interativa de documentos constituídos de texto, imagens e som.

Routing Information Protocol – RIP: o conceito de roteamento é uma


140

característica presente nos protocolos TCP/IP. O protocolo RIP é utilizado pelos dispositivos da rede, principalmente roteadores, para troca de informações de roteamento.

Dentre aqueles citados, é importante observar que os dois últimos, PING e Traceroute, são muito utilizados no monitoramento de conectividade entre dispositivos TCP/IP. No primeiro é possível o envio de pacotes em número e tamanho variáveis e o recebimento de sua respectiva estatística. O segundo revela o caminho percorrido por um pacote entre os dispositivos origem e destino parametrizado pelo tempo de resposta.

Resumindo ...

TCP/IP não é um protocolo único, é uma coleção de protocolos com arquitetura distribuída em 4 camadas que se distribuem sobre as camadas do modelo OSI: aplicação, host-host, rede e física.

A camada física não é descrita na arquitetura TCP/IP apesar de ser a base para a comunicação entre a aplicação e a rede. O protocolo IP é a base da arquitetura pois atribui endereços lógicos aos dispositivos e às redes e assim consegue definir o caminho para levar os pacotes da origem ao destino.

TCP e UDP são protocolos da camada de transporte e tem como função principal a entrega de dados (segmentos) aos dispositivos destinos. O TCP é um protocolo orientado à conexão e assim garante que os dados cheguem na ordem certa ao seu destino. O UDP ao contrário, é não orientado a conexão e não garante a chegada dos dados ao destino.

A importância do conjunto de protocolos TCP/IP está totalmente ligada ao sucesso da Internet. Estes protocolos, apesar de suas limitações em termos de roteamento, cada vez mais, estão se tornando a base de aplicações que são disponibilizadas e necessárias à Internet.

O sucesso deste conjunto de protocolos implica inclusive no sucesso ou não da aplicação de outras tecnologias de comunicação. Atualmente podemos citar a tecnologia ATM como sendo uma das tecnologias que necessitam de artifícios de software para suportar aplicações IP.

O grande e crescente número de aplicações IP garante uma sobrevida ainda sem previsão de término à este conjunto de protocolos que já entraram para a história das comunicações. Atualmente, “falar TCP/IP” é condição básica para que um dispositivo entre na grande rede.


141

Capítulo 9 - Comandos e arquivos básicos de configuração e administração de

interfaces ethernetEntendidos os conceitos do protocolo TCP/IP, iniciaremos o estudo de comando e

arquivos usados para a configuração das interfaces de redes.

Nesse capítulo, trataremos da configuração da interface ethernet, usando basicamente o editor de textos vi. Por isso, dê uma olhadinha em modos de edição no Vi para facilitar o desenvolvimento dos exercícios.


142


143

Linux e interface ethernet.No sistema GNU/Linux, configurar uma rede é bem simples, porém trabalhoso. Para

que uma estação possa ter acesso a todos os serviços de rede, precisamos definir um ip, seja este estático ou não, informarmos para a estação quem são os servidores DNS e quais rotas deveram ser tomadas para termos acesso a nossa própria rede e redes externas.

Para entendermos melhor isso tudo, montei um roteiro de configuração. Dividido em etapas partiremos do seguinte cenário:

Um host cujo endereço IP estático 135.23.44.56 e máscara de sub-rede 255.255.255.0. O DNS dessa rede será o servidor 135.23.44.254 sendo este também o router de saída.

Para configurarmos um dispositivo ethernet no GNU/Linux, vamos editar o arquivo /etc/sysconfig/network-scripts/ifcfg-eth?. Observe que termino o nome do arquivo com um ? (ponto de interrogação) para que seja observado o número do dispositivo no sistema. Caso tenha apenas uma placa ethernet no sistema, essa será chamada de eth0 e seu arquivo será descrito como ifcfg-eth0. Caso tenhamos duas interfaces, teremos então eth0 e eth1, sendo seus arquivos ifcfg-eth0 e ifcfg-eth1, respectivamente.

Editando o arquivo, teremos :

DEVICE=eth0 ( aqui configuramos qual dispositivo será usado. Note que o dispositivo é exatamente o mesmo descrito no nome do arquivo. Ou seja, ifcfg-eth0, DEVICE=eth0 )

BOOTPROTO=static ( por ser um endereço fixo, estático, o protocolo aqui será static )

BROADCAST=135.23.44.255 ( endereço de broad da rede )

HWADDR=00:0F:20:1E:4C:FB ( endereço MAC do dispositivo ethernet )

IPADDR=135.23.44.56 ( Aqui definiremos o endereço IP do dispositivo. Esse parâmetro só será lido caso o BOOTPROTO esteja static )

NETMASK=255.255.255.0 ( aqui informamos qual máscara de sub-rede será usada )

NETWORK=135.23.44.0 ( a sub-rede da qual o host faz parte )

ONBOOT=yes ( determinamos aqui se a placa será inicializada a cada boot do sistema. )

Na prática, podemos usar apenas 5 ( cinco ) dos parâmetros acima. Enxugando o arquivo teremos...


144

Agora basta reinicializar o dispositivo para que as alterações sejam “carregadas”, para isso, edite o comando :

Em um segundo momento se faz necessário que este dispositivo tenha seus endereços carregados via servidor DHCP. Para isso, basta retirar o BOOTPROTO=static e inserir o BOOTPROTO=dhcp. Quando o BOOTPROTO for igual a dhcp, os parâmetros IPADDR e NETMASK serão ignorados. O arquivo terá então o formato

Retirando o que não é necessário, teremos ...

Apenas configurar o ifcfg-eth? Não significa que o trabalho acabou. Precisamos ainda definir quem será o DNS responsável. Para isso vamos ao arquivo /etc/resolv.conf. Veja como fica o arquivo.


145

No resolv.conf basta determinarmos o search com um domínio de rede e o nameserver com o IP do servidor DNS.

Para finalizarmos essa etapa, vamos determinar o GATEWAY da rede. Para isso, uma editada no arquivo /etc/sysconfig/network.

Aqui teremos o parâmetro NETWORK, que determinará se nosso sistema terá ou não o dispositivo de rede ativado, em seguida o HOSTNAME que é o “nome da máquina” e o GATEWAY que servirá de router para o host. Antes de continuarmos, vamos entender um pouco do conceito de GATEWAY.

Gateway é um computador que estará ligado fisicamente a duas ou mais redes, interligando – as. Observe que na figura acima, temos três subredes diferentes com três gateways ligados a uma subrede que chamarei de Backbone de interligação. Qualquer máquina da rede 2.0 que queira trocar algum tipo de informação com máquinas da rede 4.0, terá que solicitar ao gateway como chegar a outra subrede.

Feito isso, reinicie o serviço de rede do sistema. Pronto sua máquina está na rede.

Configurar uma interface realmente é simples, mas como administrarmos e quais comando poderemos usar para trabalharmos com redes no GNU/Linux ? Passe para a próxima etapa.

Para resolvermos nomes de hosts locais, configuramos o arquivo /etc/hosts. Nele


146

informamos o IP, Hostname e Apelido para os hosts locais. Veja como fica

Porém, para que hosts seja lido, precisamos definir em /etc/host.conf a ordem de busca de resolução de nomes. Veja um modelo de /etc/host.conf, primeiro buscando no arquivo /etc/hosts e depois através de um DNS o nome de hosts.

Uma forma de customizar a procura de nomes, é usar p modelo melhorado de host.conf, o arquivo nsswitch.conf. Nele poderemos configurar um mecanismo de busca para cada serviço.

Veja um modelo para o mesmo caso do host.conf.

Comandos de redes GNU/Linux.Nesse capítulo estaremos estudando os comandos mais comuns para a

administração de rede no GNU/Linux, dando condições para o aluno administrar o sistema sem grandes transtornos.

Vamos começar então.

ifconfigDescrição: O ifconfig é usado para configurar, ativar ou desativar um dispositivo de

redes.


add Adiciona um novo endereço IP ao dispositivo.

up Ativa o dispositivo ethernet

down Desativa o dispositivo ethernet

hw Define um novo endereço MAC para o dispositivo.

netmask Define o netmask do dispositivo.

Exemplos:

#ifconfig eth0 10.22.3.1 netmask 255.255.255.0 up

#ifconfig eth0 add 192.168.1.1 netmask 255.255.255.0


147

#ifconfig eth0 down

#ifconfig eth0 up

#ifconfig eth0 hw ether 00:00:00:00:00:00

arp

Descrição: Manipula o cache ARP do sistema


-v Mostrar de forma detalhada ao usuário o que está acontecendo

-n Mostra endereços numéricos. Não tenta determinar os nomes de de máquina, porta e usuário.

-H type, --hw-type type Informa ao arp que classe de entradas devem ser verificadas. Os tipos de classe podem ser ether, ARCnet (arcnet) , PROnet (pronet) , AX.25 (ax25) e NET/ROM (netrom)

-a [host], --display [host] Mostra as entradas dos hosts especificados. Caso não seja informado um host, serão mostradas todas as entradas.

-d [host], --delete host Remove qualquer entrada para o host especificado.

-D, --device Usa o MAC do dispositivo.

-i, --use-device Especifica uma interface.

-s host MAC, --set máquina Cria manualmente a entrada ARP para o host através MAC.

-f arquivo, --file arquivo Tem o mesmo efeito da opção -s, porém as informações de endereços são obtidas de um arquivo.

Exemplos:

#arp -v

#arp -a ip


148

digDescrição: Consulta servidores DNS.

Argumentos Descrições

servidor Nome ou IP do servidor DNS

nome Nome do host a ser resolvido

tipo Tipo de consulta a ser executada.

classe Classe da consulta. Podemos ter IN ( Default ), INTERNET, CS, CSNET, CH, CHAOS, HS, HESIOD, ANY, *

Opções Descrições

-b endereço IP do DNS

-f arquivo Arquivo com listagem de consultas. O arquivo terá em cada linha uma nova entrada.

-p Posta de consulta – Padrão 53

-x Consultas através do reverso do DNS, ou seja, Ips para nomes.

Exemplos:

#dig www.x25.com.br

#dig -f arquivo_lista

ifup

Descrição: Carrega um dispositivo ethernet.

Exemplos:

#ifup eth0

ifdown

Descrição: Derruba um dispositivo ethernet

Exemplos:

#ifdown eth0

route

Descrição: Manipula a tabela de roteamento.


-n Mostra os endereços numéricos.

-e Usa o formato netstat de apresentação. Com o -ee, temos uma linha com todas as informações da tabela de roteamento.

-net Define a rede alvo de roteamento.


http://www.x25.com.br/

149

-host Define um host como alvo de roteamento.

del Remove uma rota

add Adiciona uma rota

host/network Máquina ou rede alvo da rota

netmask Máscara de sub-rede do alvo

gw Define o GATEWAY da rede. Todos os pacotes para a rede destino ( alvo ) serão roteados pelo gw.

reject Instala uma rota de de bloqueio.

Exemplos:

#route add -net 192.168.1.1

#route add -net 199.43.76.0 netmask 255.255.255.0 dev eth0

#route add -net 192.130.0.0 netmask 255.255.0.0 dev eth0

dhclientDescrição: Configura um endereço ip via servidor dhcp

Exemplos:

#dhclient


150

hostnameDescrição: Configura / mostra corretamente o nome do host.


-a, --alias Mostra o alias da máquina, se usado.

-d, --domain Mostra o nome do domínio. Não use o domainname para obter o domínio do host. Ele trará o nome do domínio NIS.

-F, --file O nome do host será lido a partir de um arquivo.

-i, --ip-address Mostra o endereço ip do host

-s, --short Mostra o nome curto do host.

-v, --verbose Saída com informações detalhadas da execução.

Exemplos:

#hostname –alias

#hostname -f

#hostname -i

#hostname -s

#hostname -sv

#hostname -siv

netstatDescrição: Mostra as conexões de rede, assim como tabelas de roteamento,

estatística de interfaces e conexões mascaradas.


-r, --route Mostra informações da tabela de roteamento, no mesmo formato usado pelo route -e

-i, --interface Mostrará informações das interfaces ou interface especificada será mostrada no formato ifconfig -e.

-M, --masquerade Exibirá todas as sessões mascaradas.

-s, --statistics Mostra estatísticas de rede do Linux. As informações serão lidas a partir de /proc/net/snmp.

-v, --verbose Mostra de forma detalhada o que está acontecendo.

-n, --numeric Mostra endereços numéricos.


151

-A, --af Usa métodos diferentes para configurar a família de endereços. Podemos ter, separados por vírgula, inet, unix, ipx, ax25, netrom e ddp. O mesmo que usar --inet, --unix, --ipx, --ax25, --netrom e –ddp.

Exemplos:

#netstat -s

#netstat -n

ping

Descrição: Envia ICMP echo_request para hosts de uma rede.


-a Soa um bip a cada pacote “pingado”

-b Permite o ping em um endereço de broadcast

-s Especifica o tamanho do pacote em um ping.

-t Especifica a ttl do pacote.

-v Roda em modo verbose, detalhando a execução para o usuário.

Exemplos:

#ping -s 1024 192.169.1.4

traceroute2.

Descrição: Imprime a rota de um pacote.


-f Especifica com qual ttl será usada para iniciar o serviço. O padrão é 1.

-i Especifica qual interface será usada para execução.

-m Especifica o máximo de saltos que serão exibidos.

-p Especifica a porta que será usada para execução do trace.

Exemplos:

#traceroute -m 4 www.x25.com.br

#traceroute -f 4 www.x25.com.br




152

Comandos de redes GNU/Linux.Existem algumas maneiras de melhorar o comportamento da rede. Vamos ver

algumas maneiras de, por exemplo, o ping e rejeitar algumas rotas, usando comandos simples como o route e arquivos no /proc/sys.

Eliminando rotas Um forma interessante de trabalharmos com o roteamento do sistema é eliminando a

possibilidade de acesso de rotas não desejadas.

No exemplo abaixo, a rede 192.43.224.0 / 24 será negada pela rede 192.43.0.0/16.

#route add -net 192.43.224.0 netmask 255.255.255.0 reject

através do comando route podemos visualizar como ficou a tabela de roteamento.

Destino Roteador MáscaraGen Opções Métricas Ref Uso Iface

192.43.224.0 - 255.255.255.0 ! 0 - 0 -192.43.0.0 192.43.1.4 255.255.0.0 UG 0 0 0 eth0

Observe que a rota para a 192.43.224.0 está negada.

Negando pacotes ...Outra forma de usarmos o próprio sistema para gerar algumas regras é usar o

/proc/sys/net/ipv4.

Veja os exemplos :

#echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

Aqui, negamos os pings para essa estação.

#echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Aqui negamos os pings de broadcast da rede.

Essas são situações que podem ajudar a melhorar o comportamento do sistema.

Alguns serviços de redes

Uma da grandes vantagens do GNU/Linux, em minha opinião, é a facilidade de acessarmos arquivos remotamente. Vejamos alguns exemplos.

#wget www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.4.tar.bz2

No exemplo acima, faremos um download de um arquivo usando o wget.

Para copiarmos um arquivo de uma estação Linux para outra podemos usar o scp. Este comando dependo do ssh ativo na estação onde estão os arquivos.

#scp [email protected]:/root/pai.sh .

Entre com a senha de root para autenticar e pronto... arquivo copiado.

Outra possibilidade é usarmos o serviço NFS para montarmos partições de uma estação para outra. Aqui sim estaremos compartilhando arquivos.

Para configurarmo um compartilhamento, editamos o arquivo /etc/exports, veja o


http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.4.tar.bz2

153

exemplo.

/desenvolvimento (rw,no_root_squash)

Nele determinamos qual o diretório a ser exportado ( compartilhado ), quem e qual o nível de acesso aos arquivos.

Em outra estação GNU/Linux, monte o compartilhamento da primeira estação da seguinte forma

#mount -t nfs <host:/compartilhamento> <ponto_de_montagem_local>

Depois de montado, bom trabalho.

Durante muito tempo percebi que a maioria de meus alunos tem a necessidade de resultados imediatos. Durante os primeiros módulos do curso de Linux, aquela parte de administração de sistemas, comandos que dão dores de cabeça só em pensar neles, conceitos de protocolos, arquivos para configurar isso e aquilo, poucos conseguem entender a importância dessa etapa.

Antes de irmos aos serviços, vamos tentar imaginar essas aplicações muito bem configuradas, com o que há de mais interessante e complexo em sua utilização. Seria o grande momento de um administrador, concordam ?

Agora imaginem essa mesma aplicação, configurada com o que há de mais interessante instalado em um GNU/Linux com o kernel instável e pouco confiável, seria o inferno na vida de quem estiver administrando esse serviço. Se pensarmos em servidores como aplicações que serão usadas para dispor de algo para um conjunto de máquinas, o primeiro passo para colocá-lo no ar é pensar em termos um sistema estável e totalmente confiável. Ou seja, vamos ter que pensar primeiro no kernel, na instalação e preparação do sistema voltado para a aplicação que iremos dispor.

Nessa etapa do curso adotaremos essa linha de pensamento. Iremos nos preocupar com o funcionamento dos serviços que iremos configurar. Portas e módulos usados serão nosso foco, as configurações necessárias será o apenas o mecanismo que usaremos para fazer funcionar de acordo com nossas necessidades.

Então vamos lá, começar estudando alguns servidores necessários para a maioria das empresa.


154


155

Capítulo 10 - Servidor DNS ( Domain Name Server )

O serviço de resolução de nomes acredito ser um dos mais intrigantes pela sua organização e atuação em quase 100 % dos mecanismos de interação existentes hoje em dia. Imagine querer acessar seu sistema bancário ou seu e-mail sem este serviço. Ou imagine querer apenas ver as fotos das férias passadas que estão no site pessoal da família.

Seria realmente algo bem complicado. Precisaríamos de uma agenda bem grande e organizada para termos todos os endereços IP e ao lado deles a descrição ou o nome relacionado com este endereço.

Para isso foi criado o DNS – Domain Name Server. Ele é nossa agenda mundial onde encontraremos os endereços para acesso aos sites “publicados”.

Nesse capítulo, nosso foco será o entendimento do serviço. Entendo que só conseguimos determinar o funcionamento de algo que entendemos. Por isso estudaremos o funcionamento, requisitos e algumas dicas para configurar o serviço de resolução de nomes.

Então vamos ao que interessa !!!!


156


157

O Serviço de Resolução de Nomes – DNSVeremos aqui o funcionamento do pacote BIND, o serviço de resolução de nomes e

sua relação com este pacote.

Fundamentos do DNS

Existem várias maneiras para conversões de nomes em endereços. Uma delas é configurar o arquivo /etc/hosts, muito útil em redes pequenas, mantidas por uma equipe realmente organizada ou uma única pessoa e não mantém necessidade de saída para o mundo exterior.

Outra saída é a utilização de um servidor BIND – Servidor DNS da Berkeley. Com ele podemos mapear nomes dos servidores para endereços IP. Como tudo, podemos enfrentar certa dificuldade para configurar o nosso primeiro servidor, porém, depois de feito as alterações ficam simples.

O Domain name server é uma hierarquia distribuída de base de informação. Nela estarão armazenadas mapeamentos de nome de hosts com seus endereços IP e vice-versa, informações de rotas de e-mail e outras informações usadas por aplicativos de Internet. Os clientes enviarão uma pesquisa por biblioteca resolv para um ou mais servidores DNS e interpretará a resposta.

Requisitos de sistema.

Para configurarmos um servidor DNS não precisamos de muito, observe os requisitos necessários abaixo.

Hardware

Não precisamos de muito para rodar o serviço DNS, uma máquina modesta poderá nos atender plenamente para configurações mais simples até configurações mais personalizadas do serviço.

Processador

Um i486-class pode servir para um servidor com zonas estáticas sem caching.

Memória RAM

A opção max-cache-size pode ser usado para limitar o uso de memória no serviço DNS.

Sistemas operacionais suportados

• IBM AIX 4.3

• Compaq Digital/Tru64 UNIX 4.0D

• Compaq Digital/Tru64 UNIX 5 (with IPv6 EAK)

• HP HP-UX 11

• IRIX64 6.5

• Sun Solaris 2.6, 7, 8


158

• NetBSD 1.5 (with unproven-pthreads 0.17)

• FreeBSD 3.4-STABLE, 3.5, 4.0, 4.1 e posteriores

• Red Hat Linux 6.0, 6.1, 6.2, 7.0 e posteriores

Instalação do BINDPara instalarmos o pacote BIND, podemos usar algumas das etapas abaixo.

#apt-get install bind*

#yum install bind*

#rpm -ivh bind*.rpm

#dpkg -i bind*.deb

Configurando o Nameserver

Sendo o serviço responsável pelo famoso servidor DNS, Domain Name Server, o named está dividido em duas etapas.

1. Declaração dos domínios que serão “resolvidos” por ele (Arquivo /etc/named.conf);

2. Configuração dos domínios declarados, (Arquivos encontrados em /var/named/chroot/var/named ou somente /var/named).

Vimos anteriormente que é necessário ainda um conjunto de configurações para fazermos nossa máquina resolver nomes. Isso também é necessário no servidor. Configurações do /etc/resolv.conf e /etc/host.conf são necessárias aqui, além do hostname da máquina.

Vamos aos arquivos então.

/etc/named.conf

É neste arquivo que definimos os domínios que serão “resolvidos” pelo nosso servidor. O mesmo é dividido em 3 partes, o options { < configuração > }, zone “domínio” IN { < configuração > } e zone "reverso.in-addr.arpa." IN { < configuração > }.

A primeira parte, é responsável por informações sobre o funcionamento do sistema, locais onde os arquivos dos domínios serão gravados, dentre outras informações. A segunda parte, é onde declaramos o domínio e seu arquivo de referência e a terceira é a configuração do reverso do domínio.


159

#vim /etc/named.conf

options {

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

query-source address * port 53;

max-cache-size 200

};

zone "lps.com.br" IN {

type master;

file "lps.zone";

allow-update { none; };

};

zone "241.200.10.in-addr.arpa." IN {

type master;

file "lps.rev";

allow-update { none; };

};

include "/etc/rndc.key";

#vim /var/named/lpn.zone

$TTL 86400

@ IN SOA nsrv.lps.com.br. root.nsrv.lps.com.br. (

42 ; Serial

8H ; Atualizar

2H ; Tentativas

1W ; Expiração

1D ) ; TTL mínimo

IN NS nsrv.lps.com.br. ; servidor responsável pelo Name Server.

IN MX 10 mail.lps.com.br. ; servidor de e-mail do domínio.

IN MX 5 mail2.lps.com.br. ;servidor de e-mail do domínio.

nsrv IN A 10.200.241.122 ; aqui declaramos os endereços ip para cada máquina que responda por algo no domínio.

mail IN A 10.200.241.123


160

mail2 IN A 10.200.241.124

web IN A 10.200.241.125

www IN CNAME web.lps.com.br. ; CNAME nos permite resultados de busca como www.domínio.com.br.

#vim /var/named/lpn.rev

$TTL 86400

@ IN SOA nsrv.lps.com.br. root.nsrv.lps.com.br. (

42 ; Serial

8H ; Atualizar

2H ; Tentativas

1W ; Expiração

1D ) ; TTL mínimo

IN NS nsrv.lps.com.br.

122 IN PTR nsrv.lps.com.br. ; Aqui informamos os endereços IP de cada estação usada para responder por algo no domínio.

123 IN PTR mail.lps.com.br.

124 IN PTR mail2.lps.com.br.

125 IN PTR web.lps.com.br.

Não deixa de colocar os pontos ao final de cada linha, como demonstrado acima. Elas fecham a informação do domínio, impedindo resultados do tipo www.dominio.com.br.dominio.com.br, ou seja duplicação do domínio.

Após configurar, levante o serviço, como demonstrado abaixo.

#/etc/rc.d/init.d/named restart

Para testarmos nossa configuração, o comando dig ou o nslookup nos serão úteis. Vamos aos exemplos.

#nslookup

>set q=any

>www.uol.com.br


http://www.uol.com.br/

http://www.dominio.com.br.dominio.com.br/

161

Capítulo 11 - O SAMBA – Servidor Compartilhamento GNU/Linux Windows

Um dos mecanismos mais usados para estruturar redes MS-Windows, o serviço samba se demonstra eficaz em suas atribuições. Usando os protocolos SMB e NMB e sobre as portas nos serviços NetBIOS sobre a porta TCP 139, SMB sobre TCP/IP porta TCP 445 para sessões de serviços e compatível com os serviços ONC DCE RPC sobre a porta TCP 135.

Para melhor entendimento, vamos partir para a configuração do servidor, assim poderemos discutir melhor alguns conceitos.

Vamos buscar algumas particularidades de situações cotidianas.


162


163

InstalaçãoO processo de instalação do samba é bem simples, veja nas linhas de comando

abaixo como o faríamos usando os pacotes .rpm e .deb.

#rpm -ivh samba-versão.rpm

#dpkg -i samba-versão.deb

#yum install samba*

#apt-get install samba*

Respeitadas as dependências, o sistema deverá ser instalado corretamente.

ConfiguraçãoO arquivo de configuração do samba está dividido em duas partes. A primeira, está

identificada como [global], nela definimos o comportamento do serviço. A segunda, [share], é onde definimos os compartilhamentos do servidor. Observe o arquivo abaixo.

[ global ]

O parâmetro workgroup determina o domínio da rede local.

workgroup = intralps

A linha server string, conterá uma descrição do servidor.

server string = Servidor Samba (descrição do servidor)

O parâmetro os level, determina a procedência do servidor no processo de eleição de navegação. Trocando em miúdos, garante que o servidor seja prioritário em relação aos outros servidores da rede.

os level = 33

As próximas 3 linhas definem o servidor como master do domínio. A opção preferred master força a eleição do servidor como master do domínio. Caso não queira que o servidor samba seja o master da rede, defina no na opção local master. Caso tenha um servidor windows como controlador do domínio, defina no na opção domain master.

preferred master = yes

domain master = yes

local master = yes

A linha security determina o comportamento do servidor em relação ao acesso de usuários. A opção user obriga o usuário a logar – se no sistema para ter acesso aos compartilhamentos. Se for informado ao sistema a opção share, o sistema irá compartilhar arquivos sem a necessidade de log do usuário.

security = user

Caso existam estações windows 95, use a opção domain logons.

domain logons = yes


164

Especifique com a opção logon script, qual o formato de nome do script de log do usuário. No exemplo abaixo, determino que para cada usuário existirá um script com seu login.

logon script = %U.bat

Compartilhar arquivos no samba é simples. Veja o exemplo abaixo.

A linha [desenv] determina o nome do compartilhamento. Muito cuidado com os nomes de compartilhamentos, nomes muito grande podem causar problemas.

[ desenv ]

path recebe o caminho do diretório que será compartilhado.

path=/empresa/compartilhamentos/desenvolvimento

read only determina se no compartilhamento poderá ou não ser gravado arquivos.

read only = yes

valid users determina quais usuários poderão acessar o compartilhamento. Note que uso o @ para determinar um grupo.

valid users = @desenv

Note que o arquivo possui apenas as informações necessárias para torná-lo master da rede. Para o funcionamento do servidor, basta alterar o parâmetro workgroup, definindo o domínio da rede.

Outra forma de configurar o servidor samba está descrita abaixo, aqui usaremos apenas a possibilidade de compartilhamento, sem a necessidade de login de rede.

[global]

workgroup = intralps

security = share

printing = CUPS

printcap name = CUPS

disable spoolss = Yes

show add printer wizard = Nowins

support = yes

[rh]

comment = RH Compartilhamento

Filespath = /data/rh

read only = No

Note que temos aqui a opção force group. Nela determinamos qual o grupo de referência de cada um dos arquivos criados no compartilhamento, garantindo o acesso de todos os membros do grupo ao mesmo.

force group = rh


165

[base]

comment = Reposiorio da BD

path = /data/dbrepositorio

read only = No

force user = clayton

force group = db

[printers]

comment = Print Temporary Spool Configuration

path = /var/spool/samba

printable = Yes

guest ok = Yes

use client driver = Yes

browseable = No

Nesse caso apresentado, não há muitas regras de acesso, o samba foi configurado apenas para compartilhar arquivos, definido pelo uso do share no parâmetro security.

Um arquivo geral do samba seria descrito como abaixo. Segundo os criadores do serviço, o samba foi projetado para ter o melhor da performance, por isso devemos alterar o mínimo possível as configurações.

# Global parameters

[global]

workgroup = lpsnet

netbios name = PDC-SRV

security = user

Algo que devemos ter muito cuidado durante o processo de configuração do servidor samba é na determinação de qual interface aceitará solicitações de clientes. Caso não seja especificado, o servidor aceitará de qualquer interface nele configurado solicitações clientes, fazendo com que o controle de acesso seja prejudicado.

interfaces = 192.168.5.11

#username map = /etc/samba/smbusers

server string = Samba Server %v

#security = ads

encrypt passwords = Yes

min passwd length = 3

Na linha acima informo qual o número mínimo de caracteres por senha.

#pam password change = no

#obey pam restrictions = No

#ldap passwd sync = Yes


166

unix password sync = Yes

passwd program = /opt/IDEALX/sbin/smbldap-passwd -u %u

passwd chat = "Changing password for*\nNew password*" %n\n "*Retype new password*" %n\n"

#passwd chat debug = Yes

log level = 0

syslog = 0

log file = /var/log/samba/log.%m

max log size = 100000

time server = Yes

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

mangling method = hash2

Dos charset = 850

Unix charset = ISO8859-1

logon script = logon.bat

logon drive = H:

logon home =

logon path =

domain logons = Yes

domain master = Yes

os level = 65

preferred master = Yes

wins support = yes

Abaixo teremos as configurações para autenticação no servidor LDAP. Como não é escopo deste treinamento, não entraremos em detalhes a respeito dos mecanismos de integração entre o LDAP e o Samba.

passdb backend = ldapsam:ldap://127.0.0.1/

ldap admin dn = cn=Manager,dc=idealx,dc=org

ldap suffix = dc=idealx,dc=org

ldap group suffix = ou=Groups

ldap user suffix = ou=Users

ldap machine suffix = ou=Computers

add user script = /opt/IDEALX/sbin/smbldap-useradd -m "%u"

#ldap delete dn = Yes

delete user script = /opt/IDEALX/sbin/smbldap-userdel "%u"

add machine script = /opt/IDEALX/sbin/smbldap-useradd -t 0 -w "%u"

add group script = /opt/IDEALX/sbin/smbldap-groupadd -p "%g"


167

#delete group script = /opt/IDEALX/sbin/smbldap-groupdel "%g"

add user to group script = /opt/IDEALX/sbin/smbldap-groupmod -m "%u" "%g"

delete user from group script = /opt/IDEALX/sbin/smbldap-groupmod -x "%u" "%g"

set primary group script = /opt/IDEALX/sbin/smbldap-usermod -g '%g' '%u'

# printers configuration

printer admin = @"Print Operators"

load printers = Yes

create mask = 0640

directory mask = 0750

#force create mode = 0640

#force directory mode = 0750

nt acl support = No

printing = cups

printcap name = cups

deadtime = 10

guest account = nobody

map to guest = Bad User

dont descend = /proc,/dev,/etc,/lib,/lost+found,/initrd

show add printer wizard = yes

; to maintain capital letters in shortcuts in any of the profile folders:

preserve case = yes

short preserve case = yes

case sensitive = no

A partir daqui teremos os compartilhamentos do servidor. O padrão seria o mesmo que apresentado nos exemplos anteriores.

[netlogon]

path = /home/netlogon/

browseable = No

read only = yes

[profiles]

path = /home/profiles

read only = no

create mask = 0600


browseable = No

guest ok = Yes


168

profile acls = yes

csc policy = disable

# next line is a great way to secure the profiles

#force user = %U

# next line allows administrator to access all profiles

#valid users = %U "Domain Admins"

[printers]

comment = Network Printers

printer admin = @"Print Operators"

guest ok = yes

printable = yes

path = /home/spool/

browseable = No

read only = Yes

printable = Yes

print command = /usr/bin/lpr -P%p -r %s

lpq command = /usr/bin/lpq -P%p

lprm command = /usr/bin/lprm -P%p %j

# print command = /usr/bin/lpr -U%U@%M -P%p -r %s

# lpq command = /usr/bin/lpq -U%U@%M -P%p

# lprm command = /usr/bin/lprm -U%U@%M -P%p %j

# lppause command = /usr/sbin/lpc -U%U@%M hold %p %j

# lpresume command = /usr/sbin/lpc -U%U@%M release %p %j

# queuepause command = /usr/sbin/lpc -U%U@%M stop %p

# queueresume command = /usr/sbin/lpc -U%U@%M start %p

[print$]

path = /home/printers

guest ok = No

browseable = Yes

read only = Yes

valid users = @"Print Operators"

write list = @"Print Operators"

create mask = 0664



169

Após configurado, basta criarmos os usuários do sistema samba, para isso...

#useradd -s /bin/false -d /work/usuarios/clayton clayton

#smbpasswd -a clayton

4. Arquivos .bat - NETLOGON.

Agora crie o arquivo de netlogon para os usuários, com esse arquivo, será montado na máquina cliente os compartilhamentos definidos para o usuário. Sempre interessante que após edição dos arquivos .bat, em ambiente linux, que se use o comando unix2dos arquivo.bat, convertendo o mesmo para o padrão do windows. Assim, evitamos problemas com a execução das montagens do sistema.

Veja o exemplo abaixo...

#vim /netlogon/clayton.bat

@echo off

echo Empresa LPS

echo Logon script padrao para a rede.

echo net time \\servidor /set /yes

if %OS%.==Windows_NT. goto WinNT

:WinNT

# net use drive_no_cliente: \\servidor\compartilhamento

net use m: \\200.241.1.138\treinamento /persistent:no

net use y: \\200.241.1.138\linux /persistent:no

net use n: \\200.241.1.138\informatica /persistent:no

if errorlevel<>0 pause

:end

Tudo configurado e nada funcionando. Essa é uma dura realidade do samba. Enquanto muitos administradores se preocupam com as configurações do arquivo /etc/smb.conf, esquecem-se que nada funcionará corretamente se as relações entre usuários, grupos e arquivos não estiverem corretas. Note que nos compartilhamentos definimos com o parâmetro valid users quem teria acesso ao compartilhamento e será usado normalmente um grupo, descrito com o prefixo @, como no exemplo valid users = @suporte. Durante o processo de solicitações dos usuários ao servidor samba, o serviço irá “questionar” junto ao sistema se o usuário é membro do grupo de referência do arquivo. Por isso, só conseguimos criar um usuário para o servidor samba, se o mesmo existir de alguma forma como usuário do sistema, mesmo que este não tenha acesso a uma console ou qualquer outro mecanismo de interação que não seja o servidor samba.

Conclusão de tudo... Não basta conhecer a fundo cada opção do arquivo de configuração do samba se não definir corretamente a relação dos usuários, seus grupos e o acesso aos arquivos. Por isso, antes de pensar em configurar o samba, preocupe-se em organizar corretamente sua estrutura de arquivos.


170


171

Capítulo 12 - SQUID – Proxy Firewall em Layer 7 ?

Durante muito tempo o servidor squid foi considerado um mero proxy para a grande maioria das pessoas.

Respondendo na porta 3128, como padrão, o sistema irá restringir de forma mais simples o acesso a conteúdos na internet, através de recursos como bloqueios de palavras, sites, domínios.

Estudaremos o squid em duas etapas. Na primeira, iremos determinar uma configuração simples do serviço, com alguns poucos bloqueios e nenhuma preocupação com o uso da banda de internet.

No segundo momento, um modelo de aquivo para o uso de recurso de bloqueios e controles de banda, taxas de download dentre outras configurações será apresentado.


172


173

Instalação do SquidPodemos instalar o pacote de várias maneiras. As mais comuns seriam o uso de

pacotes rpm, deb ou as ferramentas apt-get ou yum, como demonstrado abaixo.

#rpm -ivh squid*.rpm

#dpkg -i squid*.deb

#yum install squid*

#apt-get install squid*

Existe ainda a possibilidade da instalação ser feita a partir do código fonte da aplicação - processo chamado de compilação - algo nem sempre simples e nem tão pouco de fácil entendimento. O grande problema é determinar a necessidade de compilação, haja vista que o sistema estará pronto para atender mais de 90% das necessidades da maioria dos usuários.

Se pensarmos em squid como apenas um filtro de acesso a conteúdos, a simples instalação via pacotes será suficiente. Porém, se pensarmos em squid como um controlador de uso de recursos, restringindo acessos e checando requisições através de mac-address, por exemplo, a saída será a compilação.

Para compilarmos o serviço, baixe o fonte do site www.squid-cache.org, descompacte e compile como demonstrado abaixo.

#links www.squid-cache.org

#tar -zxvf squid-*.tar.gz

#cd squid-*

#./configure --prefix=/usr –sysconfdir=/etc/squid\

--libexecdir=/usr/lib/squid –infodir=/usr/share/info\

--mandir=/usr/share/man –enable-delay-pools\

--enable-useragent-log –enable-cachemgr-hostname=clayton\

--enable-arp-acl –enable-default-err-language="Portuguese"\

--enable-underscores --disable-htcp –disable-internal-dns\

--enable-cache-digests

#make

#make install

Para maiores informações sobre as possibilidades de compilação, use o ./configure –help.

Após a compilação, devemos verificar se os pacotes foram realmente gravados nos locais definidos pelos parâmetros prefix, sysconfdir, infodir, libexecdir, mandir. Caso esses parâmetros não sejam usados, será criado uma estrutura para o squid em /usr/local.

Após a instalação do sistema, é importante conhecer o equipamento que estamos usando para poder determinar configurações refinadas para prover melhores performances.


http://www.squid-cache.org/

174

Arquivo de configuração – Squid limitando acesso por arquivo reject, segmentando banda por delay_pools e restringindo o volume de download com reply_body_max_size 500 allow all

# Squid normally listens to port 3128

O primeiro passo é determinarmos a porta na qual o servidor irá responder. Observe que mantive o padrão 3128, porém , poderíamos ter alterado para outros valores como 8080, por exemplo.

http_port 3128

Aqui determinamos o quanto de memória será usado para cache do servidor. É sempre interessante termos um volume alto para cache em memória, quanto mais memória, em tese, melhor será a performance na resposta da aplicação para o cliente.

cache_mem 1000 MB

Neste momento determinamos os valores de cache considerados baixo e alto. No exemplo abaixo mantenho novamente o padrão de 90% para cache baixo e 95% para cache alto.

cache_swap_low 90

cache_swap_high 95

As linhas seguintes geram um pouco de dúvida para as pessoas que estão iniciando no processo de administração do sistema. Aqui determinamos o tamanho máximo e mínimos que poderemos fazer cache no servidor e quanto será o volume máximo de um objeto em memória.

maximum_object_size 4096 KB

minimum_object_size 0 KB

maximum_object_size_in_memory 8 KB

ipcache_size 1024

ipcache_low 90

ipcache_high 95

Na linha abaixo, temos toda a estrutura dos diretórios que serão usados para cache do sistema. Determinamos aqui que teremos o diretório onde será criada a estrutura de cache </var/spool/squid>, o espaço máximo em disco que será usado para cache. Havendo um “estouro” desse espaço, os objetos serão repostos. Em seguida temos o número de diretórios e subdiretórios que serão criados para montar a estrutura de cache em disco. Se passarmos com parâmetro o valor max-size, determinaremos o tamanho máximo de objeto na estrutura.

cache_dir ufs /var/spool/squid 100 16 256

access_log /var/log/squid/access.log squid

cache_log /var/log/squid/cache.log

cache_store_log /var/log/squid/store.log

Nessa etapa declaramos os endereços das subredes tratadas pelo servidor, horários de acesso, listas de acesso ou negação. Note que falei declaração. Não é na estrutura de acl que determinamos se determinado endereço terá ou não acesso . Isso é feito pelo http_access, as acls apenas declaram uma informação para que o servidor tenha como interpretar no momento de negação ou aceitação de uma determinada conexão.


175

O padrão de declaração de uma acl é bem simples. Teremos a estrutura iniciada por acl, palavra reservada, em seguida o nome da acl, o qual será usado para referenciar valores ao servidor, após o nome teremos o tipo de acl que iremos usar. Existe uma lista bem vasta de acls que podem ser usadas, para conhecer mais sobre os tipos leia o arquivo de configuração do squid. Por último, temos o valor da acl declarada.

Em grande parte dos servidores instalados teremos algumas acls como a base de configuração dos mesmos, são elas.

src – determina um endereço de host ou subrede no padrão ip/netmask

time – determina a hora

url_regex -i – usada para determinar o tratamento de palavras, principalmente em um arquivo, passado com o uso do caminho absoluto. No exemplo usamos duas acls, uma para determinar a rede e outra para informarmos um arquivo que será usado como base de “pesquisa” para o squid.

acl all src 0.0.0.0/0.0.0.0

acl rede 192.168.1.0/255.255.255.0

acl recusados url_regex -i "/etc/squid/recusados"

acl comercialm time MTWHF 8-11:59

acl comercialt time MTWHF 13:59-18

Na linha seguinte determinamos o número máximo permitido por usuário.

acl maxconn 1

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl to_localhost dst 127.0.0.0/8

acl SSL_ports port 443 563

acl Safe_ports port 80 # http

acl Safe_ports port 21 # ftp

acl Safe_ports port 443 563 # https, snews

acl Safe_ports port 70 # gopher

acl Safe_ports port 210 # wais

acl Safe_ports port 1025-65535 # unregistered ports

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 488 # gss-http

acl Safe_ports port 591 # filemaker

acl Safe_ports port 777 # multiling http

acl CONNECT method CONNECT

http_access allow manager localhost

http_access deny manager

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports


176

Falei anteriormente que o responsável pelas negações do serviço é o http_access. Abaixo temos o tratamento das acls criadas. Note que por padrão o valor all, padrão do sistema, sempre negando o acesso a redes não declaradas.

A rede que criamos está com seu acesso aceito, exceto para materiais com conteúdos que contenham uma das palavras ou sites da acl recusados.

http_access allow localhost

http_access deny comercialm rede

http_access deny comercialt rede

http_access allow rede !recusados

http_access deny all

http_reply_access allow all

icp_access allow all

Na linha abaixo determinamos o valor máximo permitido para download.

reply_body_max_size 500 allow all

Aqui começa realmente o que há de interessante no squid. Iremos usá-lo como segmentador de banda, para isso usaremos o valor delay_pools. Não esqueça de compilar o squid e habilitar os valores para delay_pools.

Vamos determinar 3 situações típicas de uma rede empresarial.

1. Precisamos determinar uma largura para acesso de uma subrede da empresa, sem afetar o comportamento do restante da empresa;

2. Precisamos determinar valores individuais para acessos;

3. Determinaremos valores para uma determinada subrede e nesta, valores individuais para hosts que a compõe.

Essas são as informações necessárias para configurarmos o comportamento das bandas pelo squid. chamamos esses comportamentos de classes e as dividimos em classe 1, classe 2 e classe 3 , como descrito no parágrafo anterior.

Como primeira tarefa, determine o valor em bytes para a banda. Ou seja, converta de kb/s para b/s.

Vamos determinar nossa banda de 380 kb/s, isso nos dará o valor 47500 bytes/s.

Determine o número de pools que teremos. De acordo com o número de pools poderemos ter configurações mais completas do sistemas. Como definiremos um único pools, só poderemos passar um valor ao sistema.

delay_pools 1

Definiremos a relação entre o pools declarado e a classe que usaremos com o mesmo. Não esqueça que temos 3 classes e cada uma nos dará um resultado bem específico, por isso, cuidado ao declarar a classe do pools.

delay_class 1 1

Definiremos os valores de banda no parâmetro delay_parameters. Note que aqui foi informado o valor da banda e que a relacionamos com o pools declarado anteriormente.

delay_parameters 1 47500/47500

Agora basta definirmos a relação das regras de pools criada com uma subrede


177

declara nas acls, como no exemplo abaixo.

delay_access 1 allow rede

Seguindo os mesmos valores, para uma delay_class 2, com uma taxa individual de 200kb/s para cada conexão, teremos.

delay_pools 1

delay_class 1 2

delay_parameters 1 47500/47500 2500/2500


Observe que um valor novo apareceu. O Max, logo após o Replace. Aqui determinamos o comportamento das conexões em relação a banda, desde que não exceda o valor de replace.

Usando o delay_class 3, precisamos de mais algumas informações, haja vista que determinaremos valores para a subrede e para cada host desta subrede. Vamos determinar nossos valores em bytes.

Largura total = 520 kb/s (65000 bytes/s)

Largura por subrede = 255 kb/s (31875 bytes/s)

Largura por host = 40 kb/s (5000 bytes/s)

Com isso, teremos no arquivo squid.conf a seguinte configuração.

delay_pools 1

delay_class 1 3

delay_parameters 1 65000/65000 31875/31875 5000/5000


Um detalhe importante aqui é que a classe 3 só poderá ser usada para endereços ip em classe C.

Configurações feitas, reinicie o serviço e boa sorte.


178


179

Capítulo 13 - Servidor DHCPVamos definir a configuração do servidor DHCP, nele usaremos dois momentos. O

primeiro será simples e será configurado um range de IP para distribuir dinamicamente para as máquinas solicitantes. No outro, usaremos informações de MAC Address para determinarmos o endereço IP de nossas máquinas.


180


181

1. DHCP simples.Veja no exemplo abaixo como é simples definirmos um range de IP para distribuir

dinamicamente.

#vim /etc/dhcpd.conf

ddns-update-style interim;

ignore client-updates;

Declaramos a subrede que será gerenciada pelo servidor DHCP. Observe a estrutura das informações, informamos a subnet e em seguida a netmask, iniciando o bloco por uma {

subnet 192.168.0.0 netmask 255.255.255.0 {

Definimos a estrutura de servidores para esta subrede. Option routers seria o gateway da rede, subnetmask do servidor, o domain-name é domínio da rede e por fim o domain-name-servers, endereço ip do servidor dns.

# --- default gateway

option routers 192.168.0.1;

option subnet-mask 255.255.255.0;

option nis-domain "domain.org";

option domain-name "domain.org";

option domain-name-servers 192.168.1.1;

option time-offset -18000; # Eastern Standard Time

# option ntp-servers 192.168.1.1;

# option netbios-name-servers 192.168.1.1;

# --- Selects point-to-point node (default is hybrid). Don't change this unless

# -- you understand Netbios very well

# option netbios-node-type 2;

Determinamos os ips que serão distribuídos dinamicamente.

range dynamic-bootp 192.168.0.128 192.168.0.254;

default-lease-time 21600;

max-lease-time 43200;

}

No exemplo abaixo, uso as mesmas referências usadas anteriormente, porém associo um endereço ip ao mac-address pelo parâmetro host.


182

2. IP fixo usando DHCP.default-lease-time 86400;

max-lease-time 172800;

option ntp-servers 10.0.0.138;

option domain-name "intra";

option domain-name-servers 10.0.0.138;

option netbios-name-servers 10.0.0.138;

option netbios-node-type 8;

ddns-updates on;

ddns-update-style interim;

subnet 10.42.225.12 netmask 255.255.255.252 {

}

#sala 1

subnet 10.42.228.0 netmask 255.255.255.248 {

option routers 10.0.0.138;


host maq01_01 {

hardware ethernet 00:0F:EA:DD:1A:A6;

fixed-address 10.42.228.1;


}

host maq02-01 {

hardware ethernet 00:0F:EA:DA:04:9B;



}

host maq03-01 {

hardware ethernet 00:0F:EA:DD:B1:18;



}

host maq04-01 {

hardware ethernet 00:0F:EA:DD:21:30;



183


}

host maq05-01 {

hardware ethernet 00:0F:EA:DC:1E:6E;



}

host maq06-01 {

hardware ethernet 00:0F:EA:DD:50:AA;



}

Observe que usei endereços IP relacionados com os MACs das estações.


184


185

Capítulo 14 - Servidor Postfix / DovecotResponsável pelo processo de troca de mail entre usuários de mesmo domínio e de

domínios diferentes, o postfix é um servidor de mail, substituto do sendmail pela facilidade de configuração e rápido entendimento do arquivo de configuração.

A sensação de enviarmos um arquivo para outra pessoa, no outro lado do mundo é fascinante realmente, e pensar em como tudo isso funciona pode ser realmente complicado.

Veremos nessa etapa como configurar o servidor de mail postfix e o dovecot, que é o responsável pelos serviços de pop e smtp, além de entendermos qual a relação do servidor de mail com o servidor DNS.


186


187

Este é um dos servidores mais simples de ser configurado. Desde que saibamos algumas poucas informações o servidor de mail está em pleno funcionamento. Não devemos ignorar sua relação com o servidor DNS. Lembre-se que durante a configuração do named, informamos através do parâmetro MX quem seria o responsável pelos e-mail do domínio declarado.

Muitos alunos durante o processo de aprendizado acabam me ligando por terem esquecido do relacionamento direto entre o DNS e o Mail Server, no nosso caso, o PostFix.

Para instalar o postfix, usaremos o padrão de pacotes.

#rpm -ivh postfix*.rpm

#dpkg -i postfix*.deb

#yum install postfix*

#apt-get install postfix*

Uma vez instalado e o DNS apontando corretamente para ele, vamos configurá-lo.

Seu arquivo de configurações é o /etc/postfix/main.cf, de fácil leitura e entendimento.

#vim /etc/postfix/main.cf

# Global Postfix configuration file. This file lists only a subset

# of all parameters. For the syntax, and for a complete parameter

# list, see the postconf(5) manual page (command: "man 5 postconf").

#

# For common configuration examples, see BASIC_CONFIGURATION_README

# and STANDARD_CONFIGURATION_README. To find these documents, use

# the command "postconf html_directory readme_directory", or go to

# http://www.postfix.org/.

#

# For best results, change no more than 2-3 parameters at a time,

# and test if Postfix still works after every change.

# SOFT BOUNCE

#

# The soft_bounce parameter provides a limited safety net for

# testing. When soft_bounce is enabled, mail will remain queued that

# would otherwise bounce. This parameter disables locally-generated

# bounces, and prevents the SMTP server from rejecting mail permanently

# (by changing 5xx replies into 4xx replies). However, soft_bounce

# is no cure for address rewriting mistakes or mail routing mistakes.

#


188

#soft_bounce = no

# LOCAL PATHNAME INFORMATION

#

# The queue_directory specifies the location of the Postfix queue.

# This is also the root directory of Postfix daemons that run chrooted.

# See the files in examples/chroot-setup for setting up Postfix chroot

# environments on different UNIX systems.

#

Na linha abaixo informamos ao servidor onde será o diretório de spools de mail.

queue_directory = /var/spool/postfix

# The command_directory parameter specifies the location of all

# postXXX commands.

#

command_directory = /usr/sbin

# The daemon_directory parameter specifies the location of all Postfix

# daemon programs (i.e. programs listed in the master.cf file). This

# directory must be owned by root.

#

daemon_directory = /usr/libexec/postfix

# QUEUE AND PROCESS OWNERSHIP

#

# The mail_owner parameter specifies the owner of the Postfix queue

# and of most Postfix daemon processes. Specify the name of a user

# account THAT DOES NOT SHARE ITS USER OR GROUP ID WITH OTHER ACCOUNTS

# AND THAT OWNS NO OTHER FILES OR PROCESSES ON THE SYSTEM. In

# particular, don't specify nobody or daemon. PLEASE USE A DEDICATED

# USER.

#

Observe que desde o início deste material afirmo que tudo no sistema está relacionado de alguma forma com um usuário. Com o servidor postfix não é diferente. Durante o processo de instalação com o uso de pacotes, foi criado um usuário de sistema para o servidor, chamado postfix.

Na linha mail_owner definiremos qual usuário será responsável pelo serviço.


189

mail_owner = postfix

# The default_privs parameter specifies the default rights used by

# the local delivery agent for delivery to external file or command.

# These rights are used in the absence of a recipient user context.

# DO NOT SPECIFY A PRIVILEGED USER OR THE POSTFIX OWNER.

#

#default_privs = nobody

# INTERNET HOST AND DOMAIN NAMES

#

# The myhostname parameter specifies the internet hostname of this

# mail system. The default is to use the fully-qualified domain name

# from gethostname(). $myhostname is used as a default value for many

# other configuration parameters.

#

#myhostname = host.domain.tld

Na linha abaixo informamos quem é o servidor de e-mail. Observe que uso o nome completo da máquina.

myhostname = server.clayton.com

# The mydomain parameter specifies the local internet domain name.

# The default is to use $myhostname minus the first component.

# $mydomain is used as a default value for many other configuration

# parameters.

#

Informaremos na opção mydomain o nome do domínio do servidor de mail .

mydomain = clayton.com

# SENDING MAIL

#

# The myorigin parameter specifies the domain that locally-posted

# mail appears to come from. The default is to append $myhostname,

# which is fine for small sites. If you run a domain with multiple

# machines, you should (1) change this to $mydomain and (2) set up

# a domain-wide alias database that aliases each user to

# [email protected].


190

#

# For the sake of consistency between sender and recipient addresses,

# myorigin also specifies the default domain name that is appended

# to recipient addresses that have no @domain part.

#

#myorigin = $myhostname

myorigin = $mydomain

# RECEIVING MAIL

# The inet_interfaces parameter specifies the network interface

# addresses that this mail system receives mail on. By default,

# the software claims all active interfaces on the machine. The

# parameter also controls delivery of mail to user@[ip.address].

#

# See also the proxy_interfaces parameter, for network addresses that

# are forwarded to us via a proxy or network address translator.

#

# Note: you need to stop/start Postfix when this parameter changes.

#

inet_interfaces = all

#inet_interfaces = $myhostname

#inet_interfaces = $myhostname, localhost

#inet_interfaces = localhost

# The proxy_interfaces parameter specifies the network interface

# addresses that this mail system receives mail on by way of a

# proxy or network address translation unit. This setting extends

# the address list specified with the inet_interfaces parameter.

#

# You must specify your proxy/NAT addresses when your system is a

# backup MX host for other domains, otherwise mail delivery loops

# will happen when the primary MX host is down.

#

#proxy_interfaces =

#proxy_interfaces = 1.2.3.4


191

# The mydestination parameter specifies the list of domains that this

# machine considers itself the final destination for.

#

# These domains are routed to the delivery agent specified with the

# local_transport parameter setting. By default, that is the UNIX

# compatible delivery agent that lookups all recipients in /etc/passwd

# and /etc/aliases or their equivalent.

#

# The default is $myhostname + localhost.$mydomain. On a mail domain

# gateway, you should also include $mydomain.

#

# Do not specify the names of virtual domains - those domains are

# specified elsewhere (see VIRTUAL_README).

#

# Do not specify the names of domains that this machine is backup MX

# host for. Specify those names via the relay_domains settings for

# the SMTP server, or use permit_mx_backup if you are lazy (see

# STANDARD_CONFIGURATION_README).

#

# The local machine is always the final destination for mail addressed

# to user@[the.net.work.address] of an interface that the mail system

# receives mail on (see the inet_interfaces parameter).

#

# Specify a list of host or domain names, /file/name or type:table

# patterns, separated by commas and/or whitespace. A /file/name

# pattern is replaced by its contents; a type:table is matched when

# a name matches a lookup key (the right-hand side is ignored).

# Continue long lines by starting the next line with whitespace.

#

# See also below, section "REJECTING MAIL FOR UNKNOWN LOCAL USERS".

#

#mydestination = $myhostname, localhost.$mydomain, localhost

#mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, mail.$mydomain, www.$mydomain, ftp.$mydomain, /etc/postfix/domains


192

# REJECTING MAIL FOR UNKNOWN LOCAL USERS

#

# The local_recipient_maps parameter specifies optional lookup tables

# with all names or addresses of users that are local with respect

# to $mydestination, $inet_interfaces or $proxy_interfaces.

#

# If this parameter is defined, then the SMTP server will reject

# mail for unknown local users. This parameter is defined by default.

#

# To turn off local recipient checking in the SMTP server, specify

# local_recipient_maps = (i.e. empty).

#

# The default setting assumes that you use the default Postfix local

# delivery agent for local delivery. You need to update the

# local_recipient_maps setting if:

#

# - You define $mydestination domain recipients in files other than

# /etc/passwd, /etc/aliases, or the $virtual_alias_maps files.

# For example, you define $mydestination domain recipients in

# the $virtual_mailbox_maps files.

#

# - You redefine the local delivery agent in master.cf.

#

# - You redefine the "local_transport" setting in main.cf.

#

# - You use the "luser_relay", "mailbox_transport", or "fallback_transport"

# feature of the Postfix local delivery agent (see local(8)).

#

# Details are described in the LOCAL_RECIPIENT_README file.

#

# Beware: if the Postfix SMTP server runs chrooted, you probably have

# to access the passwd file via the proxymap service, in order to

# overcome chroot restrictions. The alternative, having a copy of

# the system passwd file in the chroot jail is just not practical.

#

# The right-hand side of the lookup tables is conveniently ignored.


193

# In the left-hand side, specify a bare username, an @domain.tld

# wild-card, or specify a [email protected] address.

#

#local_recipient_maps = unix:passwd.byname $alias_maps

#local_recipient_maps = proxy:unix:passwd.byname $alias_maps

#local_recipient_maps =

# The unknown_local_recipient_reject_code specifies the SMTP server

# response code when a recipient domain matches $mydestination or

# ${proxy,inet}_interfaces, while $local_recipient_maps is non-empty

# and the recipient address or address local-part is not found.

#

# The default setting is 550 (reject mail) but it is safer to start

# with 450 (try again later) until you are certain that your

# local_recipient_maps settings are OK.

#

unknown_local_recipient_reject_code = 550

# TRUST AND RELAY CONTROL

# The mynetworks parameter specifies the list of "trusted" SMTP

# clients that have more privileges than "strangers".

#

# In particular, "trusted" SMTP clients are allowed to relay mail

# through Postfix. See the smtpd_recipient_restrictions parameter

# in postconf(5).

#

# You can specify the list of "trusted" network addresses by hand

# or you can let Postfix do it for you (which is the default).

#

# By default (mynetworks_style = subnet), Postfix "trusts" SMTP

# clients in the same IP subnetworks as the local machine.

# On Linux, this does works correctly only with interfaces specified

# with the "ifconfig" command.

#

# Specify "mynetworks_style = class" when Postfix should "trust" SMTP


194

# clients in the same IP class A/B/C networks as the local machine.

# Don't do this with a dialup site - it would cause Postfix to "trust"

# your entire provider's network. Instead, specify an explicit

# mynetworks list by hand, as described below.

#

# Specify "mynetworks_style = host" when Postfix should "trust"

# only the local machine.

#

#mynetworks_style = class

mynetworks_style = subnet

#mynetworks_style = host

# Alternatively, you can specify the mynetworks list by hand, in

# which case Postfix ignores the mynetworks_style setting.

#

# Specify an explicit list of network/netmask patterns, where the

# mask specifies the number of bits in the network part of a host

# address.

#

# You can also specify the absolute pathname of a pattern file instead

# of listing the patterns here. Specify type:table for table-based lookups

# (the value on the table right-hand side is not used).

#

Precisamos informar quais as redes que o servidor está operando. Use como no exemplo abaixo.

mynetworks = 192.168.1.0/24, 127.0.0.0/8

#mynetworks = $config_directory/mynetworks

#mynetworks = hash:/etc/postfix/network_table

# The relay_domains parameter restricts what destinations this system will

# relay mail to. See the smtpd_recipient_restrictions description in

# postconf(5) for detailed information.

#

# By default, Postfix relays mail

# - from "trusted" clients (IP address matches $mynetworks) to any destination,

# - from "untrusted" clients to destinations that match $relay_domains or

# subdomains thereof, except addresses with sender-specified routing.


195

# The default relay_domains value is $mydestination.

#

# In addition to the above, the Postfix SMTP server by default accepts mail

# that Postfix is final destination for:

# - destinations that match $inet_interfaces or $proxy_interfaces,

# - destinations that match $mydestination

# - destinations that match $virtual_alias_domains,

# - destinations that match $virtual_mailbox_domains.

# These destinations do not need to be listed in $relay_domains.

#

# Specify a list of hosts or domains, /file/name patterns or type:name

# lookup tables, separated by commas and/or whitespace. Continue

# long lines by starting the next line with whitespace. A file name

# is replaced by its contents; a type:name table is matched when a

# (parent) domain appears as lookup key.

#

# NOTE: Postfix will not automatically forward mail for domains that

# list this system as their primary or backup MX host. See the

# permit_mx_backup restriction description in postconf(5).

#

relay_domains = $mydestination

# INTERNET OR INTRANET

# The relayhost parameter specifies the default host to send mail to

# when no entry is matched in the optional transport(5) table. When

# no relayhost is given, mail is routed directly to the destination.

#

# On an intranet, specify the organizational domain name. If your

# internal DNS uses no MX records, specify the name of the intranet

# gateway host instead.

#

# In the case of SMTP, specify a domain, host, host:port, [host]:port,

# [address] or [address]:port; the form [host] turns off MX lookups.

#

# If you're connected via UUCP, see also the default_transport parameter.


196

#

#relayhost = $mydomain

#relayhost = [gateway.my.domain]

#relayhost = [mailserver.isp.tld]

#relayhost = uucphost

#relayhost = [an.ip.add.ress]

# REJECTING UNKNOWN RELAY USERS

#

# The relay_recipient_maps parameter specifies optional lookup tables

# with all addresses in the domains that match $relay_domains.

#

# If this parameter is defined, then the SMTP server will reject

# mail for unknown relay users. This feature is off by default.

#

# The right-hand side of the lookup tables is conveniently ignored.

# In the left-hand side, specify an @domain.tld wild-card, or specify

# a [email protected] address.

#

#relay_recipient_maps = hash:/etc/postfix/relay_recipients

# INPUT RATE CONTROL

#

# The in_flow_delay configuration parameter implements mail input

# flow control. This feature is turned on by default, although it

# still needs further development (it's disabled on SCO UNIX due

# to an SCO bug).

#

# A Postfix process will pause for $in_flow_delay seconds before

# accepting a new message, when the message arrival rate exceeds the

# message delivery rate. With the default 100 SMTP server process

# limit, this limits the mail inflow to 100 messages a second more

# than the number of messages delivered per second.

#

# Specify 0 to disable the feature. Valid delays are 0..10.

#


197

#in_flow_delay = 1s

# ADDRESS REWRITING

#

# The ADDRESS_REWRITING_README document gives information about

# address masquerading or other forms of address rewriting including

# username->Firstname.Lastname mapping.

# ADDRESS REDIRECTION (VIRTUAL DOMAIN)

#

# The VIRTUAL_README document gives information about the many forms

# of domain hosting that Postfix supports.

# "USER HAS MOVED" BOUNCE MESSAGES

#

# See the discussion in the ADDRESS_REWRITING_README document.

# TRANSPORT MAP

#

# See the discussion in the ADDRESS_REWRITING_README document.

# ALIAS DATABASE

#

# The alias_maps parameter specifies the list of alias databases used

# by the local delivery agent. The default list is system dependent.

#

# On systems with NIS, the default is to search the local alias

# database, then the NIS alias database. See aliases(5) for syntax

# details.

#

# If you change the alias database, run "postalias /etc/aliases" (or

# wherever your system stores the mail alias file), or simply run

# "newaliases" to build the necessary DBM or DB file.

#

# It will take a minute or so before changes become visible. Use

# "postfix reload" to eliminate the delay.


198

#

#alias_maps = dbm:/etc/aliases

alias_maps = hash:/etc/aliases

#alias_maps = hash:/etc/aliases, nis:mail.aliases

#alias_maps = netinfo:/aliases

# The alias_database parameter specifies the alias database(s) that

# are built with "newaliases" or "sendmail -bi". This is a separate

# configuration parameter, because alias_maps (see above) may specify

# tables that are not necessarily all under control by Postfix.

#

#alias_database = dbm:/etc/aliases

#alias_database = dbm:/etc/mail/aliases

alias_database = hash:/etc/aliases

#alias_database = hash:/etc/aliases, hash:/opt/majordomo/aliases

# ADDRESS EXTENSIONS (e.g., user+foo)

#

# The recipient_delimiter parameter specifies the separator between

# user names and address extensions (user+foo). See canonical(5),

# local(8), relocated(5) and virtual(5) for the effects this has on

# aliases, canonical, virtual, relocated and .forward file lookups.

# Basically, the software tries user+foo and .forward+foo before

# trying user and .forward.

#

#recipient_delimiter = +

# DELIVERY TO MAILBOX

#

# The home_mailbox parameter specifies the optional pathname of a

# mailbox file relative to a user's home directory. The default

# mailbox file is /var/spool/mail/user or /var/mail/user. Specify

# "Maildir/" for qmail-style delivery (the / is required).

#

#home_mailbox = Mailbox

#home_mailbox = Maildir/


199

# The mail_spool_directory parameter specifies the directory where

# UNIX-style mailboxes are kept. The default setting depends on the

# system type.

#

#mail_spool_directory = /var/mail

#mail_spool_directory = /var/spool/mail

# The mailbox_command parameter specifies the optional external

# command to use instead of mailbox delivery. The command is run as

# the recipient with proper HOME, SHELL and LOGNAME environment settings.

# Exception: delivery for root is done as $default_user.

#

# Other environment variables of interest: USER (recipient username),

# EXTENSION (address extension), DOMAIN (domain part of address),

# and LOCAL (the address localpart).

#

# Unlike other Postfix configuration parameters, the mailbox_command

# parameter is not subjected to $parameter substitutions. This is to

# make it easier to specify shell syntax (see example below).

#

# Avoid shell meta characters because they will force Postfix to run

# an expensive shell process. Procmail alone is expensive enough.

#

# IF YOU USE THIS TO DELIVER MAIL SYSTEM-WIDE, YOU MUST SET UP AN

# ALIAS THAT FORWARDS MAIL FOR ROOT TO A REAL USER.

#

#mailbox_command = /some/where/procmail

#mailbox_command = /some/where/procmail -a "$EXTENSION"

# The mailbox_transport specifies the optional transport in master.cf

# to use after processing aliases and .forward files. This parameter

# has precedence over the mailbox_command, fallback_transport and

# luser_relay parameters.

#

# Specify a string of the form transport:nexthop, where transport is


200

# the name of a mail delivery transport defined in master.cf. The

# :nexthop part is optional. For more details see the sample transport

# configuration file.

#

# NOTE: if you use this feature for accounts not in the UNIX password

# file, then you must update the "local_recipient_maps" setting in

# the main.cf file, otherwise the SMTP server will reject mail for

# non-UNIX accounts with "User unknown in local recipient table".

#

#mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp

# If using the cyrus-imapd IMAP server deliver local mail to the IMAP

# server using LMTP (Local Mail Transport Protocol), this is prefered

# over the older cyrus deliver program by setting the

# mailbox_transport as below:

#

# mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp

#

# The efficiency of LMTP delivery for cyrus-imapd can be enhanced via

# these settings.

#

# local_destination_recipient_limit = 300

# local_destination_concurrency_limit = 5

#

# Of course you should adjust these settings as appropriate for the

# capacity of the hardware you are using. The recipient limit setting

# can be used to take advantage of the single instance message store

# capability of Cyrus. The concurrency limit can be used to control

# how many simultaneous LMTP sessions will be permitted to the Cyrus

# message store.

#

# To use the old cyrus deliver program you have to set:

#mailbox_transport = cyrus

# The fallback_transport specifies the optional transport in master.cf

# to use for recipients that are not found in the UNIX passwd database.


201

# This parameter has precedence over the luser_relay parameter.

#

# Specify a string of the form transport:nexthop, where transport is

# the name of a mail delivery transport defined in master.cf. The

# :nexthop part is optional. For more details see the sample transport

# configuration file.

#


# file, then you must update the "local_recipient_maps" setting in



#

#fallback_transport = lmtp:unix:/var/lib/imap/socket/lmtp

#fallback_transport =

# The luser_relay parameter specifies an optional destination address

# for unknown recipients. By default, mail for unknown@$mydestination,

# unknown@[$inet_interfaces] or unknown@[$proxy_interfaces] is returned

# as undeliverable.

#

# The following expansions are done on luser_relay: $user (recipient

# username), $shell (recipient shell), $home (recipient home directory),

# $recipient (full recipient address), $extension (recipient address

# extension), $domain (recipient domain), $local (entire recipient

# localpart), $recipient_delimiter. Specify ${name?value} or

# ${name:value} to expand value only when $name does (does not) exist.

#

# luser_relay works only for the default Postfix local delivery agent.

#


# file, then you must specify "local_recipient_maps =" (i.e. empty) in



#

#luser_relay = [email protected]

#luser_relay = [email protected]


202

#luser_relay = admin+$local

# JUNK MAIL CONTROLS

#

# The controls listed here are only a very small subset. The file

# SMTPD_ACCESS_README provides an overview.

# The header_checks parameter specifies an optional table with patterns

# that each logical message header is matched against, including

# headers that span multiple physical lines.

#

# By default, these patterns also apply to MIME headers and to the

# headers of attached messages. With older Postfix versions, MIME and

# attached message headers were treated as body text.

#

# For details, see "man header_checks".

#

#header_checks = regexp:/etc/postfix/header_checks

# FAST ETRN SERVICE

#

# Postfix maintains per-destination logfiles with information about

# deferred mail, so that mail can be flushed quickly with the SMTP

# "ETRN domain.tld" command, or by executing "sendmail -qRdomain.tld".

# See the ETRN_README document for a detailed description.

#

# The fast_flush_domains parameter controls what destinations are

# eligible for this service. By default, they are all domains that

# this server is willing to relay mail to.

#

#fast_flush_domains = $relay_domains

# SHOW SOFTWARE VERSION OR NOT

#

# The smtpd_banner parameter specifies the text that follows the 220

# code in the SMTP server's greeting banner. Some people like to see


203

# the mail version advertised. By default, Postfix shows no version.

#

# You MUST specify $myhostname at the start of the text. That is an

# RFC requirement. Postfix itself does not care.

#

#smtpd_banner = $myhostname ESMTP $mail_name

#smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)

# PARALLEL DELIVERY TO THE SAME DESTINATION

#

# How many parallel deliveries to the same user or domain? With local

# delivery, it does not make sense to do massively parallel delivery

# to the same user, because mailbox updates must happen sequentially,

# and expensive pipelines in .forward files can cause disasters when

# too many are run at the same time. With SMTP deliveries, 10

# simultaneous connections to the same domain could be sufficient to

# raise eyebrows.

#

# Each message delivery transport has its XXX_destination_concurrency_limit

# parameter. The default is $default_destination_concurrency_limit for

# most delivery transports. For the local delivery agent the default is 2.

#local_destination_concurrency_limit = 2

#default_destination_concurrency_limit = 20

# DEBUGGING CONTROL

#

# The debug_peer_level parameter specifies the increment in verbose

# logging level when an SMTP client or server host name or address

# matches a pattern in the debug_peer_list parameter.

#

debug_peer_level = 2

# The debug_peer_list parameter specifies an optional list of domain

# or network patterns, /file/name patterns or type:name tables. When

# an SMTP client or server host name or address matches a pattern,


204

# increase the verbose logging level by the amount specified in the

# debug_peer_level parameter.

#

#debug_peer_list = 127.0.0.1

#debug_peer_list = some.domain

# The debugger_command specifies the external command that is executed

# when a Postfix daemon program is run with the -D option.

#

# Use "command .. & sleep 5" so that the debugger can attach before

# the process marches on. If you use an X-based debugger, be sure to

# set up your XAUTHORITY environment variable before starting Postfix.

#

debugger_command =

PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin

xxgdb $daemon_directory/$process_name $process_id & sleep 5

# If you can't use X, use this to capture the call stack when a

# daemon crashes. The result is in a file in the configuration

# directory, and is named after the process name and the process ID.

#

# debugger_command =

# PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont;

# echo where) | gdb $daemon_directory/$process_name $process_id 2>&1

# >$config_directory/$process_name.$process_id.log & sleep 5

#

# Another possibility is to run gdb under a detached screen session.

# To attach to the screen sesssion, su root and run "screen -r

# <id_string>" where <id_string> uniquely matches one of the detached

# sessions (from "screen -list").

#

# debugger_command =

# PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH; screen

# -dmS $process_name gdb $daemon_directory/$process_name

# $process_id & sleep 1


205

# INSTALL-TIME CONFIGURATION INFORMATION

#

# The following parameters are used when installing a new Postfix version.

#

# sendmail_path: The full pathname of the Postfix sendmail command.

# This is the Sendmail-compatible mail posting interface.

#

sendmail_path = /usr/sbin/sendmail.postfix

# newaliases_path: The full pathname of the Postfix newaliases command.

# This is the Sendmail-compatible command to build alias databases.

#

newaliases_path = /usr/bin/newaliases.postfix

# mailq_path: The full pathname of the Postfix mailq command. This

# is the Sendmail-compatible mail queue listing command.

#

mailq_path = /usr/bin/mailq.postfix

# setgid_group: The group for mail submission and queue management

# commands. This must be a group name with a numerical group ID that

# is not shared with other accounts, not even with the Postfix account.

#

setgid_group = postdrop

# html_directory: The location of the Postfix HTML documentation.

#

html_directory = no

# manpage_directory: The location of the Postfix on-line manual pages.

#

manpage_directory = /usr/share/man

# sample_directory: The location of the Postfix sample configuration files.

# This parameter is obsolete as of Postfix 2.1.

#


206

sample_directory = /usr/share/doc/postfix-2.3.3/samples

# readme_directory: The location of the Postfix README files.

#

readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES

Observe que alteramos meia dúzia de parâmetros para colocar o Postfix rodando, agora, vamos ao dovecot.

O servidor dovecot é a peça da engrenagem responsável pelo envio e recebimento de e-mail com os clientes.

Para instalarmos o servidor dovecot, seguiremos o padrão de instalação do postfix.

#apt-get install dovecot

#yum install dovecot

#rpm -ivh dovecot*.rpm

#dpkg -i dovecot*.deb

Para confiurá-lo siga os passos abaixo.

#vim /etc/dovecot.conf

## Dovecot configuration file

# If you're in a hurry, see http://wiki.dovecot.org/QuickConfiguration

# "dovecot -n" command gives a clean output of the changed settings. Use it

# instead of copy&pasting this file when posting to the Dovecot mailing list.

# '#' character and everything after it is treated as comments. Extra spaces

# and tabs are ignored. If you want to use either of these explicitly, put the

# value inside quotes, eg.: key = "# char and trailing whitespace "

# Default values are shown for each setting, it's not required to uncomment

# any of the lines.

# Base directory where to store runtime data.

#base_dir = /var/run/dovecot/

# Protocols we want to be serving: imap imaps pop3 pop3s

# If you only want to use dovecot-auth, you can set this to "none".

Basicamente defina o comportamento dos protocolos com os quais o dovecot irá trabalhar.

protocols = imap pop3


207

# IP or host address where to listen in for connections. It's not currently

# possible to specify multiple addresses. "*" listens in all IPv4 interfaces.

# "[::]" listens in all IPv6 interfaces, but may also listen in all IPv4

# interfaces depending on the operating system.

#

# If you want to specify ports for each service, you will need to configure

# these settings inside the protocol imap/pop3 { ... } section, so you can

# specify different ports for IMAP/POP3. For example:

# protocol imap {

# listen = *:10143

# ssl_listen = *:10943

# ..

# }

# protocol pop3 {

# listen = *:10100

# ..

# }

Determine para cada protocolo uma porta e um comportamento para ouvir as requisições dos clientes.

listen = [*]

# Disable LOGIN command and all other plaintext authentications unless

# SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP

# matches the local IP (ie. you're connecting from the same computer), the

# connection is considered secure and plaintext authentication is allowed.

#disable_plaintext_auth = no

# Should all IMAP and POP3 processes be killed when Dovecot master process

# shuts down. Setting this to "no" means that Dovecot can be upgraded without

# forcing existing client connections to close (although that could also be

# a problem if the upgrade is eg. because of a security fix). This however

# means that after master process has died, the client processes can't write

# to log files anymore.


208

#shutdown_clients = yes

##

## Logging

##

# Log file to use for error messages, instead of sending them to syslog.

# /dev/stderr can be used to log into stderr.

#log_path =

# Log file to use for informational and debug messages.

# Default is the same as log_path.

#info_log_path =

# Prefix for each line written to log file. % codes are in strftime(3)

# format.

#log_timestamp = "%b %d %H:%M:%S "

# Syslog facility to use if you're logging to syslog. Usually if you don't

# want to use "mail", you'll use local0..local7. Also other standard

# facilities are supported.

#syslog_facility = mail

##

## SSL settings

##

# IP or host address where to listen in for SSL connections. Defaults

# to above if not specified.

#ssl_listen =

# Disable SSL/TLS support.

#ssl_disable = no

# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before

# dropping root privileges, so keep the key file unreadable by anyone but


209

# root. Included doc/mkcert.sh can be used to easily generate self-signed

# certificate, just make sure to update the domains in dovecot-openssl.cnf

#ssl_cert_file = /etc/pki/dovecot/certs/dovecot.pem

#ssl_key_file = /etc/pki/dovecot/private/dovecot.pem

# If key file is password protected, give the password here. Alternatively

# give it when starting dovecot with -p parameter.

#ssl_key_password =

# File containing trusted SSL certificate authorities. Usually not needed.

# The CAfile should contain the CA-certificate(s) followed by the matching

# CRL(s). CRL checking is new in dovecot .rc1

#ssl_ca_file =

# Request client to send a certificate. If you also want to require it, set

# ssl_require_client_cert=yes in auth section.

#ssl_verify_client_cert = no

# How often to regenerate the SSL parameters file. Generation is quite CPU

# intensive operation. The value is in hours, 0 disables regeneration

# entirely.

#ssl_parameters_regenerate = 168

# SSL ciphers to use

#ssl_cipher_list = ALL:!LOW

# Show protocol level SSL errors.

#verbose_ssl = no

##

## Login processes

##

# <doc/wiki/LoginProcess.txt>

# Directory where authentication process places authentication UNIX sockets


210

# which login needs to be able to connect to. The sockets are created when

# running as root, so you don't have to worry about permissions. Note that

# everything in this directory is deleted when Dovecot is started.

#login_dir = /var/run/dovecot/login

# chroot login process to the login_dir. Only reason not to do this is if you

# wish to run the whole Dovecot without roots. <doc/wiki/Rootless.txt>

#login_chroot = yes

# User to use for the login process. Create a completely new user for this,

# and don't use it anywhere else. The user must also belong to a group where

# only it has access, it's used to control access for authentication process.

# Note that this user is NOT used to access mails. <doc/wiki/UserIds.txt>

#login_user = dovecot

# Set max. process size in megabytes. If you don't use

# login_process_per_connection you might need to grow this.

#login_process_size = 32

# Should each login be processed in it's own process (yes), or should one

# login process be allowed to process multiple connections (no)? Yes is more

# secure, espcially with SSL/TLS enabled. No is faster since there's no need

# to create processes all the time.

#login_process_per_connection = yes

# Number of login processes to keep for listening new connections.

#login_processes_count = 3

# Maximum number of login processes to create. The listening process count

# usually stays at login_processes_count, but when multiple users start logging

# in at the same time more extra processes are created. To prevent fork-bombing

# we check only once in a second if new processes should be created - if all

# of them are used at the time, we double their amount until the limit set


211

by

# this setting is reached.

#login_max_processes_count = 128

# Maximum number of connections allowed per each login process. This setting

# is used only if login_process_per_connection=no. Once the limit is reached,

# the process notifies master so that it can create a new login process.

# You should make sure that the process has at least

# 16 + login_max_connections * 2 available file descriptors.

#login_max_connections = 256

# Greeting message for clients.

#login_greeting = Dovecot ready.

# Space-separated list of elements we want to log. The elements which have

# a non-empty variable value are joined together to form a comma-separated

# string.

#login_log_format_elements = user=<%u> method=%m rip=%r lip=%l %c

# Login log format. %$ contains login_log_format_elements string, %s contains

# the data we want to log.

#login_log_format = %$: %s

##

## Mailbox locations and namespaces

##

# Location for users' mailboxes. This is the same as the old default_mail_env

# setting. The default is empty, which means that Dovecot tries to find the

# mailboxes automatically. This won't work if the user doesn't have any mail

# yet, so you should explicitly tell Dovecot the full location.


212

#

# If you're using mbox, giving a path to the INBOX file (eg. /var/mail/%u)

# isn't enough. You'll also need to tell Dovecot where the other mailboxes are

# kept. This is called the "root mail directory", and it must be the first

# path given in the mail_location setting.

#

# There are a few special variables you can use, eg.:

#

# %u - username

# %n - user part in user@domain, same as %u if there's no domain

# %d - domain part in user@domain, empty if there's no domain

# %h - home directory

#

# See doc/wiki/Variables.txt for full list. Some examples:

#

# mail_location = maildir:~/Maildir

# mail_location = mbox:~/mail:INBOX=/var/mail/%u

# mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n

#

# <doc/wiki/MailLocation.txt>

#

#mail_location =

# If you need to set multiple mailbox locations or want to change default

# namespace settings, you can do it by defining namespace sections.

# NOTE: Namespaces currently work ONLY with IMAP! POP3 and LDA currently ignore

# namespaces completely, they use only the mail_location setting.

#

# You can have private, shared and public namespaces. The only difference

# between them is how Dovecot announces them to client via NAMESPACE

# extension. Shared namespaces are meant for user-owned mailboxes which are

# shared to other users, while public namespaces are for more globally

# accessible mailboxes.


213

#

# REMEMBER: If you add any namespaces, the default namespace must be added

# explicitly, ie. mail_location does nothing unless you have a namespace

# without a location setting. Default namespace is simply done by having a

# namespace with empty prefix.

#namespace private {

# Hierarchy separator to use. You should use the same separator for all

# namespaces or some clients get confused. '/' is usually a good one.

# The default however depends on the underlying mail storage format.

#separator =

# Prefix required to access this namespace. This needs to be different for

# all namespaces. For example "Public/".

#prefix =

# Physical location of the mailbox. This is in same format as

# mail_location, which is also the default for it.

#location =

# There can be only one INBOX, and this setting defines which namespace

# has it.

#inbox = yes

# If namespace is hidden, it's not advertised to clients via NAMESPACE

# extension or shown in LIST replies. This is mostly useful when converting

# from another server with different namespaces which you want to depricate

# but still keep working. For example you can create hidden namespaces with

# prefixes "~/mail/", "~%u/mail/" and "mail/".

#hidden = yes

#}

# Grant access to these extra groups for mail processes. Typical use would be

# to give "mail" group write access to /var/mail to be able to create


214

dotlocks.

#mail_extra_groups =

# Allow full filesystem access to clients. There's no access checks other than

# what the operating system does for the active UID/GID. It works with both

# maildir and mboxes, allowing you to prefix mailboxes names with eg. /path/

# or ~user/.

#mail_full_filesystem_access = no

##

## Mail processes

##

# Enable mail process debugging. This can help you figure out why Dovecot

# isn't finding your mails.

#mail_debug = no

# Log prefix for mail processes. See doc/wiki/Variables.txt for list of

# possible variables you can use.

#mail_log_prefix = "%Us(%u): "

# Max. number of lines a mail process is allowed to log per second before it's

# throttled. 0 means unlimited. Typically there's no need to change this

# unless you're using mail_log plugin, which may log a lot.

#mail_log_max_lines_per_sec = 10

# Don't use mmap() at all. This is required if you store indexes to shared

# filesystems (NFS or clustered filesystem).

#mmap_disable = no

# Don't write() to mmaped files. This is required for some operating systems

# which use separate caches for them, such as OpenBSD.

#mmap_no_write = no


215

# Rely on O_EXCL to work when creating dotlock files. The default is to use

# hard linking. O_EXCL makes the dotlocking faster, but it doesn't always

# work with NFS.

#dotlock_use_excl = no

# Don't use fsync() or fdatasync() calls. This makes the performance better

# at the cost of potential data loss if the server (or the file server)

# goes down.

#fsync_disable = no

# Locking method for index files. Alternatives are fcntl, flock and dotlock.

# Dotlocking uses some tricks which may create more disk I/O than other locking

# methods. NFS users: flock doesn't work, remember to change mmap_disable.

#lock_method = fcntl

# Drop all privileges before exec()ing the mail process. This is mostly

# meant for debugging, otherwise you don't get core dumps. It could be a small

# security risk if you use single UID for multiple users, as the users could

# ptrace() each others processes then.

#mail_drop_priv_before_exec = no

# Show more verbose process titles (in ps). Currently shows user name and

# IP address. Useful for seeing who are actually using the IMAP processes

# (eg. shared mailboxes or if same uid is used for multiple accounts).

#verbose_proctitle = no

# Valid UID range for users, defaults to 500 and above. This is mostly

# to make sure that users can't log in as daemons or other system users.

# Note that denying root logins is hardcoded to dovecot binary and can't

# be done even if first_valid_uid is set to 0.

#first_valid_uid = 500

#last_valid_uid = 0


216

# Valid GID range for users, defaults to non-root/wheel. Users having

# non-valid GID as primary group ID aren't allowed to log in. If user

# belongs to supplementary groups with non-valid GIDs, those groups are

# not set.

#first_valid_gid = 1

#last_valid_gid = 0

# Maximum number of running mail processes. When this limit is reached,

# new users aren't allowed to log in.

#max_mail_processes = 1024

# Set max. process size in megabytes. Most of the memory goes to mmap()ing

# files, so it shouldn't harm much even if this limit is set pretty high.

#mail_process_size = 256

# Maximum allowed length for mail keyword name. It's only forced when trying

# to create new keywords.

#mail_max_keyword_length = 50

# ':' separated list of directories under which chrooting is allowed for mail

# processes (ie. /var/mail will allow chrooting to /var/mail/foo/bar too).

# This setting doesn't affect login_chroot or auth chroot variables.

# WARNING: Never add directories here which local users can modify, that

# may lead to root exploit. Usually this should be done only if you don't

# allow shell access for users. <doc/wiki/Chrooting.txt>

#valid_chroot_dirs =

# Default chroot directory for mail processes. This can be overridden for

# specific users in user database by giving /./ in user's home directory

# (eg. /home/./user chroots into /home). Note that usually there is no real

# need to do chrooting, Dovecot doesn't allow users to access files outside

# their mail directory anyway. <doc/wiki/Chrooting.txt>

#mail_chroot =

##


217

## Mailbox handling optimizations

##

# Space-separated list of fields to initially save into cache file. Currently

# these fields are allowed:

#

# flags, date.sent, date.received, size.virtual, size.physical

# mime.parts, imap.body, imap.bodystructure

#

# Different IMAP clients work in different ways, so they benefit from

# different cached fields. Some do not benefit from them at all. Caching more

# than necessary generates useless disk I/O, so you don't want to do that

# either.

#

# Dovecot attempts to automatically figure out what client wants and it keeps

# only that. However the first few times a mailbox is opened, Dovecot hasn't

# yet figured out what client needs, so it may not perform optimally. If you

# know what fields the majority of your clients need, it may be useful to set

# these fields by hand. If client doesn't actually use them, Dovecot will

# eventually drop them.

#

# Usually you should just leave this field alone. The potential benefits are

# typically unnoticeable.

#mail_cache_fields =

# Space-separated list of fields that Dovecot should never save to cache file.

# Useful if you want to save disk space at the cost of more I/O when the fields

# needed.

#mail_never_cache_fields =

# The minimum number of mails in a mailbox before updates are done to cache

# file. This allows optimizing Dovecot's behavior to do less disk writes at


218

# the cost of more disk reads.

#mail_cache_min_mail_count = 0

# When IDLE command is running, mailbox is checked once in a while to see if

# there are any new mails or other changes. This setting defines the minimum

# time to wait between those checks. Dovecot is however able to use dnotify

# and inotify with Linux to reply immediately after the change occurs.

#mailbox_idle_check_interval = 30

# Save mails with CR+LF instead of plain LF. This makes sending those mails

# take less CPU, especially with sendfile() syscall with Linux and FreeBSD.

# But it also creates a bit more disk I/O which may just make it slower.

# Also note that if other software reads the mboxes/maildirs, they may handle

# the extra CRs wrong and cause problems.

#mail_save_crlf = no

##

## Maildir-specific settings

##

# By default LIST command returns all entries in maildir beginning with a dot.

# Enabling this option makes Dovecot return only entries which are directories.

# This is done by stat()ing each entry, so it causes more disk I/O.

# (For systems setting struct dirent->d_type, this check is free and it's

# done always regardless of this setting)

#maildir_stat_dirs = no

# When copying a message, do it with hard links whenever possible. This makes

# the performance much better, and it's unlikely to have any side effects.

#maildir_copy_with_hardlinks = no


219

# When copying a message, try to preserve the base filename. Only if the

# destination mailbox already contains the same name (ie. the mail is being

# copied there twice), a new name is given. The destination filename check is

# done only by looking at dovecot-uidlist file, so if something outside

# Dovecot does similar filename preserving copies, you may run into problems.

# NOTE: This setting requires maildir_copy_with_hardlinks = yes to work.

#maildir_copy_preserve_filename = no

##

## mbox-specific settings

##

# Which locking methods to use for locking mbox. There are four available:

# dotlock: Create <mailbox>.lock file. This is the oldest and most NFS-safe

# solution. If you want to use /var/mail/ like directory, the users

# will need write access to that directory.

# fcntl : Use this if possible. Works with NFS too if lockd is used.

# flock : May not exist in all systems. Doesn't work with NFS.

# lockf : May not exist in all systems. Doesn't work with NFS.

#

# You can use multiple locking methods; if you do the order they're declared

# in is important to avoid deadlocks if other MTAs/MUAs are using multiple

# locking methods as well. Some operating systems don't allow using some of

# them simultaneously.

#mbox_read_locks = fcntl

#mbox_write_locks = fcntl

# Maximum time in seconds to wait for lock (all of them) before aborting.

#mbox_lock_timeout = 300

# If dotlock exists but the mailbox isn't modified in any way, override the

# lock file after this many seconds.

#mbox_dotlock_change_timeout = 120


220

# When mbox changes unexpectedly we have to fully read it to find out what

# changed. If the mbox is large this can take a long time. Since the change

# is usually just a newly appended mail, it'd be faster to simply read the

# new mails. If this setting is enabled, Dovecot does this but still safely

# fallbacks to re-reading the whole mbox file whenever something in mbox isn't

# how it's expected to be. The only real downside to this setting is that if

# some other MUA changes message flags, Dovecot doesn't notice it immediately.

# Note that a full sync is done with SELECT, EXAMINE, EXPUNGE and CHECK

# commands.

#mbox_dirty_syncs = yes

# Like mbox_dirty_syncs, but don't do full syncs even with SELECT, EXAMINE,

# EXPUNGE or CHECK commands. If this is set, mbox_dirty_syncs is ignored.

#mbox_very_dirty_syncs = no

# Delay writing mbox headers until doing a full write sync (EXPUNGE and CHECK

# commands and when closing the mailbox). This is especially useful for POP3

# where clients often delete all mails. The downside is that our changes

# aren't immediately visible to other MUAs.

#mbox_lazy_writes = yes

# If mbox size is smaller than this (in kilobytes), don't write index files.

# If an index file already exists it's still read, just not updated.

#mbox_min_index_size = 0

##

## dbox-specific settings

##

# Maximum dbox file size in kilobytes until it's rotated.

#dbox_rotate_size = 2048


221

# Minimum dbox file size in kilobytes before it's rotated

# (overrides dbox_rotate_days)

#dbox_rotate_min_size = 16

# Maximum dbox file age in days until it's rotated. Day always begins from

# midnight, so 1 = today, 2 = yesterday, etc. 0 = check disabled.

#dbox_rotate_days = 0

##

## IMAP specific settings

##

protocol imap {

# Login executable location.

#login_executable = /usr/libexec/dovecot/imap-login

# IMAP executable location. Changing this allows you to execute other

# binaries before the imap process is executed.

#

# This would write rawlogs into ~/dovecot.rawlog/ directory:

# mail_executable = /usr/libexec/dovecot/rawlog /usr/libexec/dovecot/imap

#

# This would attach gdb into the imap process and write backtraces into

# /tmp/gdbhelper.* files:

# mail_executable = /usr/libexec/dovecot/gdbhelper /usr/libexec/dovecot/imap

#

#mail_executable = /usr/libexec/dovecot/imap

# Maximum IMAP command line length in bytes. Some clients generate very long

# command lines with huge mailboxes, so you may need to raise this if you get

# "Too long argument" or "IMAP command line too large" errors often.

#imap_max_line_length = 65536


222

# Support for dynamically loadable plugins. mail_plugins is a space separated

# list of plugins to load.

#mail_plugins =

#mail_plugin_dir = /usr/lib/dovecot/imap

# Send IMAP capabilities in greeting message. This makes it unnecessary for

# clients to request it with CAPABILITY command, so it saves one round-trip.

# Many clients however don't understand it and ask the CAPABILITY anyway.

#login_greeting_capability = no

# Override the IMAP CAPABILITY response.

#imap_capability =

# Workarounds for various client bugs:

# delay-newmail:

# Send EXISTS/RECENT new mail notifications only when replying to NOOP

# and CHECK commands. Some clients ignore them otherwise, for example OSX

# Mail (<v2.1). Outlook Express breaks more badly though, without this it

# may show user "Message no longer in server" errors. Note that OE6 still

# breaks even with this workaround if synchronization is set to

# "Headers Only".

# outlook-idle:

# Outlook and Outlook Express never abort IDLE command, so if no mail

# arrives in half a hour, Dovecot closes the connection. This is still

# fine, except Outlook doesn't connect back so you don't see if new mail

# arrives.

# netscape-eoh:

# Netscape 4.x breaks if message headers don't end with the empty "end of

# headers" line. Normally all messages have this, but setting this


223

# workaround makes sure that Netscape never breaks by adding the line if

# it doesn't exist. This is done only for FETCH BODY[HEADER.FIELDS..]

# commands. Note that RFC says this shouldn't be done.

# tb-extra-mailbox-sep:

# With mbox storage a mailbox can contain either mails or submailboxes,

# but not both. Thunderbird separates these two by forcing server to

# accept '/' suffix in mailbox names in subscriptions list.

# The list is space-separated.

#imap_client_workarounds = outlook-idle

}

##

## POP3 specific settings

##

protocol pop3 {

# Login executable location.

#login_executable = /usr/libexec/dovecot/pop3-login

# POP3 executable location. See IMAP's mail_executable above for examples

# how this could be changed.

#mail_executable = /usr/libexec/dovecot/pop3

# Don't try to set mails non-recent or seen with POP3 sessions. This is

# mostly intended to reduce disk I/O. With maildir it doesn't move files

# from new/ to cur/, with mbox it doesn't write Status-header.

#pop3_no_flag_updates = no

# Support LAST command which exists in old POP3 specs, but has been removed

# from new ones. Some clients still wish to use this though. Enabling this

# makes RSET command clear all \Seen flags from messages.

#pop3_enable_last = no


224

# If mail has X-UIDL header, use it as the mail's UIDL.

#pop3_reuse_xuidl = no

# Keep the mailbox locked for the entire POP3 session.

#pop3_lock_session = no

# POP3 UIDL (unique mail identifier) format to use. You can use following

# variables:

#

# %v - Mailbox's IMAP UIDVALIDITY

# %u - Mail's IMAP UID

# %m - MD5 sum of the mailbox headers in hex (mbox only)

# %f - filename (maildir only)

#

# If you want UIDL compatibility with other POP3 servers, use:

# UW's ipop3d : %08Xv%08Xu

# Courier version 0 : %f

# Courier version 1 : %u

# Courier version 2 : %v-%u

# Cyrus (<= 2.1.3) : %u

# Cyrus (>= 2.1.4) : %v.%u

# Older Dovecots : %v.%u

# tpop3d : %Mf

#

# Note that Outlook 2003 seems to have problems with %v.%u format which was

# Dovecot's default, so if you're building a new server it would be a good

# idea to change this. %08Xu%08Xv should be pretty fail-safe.

#

# NOTE: Nowadays this is required to be set explicitly, since the old

# default was bad but it couldn't be changed without breaking existing

# installations. %08Xu%08Xv will be the new default, so use it for new

# installations.

#

#pop3_uidl_format = %08Xu%08Xv

# POP3 logout format string:


225

# %t - number of TOP commands

# %p - number of bytes sent to client as a result of TOP command

# %r - number of RETR commands

# %b - number of bytes sent to client as a result of RETR command

# %d - number of deleted messages

# %m - number of messages (before deletion)

# %s - mailbox size in bytes (before deletion)

#pop3_logout_format = top=%t/%p, retr=%r/%b, del=%d/%m, size=%s



#mail_plugins =

#mail_plugin_dir = /usr/lib/dovecot/pop3

# Workarounds for various client bugs:

# outlook-no-nuls:

# Outlook and Outlook Express hang if mails contain NUL characters.

# This setting replaces them with 0x80 character.

# oe-ns-eoh:

# Outlook Express and Netscape Mail breaks if end of headers-line is

# missing. This option simply sends it if it's missing.

# The list is space-separated.

#pop3_client_workarounds =

}

##

## LDA specific settings

##

protocol lda {

# Address to use when sending rejection mails.

postmaster_address = [email protected]

# Hostname to use in various parts of sent mails, eg. in Message-Id.

# Default is the system's real hostname.

#hostname =


226



#mail_plugins =

#mail_plugin_dir = /usr/lib/dovecot/lda

# Binary to use for sending mails.

#sendmail_path = /usr/lib/sendmail

# UNIX socket path to master authentication server to find users.

#auth_socket_path = /var/run/dovecot/auth-master

}

##

## Authentication processes

##

# Executable location

#auth_executable = /usr/libexec/dovecot/dovecot-auth

# Set max. process size in megabytes.

#auth_process_size = 256

# Authentication cache size in kilobytes. 0 means it's disabled.

# Note that bsdauth, PAM and vpopmail require cache_key to be set for caching

# to be used.

#auth_cache_size = 0

# Time to live in seconds for cached data. After this many seconds the cached

# record is no longer used, *except* if the main database lookup returns

# internal failure. We also try to handle password changes automatically: If

# user's previous authentication was successful, but this one wasn't, the

# cache isn't used. For now this works only with plaintext authentication.

#auth_cache_ttl = 3600


227

# Space separated list of realms for SASL authentication mechanisms that need

# them. You can leave it empty if you don't want to support multiple realms.

# Many clients simply use the first one listed here, so keep the default realm

# first.

#auth_realms =

# Default realm/domain to use if none was specified. This is used for both

# SASL realms and appending @domain to username in plaintext logins.

#auth_default_realm =

# List of allowed characters in username. If the user-given username contains

# a character not listed in here, the login automatically fails. This is just

# an extra check to make sure user can't exploit any potential quote escaping

# vulnerabilities with SQL/LDAP databases. If you want to allow all characters,

# set this value to empty.

#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@

# Username character translations before it's looked up from databases. The

# value contains series of from -> to characters. For example "#@/@" means

# that '#' and '/' characters are translated to '@'.

#auth_username_translation =

# Username formatting before it's looked up from databases. You can use

# the standard variables here, eg. %Lu would lowercase the username, %n would

# drop away the domain if it was given, or "%n-AT-%d" would change the '@' into

# "-AT-". This translation is done after auth_username_translation changes.

#auth_username_format =

# If you want to allow master users to log in by specifying the master


228

# username within the normal username string (ie. not using SASL mechanism's

# support for it), you can specify the separator character here. The format

# is then <username><separator><master username>. UW-IMAP uses "*" as the

# separator, so that could be a good choice.

#auth_master_user_separator =

# Username to use for users logging in with ANONYMOUS SASL mechanism

#auth_anonymous_username = anonymous

# More verbose logging. Useful for figuring out why authentication isn't

# working.

#auth_verbose = no

# Even more verbose logging for debugging purposes. Shows for example SQL

# queries.

#auth_debug = no

# In case of password mismatches, log the passwords and used scheme so the

# problem can be debugged. Requires auth_debug=yes to be set.

#auth_debug_passwords = no

# Maximum number of dovecot-auth worker processes. They're used to execute

# blocking passdb and userdb queries (eg. MySQL and PAM). They're

# automatically created and destroyed as needed.

#auth_worker_max_count = 30

# Host name to use in GSSAPI principal names. The default is to use the

# name returned by gethostname().

#auth_gssapi_hostname =

# Kerberos keytab to use for the GSSAPI mechanism. Will use the system

# default (usually /etc/krb5.keytab) if not specified.

#auth_krb5_keytab =


229

auth default {

# Space separated list of wanted authentication mechanisms:

# plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi

# NOTE: See also disable_plaintext_auth setting.

mechanisms = plain

#

# Password database is used to verify user's password (and nothing more).

# You can have multiple passdbs and userdbs. This is useful if you want to

# allow both system users (/etc/passwd) and virtual users to login without

# duplicating the system users into virtual database.

#

# <doc/wiki/PasswordDatabase.txt>

#

# By adding master=yes setting inside a passdb you make the passdb a list

# of "master users", who can log in as anyone else. Unless you're using PAM,

# you probably still want the destination user to be looked up from passdb

# that it really exists. This can be done by adding pass=yes setting to the

# master passdb. <doc/wiki/Authentication.MasterUsers.txt>

# Users can be temporarily disabled by adding a passdb with deny=yes.

# If the user is found from that database, authentication will fail.

# The deny passdb should always be specified before others, so it gets

# checked first. Here's an example:

#passdb passwd-file {

# File contains a list of usernames, one per line

#args = /etc/dovecot.deny

#deny = yes

#}

# PAM authentication. Preferred nowadays by most systems.

# Note that PAM can only be used to verify if user's password is correct,


230

# so it can't be used as userdb. If you don't want to use a separate user

# database (passwd usually), you can use static userdb.

# REMEMBER: You'll need /etc/pam.d/dovecot file created for PAM

# authentication to actually work. <doc/wiki/PasswordDatabase.PAM.txt>

passdb pam {

# [blocking=yes] [session=yes] [setcred=yes]

# [cache_key=<key>] [<service name>]

#

# By default a new process is forked from dovecot-auth for each PAM lookup.

# Setting blocking=yes uses the alternative way: dovecot-auth worker

# processes do the PAM lookups.

#

# session=yes makes Dovecot open and immediately close PAM session. Some

# PAM plugins need this to work, such as pam_mkhomedir.

#

# setcred=yes makes Dovecot establish PAM credentials if some PAM plugins

# need that. They aren't ever deleted though, so this isn't enabled by

# default.

#

# cache_key can be used to enable authentication caching for PAM

# (auth_cache_size also needs to be set). It isn't enabled by default

# because PAM modules can do all kinds of checks besides checking password,

# such as checking IP address. Dovecot can't know about these checks

# without some help. cache_key is simply a list of variables (see

# doc/wiki/Variables.txt) which must match for the cached data to be used.

# Here are some examples:

# %u - Username must match. Probably sufficient for most uses.

# %u%r - Username and remote IP address must match.

# %u%s - Username and service (ie. IMAP, POP3) must match.

#

# If service name is "*", it means the authenticating service name

# is used, eg. pop3 or imap (/etc/pam.d/pop3, /etc/pam.d/imap).

#


231

# Some examples:

# args = session=yes *

# args = cache_key=%u dovecot

#args = dovecot

}

# System users (NSS, /etc/passwd, or similiar)

# In many systems nowadays this uses Name Service Switch, which is

# configured in /etc/nsswitch.conf. <doc/wiki/AuthDatabase.Passwd.txt>

#passdb passwd {

# [blocking=yes] - See userdb passwd for explanation

#args =

#}

# Shadow passwords for system users (NSS, /etc/shadow or similiar).

# Deprecated by PAM nowadays.

# <doc/wiki/PasswordDatabase.Shadow.txt>

#passdb shadow {

# [blocking=yes] - See userdb passwd for explanation

#args =

#}

# PAM-like authentication for OpenBSD.

# <doc/wiki/PasswordDatabase.BSDAuth.txt>

#passdb bsdauth {

# [cache_key=<key>] - See cache_key in PAM for explanation.

#args =

#}

# passwd-like file with specified location

# <doc/wiki/AuthDatabase.PasswdFile.txt>

#passdb passwd-file {

# Path for passwd-file

#args =

#}


232

# checkpassword executable authentication

# NOTE: You will probably want to use "userdb prefetch" with this.

# <doc/wiki/PasswordDatabase.CheckPassword.txt>

#passdb checkpassword {

# Path for checkpassword binary

#args =

#}

# SQL database <doc/wiki/AuthDatabase.SQL.txt>

#passdb sql {

# Path for SQL configuration file, see doc/dovecot-sql-example.conf

#args =

#}

# LDAP database <doc/wiki/AuthDatabase.LDAP.txt>

#passdb ldap {

# Path for LDAP configuration file, see doc/dovecot-ldap-example.conf

#args =

#}

# vpopmail authentication <doc/wiki/AuthDatabase.VPopMail.txt>

#passdb vpopmail {

# [cache_key=<key>] - See cache_key in PAM for explanation.

#args =

#}

#

# User database specifies where mails are located and what user/group IDs

# own them. For single-UID configuration use "static".

#

# <doc/wiki/UserDatabase.txt>

#

# System users (NSS, /etc/passwd, or similiar). In many systems nowadays this

# uses Name Service Switch, which is configured in /etc/nsswitch.conf.


233

# <doc/wiki/AuthDatabase.Passwd.txt>

userdb passwd {

# [blocking=yes] - By default the lookups are done in the main dovecot-auth

# process. This setting causes the lookups to be done in auth worker

# proceses. Useful with remote NSS lookups that may block.

# NOTE: Be sure to use this setting with nss_ldap or users might get

# logged in as each others!

#args =

}

# passwd-like file with specified location

# <doc/wiki/AuthDatabase.PasswdFile.txt>

#userdb passwd-file {

# Path for passwd-file

#args =

#}

# static settings generated from template <doc/wiki/UserDatabase.Static.txt>

#userdb static {

# Template for the fields. Can return anything a userdb could normally

# return. For example:

#

# args = uid=500 gid=500 home=/var/mail/%u

#

# If you use deliver, it needs to look up users only from the userdb. This

# of course doesn't work with static because there is no list of users.

# Normally static userdb handles this by doing a passdb lookup. This works

# with most passdbs, with PAM being the most notable exception. If you do

# the user verification another way, you can add allow_all_users=yes to

# the args in which case the passdb lookup is skipped.

#

#args =

#}


234

# SQL database <doc/wiki/AuthDatabase.SQL.txt>

#userdb sql {

# Path for SQL configuration file, see doc/dovecot-sql-example.conf

#args =

#}

# LDAP database <doc/wiki/AuthDatabase.LDAP.txt>

#userdb ldap {

# Path for LDAP configuration file, see doc/dovecot-ldap-example.conf

#args =

#}

# vpopmail <doc/wiki/AuthDatabase.VPopMail.txt>

#userdb vpopmail {

#}

# "prefetch" user database means that the passdb already provided the

# needed information and there's no need to do a separate userdb lookup.

# This can be made to work with SQL and LDAP databases, see their example

# configuration files for more information how to do it.

# <doc/wiki/UserDatabase.Prefetch.txt>

#userdb prefetch {

#}

# User to use for the process. This user needs access to only user and

# password databases, nothing else. Only shadow and pam authentication

# requires roots, so use something else if possible. Note that passwd

# authentication with BSDs internally accesses shadow files, which also

# requires roots. Note that this user is NOT used to access mails.

# That user is specified by userdb above.

user = root

# Directory where to chroot the process. Most authentication backends don't

# work if this is set, and there's no point chrooting if auth_user is root.


235

# Note that valid_chroot_dirs isn't needed to use this setting.

#chroot =

# Number of authentication processes to create

#count = 1

# Require a valid SSL client certificate or the authentication fails.

#ssl_require_client_cert = no

# Take the username from client's SSL certificate, using

# X509_NAME_get_text_by_NID() which returns the subject's DN's

# CommonName.

#ssl_username_from_cert = no

# It's possible to export the authentication interface to other programs:

#socket listen {

#master {

# Master socket provides access to userdb information. It's typically

# used to give Dovecot's local delivery agent access to userdb so it

# can find mailbox locations.

#path = /var/run/dovecot/auth-master

#mode = 0600

# Default user/group is the one who started dovecot-auth (root)

#user =

#group =

#}

#client {

# The client socket is generally safe to export to everyone. Typical use

# is to export it to your SMTP server so it can do SMTP AUTH lookups

# using it.

#path = /var/run/dovecot/auth-client

#mode = 0660

#}

#}

}


236

# If you wish to use another authentication server than dovecot-auth, you can

# use connect sockets. They are assumed to be already running, Dovecot's master

# process only tries to connect to them. They don't need any other settings

# than the path for the master socket, as the configuration is done elsewhere.

# Note that the client sockets must exist in the login_dir.

#auth external {

# socket connect {

# master {

# path = /var/run/dovecot/auth-master

# }

# }

#}

##

## Dictionary server settings

##

# Dictionary can be used by some plugins to store key=value lists.

# Currently this is only used by dict quota backend. The dictionary can be

# used either directly or though a dictionary server. The following dict block

# maps dictionary names to URIs when the server is used. These can then be

# referenced using URIs in format "proxy:<name>".

dict {

#quota = mysql:/etc/dovecot-dict-quota.conf

}

##

## Plugin settings

##

plugin {

# Here you can give some extra environment variables to mail processes.


237

# This is mostly meant for passing parameters to plugins. %variable

# expansion is done for all values.

# Quota plugin. Multiple backends are supported:

# dirsize: Find and sum all the files found from mail directory.

# Extremely SLOW with Maildir. It'll eat your CPU and disk I/O.

# dict: Keep quota stored in dictionary (eg. SQL)

# maildir: Maildir++ quota

# fs: Read-only support for filesystem quota

#quota = maildir

# ACL plugin. vfile backend reads ACLs from "dovecot-acl" file from maildir

# directory. You can also optionally give a global ACL directory path where

# ACLs are applied to all users' mailboxes. The global ACL directory contains

# one file for each mailbox, eg. INBOX or sub.mailbox.

#acl = vfile:/etc/dovecot-acls

# Convert plugin. If set, specifies the source storage path which is

# converted to destination storage (mail_location) when the user logs in.

# The existing mail directory is renamed to <dir>-converted.

#convert_mail = mbox:%h/mail

# Skip mailboxes which we can't open successfully instead of aborting.

#convert_skip_broken_mailboxes = no

# Trash plugin. When saving a message would make user go over quota, this

# plugin automatically deletes the oldest mails from configured mailboxes

# until the message can be saved within quota limits. The configuration file

# is a text file where each line is in format: <priority> <mailbox name>

# Mails are first deleted in lowest -> highest priority number order

#trash = /etc/dovecot-trash.conf

# Lazy expunge plugin. Currently works only with maildirs. When a user

# expunges mails, the mails are moved to a mailbox in another namespace

# (1st). When a mailbox is deleted, the mailbox is moved to another


238

namespace

# (2nd) as well. Also if the deleted mailbox had any expunged messages,

# they're moved to a 3rd namespace. The mails won't be counted in quota,

# and they're not deleted automatically (use a cronjob or something).

#lazy_expunge = .EXPUNGED/ .DELETED/ .DELETED/.EXPUNGED/

}

De forma geral, é simples colocar o dovecot funcionando. Basta alterarmos as linhas acima marcadas e pronto, tudo está funcionando.


239

Capítulo 15 . Servidor WWW

Essa é uma etapa interessante. Para configurarmos o servidor apache, uma das primeiras coisas que devemos fazer é configurar a base de funcionamento deste servidor.

Nunca devemos esquecer de checar a tabela de roteamento e se o nosso servidor DNS está conseguindo resolver corretamente o endereço do servidor destinado ao serviço www. A configuração do servidor apache não requer um grande esforço, deste que saibamos exatamente o que queremos e como solicitar ao apache nossas necessidades.

Vamos analisar o arquivo de configuração.


240


241

InstalaçãoAntes de irmos ao arquivo de configuração, vamos entender como instalar o servidor

www.

Vamos começar pelo mais complexo, compilando os fontes do sistema.Para que possamos fazê-lo, devemos ter :

1. Os fontes do apache necessitam de aproximadamente 50 M de espaço em disco e após instalado, o sistema requer cerca de 10 M de espaço livre em disco.

2. Compilador ANSI-C, make e glibc

3. Baixar pacote do site do apache, isso pode ser feito com o comando #links http://http.apache.org/download.cgi, certifique-se de estar com a versão estável do programa.

O primeiro passo é descompactar do arquivo tarball.

Usaremos o comando #tar -zxvf httpd-versão.tar.gz para descompactar o pacote.

Acesse o diretório criado pelo processo de descompactação e siga as instruções abaixo.

#./configure

#make

#make install

Existe uma diferença considerável entre instalarmos o apache usando os pacotes .deb ou .rpm e compilando os fontes do sistema. Uma das mais notáveis está ligada a localização dos arquivos. No processo de compilação precisamos passar exatamente onde queremos que os arquivos sejam colocados, usando as opções do #./configure (para mais insformações a respeitos use o comando #./configure –help), caso contrário, todos os arquivos serão gravados em um subdiretório em /usr/local. Por padrão, os arquivos de configuração podem ser encontrados em /etc/httpd/conf/httpd.conf

Existe ainda a possibilidade de instalarmos os httpd através de seus pacotes .deb (padrão debian) e .rpm (padrão redhat).

Existem basicamente duas maneiras de instalação do servidor.

1. Usando os pacotes, sejam .deb ou rpm.

2. Compilando o sistema a partir dos fontes.

#apt-get install httpd

#yum install httpd

#rpm -ivh httpd*.rpm

#dpkg -i httpd*.deb

Caso queira instalá-lo a partir dos fontes, o processo básico estás descrito a seguir, porém, devemos observar alguns detalhes.

Pacote instalado, vamos a configuração do servidor.

#vim /etc/httpd/conf/httpd.conf


http://http.apache.org/download.cgi

242

### Section 1: Global Environment

ServerTokens OS

ServerRoot "/etc/httpd"

PidFile run/httpd.pid

Timeout 120

KeepAlive Off

MaxKeepAliveRequests 100

KeepAliveTimeout 15

<IfModule prefork.c>

StartServers 8

MinSpareServers 5

MaxSpareServers 20

ServerLimit 256

MaxClients 256

MaxRequestsPerChild 4000

</IfModule>

<IfModule worker.c>

StartServers 2

MaxClients 150

MinSpareThreads 25

MaxSpareThreads 75

ThreadsPerChild 25

MaxRequestsPerChild 0

</IfModule>

#Listen 12.34.56.78:80

Determine a porta que estará sendo usada pelo servidor.

Listen 80

Configure os módulos usados pelo servidor. Caso queiram trabalhar com o php. por exemplo, o módulos deverá constar aqui na lista do apache.

# LoadModule foo_module modules/mod_foo.so

LoadModule auth_basic_module modules/mod_auth_basic.so

LoadModule auth_digest_module modules/mod_auth_digest.so

LoadModule authn_file_module modules/mod_authn_file.so


243

LoadModule authn_alias_module modules/mod_authn_alias.so

LoadModule authn_anon_module modules/mod_authn_anon.so

LoadModule authn_dbm_module modules/mod_authn_dbm.so

LoadModule authn_default_module modules/mod_authn_default.so

LoadModule authz_host_module modules/mod_authz_host.so

LoadModule authz_user_module modules/mod_authz_user.so

LoadModule authz_owner_module modules/mod_authz_owner.so

LoadModule authz_groupfile_module modules/mod_authz_groupfile.so

LoadModule authz_dbm_module modules/mod_authz_dbm.so

LoadModule authz_default_module modules/mod_authz_default.so

LoadModule ldap_module modules/mod_ldap.so

LoadModule authnz_ldap_module modules/mod_authnz_ldap.so

LoadModule include_module modules/mod_include.so

LoadModule log_config_module modules/mod_log_config.so

LoadModule logio_module modules/mod_logio.so

LoadModule env_module modules/mod_env.so

LoadModule ext_filter_module modules/mod_ext_filter.so

LoadModule mime_magic_module modules/mod_mime_magic.so

LoadModule expires_module modules/mod_expires.so

LoadModule deflate_module modules/mod_deflate.so

LoadModule headers_module modules/mod_headers.so

LoadModule usertrack_module modules/mod_usertrack.so

LoadModule setenvif_module modules/mod_setenvif.so

LoadModule mime_module modules/mod_mime.so

LoadModule dav_module modules/mod_dav.so

LoadModule status_module modules/mod_status.so

LoadModule autoindex_module modules/mod_autoindex.so

LoadModule info_module modules/mod_info.so

LoadModule dav_fs_module modules/mod_dav_fs.so

LoadModule vhost_alias_module modules/mod_vhost_alias.so

LoadModule negotiation_module modules/mod_negotiation.so

LoadModule dir_module modules/mod_dir.so

LoadModule actions_module modules/mod_actions.so

LoadModule speling_module modules/mod_speling.so

LoadModule userdir_module modules/mod_userdir.so

LoadModule alias_module modules/mod_alias.so


244

LoadModule rewrite_module modules/mod_rewrite.so

LoadModule proxy_module modules/mod_proxy.so

LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

LoadModule proxy_ftp_module modules/mod_proxy_ftp.so

LoadModule proxy_http_module modules/mod_proxy_http.so

LoadModule proxy_connect_module modules/mod_proxy_connect.so

LoadModule cache_module modules/mod_cache.so

LoadModule suexec_module modules/mod_suexec.so

LoadModule disk_cache_module modules/mod_disk_cache.so

LoadModule file_cache_module modules/mod_file_cache.so

LoadModule mem_cache_module modules/mod_mem_cache.so

LoadModule cgi_module modules/mod_cgi.so

#LoadModule cern_meta_module modules/mod_cern_meta.so

#LoadModule asis_module modules/mod_asis.so

Include conf.d/*.conf

ExtendedStatus On

Determine o usuário e grupo responsáveis pelo serviço.

User apache

Group apache

Podemos configurar o comportamento do servidor, o mail do administrador, caso algo aconteça e este precise receber um mail, o uso do www definido pelo dns, e o local onde os arquivo deverão constar.

ServerAdmin root@localhost

ServerName www.example.com:80

UseCanonicalName Off

DocumentRoot "/var/www/html"

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

<Directory "/var/www/html">

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny


245

Allow from all

</Directory>

<IfModule mod_userdir.c>

UserDir disable

#UserDir public_html

</IfModule>

#<Directory /home/*/public_html>

# AllowOverride FileInfo AuthConfig Limit

# Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

# <Limit GET POST OPTIONS>

# Order allow,deny

# Allow from all

# </Limit>

# <LimitExcept GET POST OPTIONS>

# Order deny,allow

# Deny from all

# </LimitExcept>

#</Directory>

Aqui definimos por quais páginas iniciais o servidor deverá buscar.

DirectoryIndex index.html index.html.var index.php

AccessFileName .htaccess

<Files ~ "^\.ht">

Order allow,deny

Deny from all

</Files>

TypesConfig /etc/mime.types

DefaultType text/plain

<IfModule mod_mime_magic.c>

# MIMEMagicFile /usr/share/magic.mime

MIMEMagicFile conf/magic

</IfModule>

HostnameLookups Off

#EnableMMAP off

#EnableSendfile off


246

ErrorLog logs/error_log

LogLevel warn

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

LogFormat "%h %l %u %t \"%r\" %>s %b" common

LogFormat "%{Referer}i -> %U" referer

LogFormat "%{User-agent}i" agent

# "combinedio" includes actual counts of actual bytes received (%I) and sent (%O); this

# requires the mod_logio module to be loaded.

#LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio

#CustomLog logs/access_log common

#CustomLog logs/referer_log referer

#CustomLog logs/agent_log agent

CustomLog logs/access_log combined

ServerSignature On

Alias /icons/ "/var/www/icons/"

<Directory "/var/www/icons">

Options Indexes MultiViews

AllowOverride None

Order allow,deny

Allow from all

</Directory>

<IfModule mod_dav_fs.c>

# Location of the WebDAV lock database.

DAVLockDB /var/lib/dav/lockdb

</IfModule>

ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

<Directory "/var/www/cgi-bin">

AllowOverride None

Options None

Order allow,deny

Allow from all

</Directory>


247

IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) text/*

AddIconByType (IMG,/icons/image2.gif) image/*

AddIconByType (SND,/icons/sound2.gif) audio/*

AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe

AddIcon /icons/binhex.gif .hqx

AddIcon /icons/tar.gif .tar

AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv

AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip

AddIcon /icons/a.gif .ps .ai .eps

AddIcon /icons/layout.gif .html .shtml .htm .pdf

AddIcon /icons/text.gif .txt

AddIcon /icons/c.gif .c

AddIcon /icons/p.gif .pl .py

AddIcon /icons/f.gif .for

AddIcon /icons/dvi.gif .dvi

AddIcon /icons/uuencoded.gif .uu

AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl

AddIcon /icons/tex.gif .tex

AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..

AddIcon /icons/hand.right.gif README

AddIcon /icons/folder.gif ^^DIRECTORY^^

AddIcon /icons/blank.gif ^^BLANKICON^^

#

# DefaultIcon is which icon to show for files which do not have an icon

# explicitly set.

#

DefaultIcon /icons/unknown.gif

#


248

# AddDescription allows you to place a short description after a file in

# server-generated indexes. These are only displayed for FancyIndexed

# directories.

# Format: AddDescription "description" filename

#

#AddDescription "GZIP compressed document" .gz

#AddDescription "tar archive" .tar

#AddDescription "GZIP compressed tar archive" .tgz

#

# ReadmeName is the name of the README file the server will look for by

# default, and append to directory listings.

#

# HeaderName is the name of a file which should be prepended to

# directory indexes.

ReadmeName README.html

HeaderName HEADER.html

#

# IndexIgnore is a set of filenames which directory indexing should ignore

# and not include in the listing. Shell-style wildcarding is permitted.

#

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

#

# DefaultLanguage and AddLanguage allows you to specify the language of

# a document. You can then use content negotiation to give a browser a

# file in a language the user can understand.

#

# Specify a default language. This means that all data

# going out without a specific language tag (see below) will

# be marked with this one. You probably do NOT want to set

# this unless you are sure it is correct for all cases.

#

# * It is generally better to not mark a page as

# * being a certain language than marking it with the wrong


249

# * language!

#

# DefaultLanguage nl

#

# Note 1: The suffix does not have to be the same as the language

# keyword --- those with documents in Polish (whose net-standard

# language code is pl) may wish to use "AddLanguage pl .po" to

# avoid the ambiguity with the common suffix for perl scripts.

#

# Note 2: The example entries below illustrate that in some cases

# the two character 'Language' abbreviation is not identical to

# the two character 'Country' code for its country,

# E.g. 'Danmark/dk' versus 'Danish/da'.

#

# Note 3: In the case of 'ltz' we violate the RFC by using a three char

# specifier. There is 'work in progress' to fix this and get

# the reference data for rfc1766 cleaned up.

#

# Catalan (ca) - Croatian (hr) - Czech (cs) - Danish (da) - Dutch (nl)

# English (en) - Esperanto (eo) - Estonian (et) - French (fr) - German (de)

# Greek-Modern (el) - Hebrew (he) - Italian (it) - Japanese (ja)

# Korean (ko) - Luxembourgeois* (ltz) - Norwegian Nynorsk (nn)

# Norwegian (no) - Polish (pl) - Portugese (pt)

# Brazilian Portuguese (pt-BR) - Russian (ru) - Swedish (sv)

# Simplified Chinese (zh-CN) - Spanish (es) - Traditional Chinese (zh-TW)

#

AddLanguage ca .ca

AddLanguage cs .cz .cs

AddLanguage da .dk

AddLanguage de .de

AddLanguage el .el

AddLanguage en .en

AddLanguage eo .eo

AddLanguage es .es

AddLanguage et .et

AddLanguage fr .fr


250

AddLanguage he .he

AddLanguage hr .hr

AddLanguage it .it

AddLanguage ja .ja

AddLanguage ko .ko

AddLanguage ltz .ltz

AddLanguage nl .nl

AddLanguage nn .nn

AddLanguage no .no

AddLanguage pl .po

AddLanguage pt .pt

AddLanguage pt-BR .pt-br

AddLanguage ru .ru

AddLanguage sv .sv

AddLanguage zh-CN .zh-cn

AddLanguage zh-TW .zh-tw

#

# LanguagePriority allows you to give precedence to some languages

# in case of a tie during content negotiation.

#

# Just list the languages in decreasing order of preference. We have

# more or less alphabetized them here. You probably want to change this.

#

LanguagePriority en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt pt-BR ru sv zh-CN zh-TW

#

# ForceLanguagePriority allows you to serve a result page rather than

# MULTIPLE CHOICES (Prefer) [in case of a tie] or NOT ACCEPTABLE (Fallback)

# [in case no accepted languages matched the available variants]

#

ForceLanguagePriority Prefer Fallback

#

# Specify a default charset for all content served; this enables


251

# interpretation of all content as UTF-8 by default. To use the

# default browser choice (ISO-8859-1), or to allow the META tags

# in HTML content to override this choice, comment out this

# directive:

#

AddDefaultCharset UTF-8

#

# AddType allows you to add to or override the MIME configuration

# file mime.types for specific file types.

#

#AddType application/x-tar .tgz

#

# AddEncoding allows you to have certain browsers uncompress

# information on the fly. Note: Not all browsers support this.

# Despite the name similarity, the following Add* directives have nothing

# to do with the FancyIndexing customization directives above.

#

#AddEncoding x-compress .Z

#AddEncoding x-gzip .gz .tgz

# If the AddEncoding directives above are commented-out, then you

# probably should define those extensions to indicate media types:

#

AddType application/x-compress .Z

AddType application/x-gzip .gz .tgz

#

# AddHandler allows you to map certain file extensions to "handlers":

# actions unrelated to filetype. These can be either built into the server

# or added with the Action directive (see below)

#

# To use CGI scripts outside of ScriptAliased directories:

# (You will also need to add "ExecCGI" to the "Options" directive.)

#


252

#AddHandler cgi-script .cgi

#

# For files that include their own HTTP headers:

#

#AddHandler send-as-is asis

#

# For type maps (negotiated resources):

# (This is enabled by default to allow the Apache "It Worked" page

# to be distributed in multiple languages.)

#

AddHandler type-map var

#

# Filters allow you to process content before it is sent to the client.

#

# To parse .shtml files for server-side includes (SSI):

# (You will also need to add "Includes" to the "Options" directive.)

#

AddType text/html .shtml

AddOutputFilter INCLUDES .shtml

#

# Action lets you define media types that will execute a script whenever

# a matching file is called. This eliminates the need for repeated URL

# pathnames for oft-used CGI file processors.

# Format: Action media/type /cgi-script/location

# Format: Action handler-name /cgi-script/location

#

#

# Customizable error responses come in three flavors:

# 1) plain text 2) local redirects 3) external redirects

#

# Some examples:


253

#ErrorDocument 500 "The server made a boo boo."

#ErrorDocument 404 /missing.html

#ErrorDocument 404 "/cgi-bin/missing_handler.pl"

#ErrorDocument 402 http://www.example.com/subscription_info.html

#

#

# Putting this all together, we can internationalize error responses.

#

# We use Alias to redirect any /error/HTTP_<error>.html.var response to

# our collection of by-error message multi-language collections. We use

# includes to substitute the appropriate text.

#

# You can modify the messages' appearance without changing any of the

# default HTTP_<error>.html.var files by adding the line:

#

# Alias /error/include/ "/your/include/path/"

#

# which allows you to create your own set of files by starting with the

# /var/www/error/include/ files and

# copying them to /your/include/path/, even on a per-VirtualHost basis.

#

Alias /error/ "/var/www/error/"

<IfModule mod_negotiation.c>

<IfModule mod_include.c>

<Directory "/var/www/error">

AllowOverride None

Options IncludesNoExec

AddOutputFilter Includes html

AddHandler type-map var

Order allow,deny

Allow from all

LanguagePriority en es de fr

ForceLanguagePriority Prefer Fallback


254

</Directory>

# ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var

# ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var

# ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var

# ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var

# ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var

# ErrorDocument 408 /error/HTTP_REQUEST_TIME_OUT.html.var

# ErrorDocument 410 /error/HTTP_GONE.html.var

# ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var

# ErrorDocument 412 /error/HTTP_PRECONDITION_FAILED.html.var

# ErrorDocument 413 /error/HTTP_REQUEST_ENTITY_TOO_LARGE.html.var

# ErrorDocument 414 /error/HTTP_REQUEST_URI_TOO_LARGE.html.var

# ErrorDocument 415 /error/HTTP_UNSUPPORTED_MEDIA_TYPE.html.var

# ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var

# ErrorDocument 501 /error/HTTP_NOT_IMPLEMENTED.html.var

# ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var

# ErrorDocument 503 /error/HTTP_SERVICE_UNAVAILABLE.html.var

# ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var

</IfModule>

</IfModule>

#

# The following directives modify normal HTTP response behavior to

# handle known problems with browser implementations.

#

BrowserMatch "Mozilla/2" nokeepalive

BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0

BrowserMatch "RealPlayer 4\.0" force-response-1.0

BrowserMatch "Java/1\.0" force-response-1.0

BrowserMatch "JDK/1\.0" force-response-1.0

#

# The following directive disables redirects on non-GET requests for

# a directory that does not include the trailing slash. This fixes a


255

# problem with Microsoft WebFolders which does not appropriately handle

# redirects for folders with DAV methods.

# Same deal with Apple's DAV filesystem and Gnome VFS support for DAV.

#

BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully

BrowserMatch "MS FrontPage" redirect-carefully

BrowserMatch "^WebDrive" redirect-carefully

BrowserMatch "^WebDAVFS/1.[0123]" redirect-carefully

BrowserMatch "^gnome-vfs/1.0" redirect-carefully

BrowserMatch "^XML Spy" redirect-carefully

BrowserMatch "^Dreamweaver-WebDAV-SCM1" redirect-carefully

#

# Allow server status reports generated by mod_status,

# with the URL of http://server [email protected]

name/server-status

# Change the ".example.com" to match your domain to enable.

#

#<Location /server-status>

# SetHandler server-status

# Order deny,allow

# Deny from all

# Allow from .example.com

#</Location>

#

# Allow remote server configuration reports, with the URL of

# http://servername/server-info (requires that mod_info.c be loaded).

# Change the ".example.com" to match your domain to enable.

#

#<Location /server-info>

# SetHandler server-info

# Order deny,allow

# Deny from all


#</Location>


256

#

# Proxy Server directives. Uncomment the following lines to

# enable the proxy server:

#

#<IfModule mod_proxy.c>

#ProxyRequests On

#

#<Proxy *>

# Order deny,allow

# Deny from all


#</Proxy>

#

# Enable/disable the handling of HTTP/1.1 "Via:" headers.

# ("Full" adds the server version; "Block" removes all outgoing Via: headers)

# Set to one of: Off | On | Full | Block

#

#ProxyVia On

#

# To enable a cache of proxied content, uncomment the following lines.

# See http://httpd.apache.org/docs/2.2/mod/mod_cache.html for more details.

#

#<IfModule mod_disk_cache.c>

# CacheEnable disk /

# CacheRoot "/var/cache/mod_proxy"

#</IfModule>

#

#</IfModule>

# End of proxy directives.

### Section 3: Virtual Hosts


257

#

# VirtualHost: If you want to maintain multiple domains/hostnames on your

# machine you can setup VirtualHost containers for them. Most configurations

# use only name-based virtual hosts so the server doesn't need to worry about

# IP addresses. This is indicated by the asterisks in the directives below.

#

# Please see the documentation at

# <URL:http://httpd.apache.org/docs/2.2/vhosts/>

# for further details before you try to setup virtual hosts.

#

# You may use the command line option '-S' to verify your virtual host

# configuration.

#

# Use name-based virtual hosting.

#

#NameVirtualHost *:80

# NOTE: NameVirtualHost cannot be used without a port specifier

# (e.g. :80) if mod_ssl is being used, due to the nature of the

# SSL protocol.

#

#

# VirtualHost example:

# Almost any Apache directive may go into a VirtualHost container.

# The first VirtualHost section is used for requests without a known

# server name.

#

Um mesmo servidor pode conter mais de uma página de domínios diferentes. Para que possamos abrir ambos, devemos configurar o VirtualHost. Não esqueça que o direcionamento de mais de um domínio será feito pelo DNS.

<VirtualHost *:80>

ServerAdmin [email protected]

DocumentRoot /www/docs/dummy-host.example.com

ServerName dummy-host.example.com

ErrorLog logs/dummy-host.example.com-error_log


258

CustomLog logs/dummy-host.example.com-access_log common

</VirtualHost>

Definidas as configurações do servidor, tente acessar o mesmo através de um browser. Antes...

#/etc/rc.d/init.d/httpd restart

Agora podemos testar...

#lynx localhost

#lynx ip_servidor_apache


259

Capítulo 16 - Compartilhando arquivos no GNU/Linux

Sabemos que compartilhar arquivos no entre estações windows é simples e podemos ter acesso a esses compartilhamentos através de estações GNU/Linux. A pergunta é.. .como compartilharmos arquivos no GNU/Linux, para que outra estação GNU/Linux tenha acesso ?

É o que veremos nessa etapa.


260


261

Para compartilharmos arquivos no GNU/Linux, basta configurarmos o arquivo /etc/exports, o qual está relacionado com o serviço NFS – Network File System.

O grande questionamento existente hoje é... Quando se torna viável o compartilhamento de arquivos entre estações em uma rede, fora do padrão SMB?

Restringiremos o compartilhamento a estações GNU/Linux, estáções Windows não terão acesso ao arquivos.

Em um processo de instalação remota, troca de informações entre servidores, mecanismos de backup isso poderá ser muito útil.

O processo é simples, veja o exemplo do arquivo exports.

#vim /etc/exports

/aula base(rw) aluno(rw,no_root_squash)

/projects desenvolv*.local.domain(rw)

Carregue o serviço nfs (/etc/rc.d/init.d/nfs restart) e acesse via cliente montando a partição.

Para montarmos uma compartilhamento de outra estação GNU/Linux, usamos a linha

mount -t nfs <máquina>:<caminho remoto> <ponto de montagem>

#clayton@clayton ~]#mount -t nfs 192.162.4.21:/home /mnt/home


262


263

Capítulo 17 - Serviço OpenSSHServiço usado para acessos remotos aos sistema, o ssh é uma forma “segura” de

administração remota.

Sempre que pensarmos em ter qualquer tipo de acesso remoto ao sistema, garantir que o sistema não fique vulnerável é fundamental.

Usar recursos como o ssh é importante para que possamos desenvolver a administração do sistema com tranquilidade e é o que veremos nessa etapa.


264


265

Antes de mais nada, vamos pensar em instalar o ssh. Podemos usar os mecanismos tradicionais de instalação, usando pacotes deb ou rpm. Eles serão suficientes.

#rpm -ivh ssh

#yum-install ssh

#apt-get install ssh

Instalado, vamos configurar o serviço.

Os arquivos base de configuração do servidor ssh estão localizados em /etc/ssh/sshd_config.

# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file. See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented. Uncommented options change a

# default value.

#Port 22

#Protocol 2,1

Definiremos o protocolo que será usado para prover a comunicação. Sempre interessante usarmos o nível 2 para garantir um pouco menos de insegurança.

Protocol 2

#AddressFamily any

#ListenAddress 0.0.0.0

Definiremos na linha seguinte qual ou quais estações poderão se conectar com o servidor ssh.

#ListenAddress ::

# HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key


266

#KeyRegenerationInterval 1h

#ServerKeyBits 768

# Logging

# obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

SyslogFacility AUTHPRIV

#LogLevel INFO

# Authentication:

#LoginGraceTime 2m

Limitamos na linha seguinte a ação do login do root, ou liberamos o login de root.

PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

#RSAAuthentication yes

#PubkeyAuthentication yes

#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

# similar for protocol version 2

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no

PasswordAuthentication yes

# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

ChallengeResponseAuthentication no

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes


267

#KerberosTicketCleanup yes

#KerberosGetAFSToken no

# GSSAPI options

#GSSAPIAuthentication no

GSSAPIAuthentication yes

#GSSAPICleanupCredentials yes

GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication mechanism.

# Depending on your PAM configuration, this may bypass the setting of

# PasswordAuthentication, PermitEmptyPasswords, and

# "PermitRootLogin without-password". If you just want the PAM account and

# session checks to run without PAM authentication, then enable this but set

# ChallengeResponseAuthentication=no

#UsePAM no

UsePAM yes

# Accept locale-related environment variables

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES

AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT

AcceptEnv LC_IDENTIFICATION LC_ALL

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

X11Forwarding yes

#X11DisplayOffset 10

#X11UseLocalhost yes

#PrintMotd yes

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

#UsePrivilegeSeparation yes

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3


268

#ShowPatchLevel no

#UseDNS yes

#PidFile /var/run/sshd.pid

#MaxStartups 10

#PermitTunnel no

# no default banner path

#Banner /some/path

# override default of no subsystems

Subsystem sftp /usr/libexec/openssh/sftp-server

Configurado o serviço, acesse o serviço por outro sistema. Podemos ainda usar o scp, como no exemplo de sala.


269

Capítulo 18 - Referências Bibliográficaswww.samba.org

www.tldp.org

http://www.tldp.org/docs.html#howto

http://www.tldp.org/guides.html

http://www.tldp.org/docs.html#man

www.squid-cache.org

www.kernel.org

www.postfix.org

http://www.isc.org/index.pl?/sw/dhcp/

http://www.isc.org/sw/bind/arm94/

Advanced Bash-Scripting Guide, Mendel Cooper

Bash Guide for Beginners, Machtelt Garrels

The Linux Kernel Module Programming Guide, Peter Jay Salzman, Michael Burian, Ori Pomerantz

The Linux System Administrators' Guide,Lars Wirzenius, Joanna Oja, Stephen Stafford, and Alex Weeks

Linux Filesystem Hierarchy, Binh Nguyen

The Linux Network Administrator's Guide, Second Edition,Olaf Kirch and Terry Dawson

GNU/Linux Command-Line Tools Summary, Gareth Anderson

http://www.x.org/wiki/

Linux Shadow Password HOWTO, Michael H. Jackson


http://www.samba.org/

http://www.x.org/wiki/

http://www.tldp.org/docs.html#man

http://www.tldp.org/guides.html

http://www.tldp.org/docs.html#howto

http://www.tldp.org/

http://www.isc.org/sw/bind/arm94/

http://www.isc.org/index.pl?/sw/dhcp/

http://www.postfix.org/

http://www.kernel.org/

http://www.squid-cache.org/

Livro Formatado e Organizado Final LPG260-Pag182

Documents

Transcript of Livro Formatado e Organizado Final LPG260-Pag182